Keystore المدعومة بالأجهزة

يوفر توفر بيئة تنفيذ موثوقة في نظام على شريحة (SoC) فرصة لأجهزة Android لتوفير خدمات أمان قوية ومدعومة بالأجهزة لنظام التشغيل Android ، وخدمات النظام الأساسي ، وحتى لتطبيقات الجهات الخارجية. يجب على المطورين الذين يسعون للحصول على امتدادات خاصة بنظام Android الانتقال إلى android.security.keystore .

قبل Android 6.0 ، كان لدى Android بالفعل واجهة برمجة تطبيقات خدمات تشفير بسيطة مدعومة بالأجهزة ، يتم توفيرها بواسطة الإصدارين 0.2 و 0.3 من Keymaster Hardware Abstraction Layer (HAL). قدمت Keystore عمليات التوقيع والتحقق الرقمية ، بالإضافة إلى إنشاء واستيراد أزواج مفاتيح التوقيع غير المتماثلة. تم تنفيذ هذا بالفعل على العديد من الأجهزة ، ولكن هناك العديد من أهداف الأمان التي لا يمكن تحقيقها بسهولة باستخدام توقيع API فقط. قام Keystore في Android 6.0 بتوسيع Keystore API لتوفير نطاق أوسع من الإمكانات.

في Android 6.0 ، أضاف Keystore أساسيات التشفير المتماثل ، AES و HMAC ، ونظام التحكم في الوصول للمفاتيح المدعومة بالأجهزة. يتم تحديد عناصر التحكم في الوصول أثناء إنشاء المفتاح ويتم فرضها طوال عمر المفتاح. يمكن تقييد استخدام المفاتيح فقط بعد مصادقة المستخدم ، ولأغراض محددة فقط أو باستخدام معلمات تشفير محددة. لمزيد من المعلومات ، راجع صفحات علامات التفويض والوظائف .

بالإضافة إلى توسيع نطاق أساسيات التشفير ، أضاف Keystore في Android 6.0 ما يلي:

• نظام التحكم في الاستخدام للسماح بتحديد استخدام المفتاح ، للتخفيف من مخاطر الاختراق الأمني ​​بسبب إساءة استخدام المفاتيح
• نظام التحكم في الوصول لتمكين تقييد المفاتيح لمستخدمين معينين وعملاء ونطاق زمني محدد

في Android 7.0 ، أضاف Keymaster 2 دعمًا للمصادقة الرئيسية وربط الإصدار. يوفر التصديق على المفتاح شهادات المفاتيح العامة التي تحتوي على وصف مفصل للمفتاح وعناصر التحكم في الوصول الخاصة به ، لجعل وجود المفتاح في الأجهزة الآمنة وتكوينه قابلاً للتحقق عن بُعد.

ربط الإصدار يربط المفاتيح بنظام التشغيل وإصدار مستوى التصحيح. هذا يضمن أن المهاجم الذي يكتشف نقطة ضعف في إصدار قديم من النظام أو برنامج TEE لا يمكنه إعادة الجهاز إلى الإصدار الضعيف واستخدام المفاتيح التي تم إنشاؤها باستخدام الإصدار الأحدث. بالإضافة إلى ذلك ، عند استخدام مفتاح بإصدار معين ومستوى تصحيح على جهاز تمت ترقيته إلى إصدار أحدث أو مستوى تصحيح ، تتم ترقية المفتاح قبل أن يمكن استخدامه ، ويتم إبطال الإصدار السابق من المفتاح. أثناء ترقية الجهاز ، "تضاعف" المفاتيح للأمام مع الجهاز ، ولكن أي ارتداد للجهاز إلى إصدار سابق يتسبب في أن تصبح المفاتيح غير قابلة للاستخدام.

في Android 8.0 ، انتقل Keymaster 3 من طبقة تجريد الأجهزة ذات البنية C القديمة (HAL) إلى واجهة C ++ HAL التي تم إنشاؤها من تعريف في لغة تعريف واجهة الأجهزة الجديدة (HIDL). كجزء من التغيير ، تم تغيير العديد من أنواع الوسيطات ، على الرغم من أن الأنواع والطرق لها تطابق واحد لواحد مع الأنواع القديمة وطرق HAL Struct. انظر صفحة الوظائف لمزيد من التفاصيل.

