ویژگی‌ها

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

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

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

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

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

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

موارد اولیه و حالت هایی که باید توسط اجرای KeyMint پشتیبانی شوند در مشخصات رابط IKeyMintDevice HAL توضیح داده شده اند.

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

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

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

کنترل های دسترسی به عنوان یک "لیست مجوز" از جفت های برچسب/مقدار تعریف می شوند. تگ های مجوز اعداد صحیح 32 بیتی هستند و مقادیر انواع مختلفی دارند. برخی از تگ ها را می توان برای تعیین چندین مقدار تکرار کرد. اینکه آیا یک برچسب می‌تواند تکرار شود یا خیر در رابط HAL KeyMint (که قبلاً Keymaster بود) مشخص شده است.

مقادیر تگ پشتیبانی شده در فایل Tag.aidl تعریف شده‌اند و هر کدام با یک TagType مرتبط هستند که نوع مقدار مرتبط (به عنوان مثال، عدد صحیح یا بایت) را نشان می‌دهد و اینکه آیا می‌توان آن را برای تعیین چندین مقدار پشتیبانی شده تکرار کرد یا خیر.

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

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

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

این در 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 که می تواند هم برای رمزگذاری و هم برای امضا استفاده شود، به مهاجمی اجازه می دهد تا سیستم را متقاعد کند که داده های دلخواه را برای تولید امضا رمزگشایی کند.

واردات کلید

KeyMint از واردات موارد زیر پشتیبانی می کند:

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

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

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

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