ویژگی‌ها

این صفحه حاوی اطلاعاتی در مورد ویژگی‌های رمزنگاری Android Keystore است که توسط پیاده‌سازی زیربنایی KeyMint (یا Keymaster) ارائه شده است.

اصول اولیه رمزنگاری

کی‌استور دسته‌های عملیات زیر را ارائه می‌دهد:

• ایجاد کلیدها، که منجر به ایجاد کلید خصوصی یا مخفی می‌شود که فقط در محیط امن قابل دسترسی است. کلاینت‌ها می‌توانند به روش‌های زیر کلید ایجاد کنند:
  • تولید کلید جدید
  • وارد کردن مواد کلیدی رمزگذاری نشده
  • وارد کردن مواد کلید رمزگذاری شده
• گواهی کلید: ایجاد کلید نامتقارن، گواهی‌ای ایجاد می‌کند که بخش کلید عمومی جفت کلید را در خود نگه می‌دارد. این گواهی به صورت اختیاری اطلاعاتی در مورد فراداده‌های کلید و وضعیت دستگاه را نیز در خود نگه می‌دارد که همگی توسط یک زنجیره کلید به یک ریشه مورد اعتماد امضا می‌شوند.
• عملیات رمزنگاری:
  • رمزگذاری و رمزگشایی متقارن (AES، 3DES)
  • رمزگشایی نامتقارن (RSA)
  • امضای نامتقارن (ECDSA، RSA)
  • امضا و تأیید متقارن (HMAC)
  • توافق کلید نامتقارن (ECDH)

توجه داشته باشید که Keystore و KeyMint عملیات کلید عمومی را برای کلیدهای نامتقارن انجام نمی‌دهند.

عناصر پروتکل، مانند هدف، حالت و فاصله‌گذاری، و همچنین محدودیت‌های کنترل دسترسی ، هنگام تولید یا وارد کردن کلیدها مشخص می‌شوند و به طور دائم به کلید متصل می‌شوند و تضمین می‌کنند که کلید به هیچ روش دیگری قابل استفاده نیست.

علاوه بر لیست بالا، یک سرویس دیگر نیز وجود دارد که پیاده‌سازی‌های KeyMint (که قبلاً Keymaster نام داشت) ارائه می‌دهند، اما به عنوان یک API در دسترس نیست: تولید اعداد تصادفی. این سرویس به صورت داخلی برای تولید کلیدها، بردارهای مقداردهی اولیه (IVها)، لایه‌گذاری تصادفی و سایر عناصر پروتکل‌های امن که به تصادفی بودن نیاز دارند، استفاده می‌شود.

عناصر اولیه ضروری

تمام پیاده‌سازی‌های KeyMint موارد زیر را ارائه می‌دهند:

• آر اس ای
  • پشتیبانی از کلیدهای 2048، 3072 و 4096 بیتی
  • پشتیبانی از توان عمومی F4 (2^16+1)
  • حالت‌های Padding برای امضای RSA:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • حالت‌های خلاصه برای امضای RSA:
    • SHA-256
  • حالت‌های لایه‌گذاری برای رمزگذاری/رمزگشایی RSA:
    • بدون پد
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • پشتیبانی از کلیدهای ۲۲۴، ۲۵۶، ۳۸۴ و ۵۲۱ بیتی، به ترتیب با استفاده از منحنی‌های NIST P-224، P-256، P-384 و P-521 پشتیبانی می‌شود.
  • حالت‌های خلاصه‌سازی برای ECDSA:
    • بدون خلاصه (منسوخ شده، در آینده حذف خواهد شد)
    • SHA-256
• AES
  • کلیدهای ۱۲۸ و ۲۵۶ بیتی پشتیبانی می‌شوند
  • CBC ، CTR، ECB و GCM. پیاده‌سازی GCM اجازه استفاده از تگ‌های کوچک‌تر از ۹۶ بیت یا طول‌های غیر از ۹۶ بیت را نمی‌دهد.
  • حالت‌های PaddingMode::NONE و PaddingMode::PKCS7 برای حالت‌های CBC و ECB پشتیبانی می‌شوند. بدون padding، رمزگذاری حالت CBC یا ECB در صورتی که ورودی مضربی از اندازه بلوک نباشد، با شکست مواجه می‌شود.
• HMAC SHA-256 ، با هر اندازه کلیدی تا حداقل ۳۲ بایت.