بالإضافة إلى مراجعة الواجهة هذه ، قام Android 8.0 بتوسيع ميزة التصديق في Keymaster 2 لدعم توثيق الهوية . يوفر إثبات الهوية آلية محدودة واختيارية للتصديق بقوة على معرفات الأجهزة ، مثل الرقم التسلسلي للجهاز واسم المنتج ومعرف الهاتف (IMEI / MEID). لتنفيذ هذه الإضافة ، قام Android 8.0 بتغيير مخطط شهادة ASN.1 لإضافة شهادة ID. تحتاج تطبيقات Keymaster إلى إيجاد طريقة آمنة لاسترداد عناصر البيانات ذات الصلة ، بالإضافة إلى تحديد آلية لتعطيل الميزة بشكل آمن ودائم.

في Android 9 ، تضمنت التحديثات:

• التحديث إلى Keymaster 4
• دعم العناصر الآمنة المضمنة
• دعم استيراد المفتاح الآمن
• دعم تشفير 3DES
• التغييرات في ربط الإصدار بحيث يكون لكل من boot.img و system.img إصدارات محددة بشكل منفصل للسماح بالتحديثات المستقلة

قائمة المصطلحات

فيما يلي نظرة عامة سريعة على مكونات Keystore وعلاقاتها.

AndroidKeystore هو Android Framework API والمكون الذي تستخدمه التطبيقات للوصول إلى وظائف Keystore. يتم تنفيذه كامتداد لواجهات برمجة تطبيقات Java Cryptography Architecture القياسية ، ويتكون من كود Java يتم تشغيله في مساحة العملية الخاصة بالتطبيق. يفي AndroidKeystore بطلبات التطبيق الخاصة بسلوك Keystore عن طريق إعادة توجيهها إلى البرنامج الخفي لـ keystore.

برنامج keystore daemon هو برنامج خفي لنظام Android يوفر الوصول إلى جميع وظائف Keystore عبر Binder API . إنه مسؤول عن تخزين "النقاط الرئيسية" ، التي تحتوي على مادة المفتاح السري الفعلي ، المشفرة حتى يتمكن Keystore من تخزينها ولكن لا يستخدمها أو يكشف عنها.

keymasterd هو خادم HIDL يوفر الوصول إلى Keymaster TA. (هذا الاسم ليس موحدًا ولأغراض مفاهيمية.)

Keymaster TA (تطبيق موثوق به) هو البرنامج الذي يتم تشغيله في سياق آمن ، غالبًا في TrustZone على ARM SoC ، والذي يوفر جميع عمليات Keystore الآمنة ، ولديه حق الوصول إلى مادة المفتاح الخام ، والتحقق من صحة جميع شروط التحكم في الوصول على المفاتيح ، إلخ.

LockSettingsService هو مكون نظام Android المسؤول عن مصادقة المستخدم ، وكلمة المرور وبصمة الإصبع. إنه ليس جزءًا من Keystore ، ولكنه ذو صلة لأن العديد من عمليات مفتاح Keystore تتطلب مصادقة المستخدم. تتفاعل LockSettingsService مع Gatekeeper TA و Fingerprint TA للحصول على رموز المصادقة ، التي توفرها لخادم keystore ، والتي يستهلكها تطبيق Keymaster TA في النهاية.

Gatekeeper TA (تطبيق موثوق به) هو مكون آخر يعمل في السياق الآمن ، وهو مسؤول عن مصادقة كلمات مرور المستخدم وإنشاء رموز المصادقة المميزة المستخدمة لإثبات Keymaster TA أن المصادقة قد تم إجراؤها لمستخدم معين في وقت معين.

Fingerprint TA (تطبيق موثوق به) هو مكون آخر يعمل في السياق الآمن وهو مسؤول عن مصادقة بصمات أصابع المستخدم وإنشاء رموز المصادقة المستخدمة لإثبات Keymaster TA أن المصادقة قد تم إجراؤها لمستخدم معين في وقت معين.

