تلتزم Google بتعزيز المساواة العرقية للمجتمعات السوداء. أنظر كيف.
ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هندسة معمارية

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

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

الوصول إلى Keymaster

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

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

الغرض من 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.

نظرة عامة على 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;

حيث generate_cb هو مؤشر دالة يعرف بأنه:

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

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

للحصول على مثال مفصل ، انظر التنفيذ الافتراضي في hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . يوفر التطبيق الافتراضي توافقًا عكسيًا للأجهزة ذات keymaster0 أو keymaster1 أو keymaster2 HALS ذات الطراز القديم.