Keystore با پشتیبانی سخت افزار

با مجموعه‌ها، منظم بمانید ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.

در دسترس بودن یک محیط اجرایی قابل اعتماد در یک سیستم بر روی یک تراشه (SoC) فرصتی را برای دستگاه‌های Android فراهم می‌کند تا خدمات امنیتی قوی و سخت‌افزاری را برای سیستم‌عامل Android، خدمات پلت‌فرم و حتی برنامه‌های شخص ثالث ارائه کنند. برنامه‌نویسانی که به دنبال برنامه‌های افزودنی مخصوص Android هستند باید به android.security.keystore مراجعه کنند.

قبل از اندروید 6.0، اندروید یک API خدمات رمزنگاری ساده و سخت افزاری داشت که توسط نسخه های 0.2 و 0.3 لایه انتزاعی سخت افزار Keymaster (HAL) ارائه شده بود. Keystore عملیات امضای دیجیتال و تأیید، به علاوه تولید و واردات جفت کلید امضای نامتقارن را ارائه می‌کرد. این در حال حاضر بر روی بسیاری از دستگاه ها اجرا شده است، اما اهداف امنیتی بسیاری وجود دارد که به راحتی تنها با یک API امضا نمی توان به آنها دست یافت. Keystore در Android 6.0 API Keystore را گسترش داد تا طیف وسیع تری از قابلیت ها را ارائه دهد.

در Android 6.0، Keystore رمزنگاری های اولیه متقارن ، AES و HMAC و یک سیستم کنترل دسترسی برای کلیدهای سخت افزاری را اضافه کرد. کنترل های دسترسی در طول تولید کلید مشخص می شوند و برای طول عمر کلید اجرا می شوند. کلیدها فقط پس از احراز هویت کاربر و فقط برای اهداف مشخص یا با پارامترهای رمزنگاری مشخص قابل استفاده هستند محدود شوند. برای اطلاعات بیشتر، به صفحه برچسب های مجوز مراجعه کنید.

علاوه بر گسترش دامنه رمزنگاری اولیه، Keystore در Android 6.0 موارد زیر را اضافه کرد:

• یک طرح کنترل استفاده برای محدود کردن استفاده از کلید، برای کاهش خطر به خطر افتادن امنیت به دلیل استفاده نادرست از کلیدها
• یک طرح کنترل دسترسی برای فعال کردن محدودیت کلیدها برای کاربران مشخص، مشتریان، و محدوده زمانی تعریف شده

در اندروید 7.0، Keymaster 2 پشتیبانی از گواهی کلید و اتصال نسخه را اضافه کرد. تأیید کلید، گواهی‌های کلید عمومی را ارائه می‌کند که حاوی شرح مفصلی از کلید و کنترل‌های دسترسی آن است تا وجود کلید در سخت‌افزار امن و پیکربندی آن از راه دور قابل تأیید باشد.

Version binding کلیدها را به سیستم عامل و نسخه سطح وصله متصل می کند. این تضمین می کند که مهاجمی که ضعفی را در نسخه قدیمی سیستم یا نرم افزار TEE کشف می کند، نمی تواند دستگاه را به نسخه آسیب پذیر برگرداند و از کلیدهای ایجاد شده با نسخه جدیدتر استفاده کند. علاوه بر این، هنگامی که کلیدی با یک نسخه معین و سطح وصله روی دستگاهی استفاده می‌شود که به نسخه جدیدتر یا سطح وصله ارتقا یافته است، کلید قبل از اینکه بتوان از آن استفاده کرد ارتقا داده می‌شود و نسخه قبلی کلید باطل می‌شود. با ارتقای دستگاه، کلیدها همراه با دستگاه به جلو حرکت می‌کنند، اما هرگونه بازگشت دستگاه به نسخه قبلی باعث می‌شود کلیدها غیرقابل استفاده باشند.

در اندروید 8.0، Keymaster 3 از لایه انتزاعی سخت افزاری ساختار C قدیمی (HAL) به رابط C++ HAL که از تعریفی در زبان تعریف رابط سخت افزاری جدید (HIDL) ایجاد شده بود، انتقال یافت. به عنوان بخشی از تغییر، بسیاری از انواع آرگومان ها تغییر کردند، اگرچه انواع و روش ها مطابقت یک به یک با انواع قدیمی و روش های ساختار HAL دارند.

