ویژگی‌ها

این صفحه حاوی اطلاعاتی درباره ویژگی های رمزنگاری Keystore در اندروید 6.0 و بالاتر است.

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

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

  • تولید کلید
  • واردات و صادرات کلیدهای نامتقارن (بدون بسته بندی کلید)
  • واردات کلیدهای متقارن خام (بدون بسته بندی کلید)
  • رمزگذاری و رمزگشایی نامتقارن با حالت های padding مناسب
  • امضا و تایید نامتقارن با حالت های هضم و لایه بندی مناسب
  • رمزگذاری و رمزگشایی متقارن در حالت های مناسب، از جمله حالت AEAD
  • تولید و تأیید کدهای تأیید اعتبار پیام متقارن

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

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

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

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

  • 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) به شدت برای پیاده سازی Keymaster توصیه می شوند. در صورتی که Keymaster سخت افزاری آنها را ارائه نکند، Keystore آنها را به صورت نرم افزاری ارائه می کند.

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

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

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

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

کنترل های دسترسی به عنوان یک "لیست مجوز" از جفت های برچسب/مقدار تعریف می شوند. تگ های مجوز اعداد صحیح 32 بیتی هستند و مقادیر انواع مختلفی دارند. برخی از تگ ها ممکن است برای تعیین چندین مقدار تکرار شوند. اینکه یک برچسب ممکن است تکرار شود یا خیر در مستندات آن برچسب مشخص شده است. هنگامی که یک کلید ایجاد می شود، تماس گیرنده یک لیست مجوز را مشخص می کند. پیاده‌سازی Keymaster زیربنای 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 .

UINT : اعداد صحیح بدون علامت 32 بیتی. مثال: TAG::KEY_SIZE

UINT_REP : مانند UINT ، با این تفاوت که ممکن است برچسب در لیست مجوزها تکرار شود. تکرار چندین مقدار مجاز را نشان می دهد.

ULONG : اعداد صحیح بدون علامت 64 بیتی. مثال: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : مانند ULONG است، با این تفاوت که ممکن است برچسب در لیست مجوزها تکرار شود. تکرار چندین مقدار مجاز را نشان می دهد.

DATE : مقادیر تاریخ/زمان، بیان شده به صورت میلی ثانیه از 1 ژانویه 1970. مثال: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : درست یا نادرست. یک برچسب از نوع BOOL در صورت عدم وجود برچسب "نادرست" و در صورت وجود "درست" در نظر گرفته می شود. مثال: TAG::ROLLBACK_RESISTANT

BIGNUM : اعداد صحیح با طول دلخواه، که به صورت آرایه بایتی به ترتیب بزرگ اندیان بیان می شوند. مثال: TAG::RSA_PUBLIC_EXPONENT

BYTES : دنباله ای از بایت ها. مثال: TAG::ROOT_OF_TRUST

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

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

تمامی پیاده سازی ها:

  • مطابقت دقیق (نه اجرا) همه مجوزها را اجرا کنید. فهرست‌های مجوز در حباب‌های کلیدی دقیقاً با مجوزهای بازگردانده شده در طول تولید کلید، از جمله سفارش، مطابقت دارند. هر گونه عدم تطابق باعث تشخیص خطا می شود.
  • مجوزهایی را که ارزشهای معنایی آنها اجرا می شود را اعلام کنید.

مکانیسم API برای اعلام مجوزهای سخت افزاری در ساختار keymaster_key_characteristics_t است. این فهرست مجوز را به دو فهرست فرعی تقسیم می‌کند، hw_enforced و sw_enforced . سخت افزار امن مسئول قرار دادن مقادیر مناسب در هر یک بر اساس آنچه که می تواند اعمال کند، است.

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

به عنوان مثال، پیاده سازی مبتنی بر TrustZone را در نظر بگیرید که از انقضای کلید پشتیبانی نمی کند. ممکن است همچنان کلیدی با تاریخ انقضا ایجاد شود. فهرست مجوز آن کلید شامل برچسب TAG::ORIGINATION_EXPIRE_DATETIME با تاریخ انقضا خواهد بود. درخواستی به Keystore برای ویژگی‌های کلیدی، این برچسب را در لیست sw_enforced پیدا می‌کند و سخت‌افزار امن، شرط انقضا را اجرا نمی‌کند. با این حال، تلاش برای استفاده از کلید پس از انقضا توسط Keystore رد خواهد شد.

