ویژگی‌ها

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

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

Keystore دسته‌بندی عملیات زیر را ارائه می‌کند:

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

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

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

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

اولیه های ضروری

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

• RSA
  • پشتیبانی از کلیدهای 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
  • پشتیبانی از کلیدهای 224، 256، 384 و 521 بیتی به ترتیب با استفاده از منحنی های NIST P-224، P-256، P-384 و P-521 پشتیبانی می شود.
  • حالت های خلاصه برای ECDSA:
    • بدون خلاصه (منسوخ شده، در آینده حذف خواهد شد)
    • SHA-256
• AES
  • کلیدهای 128 و 256 بیتی پشتیبانی می شوند
  • CBC ، CTR، ECB، و GCM. پیاده سازی GCM اجازه استفاده از برچسب های کوچکتر از 96 بیت یا طول های غیر از 96 بیت را نمی دهد.
  • حالت‌های Padding PaddingMode::NONE و PaddingMode::PKCS7 برای حالت‌های CBC و ECB پشتیبانی می‌شود. اگر ورودی مضربی از اندازه بلوک نباشد، رمزگذاری حالت CBC یا ECB بدون لایه‌بندی انجام نمی‌شود.
• HMAC SHA-256 ، با هر اندازه کلید تا حداقل 32 بایت.

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

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

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

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

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

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

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

Keymaster 3 پیشوند KM_TAG را به Tag:: تغییر داد.

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

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

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

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

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

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

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

برای مثال، محدودیت‌های مربوط به فاصله زمانی و تاریخ زمانی که می‌توان از یک کلید استفاده کرد، معمولاً توسط محیط امن اعمال نمی‌شود، زیرا دسترسی قابل اعتمادی به اطلاعات تاریخ و زمان ندارد. در نتیجه، مجوزهایی مانند Tag::ORIGINATION_EXPIRE_DATETIME توسط Keystore در Android اعمال می‌شوند و دارای 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 است.

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

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

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

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

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

• Tag::NO_AUTHENTICATION_REQUIRED نشان می‌دهد که نیازی به احراز هویت کاربر نیست، اگرچه دسترسی به کلید همچنان محدود به برنامه مالک (و هر برنامه‌ای که به آن دسترسی می‌دهد) است.
• Tag::AUTH_TIMEOUT یک مقدار عددی است که در عرض چند ثانیه مشخص می‌کند که احراز هویت کاربر چقدر باید برای مجاز کردن استفاده از کلید تازه باشد. تایم اوت ها از راه اندازی مجدد عبور نمی کنند. پس از راه اندازی مجدد، همه احراز هویت باطل می شوند. زمان پایان را می توان روی مقدار زیادی تنظیم کرد تا نشان دهد که احراز هویت یک بار در هر بوت مورد نیاز است (2^32 ثانیه ~ 136 سال است؛ احتمالاً دستگاه های Android بیشتر از آن راه اندازی مجدد می شوند).

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

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

UNLOCKED_DEVICE_REQUIRED توسط Keystore اجرا می‌شود، نه توسط KeyMint. با این حال، در Android 12 و بالاتر، Keystore به صورت رمزنگاری از کلیدهای UNLOCKED_DEVICE_REQUIRED در حالی که دستگاه قفل است محافظت می‌کند تا اطمینان حاصل کند که در بیشتر موارد، حتی اگر Keystore در زمانی که دستگاه قفل است، قابل استفاده نباشد.

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

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

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

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

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

• اگر کاربر فقط پین، الگو یا رمز عبور را فعال کرده باشد، Keystore قسمت های مخفی کلیدهای فوق العاده ذخیره شده خود را صفر می کند. این باعث می‌شود که کلیدهای فوق‌العاده فقط از طریق کپی رمزگذاری شده در پایگاه داده قابل بازیابی باشند که فقط با پین، الگو یا رمز عبور رمزگشایی می‌شوند.
• اگر کاربر فقط بیومتریک کلاس 3 ("قوی") و پین، الگو یا رمز عبور را فعال کرده باشد، Keystore ترتیبی می دهد که کلیدهای فوق العاده با هر یک از بیومتریک های کلاس 3 ثبت نام شده کاربر (معمولا اثر انگشت) به عنوان جایگزینی برای پین، الگو، یا معادل رمز عبور قابل بازیابی باشند. برای انجام این کار، یک کلید AES-256-GCM جدید تولید می کند، قسمت های مخفی کلیدهای فوق العاده را با آن رمزگذاری می کند، کلید AES-256-GCM را به عنوان یک کلید بیومتریک به KeyMint وارد می کند که نیاز به احراز هویت بیومتریک دارد تا در 15 ثانیه آخر این کلیدهای همزمان صفر باشد.
• اگر کاربر یک بیومتریک کلاس 1 («راحتی»)، بیومتریک کلاس 2 («ضعیف»)، یا عامل اعتماد بازگشایی قفل فعال را فعال کرده باشد، پس Keystore کلیدهای فوق‌العاده را به صورت متن ساده در حافظه پنهان نگه می‌دارد. در این مورد، امنیت رمزنگاری برای کلیدهای UNLOCKED_DEVICE_REQUIRED ارائه نشده است. کاربران می توانند با فعال نکردن این روش های باز کردن قفل، از این بازگشت امن کمتر جلوگیری کنند. رایج‌ترین روش‌های باز کردن قفل که در این دسته‌ها قرار می‌گیرند، باز کردن قفل با چهره در بسیاری از دستگاه‌ها و باز کردن قفل با ساعت هوشمند جفتی است.

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

الزام آور مشتری

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

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

انقضا

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

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

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

ریشه اعتماد الزام آور است

Keystore به کلیدها نیاز دارد که به یک ریشه اعتماد متصل شوند، که یک رشته بیتی است که در هنگام راه‌اندازی به سخت‌افزار امن KeyMint ارائه می‌شود، ترجیحاً توسط بوت‌لودر. این رشته بیتی از نظر رمزنگاری به هر کلیدی که توسط KeyMint مدیریت می شود، متصل است.

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

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

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

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

سرعت

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

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

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

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

مولد اعداد تصادفی دوباره بذر

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

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