علاوه بر این ویرایش رابط، Android 8.0 ویژگی تأیید Keymaster 2 را برای پشتیبانی از تأیید شناسه گسترش داد. گواهی شناسه مکانیزم محدود و اختیاری را برای تأیید قوی شناسه های سخت افزاری مانند شماره سریال دستگاه، نام محصول و شناسه تلفن (IMEI / MEID) ارائه می دهد. برای پیاده سازی این افزوده، Android 8.0 طرح گواهی ASN.1 را برای افزودن گواهی ID تغییر داد. پیاده‌سازی‌های Keymaster باید راهی مطمئن برای بازیابی اقلام داده‌های مربوطه و همچنین تعریف مکانیزمی برای غیرفعال کردن ایمن و دائمی این ویژگی پیدا کنند.

در اندروید 9، به روز رسانی ها شامل:

• به روز رسانی به Keymaster 4
• پشتیبانی از عناصر امن جاسازی شده
• پشتیبانی از واردات کلید امن
• پشتیبانی از رمزگذاری 3DES
• تغییرات در binding نسخه به طوری که boot.img و system.img به طور جداگانه نسخه هایی را تنظیم کرده اند تا امکان به روز رسانی مستقل را فراهم کنند.

واژه نامه

در اینجا یک مرور سریع از اجزای Keystore و روابط آنها ارائه شده است.

AndroidKeystore API و جزء Android Framework است که توسط برنامه ها برای دسترسی به عملکرد Keystore استفاده می شود. این به عنوان یک افزونه برای APIهای استاندارد معماری رمزنگاری جاوا پیاده سازی شده است و از کد جاوا تشکیل شده است که در فضای فرآیند خود برنامه اجرا می شود. AndroidKeystore درخواست‌های برنامه برای رفتار Keystore را با ارسال آن‌ها به شبح keystore برآورده می‌کند.

شبح کیستور یک شبح سیستم اندرویدی است که دسترسی به تمام عملکردهای کیستور را با یک API بایندر فراهم می کند. مسئول ذخیره کردن «حباب‌های کلید» است که حاوی مواد کلید مخفی واقعی است، به طوری که Keystore بتواند آنها را ذخیره کند اما از آنها استفاده یا فاش نکند.

keymasterd یک سرور HIDL است که دسترسی به Keymaster TA را فراهم می کند. (این نام استاندارد نیست و برای اهداف مفهومی است.)

Keymaster TA (برنامه مورد اعتماد) نرم‌افزاری است که در یک زمینه امن اجرا می‌شود، اغلب در TrustZone روی یک SoC ARM، که تمام عملیات Keystore امن را فراهم می‌کند، به مواد کلید خام دسترسی دارد، تمام شرایط کنترل دسترسی کلیدها را تأیید می‌کند و غیره.

LockSettingsService جزء سیستم اندروید است که مسئول احراز هویت کاربر، رمز عبور و اثر انگشت است. این بخشی از Keystore نیست، اما مرتبط است زیرا بسیاری از عملیات کلید Keystore نیاز به احراز هویت کاربر دارند. LockSettingsService با Gatekeeper TA و Fingerprint TA تعامل می‌کند تا توکن‌های احراز هویت را به دست آورد، که آن‌ها را به شبح فروشگاه کلید می‌دهد و در نهایت توسط برنامه Keymaster TA مصرف می‌شود.

Gatekeeper TA (برنامه مورد اعتماد) مؤلفه دیگری است که در زمینه امن اجرا می شود و مسئول احراز هویت رمزهای عبور کاربر و تولید نشانه های احراز هویت است که برای اثبات به Keymaster TA استفاده می شود که احراز هویت برای یک کاربر خاص در یک مقطع زمانی خاص انجام شده است.

اثر انگشت TA (برنامه مورد اعتماد) مؤلفه دیگری است که در زمینه امن اجرا می شود و مسئول احراز هویت اثر انگشت کاربر و تولید نشانه های احراز هویت است که برای اثبات به Keymaster TA استفاده می شود که احراز هویت برای یک کاربر خاص در یک مقطع زمانی خاص انجام شده است.