SHA1 و سایر اعضای خانواده SHA2 (SHA-224، SHA384 و SHA512) برای پیاده‌سازی‌های KeyMint اکیداً توصیه می‌شوند. در صورتی که پیاده‌سازی سخت‌افزاری KeyMint آنها را ارائه ندهد، Keystore آنها را به صورت نرم‌افزاری ارائه می‌دهد.

برخی از موارد اولیه نیز برای قابلیت همکاری با سایر سیستم‌ها توصیه می‌شوند:

• اندازه‌های کلید کوچک‌تر برای RSA
• نمایندگان عمومی دلخواه برای RSA

کنترل دسترسی کلید

کلیدهای سخت‌افزاری که هرگز نمی‌توان آنها را از دستگاه استخراج کرد، اگر مهاجم بتواند از آنها به دلخواه استفاده کند، امنیت زیادی را فراهم نمی‌کنند (هرچند که از کلیدهایی که می‌توان آنها را استخراج کرد، امن‌تر هستند). بنابراین، بسیار مهم است که Keystore کنترل‌های دسترسی را اعمال کند.

کنترل‌های دسترسی به عنوان یک "لیست مجوز" از جفت‌های برچسب/مقدار تعریف می‌شوند. برچسب‌های مجوز، اعداد صحیح ۳۲ بیتی هستند و مقادیر از انواع مختلفی می‌باشند. برخی از برچسب‌ها می‌توانند برای تعیین چندین مقدار تکرار شوند. اینکه آیا یک برچسب می‌تواند تکرار شود یا خیر، در رابط KeyMint HAL مشخص می‌شود. هنگامی که یک کلید ایجاد می‌شود، فراخوانی‌کننده یک لیست مجوز را مشخص می‌کند. پیاده‌سازی KeyMint که زیربنای Keystore است، لیست را تغییر می‌دهد تا برخی اطلاعات اضافی، مانند اینکه آیا کلید دارای حفاظت بازگشت به عقب است یا خیر، را مشخص کند و یک لیست مجوز "نهایی" را که در بلوک کلید برگشتی کدگذاری شده است، بازگرداند. در صورت تغییر لیست مجوز نهایی، هرگونه تلاشی برای استفاده از کلید برای هر عملیات رمزنگاری با شکست مواجه می‌شود.

برای Keymaster 2 و قبل از آن، مجموعه برچسب‌های ممکن در شمارش keymaster_authorization_tag_t تعریف شده و به طور دائم ثابت است (اگرچه می‌توان آن را گسترش داد). نام‌ها با پیشوند KM_TAG شروع می‌شدند. چهار بیت بالای شناسه‌های برچسب برای نشان دادن نوع استفاده می‌شوند.

مدیر کلید ۳ پیشوند KM_TAG را به Tag:: تغییر داد.

انواع احتمالی عبارتند از:

ENUM : مقادیر بسیاری از تگ‌ها در enumerations تعریف می‌شوند. برای مثال، مقادیر ممکن TAG::PURPOSE در enum keymaster_purpose_t تعریف شده‌اند.

ENUM_REP : همانند ENUM است، با این تفاوت که این تگ می‌تواند در یک لیست مجوز تکرار شود. تکرار نشان‌دهنده‌ی چندین مقدار مجاز است. برای مثال، یک کلید رمزگذاری احتمالاً دارای KeyPurpose::ENCRYPT و KeyPurpose::DECRYPT .

وقتی KeyMint یک کلید ایجاد می‌کند، فراخوانی‌کننده یک لیست مجوز برای کلید مشخص می‌کند. این لیست توسط Keystore و KeyMint اصلاح می‌شود تا محدودیت‌های بیشتری اضافه شود و پیاده‌سازی اساسی KeyMint، لیست مجوز نهایی را در keyblob برگردانده شده کدگذاری می‌کند. لیست مجوز کدگذاری شده به صورت رمزنگاری به keyblob متصل می‌شود، به طوری که هرگونه تلاشی برای تغییر لیست مجوز (از جمله مرتب‌سازی) منجر به یک keyblob نامعتبر می‌شود که نمی‌توان از آن برای عملیات رمزنگاری استفاده کرد.

اجرای سخت‌افزاری در مقابل اجرای نرم‌افزاری

همه پیاده‌سازی‌های سخت‌افزاری امن دارای ویژگی‌های یکسانی نیستند. برای پشتیبانی از رویکردهای متنوع، Keymaster بین اجرای کنترل دسترسی جهانی امن و غیر امن، یا به ترتیب اجرای سخت‌افزاری و نرم‌افزاری، تمایز قائل می‌شود.

این در API KeyMint با فیلد securityLevel از نوع KeyCharacteristics نمایش داده می‌شود. سخت‌افزار امن مسئول قرار دادن مجوزها در KeyCharacteristics با سطح امنیتی مناسب، بر اساس آنچه می‌تواند اعمال کند، است. این اطلاعات همچنین در سوابق تأیید برای کلیدهای نامتقارن نمایش داده می‌شود: ویژگی‌های کلیدی SecurityLevel::TRUSTED_ENVIRONMENT یا SecurityLevel::STRONGBOX در لیست hardwareEnforced ظاهر می‌شوند و ویژگی‌های SecurityLevel::SOFTWARE یا SecurityLevel::KEYSTORE در لیست softwareEnforced ظاهر می‌شوند.

برای مثال، محدودیت‌های مربوط به تاریخ و بازه زمانی که یک کلید می‌تواند مورد استفاده قرار گیرد، معمولاً توسط محیط امن اعمال نمی‌شوند، زیرا دسترسی قابل اعتمادی به اطلاعات تاریخ و زمان ندارند. در نتیجه، مجوزهایی مانند Tag::ORIGINATION_EXPIRE_DATETIME توسط Keystore در اندروید اعمال می‌شوند و دارای SecurityLevel::KEYSTORE خواهند بود.

برای اطلاعات بیشتر در مورد تعیین اینکه آیا کلیدها و مجوزهای آنها توسط سخت‌افزار پشتیبانی می‌شوند، به بخش تأیید کلید مراجعه کنید.

مجوزهای ساخت پیام رمزنگاری

تگ‌های زیر برای تعریف ویژگی‌های رمزنگاری عملیات با استفاده از کلید مرتبط استفاده می‌شوند:

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

تگ‌های زیر قابل تکرار هستند، به این معنی که می‌توان چندین مقدار را به یک کلید اختصاص داد:

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

مقدار مورد استفاده در زمان عملیات مشخص می‌شود.

هدف

کلیدها مجموعه‌ای از اهداف مرتبط دارند که به صورت یک یا چند ورودی مجوز با Tag::PURPOSE بیان می‌شوند، که نحوه استفاده از آنها را تعریف می‌کند. این اهداف در KeyPurpose.aidl تعریف شده‌اند.

توجه داشته باشید که برخی از ترکیبات مقادیر هدف، مشکلات امنیتی ایجاد می‌کنند. به عنوان مثال، یک کلید RSA که می‌تواند هم برای رمزگذاری و هم برای امضا استفاده شود، به مهاجمی که می‌تواند سیستم را متقاعد کند تا داده‌های دلخواه را رمزگشایی کند، اجازه می‌دهد تا امضاها را تولید کند.

واردات کلید

Keymaster فقط از خروجی گرفتن کلیدهای عمومی، با فرمت X.509، و از وارد کردن موارد زیر پشتیبانی می‌کند:

• جفت کلیدهای نامتقارن در قالب PKCS#8 کدگذاری شده با DER (بدون رمزگذاری مبتنی بر رمز عبور)
• کلیدهای متقارن به عنوان بایت‌های خام

برای اطمینان از اینکه کلیدهای وارد شده از کلیدهای تولید شده به صورت ایمن قابل تشخیص هستند، Tag::ORIGIN در لیست مجوز کلید مربوطه قرار می‌گیرد. برای مثال، اگر کلیدی در سخت‌افزار ایمن تولید شده باشد، Tag::ORIGIN با مقدار KeyOrigin::GENERATED در لیست hw_enforced از ویژگی‌های کلید یافت می‌شود، در حالی که کلیدی که به سخت‌افزار ایمن وارد شده است، مقدار KeyOrigin::IMPORTED دارد.

احراز هویت کاربر

پیاده‌سازی‌های امن KeyMint احراز هویت کاربر را پیاده‌سازی نمی‌کنند، بلکه به سایر برنامه‌های قابل اعتمادی که این کار را انجام می‌دهند وابسته هستند. برای رابط کاربری که این برنامه‌ها پیاده‌سازی می‌کنند، به صفحه Gatekeeper مراجعه کنید.

الزامات احراز هویت کاربر از طریق دو مجموعه برچسب مشخص می‌شود. مجموعه اول نشان می‌دهد که کدام روش‌های احراز هویت اجازه استفاده از کلید را می‌دهند:

• Tag::USER_SECURE_ID دارای یک مقدار عددی ۶۴ بیتی است که شناسه کاربری امنی را مشخص می‌کند که در یک توکن احراز هویت امن برای باز کردن قفل استفاده از کلید ارائه شده است. در صورت تکرار، اگر هر یک از مقادیر در یک توکن احراز هویت امن ارائه شده باشد، می‌توان از کلید استفاده کرد.

مجموعه دوم نشان می‌دهد که آیا و چه زمانی کاربر نیاز به احراز هویت دارد. اگر هیچ یک از این برچسب‌ها وجود نداشته باشد، اما Tag::USER_SECURE_ID وجود داشته باشد، احراز هویت برای هر بار استفاده از کلید لازم است.

• Tag::NO_AUTHENTICATION_REQUIRED نشان می‌دهد که هیچ احراز هویتی برای کاربر لازم نیست، اگرچه دسترسی به کلید همچنان محدود به برنامه‌ی مالک (و هر برنامه‌ای که به آن دسترسی می‌دهد) است.
• Tag::AUTH_TIMEOUT یک مقدار عددی است که بر حسب ثانیه مشخص می‌کند که احراز هویت کاربر برای تأیید استفاده از کلید چقدر باید تازه باشد. مهلت‌های زمانی بین راه‌اندازی مجدد سیستم (reboots) قرار نمی‌گیرند؛ پس از راه‌اندازی مجدد، همه احراز هویت‌ها نامعتبر می‌شوند. می‌توان این مهلت زمانی را روی یک مقدار بزرگ تنظیم کرد تا نشان دهد که احراز هویت یک بار در هر بوت مورد نیاز است (۲^۳۲ ثانیه معادل تقریباً ۱۳۶ سال است؛ احتمالاً دستگاه‌های اندروید بیشتر از این تعداد راه‌اندازی مجدد می‌شوند).

نیاز به یک دستگاه قفل نشده

کلیدهایی که دارای Tag::UNLOCKED_DEVICE_REQUIRED هستند، فقط زمانی قابل استفاده هستند که دستگاه قفل نباشد. برای جزئیات بیشتر به KeyProtection.Builder#setUnlockedDeviceRequired(boolean) مراجعه کنید.

UNLOCKED_DEVICE_REQUIRED توسط Keystore اعمال می‌شود، نه توسط KeyMint. با این حال، در اندروید ۱۲ و بالاتر، Keystore به صورت رمزنگاری از کلیدهای UNLOCKED_DEVICE_REQUIRED در حالی که دستگاه قفل است محافظت می‌کند تا اطمینان حاصل شود که در بیشتر موارد، حتی اگر Keystore در حالی که دستگاه قفل است به خطر بیفتد، نمی‌توان از آنها استفاده کرد.

تمام رمزنگاری‌ها و تولید اعداد تصادفی که در این بخش شرح داده شده‌اند، از BoringSSL استفاده می‌کنند، به جز مواردی که به صراحت به استفاده از KeyMint اشاره شده است. تمام رمزها به محض اینکه دیگر نیازی به آنها نباشد، صفر می‌شوند.

دستگاه قفل نشدهسوپر کلیدهای مورد نیاز

برای محافظت رمزنگاری‌شده از کلیدهای UNLOCKED_DEVICE_REQUIRED ، Keystore قبل از ذخیره آنها در پایگاه داده خود، آنها را "superencrypts" می‌کند. در صورت امکان، کلیدهای superencryption (super keys) را در حین قفل بودن دستگاه به گونه‌ای محافظت می‌کند که فقط با باز شدن موفقیت‌آمیز دستگاه قابل بازیابی باشند. (اصطلاح "superencryption" به این دلیل استفاده می‌شود که این لایه رمزگذاری علاوه بر لایه رمزگذاری که KeyMint از قبل برای همه کلیدها اعمال می‌کند، اعمال می‌شود.)

هر کاربر (از جمله پروفایل‌ها) دو کلید فوق العاده مرتبط با UNLOCKED_DEVICE_REQUIRED دارد:

• کلید فوق متقارن UnlockedDeviceRequired. این یک کلید AES‑256‑GCM است. این کلید، کلیدهای UNLOCKED_DEVICE_REQUIRED را که هنگام باز شدن قفل دستگاه برای کاربر وارد، تولید یا استفاده می‌شوند، رمزگذاری می‌کند.
• کلید فوق نامتقارن UnlockedDeviceRequired. این یک جفت کلید ECDH P‑521 است. این کلیدها، کلیدهای UNLOCKED_DEVICE_REQUIRED را که هنگام قفل بودن دستگاه برای کاربر وارد یا تولید می‌شوند، رمزگذاری می‌کند. برای جزئیات بیشتر، به بخش «ذخیره کلیدها هنگام قفل بودن دستگاه» مراجعه کنید.

تولید و محافظت از سوپر کلیدها

وقتی کاربری ایجاد می‌شود، Keystore سوپر کلیدهای UnlockedDeviceRequired کاربر را تولید کرده و آنها را در پایگاه داده خود ذخیره می‌کند، که (به طور غیرمستقیم) توسط رمز عبور مصنوعی کاربر رمزگذاری شده‌اند:

1. سرور سیستم، رمز عبور Keystore کاربر را از رمز عبور مصنوعی او با استفاده از SP800-108 KDF استخراج می‌کند.
2. سرور سیستم، رمز عبور Keystore کاربر را به Keystore ارسال می‌کند.
3. کی‌استور، سوپر کلیدهای کاربر را تولید می‌کند.
4. برای هر یک از کلیدهای فوق العاده کاربر:
   1. Keystore یک Salt تصادفی تولید می‌کند.
   2. کی‌استور یک کلید AES‑256‑GCM را از رمز عبور کی‌استور کاربر و سالت با استفاده از HKDF‑SHA256 استخراج می‌کند.
   3. کی‌استور بخش مخفی سوپرکلید را با استفاده از این کلید AES‑256‑GCM رمزگذاری می‌کند.
   4. کی‌استور، سوپر کلید رمزگذاری شده و سالت آن را در پایگاه داده خود ذخیره می‌کند. اگر کلید نامتقارن باشد، نیمه عمومی کلید نیز به صورت رمزگذاری نشده ذخیره می‌شود.

این رویه اجازه می‌دهد تا این کلیدهای فوق العاده زمانی که رمز عبور مصنوعی کاربر مشخص است، رمزگشایی شوند، مانند زمانی که پین، الگو یا رمز عبور صحیح کاربر وارد می‌شود.

Keystore همچنین این کلیدهای فوق العاده را در حافظه پنهان می‌کند و به آن اجازه می‌دهد تا روی کلیدهای UNLOCKED_DEVICE_REQUIRED کار کند. با این حال، سعی می‌کند بخش‌های مخفی این کلیدها را فقط در زمانی که دستگاه برای کاربر قفل نشده است، ذخیره کند. وقتی دستگاه برای کاربر قفل می‌شود، Keystore در صورت امکان، کپی ذخیره شده خود از بخش‌های مخفی این کلیدهای فوق العاده را صفر می‌کند. به طور خاص، وقتی دستگاه برای کاربر قفل می‌شود، Keystore یکی از سه سطح حفاظت را برای کلیدهای فوق العاده UnlockedDeviceRequired کاربر انتخاب و اعمال می‌کند:

• اگر کاربر فقط پین، الگو یا رمز عبور را فعال کرده باشد، Keystore بخش‌های مخفی کلیدهای فوق ذخیره‌سازی شده خود را صفر می‌کند. این باعث می‌شود کلیدهای فوق فقط از طریق کپی رمزگذاری شده در پایگاه داده قابل بازیابی باشند که فقط با معادل پین، الگو یا رمز عبور قابل رمزگشایی است.
• اگر کاربر فقط بیومتریک کلاس ۳ ("قوی") داشته باشد و پین، الگو یا رمز عبور را فعال کرده باشد، Keystore ترتیبی می‌دهد که سوپر کلیدها توسط هر یک از بیومتریک‌های کلاس ۳ ثبت‌شده کاربر (معمولاً اثر انگشت) قابل بازیابی باشند، به عنوان جایگزینی برای پین، الگو یا رمز عبور معادل. برای انجام این کار، یک کلید AES‑۲۵۶‑GCM جدید تولید می‌کند، بخش‌های مخفی سوپر کلیدها را با آن رمزگذاری می‌کند، کلید AES‑۲۵۶‑GCM را به عنوان یک کلید بیومتریک-محدود که نیاز به احراز هویت بیومتریک دارد که باید ظرف ۱۵ ثانیه گذشته با موفقیت انجام شده باشد، به KeyMint وارد می‌کند و کپی‌های متن ساده همه این کلیدها را صفر می‌کند.
• اگر کاربر یک بیومتریک کلاس ۱ ("راحتی") ، بیومتریک کلاس ۲ ("ضعیف") یا عامل اعتماد فعال برای باز کردن قفل فعال داشته باشد، Keystore کلیدهای فوق را به صورت متن ساده در حافظه پنهان نگه می‌دارد. در این حالت، امنیت رمزنگاری برای کلیدهای UNLOCKED_DEVICE_REQUIRED ارائه نمی‌شود. کاربران می‌توانند با فعال نکردن این روش‌های باز کردن قفل، از این جایگزین با امنیت کمتر جلوگیری کنند. رایج‌ترین روش‌های باز کردن قفل که در این دسته‌ها قرار می‌گیرند، باز کردن قفل با تشخیص چهره در بسیاری از دستگاه‌ها و باز کردن قفل با ساعت هوشمند جفت شده است.

وقتی دستگاه برای کاربر باز می‌شود، Keystore در صورت امکان سوپر کلیدهای UnlockedDeviceRequired کاربر را بازیابی می‌کند. برای باز کردن قفل معادل با پین، الگو یا رمز عبور، کپی این کلیدها را که در پایگاه داده ذخیره شده‌اند، رمزگشایی می‌کند. در غیر این صورت، بررسی می‌کند که آیا کپی از این کلیدها را که با یک کلید بیومتریک رمزگذاری شده است، ذخیره کرده است یا خیر، و در این صورت سعی در رمزگشایی آن می‌کند. این کار تنها در صورتی موفقیت‌آمیز است که کاربر در ۱۵ ثانیه گذشته با یک بیومتریک کلاس ۳، که توسط KeyMint (نه Keystore) اعمال می‌شود، با موفقیت احراز هویت شده باشد.

ذخیره کلیدها در حالی که دستگاه قفل است

کی‌استور به کاربران اجازه می‌دهد تا کلیدهای UNLOCKED_DEVICE_REQUIRED را در حالی که دستگاه قفل است، وارد و تولید کنند. این کی‌استور از یک طرح رمزگذاری ترکیبی استفاده می‌کند تا اطمینان حاصل شود که رمزگشایی آنها فقط زمانی امکان‌پذیر است که دستگاه بعداً قفل‌گشایی شود:

• رمزگذاری (وارد کردن یا تولید کلید UNLOCKED_DEVICE_REQUIRED در حالی که دستگاه قفل است):
  1. Keystore یک جفت کلید موقت جدید ECDH P‑521 تولید می‌کند.
  2. کی‌استور با انجام توافق کلید ECDH بین کلید خصوصی این جفت کلید موقت و نیمه عمومی کلید فوق‌العاده نامتقارن UnlockedDeviceRequired، یک راز مشترک ایجاد می‌کند.
  3. Keystore یک Salt تصادفی تولید می‌کند.
  4. کی‌استور با استفاده از HKDF‑SHA256، یک کلید AES‑256‑GCM را از رمز مشترک و salt استخراج می‌کند.
  5. کی‌استور، کلید UNLOCKED_DEVICE_REQUIRED را با استفاده از این کلید AES‑256‑GCM رمزگذاری می‌کند.
  6. کی‌استور، کلید رمزگذاری‌شده‌ی UNLOCKED_DEVICE_REQUIRED ، سالت و نیمه‌ی عمومی جفت کلید موقت را در پایگاه داده‌ی خود ذخیره می‌کند.
• رمزگشایی (با استفاده از کلید UNLOCKED_DEVICE_REQUIRED ایجاد شده در حالی که دستگاه قفل گشایی شده است):
  1. کی‌استور، کلید رمزگذاری‌شده‌ی UNLOCKED_DEVICE_REQUIRED ، سالت و نیمه‌ی عمومی جفت کلید موقت را از پایگاه داده‌ی خود بارگذاری می‌کند.
  2. Keystore با انجام توافق کلید ECDH بین نیمه عمومی جفت کلید موقت و نیمه خصوصی سوپر کلید نامتقارن UnlockedDeviceRequired، یک راز مشترک ایجاد می‌کند. کلید خصوصی به دلیل باز شدن قفل دستگاه در دسترس است.
  3. کی‌استور با استفاده از HKDF‑SHA256، یک کلید AES‑256‑GCM از رمز مشترک و salt استخراج می‌کند. این کلید AES‑256‑GCM همان کلیدی است که در طول رمزگذاری استخراج شده است.
  4. کی‌استور، کلید UNLOCKED_DEVICE_REQUIRED را با استفاده از کلید AES‑256‑GCM رمزگشایی می‌کند.
  5. Keystore کلید UNLOCKED_DEVICE_REQUIRED را با استفاده از کلید اصلی متقارن UnlockedDeviceRequired دوباره رمزگذاری می‌کند. این کار بر ویژگی‌های امنیتی کلید تأثیری نمی‌گذارد، اما امکان دسترسی سریع‌تر به آن را در آینده فراهم می‌کند.

این ویژگی به برنامه‌ها این امکان را می‌دهد که داده‌ها را در حالی که دستگاه قفل است ذخیره کنند، به طوری که فقط در صورت باز شدن قفل دستگاه بتوان آنها را رمزگشایی کرد. برای انجام این کار، برنامه‌ها باید این مراحل را دنبال کنند:

1. یک کلید AES‑256‑GCM خارج از Keystore ایجاد کنید.
2. داده‌ها را با استفاده از کلید AES‑256‑GCM رمزگذاری کنید.
3. کلید AES‑256‑GCM را با تنظیم محافظت کلید setUnlockedDeviceRequired(true) به Keystore وارد کنید.
4. کپی اصلی کلید را صفر کنید.

برای رمزگشایی داده‌ها در حالی که دستگاه قفل‌گشایی شده است، از کلیدی که به Keystore وارد شده است استفاده کنید.

اتصال کلاینت

اتصال کلاینت، یعنی مرتبط کردن یک کلید با یک برنامه کلاینت خاص، از طریق یک شناسه کلاینت اختیاری و برخی داده‌های کلاینت اختیاری (به ترتیب Tag::APPLICATION_ID و Tag::APPLICATION_DATA ) انجام می‌شود. Keystore با این مقادیر به عنوان حباب‌های مات رفتار می‌کند و فقط اطمینان حاصل می‌کند که حباب‌های مشابه ارائه شده در طول تولید/وارد کردن کلید برای هر استفاده ارائه می‌شوند و بایت به بایت یکسان هستند. داده‌های اتصال کلاینت توسط KeyMint بازگردانده نمی‌شود. فراخوانی‌کننده برای استفاده از کلید باید آن را بداند.

این ویژگی در معرض برنامه‌ها نیست.

انقضا

Keystore از محدود کردن استفاده از کلید بر اساس تاریخ پشتیبانی می‌کند. شروع اعتبار کلید و انقضای کلید می‌توانند با یک کلید مرتبط شوند و Keymaster در صورتی که تاریخ/زمان فعلی خارج از محدوده معتبر باشد، از انجام عملیات روی کلید خودداری می‌کند. محدوده اعتبار کلید با برچسب‌های Tag::ACTIVE_DATETIME ، Tag::ORIGINATION_EXPIRE_DATETIME و Tag::USAGE_EXPIRE_DATETIME مشخص می‌شود. تمایز بین "origination" و "usage" بر اساس این است که آیا کلید برای "origination" یک متن رمز/امضا/و غیره جدید استفاده می‌شود یا برای "استفاده" از یک متن رمز/امضا/و غیره موجود. توجه داشته باشید که این تمایز در معرض برنامه‌ها نیست.

Tag::ACTIVE_DATETIME ، Tag::ORIGINATION_EXPIRE_DATETIME و Tag::USAGE_EXPIRE_DATETIME اختیاری هستند. اگر این تگ‌ها وجود نداشته باشند، فرض بر این است که کلید مورد نظر همیشه می‌تواند برای رمزگشایی/تأیید پیام‌ها استفاده شود.

از آنجا که زمان ساعت دیواری توسط دنیای غیر امن ارائه می‌شود، برچسب‌های مربوط به انقضا در لیست اعمال‌شده توسط نرم‌افزار قرار دارند.

ریشه اتصال اعتماد

کی‌استور (Keystore) نیاز دارد که کلیدها به یک ریشه اعتماد (root of trust) متصل باشند، که یک رشته بیتی (bitstring) است که در هنگام راه‌اندازی، ترجیحاً توسط بوت‌لودر، در اختیار سخت‌افزار امن کی‌مینت (KeyMint) قرار می‌گیرد. این رشته بیتی به صورت رمزنگاری‌شده به هر کلیدی که توسط کی‌مینت مدیریت می‌شود، متصل است.

ریشه اعتماد شامل کلید عمومی مورد استفاده برای تأیید امضای روی تصویر بوت و وضعیت قفل دستگاه است. اگر کلید عمومی تغییر کند تا امکان استفاده از یک تصویر سیستم متفاوت فراهم شود یا اگر وضعیت قفل تغییر کند، هیچ یک از کلیدهای محافظت‌شده توسط KeyMint که توسط سیستم قبلی ایجاد شده‌اند قابل استفاده نیستند، مگر اینکه ریشه اعتماد قبلی بازیابی شود و سیستمی که توسط آن کلید امضا شده است، بوت شود. هدف، افزایش ارزش کنترل‌های دسترسی کلید توسط نرم‌افزار است، با غیرممکن کردن استفاده از کلیدهای KeyMint برای یک سیستم عامل نصب‌شده توسط مهاجم.

کلیدهای مستقل

برخی از سخت‌افزارهای امن KeyMint می‌توانند به جای کلید رمزگذاری شده، کلیدها را به صورت داخلی ذخیره کرده و دستگیره‌ها را برگردانند. یا ممکن است موارد دیگری وجود داشته باشد که در آنها کلیدها تا زمانی که یک جزء سیستم جهانی امن یا غیر امن دیگر در دسترس نباشد، قابل استفاده نباشند. KeyMint HAL به تماس‌گیرنده اجازه می‌دهد تا از طریق TAG::STANDALONE درخواست کند که یک کلید "مستقل" باشد، به این معنی که به هیچ منبعی غیر از blob و سیستم در حال اجرا KeyMint نیاز نیست. برچسب‌های مرتبط با یک کلید را می‌توان بررسی کرد تا مشخص شود که آیا یک کلید مستقل است یا خیر. در حال حاضر، فقط دو مقدار تعریف شده است:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

این ویژگی در معرض برنامه‌ها نیست.

سرعت

هنگام ایجاد، حداکثر سرعت استفاده را می‌توان با TAG::MIN_SECONDS_BETWEEN_OPS مشخص کرد. پیاده‌سازی‌های TrustZone در صورتی که عملیاتی کمتر از TAG::MIN_SECONDS_BETWEEN_OPS ثانیه قبل انجام شده باشد، از انجام عملیات رمزنگاری با آن کلید خودداری می‌کنند.

رویکرد ساده برای پیاده‌سازی محدودیت‌های سرعت، جدولی از شناسه‌های کلید و آخرین مهرهای زمانی استفاده است. این جدول اندازه محدودی دارد، اما حداقل ۱۶ ورودی را در خود جای می‌دهد. در صورتی که جدول پر شود و هیچ ورودی قابل به‌روزرسانی یا حذف نباشد، پیاده‌سازی‌های سخت‌افزاری ایمن «از کار می‌افتند» و ترجیح می‌دهند تمام عملیات کلید با محدودیت سرعت را تا زمان انقضای یکی از ورودی‌ها رد کنند. منقضی شدن همه ورودی‌ها پس از راه‌اندازی مجدد قابل قبول است.

همچنین می‌توان با استفاده از TAG::MAX_USES_PER_BOOT ، تعداد دفعات استفاده از کلیدها را در هر بوت به n بار محدود کرد. این کار نیز به یک جدول ردیابی نیاز دارد که حداقل چهار کلید را در خود جای دهد و همچنین از خرابی ایمن جلوگیری کند. توجه داشته باشید که برنامه‌ها نمی‌توانند کلیدهای محدود به هر بوت ایجاد کنند. این ویژگی از طریق Keystore در دسترس نیست و برای عملیات سیستم رزرو شده است.

این ویژگی در معرض برنامه‌ها نیست.

کاشت مجدد مولد اعداد تصادفی

از آنجا که سخت‌افزار امن، اعداد تصادفی برای مواد کلیدی و بردارهای اولیه‌سازی (IVها) تولید می‌کند، و از آنجا که مولدهای اعداد تصادفی سخت‌افزاری ممکن است همیشه کاملاً قابل اعتماد نباشند، KeyMint HAL رابطی را فراهم می‌کند تا به کلاینت اجازه دهد آنتروپی اضافی را ارائه دهد که با اعداد تصادفی تولید شده مخلوط می‌شود.

از یک مولد اعداد تصادفی سخت‌افزاری به عنوان منبع اولیه استفاده کنید. داده‌های اولیه ارائه شده از طریق API خارجی نمی‌تواند تنها منبع تصادفی بودن مورد استفاده برای تولید اعداد باشد. علاوه بر این، عملیات اختلاط مورد استفاده باید اطمینان حاصل کند که اگر هر یک از منابع اولیه غیرقابل پیش‌بینی باشند، خروجی تصادفی غیرقابل پیش‌بینی باشد.