اگر دستگاه با سخت‌افزار امنی ارتقا یابد که از انقضا پشتیبانی می‌کند، درخواست برای ویژگی‌های کلیدی، TAG::ORIGINATION_EXPIRE_DATETIME در فهرست hw_enforced پیدا می‌کند و تلاش برای استفاده از کلید پس از انقضا، حتی اگر ذخیره‌سازی کلید به نحوی واژگون یا دور زده شود، با شکست مواجه خواهد شد. .

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

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

از برچسب‌های زیر برای تعریف ویژگی‌های رمزنگاری عملیات با استفاده از کلید مرتبط استفاده می‌شود: TAG::ALGORITHM ، TAG::KEY_SIZE ، TAG::BLOCK_MODE ، TAG::PADDING ، TAG::CALLER_NONCE ، و TAG::DIGEST

TAG::PADDING ، TAG::DIGEST ، و PaddingMode::BLOCK_MODE قابل تکرار هستند، به این معنی که ممکن است چندین مقدار با یک کلید مرتبط شود و مقدار مورد استفاده در زمان عملیات مشخص شود.

هدف

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

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

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

واردات و صادرات

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

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

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

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

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

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

  • TAG::ALL_USERS نشان می‌دهد که کلید برای همه کاربران قابل استفاده است. در صورت وجود، TAG::USER_ID و TAG::USER_SECURE_ID وجود ندارند.
  • TAG::USER_ID دارای یک مقدار عددی است که شناسه کاربر مجاز را مشخص می کند. توجه داشته باشید که این شناسه کاربری اندروید (برای چند کاربره) است، نه UID برنامه، و فقط توسط نرم افزارهای غیر ایمن اعمال می شود. در صورت وجود، TAG::ALL_USERS حضور ندارد.
  • TAG::USER_SECURE_ID دارای یک مقدار عددی 64 بیتی است که شناسه کاربری ایمن را مشخص می‌کند که در یک نشانه احراز هویت امن برای باز کردن قفل استفاده از کلید ارائه شده است. در صورت تکرار، اگر هر یک از مقادیر در یک نشانه احراز هویت امن ارائه شده باشد، ممکن است از کلید استفاده شود.

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

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

نیاز به دستگاه آنلاک

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

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

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

هر کاربر (از جمله نمایه ها) دارای دو کلید فوق العاده مرتبط با 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 را به عنوان یک کلید بیومتریک به Keymaster وارد می کند که برای موفقیت آمیز بودن آن نیاز به احراز هویت بیومتریک دارد. 15 ثانیه آخر، و کپی متن ساده همه این کلیدها را صفر می کند.
  • اگر کاربر یک بیومتریک کلاس 1 («راحتی»)، بیومتریک کلاس 2 («ضعیف»)، یا عامل اعتماد بازگشایی قفل فعال را فعال کرده باشد، پس Keystore کلیدهای فوق‌العاده را به صورت متن ساده در حافظه پنهان نگه می‌دارد. در این مورد، امنیت رمزنگاری برای کلیدهای UNLOCKED_DEVICE_REQUIRED ارائه نمی شود. کاربران می توانند با فعال نکردن این روش های باز کردن قفل، از این بازگشت امن کمتر جلوگیری کنند. رایج‌ترین روش‌های باز کردن قفل که در این دسته‌ها قرار می‌گیرند، باز کردن قفل با چهره در بسیاری از دستگاه‌ها و باز کردن قفل با ساعت هوشمند جفتی است.

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

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

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

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

انقضاء

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 به کلیدها نیاز دارد که به یک ریشه اعتماد متصل شوند، که یک رشته بیتی است که در هنگام راه‌اندازی به سخت‌افزار ایمن Keymaster ارائه می‌شود، ترجیحاً توسط بوت‌لودر. این رشته بیت از نظر رمزنگاری به هر کلیدی که توسط Keymaster مدیریت می‌شود، متصل است.

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

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

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

  • 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) تولید می کند، و از آنجایی که مولدهای اعداد تصادفی سخت افزاری ممکن است همیشه کاملاً قابل اعتماد نباشند، Keymaster HAL رابطی را فراهم می کند تا به مشتری امکان ارائه آنتروپی اضافی را بدهد که در تصادفی مخلوط می شود. اعداد تولید شده

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

این ویژگی در معرض برنامه‌ها قرار نمی‌گیرد، اما توسط چارچوب استفاده می‌شود، که به طور منظم آنتروپی اضافی را که از یک نمونه جاوا SecureRandom بازیابی می‌شود، به سخت‌افزار امن ارائه می‌دهد.