معماری

Android Keystore API و Keymaster HAL زیربنایی، مجموعه‌ای اساسی اما کافی از رمزنگاری‌های اولیه را فراهم می‌کنند تا امکان اجرای پروتکل‌ها با استفاده از کلیدهای کنترل‌شده با دسترسی سخت‌افزاری را فراهم کنند.

Keymaster HAL یک کتابخانه OEM با قابلیت بارگذاری پویا است که توسط سرویس Keystore برای ارائه خدمات رمزنگاری سخت افزاری استفاده می شود. برای حفظ امنیت، پیاده سازی های HAL هیچ عملیات حساسی را در فضای کاربر یا حتی در فضای هسته انجام نمی دهند. عملیات حساس به یک پردازنده ایمن واگذار می شود که از طریق برخی از رابط های هسته قابل دسترسی است. معماری حاصل به این صورت است:

شکل 1. دسترسی به Keymaster

در یک دستگاه Android، "کلینت" Keymaster HAL از چندین لایه (به عنوان مثال، برنامه، فریمورک، شبح Keystore) تشکیل شده است، اما برای اهداف این سند می توان از آن چشم پوشی کرد. این بدان معنی است که Keymaster HAL API در سطح پایینی است، توسط مؤلفه‌های داخلی پلتفرم استفاده می‌شود و در معرض توسعه‌دهندگان برنامه قرار نمی‌گیرد. API سطح بالاتر در سایت توسعه دهنده Android توضیح داده شده است.

هدف Keymaster HAL پیاده‌سازی الگوریتم‌های حساس به امنیت نیست، بلکه فقط مارشال و حذف درخواست‌ها به دنیای امن است. قالب سیم پیاده سازی شده است.

سازگاری با نسخه های قبلی

Keymaster 1 HAL کاملاً با HAL های منتشر شده قبلی، به عنوان مثال، Keymaster 0.2 و 0.3 ناسازگار است. برای تسهیل قابلیت همکاری در دستگاه‌های دارای Android نسخه 5.0 و نسخه‌های قدیمی‌تر که با Keymaster HAL‌های قدیمی‌تر راه‌اندازی شده‌اند، Keystore آداپتوری ارائه می‌کند که Keymaster 1 HAL را با فراخوانی به کتابخانه سخت‌افزار موجود پیاده‌سازی می‌کند. نتیجه نمی تواند طیف کاملی از عملکردها را در Keymaster 1 HAL ارائه دهد. به طور خاص، فقط از الگوریتم‌های RSA و ECDSA پشتیبانی می‌کند و تمام اجرای مجوزهای کلیدی توسط آداپتور در دنیای غیر ایمن انجام می‌شود.

Keymaster 2 رابط HAL را با حذف متدهای get_supported_* ساده‌تر کرد و به متد finish() اجازه داد ورودی را بپذیرد. این باعث کاهش تعداد رفت و برگشت به TEE در مواردی می شود که ورودی به یکباره در دسترس است و اجرای رمزگشایی AEAD را ساده می کند.

در اندروید 8.0، Keymaster 3 از ساختار قدیمی HAL به رابط C++ HAL که از تعریفی در زبان تعریف رابط سخت افزاری جدید (HIDL) ایجاد شده بود، انتقال یافت. یک پیاده سازی HAL به سبک جدید با زیرکلاس بندی کلاس IKeymasterDevice تولید شده و پیاده سازی روش های مجازی خالص ایجاد می شود. به عنوان بخشی از تغییر، بسیاری از انواع آرگومان ها تغییر کرده اند، اگرچه انواع و روش ها مطابقت یک به یک با انواع قدیمی و روش های ساختار HAL دارند.

نمای کلی HIDL

زبان تعریف رابط سخت افزاری (HIDL) مکانیزمی مستقل از زبان پیاده سازی برای تعیین رابط های سخت افزاری ارائه می دهد. ابزار HIDL در حال حاضر از تولید رابط های C++ و جاوا پشتیبانی می کند. ما انتظار داریم که اکثر پیاده‌سازهای Trusted Execution Environment (TEE) ابزار C++ را راحت‌تر بیابند، بنابراین این صفحه فقط نمایش C++ را مورد بحث قرار می‌دهد.