هندسة عامة

توفر واجهة برمجة تطبيقات Android Keystore و Keymaster HAL الأساسي مجموعة أساسية ولكن مناسبة من أساسيات التشفير للسماح بتنفيذ البروتوكولات باستخدام مفاتيح التحكم في الوصول والمدعومة من الأجهزة.

Keymaster HAL هي مكتبة قابلة للتحميل ديناميكيًا توفرها الشركة المصنعة للمعدات الأصلية وتستخدمها خدمة Keystore لتقديم خدمات تشفير مدعومة بالأجهزة. للحفاظ على أمان الأشياء ، لا تؤدي تطبيقات HAL أي عمليات حساسة في مساحة المستخدم ، أو حتى في مساحة kernel. يتم تفويض العمليات الحساسة إلى معالج آمن يتم الوصول إليه من خلال بعض واجهات kernel. تبدو البنية الناتجة كما يلي:

الشكل 1. الوصول إلى Keymaster

داخل جهاز Android ، يتكون "العميل" لـ Keymaster HAL من طبقات متعددة (مثل التطبيق ، والإطار ، و Keystore daemon) ، ولكن يمكن تجاهل ذلك لأغراض هذا المستند. هذا يعني أن Keymaster HAL API الموصوفة منخفضة المستوى ، وتستخدمها المكونات الداخلية للنظام الأساسي ، ولا تتعرض لمطوري التطبيقات. يتم وصف واجهة برمجة التطبيقات ذات المستوى الأعلى على موقع مطور Android .

الغرض من Keymaster HAL ليس تنفيذ خوارزميات حساسة للأمان ولكن فقط لتنظيم الطلبات وإلغاء تنظيمها في العالم الآمن. يتم تحديد تنسيق السلك حسب التنفيذ.

التوافق مع الإصدارات السابقة

Keymaster 1 HAL غير متوافق تمامًا مع HALs التي تم إصدارها مسبقًا ، مثل Keymaster 0.2 و 0.3. لتسهيل التشغيل البيني على الأجهزة التي تعمل بنظام التشغيل Android 5.0 والإصدارات الأقدم التي تم إطلاقها مع Keymaster HALs الأقدم ، يوفر Keystore محولًا ينفذ Keymaster 1 HAL مع المكالمات إلى مكتبة الأجهزة الموجودة. لا يمكن أن توفر النتيجة النطاق الكامل للوظائف في Keymaster 1 HAL. على وجه الخصوص ، فهو يدعم فقط خوارزميات RSA و ECDSA ، ويتم تنفيذ جميع عمليات إنفاذ ترخيص المفتاح بواسطة المهايئ ، في العالم غير الآمن.

قام Keymaster 2 بتبسيط واجهة HAL بشكل أكبر عن طريق إزالة أساليب get_supported_* والسماح لطريقة finish() بقبول الإدخال. هذا يقلل من عدد الرحلات ذهابًا وإيابًا إلى TEE في الحالات التي يكون فيها الإدخال متاحًا دفعة واحدة ، ويبسط تنفيذ فك تشفير AEAD.

في Android 8.0 ، انتقل Keymaster 3 من النمط القديم C- بنية HAL إلى واجهة C ++ HAL التي تم إنشاؤها من تعريف في لغة تعريف واجهة الأجهزة الجديدة (HIDL). يتم إنشاء تطبيق HAL بأسلوب جديد عن طريق التصنيف الفرعي لفئة IKeymasterDevice التي تم إنشاؤها وتنفيذ الأساليب الافتراضية البحتة. كجزء من التغيير ، تم تغيير العديد من أنواع الوسائط ، على الرغم من أن الأنواع والطرق لها تطابق واحد لواحد مع الأنواع القديمة وطرق HAL Struct.

نظرة عامة HIDL

توفر لغة تعريف واجهة الأجهزة (HIDL) آلية تنفيذ مستقلة عن اللغة لتحديد واجهات الأجهزة. تدعم أدوات HIDL حاليًا إنشاء واجهات C ++ و Java. من المتوقع أن يجد معظم منفذي بيئة التنفيذ الموثوقة (TEE) أدوات C ++ أكثر ملاءمة ، لذلك يناقش هذا المستند تمثيل C ++ فقط.

تتكون واجهات HIDL من مجموعة من الأساليب ، يتم التعبير عنها على النحو التالي:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

هناك أنواع مختلفة محددة مسبقًا ، ويمكن لـ HALs تحديد أنواع هيكلية ومعدودة جديدة. لمزيد من التفاصيل حول 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 هي دالة تأخذ قيم الإرجاع المدرجة في جملة الإنشاء. تتجاوز فئة تطبيق 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

باستخدام نطاقات Keystore ، يمكننا فصل مساحات الأسماء عن معرفات UID. يجب على العملاء الذين يصلون إلى مفتاح في Keystore تحديد النطاق ومساحة الاسم والاسم المستعار الذي يريدون الوصول إليه. بناءً على هذه المجموعة وهوية المتصل ، يمكننا تحديد المفتاح الذي يريد المتصل الوصول إليه وما إذا كان لديه الأذونات المناسبة.

نقدم خمس معلمات للمجال تحكم كيفية الوصول إلى المفاتيح. يتحكمون في دلالات معلمة مساحة الاسم لواصف المفتاح وكيفية تنفيذ التحكم في الوصول.

• DOMAIN_APP : يغطي نطاق التطبيق السلوك القديم. يستخدم Java Keystore SPI هذا المجال افتراضيًا. عند استخدام هذا المجال ، يتم تجاهل وسيطة مساحة الاسم ويتم استخدام UID الخاص بالمستدعي بدلاً من ذلك. يتم التحكم في الوصول إلى هذا المجال بواسطة تسمية Keystore إلى class keystore_key في سياسة SELinux.
• DOMAIN_SELINUX : يشير هذا المجال إلى أن مساحة الاسم لها تسمية في سياسة SELinux. يتم البحث عن معامل مساحة الاسم وترجمته إلى سياق الهدف ، ويتم إجراء فحص الإذن لسياق SELinux الذي يستدعي لفئة keystore_key . عندما يتم إنشاء الإذن للعملية المحددة ، يتم استخدام المجموعة الكاملة للبحث عن المفتاح.
• DOMAIN_GRANT : يشير مجال المنح إلى أن معلمة مساحة الاسم هي معرف منحة. تم تجاهل معلمة الاسم المستعار. يتم إجراء عمليات التحقق من SELinux عند إنشاء المنحة. يتحقق مزيد من التحكم في الوصول فقط مما إذا كان المعرف الفريد للمتصل يطابق UID الخاص بالحاصلين على المنحة المطلوبة.
• DOMAIN_KEY_ID : يشير هذا المجال إلى أن معلمة مساحة الاسم هي معرف مفتاح فريد. ربما تم إنشاء المفتاح نفسه باستخدام DOMAIN_APP أو DOMAIN_SELINUX . يتم إجراء التحقق من الإذن بعد تحميل domain namespace من قاعدة البيانات الأساسية بنفس الطريقة كما لو تم تحميل blob بواسطة المجال ومساحة الاسم ومجموعة الاسم المستعار. الأساس المنطقي لمجال معرف المفتاح هو الاستمرارية. عند الوصول إلى مفتاح بالاسم المستعار ، قد تعمل المكالمات اللاحقة على مفاتيح مختلفة ، لأنه ربما تم إنشاء مفتاح جديد أو استيراده وربطه بهذا الاسم المستعار. معرف المفتاح ، ومع ذلك ، لا يتغير أبدا. لذلك عند استخدام مفتاح بواسطة معرف المفتاح بعد تحميله من قاعدة بيانات Keystore باستخدام الاسم المستعار مرة واحدة ، يمكن للمرء التأكد من أنه نفس المفتاح طالما أن معرف المفتاح لا يزال موجودًا. لا يتم عرض هذه الوظيفة لمطوري التطبيقات. بدلاً من ذلك ، يتم استخدامه داخل Android Keystore SPI لتوفير تجربة أكثر اتساقًا حتى عند استخدامه بشكل متزامن بطريقة غير آمنة.
• DOMAIN_BLOB : يشير مجال 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: