من یک KMS اساسی را بر اساس یک HSM ساده طراحی می کنم ، فقط به AES256 ، SHA256 ، PBKDF2 ، HMAC (و ترکیب هایی مانند AES256-HMAC-SHA256) دسترسی دارم.
سرپرست و کاربران سیستم دارای HSM شخصی هستند که کلیدها در آن ذخیره شده و مانند این کار می کند:
- مدیر یک کلید را در داخل HSM خود با PBKDF2 (نمک تصادفی و دانه های تصادفی) تولید می کند.
- HSM سرپرست کلید جدید را با استفاده از AES-256 با یک کلید متقارن متفاوت برای هر کاربر رمزگذاری می کند (کلید مورد استفاده برای بسته بندی کلید در مرحله اولیه سازی فیزیکی HSM کاربر ایجاد شده است) و آن را برای هر کاربر که به آن نیاز دارد همراه با ابرداده های کلیدی ارسال می کند. . کل بار payload (مقدار کلید رمزگذاری شده + ابرداده های کلید) بار دیگر با AES256 با کلید منحصر به فرد دیگر برای هر کاربر رمزگذاری می شود.
- مبلغ بار به کاربر می رسد که به لطف دو کلید متقارن که قبلاً با سرپرست به اشتراک گذاشته شده بودند (در طول HSM اولیه سازی فیزیکی) ، قادر است کلید و ابرداده درخواستی را بازیابی کند.
من در حال فکر کردن به یک رویکرد ممکن دیگر هستم که می تواند بهتر باشد اما من واقعاً در مورد آن مطمئن نیستم:
- مدیر یک راز مشترک را برای همه کاربران مشترک برقرار می کند. سیستم این راز در هر HSM متعلق به کاربران یا سرپرست ذخیره می شود.
- هنگامی که باید یک کلید تولید شود ، مدیر با استفاده از راز مشترک و یک نمک تصادفی آن را با PBKDF2 محاسبه می کند.
- هنگامی که باید یک کلید ارسال شود. برای هر کاربر ، فقط نمکی که توسط سرپرست استفاده شده است در واقع برای کاربر ارسال می شود. نمک ممکن است با یک کلید متقارن از قبل به اشتراک گذاشته شده رمزگذاری شود (مانند مثال بالا) و توسط هر کاربر به همراه راز مشترک برای تولید مجدد کلید استفاده می شود.
رویکرد اول دارای مشکلات زیر است: من باید مقدار اصلی کلید را ارسال کنید ، من باید دو رمزگذاری را انجام دهم ، HSM باید API را برای بازیابی از حافظه داخلی فلش خود مقدار واقعی یک کلید ارائه دهد (به صورت cleartext یا متن متن بسته به انتخاب تماس گیرنده ، می توان API نامید. فقط اگر سرپرست در HSM وارد شده باشد و در صورت ورود کاربر نمی توان تماس گرفت).
رویکرد دوم مشکلات زیر را دارد: راز برای همه کاربران مشترک است بنابراین اگر یک مهاجم راز یک را پیدا کند کاربر تنها ، او راز همه را پیدا می کند. HSM باید API را برای بازیابی رمز و راز از حافظه داخلی فلش خود ارائه دهد زیرا راز باید برای هر کاربر یکسان باشد ، حتی برای کاربرانی که هفته ها / ماه ها بعد به سیستم اضافه می شوند (دوباره این API قابل تماس است در صورتی که مدیر در HSM وارد شده است).
من فکر می کنم که رویکرد دوم ، در اصل ، می تواند بهتر باشد زیرا کلیدها واقعاً از طرف مدیر به کاربران ارسال نمی شوند. اما راز مشترک برای همه یک مشکل است ، علاوه بر این تصور می کنم اگر یک مهاجم مقدار نمک تصادفی را دریابد ، ممکن است به سادگی سعی کند تمام کلیدهای ممکن را با توجه به آن نمک با استفاده از PBKDF2 و تمام دانه های ممکن محاسبه کند (زیرا اجرای آن باز است. بنابراین او می داند که راز 32 بایت طولانی است و وی همچنین به کد PBKDF2 دسترسی دارد).
در نتیجه من فکر می کنم که در دنیای واقعی رویکرد اول ایمن تر است ، به شرط اینکه ورود به عنوان سرپرست HSM توسط پین بسیار پیچیده و احتمالاً توسط فاکتور دوم (یعنی اثر انگشت) محافظت می شود. موافقید؟ آیا فکر می کنم در مورد آسیب پذیری های دیگر در رویکرد من؟