رابط های HIDL شامل مجموعه ای از روش ها هستند که به صورت زیر بیان می شوند:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

انواع مختلفی از پیش تعریف شده وجود دارد، و HAL ها می توانند انواع جدید برشماری و ساختاری را تعریف کنند. برای جزئیات بیشتر در مورد HIDL، به بخش مرجع مراجعه کنید.

یک روش مثال از Keymaster 3 IKeymasterDevice.hal این است:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

این معادل موارد زیر از keymaster2 HAL است:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

در نسخه HIDL، آرگومان dev حذف می شود، زیرا ضمنی است. آرگومان params دیگر ساختاری نیست که حاوی اشاره‌گری است که به آرایه‌ای از اشیاء key_parameter_t ارجاع می‌دهد، بلکه یک vec (بردار) حاوی اشیاء KeyParameter است. مقادیر بازگشتی در بند " generates " فهرست شده اند، از جمله بردار مقادیر uint8_t برای حباب کلید.

روش مجازی C++ تولید شده توسط کامپایلر HIDL به شرح زیر است:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

جایی که generateKey_cb یک اشاره گر تابعی است که به صورت زیر تعریف می شود:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

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

برای مثال دقیق، اجرای پیش‌فرض را در hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp ببینید. پیاده‌سازی پیش‌فرض برای دستگاه‌هایی با keymaster0، keymaster1 یا keymaster2 HALS به سبک قدیمی، سازگاری به عقب را فراهم می‌کند.

کنترل دسترسی

اساسی ترین قانون کنترل دسترسی Keystore این است که هر برنامه فضای نام خاص خود را دارد. اما برای هر قانون یک استثنا وجود دارد. Keystore دارای نقشه های سخت کدگذاری شده ای است که به اجزای سیستم خاص اجازه می دهد به برخی از فضاهای نام دیگر دسترسی داشته باشند. این ابزار بسیار صریح است زیرا به یک جزء کنترل کامل بر فضای نام دیگر می دهد. و سپس موضوع اجزای فروشنده به عنوان مشتریان Keystore وجود دارد. ما در حال حاضر راهی برای ایجاد فضای نام برای اجزای فروشنده، به عنوان مثال، درخواست کننده WPA نداریم.

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

دامنه های فروشگاه کلید

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

ما پنج پارامتر دامنه را معرفی می کنیم که نحوه دسترسی به کلیدها را کنترل می کند. آنها معنای پارامتر فضای نام توصیفگر کلید و نحوه کنترل دسترسی را کنترل می کنند.

• DOMAIN_APP : دامنه برنامه رفتار قدیمی را پوشش می دهد. Java Keystore SPI به طور پیش فرض از این دامنه استفاده می کند. وقتی از این دامنه استفاده می شود، آرگومان فضای نام نادیده گرفته می شود و به جای آن از UID تماس گیرنده استفاده می شود. دسترسی به این دامنه توسط برچسب Keystore به کلاس keystore_key در خط مشی SELinux کنترل می شود.
• DOMAIN_SELINUX : این دامنه نشان می دهد که فضای نام دارای یک برچسب در خط مشی SELinux است. پارامتر فضای نام جستجو می شود و به یک زمینه هدف ترجمه می شود و یک بررسی مجوز برای متن فراخوانی SELinux برای کلاس keystore_key انجام می شود. هنگامی که مجوز برای عملیات داده شده ایجاد شد، تاپل کامل برای جستجوی کلید استفاده می شود.
• DOMAIN_GRANT : دامنه اعطایی نشان می دهد که پارامتر فضای نام یک شناسه گرنت است. پارامتر مستعار نادیده گرفته می شود. بررسی های SELinux زمانی انجام می شود که کمک هزینه ایجاد شود. کنترل دسترسی بیشتر فقط بررسی می کند که آیا UID تماس گیرنده با UID دریافت کنندگان کمک هزینه درخواستی مطابقت دارد یا خیر.
• DOMAIN_KEY_ID : این دامنه نشان می دهد که پارامتر فضای نام یک شناسه کلید منحصر به فرد است. ممکن است خود کلید با DOMAIN_APP یا DOMAIN_SELINUX ایجاد شده باشد. بررسی مجوز پس از بارگیری domain و فضای namespace از پایگاه داده کلید انجام می شود، به همان روشی که گویی حباب توسط دامنه، فضای نام و نام مستعار بارگذاری شده است. منطق دامنه شناسه کلید تداوم است. هنگام دسترسی به یک کلید با نام مستعار، تماس‌های بعدی می‌توانند روی کلیدهای مختلف عمل کنند، زیرا ممکن است یک کلید جدید تولید یا وارد شده باشد و به این نام مستعار متصل شده باشد. با این حال، شناسه کلید هرگز تغییر نمی کند. بنابراین هنگام استفاده از شناسه کلید به کلید پس از بارگیری آن از پایگاه داده Keystore با استفاده از نام مستعار، می توان مطمئن بود که تا زمانی که شناسه کلید هنوز وجود دارد، همان کلید است. این عملکرد در معرض توسعه‌دهندگان برنامه نیست. در عوض، از آن در Android Keystore SPI استفاده می‌شود تا تجربه‌ای ثابت‌تر را ارائه دهد، حتی زمانی که به طور همزمان به روشی ناامن استفاده می‌شود.
• DOMAIN_BLOB : دامنه blob نشان می دهد که تماس گیرنده به تنهایی لکه را مدیریت می کند. این برای کلاینت هایی استفاده می شود که باید قبل از نصب پارتیشن داده به Keystore دسترسی داشته باشند. حباب کلید در قسمت blob توصیفگر کلید گنجانده شده است.

با استفاده از دامنه SELinux، می‌توانیم به اجزای فروشنده دسترسی به فضاهای نام بسیار خاص Keystore را بدهیم که می‌توانند توسط اجزای سیستم مانند گفتگوی تنظیمات به اشتراک گذاشته شوند.

خط مشی SELinux برای keystore_key

برچسب‌های فضای نام با استفاده از فایل keystore2_key_context پیکربندی می‌شوند.
هر خط در این فایل ها یک شناسه فضای نام عددی را به یک برچسب SELinux ترسیم می کند. به عنوان مثال،

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

پس از راه‌اندازی فضای نام کلید جدید به این روش، می‌توانیم با افزودن یک خط‌مشی مناسب به آن دسترسی داشته باشیم. به عنوان مثال، برای اجازه دادن به wpa_supplicant برای دریافت و استفاده از کلیدها در فضای نام جدید، خط زیر را به hal_wifi_supplicant.te اضافه می کنیم:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

پس از تنظیم فضای نام جدید، AndroidKeyStore تقریباً طبق معمول قابل استفاده است. تنها تفاوت این است که شناسه فضای نام باید مشخص شود. برای بارگیری و وارد کردن کلیدها از و به Keystore، شناسه فضای نام با استفاده از AndroidKeyStoreLoadStoreParameter مشخص می شود. به عنوان مثال،

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

برای ایجاد یک کلید در یک فضای نام مشخص، شناسه فضای نام باید با استفاده از KeyGenParameterSpec.Builder#setNamespace():

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

فایل های زمینه زیر را می توان برای پیکربندی فضای نام Keystore 2.0 SELinux استفاده کرد. هر پارتیشن دارای محدوده رزرو شده متفاوتی از 10000 شناسه فضای نام برای جلوگیری از برخورد است.

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

کلاینت با درخواست دامنه SELinux و فضای نام مجازی مورد نظر، در این مورد "wifi_key" توسط شناسه عددی خود، کلید را درخواست می کند.

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

دسترسی به بردارها

keystore_key کلاس SELinux کمی قدیمی شده است و برخی از مجوزها مانند verify یا sign معنی خود را از دست داده اند. در اینجا مجموعه جدیدی از مجوزها، keystore2_key است که Keystore 2.0 اعمال می کند.

علاوه بر این، ما مجموعه ای از مجوزهای ذخیره کلید غیر کلیدی را در keystore2 کلاس امنیتی SELinux تقسیم می کنیم: