ربط الإصدار

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

لإتاحة البنية المعيارية في Treble وفصل ربط system.img بـ boot.img، غيّر Keymaster 4 نموذج ربط إصدار المفتاح ليتضمّن مستويات تصحيح منفصلة لكل قسم. ويتيح ذلك تحديث كل قسم بشكل مستقل مع توفير الحماية من العودة إلى الإصدارات السابقة.

لتنفيذ ربط الإصدار هذا، يحتاج تطبيق KeyMint الموثوق (TA) إلى طريقة آمنة لتلقّي إصدار نظام التشغيل الحالي ومستويات التصحيح، والتأكّد من أنّ المعلومات التي يتلقّاها تتطابق مع جميع المعلومات المتعلّقة بالنظام قيد التشغيل.

• يمكن للأجهزة التي تتضمّن ميزة "التشغيل المتحقّق منه من خلال Android" (AVB) وضع جميع مستويات التصحيح وإصدار النظام في vbmeta، ما يتيح لبرنامج الإقلاع توفيرها لخدمة Keymaster. بالنسبة إلى الأقسام المتسلسلة، تكون معلومات الإصدار الخاصة بالقسم مضمّنة في ملف vbmeta المتسلسل. بشكل عام، يجب أن تكون معلومات الإصدار في vbmeta struct الذي يحتوي على بيانات التحقق من الهوية (التجزئة أو شجرة التجزئة) لقسم معيّن.
• على الأجهزة التي لا تتضمّن ميزة AVB:
  • يجب أن توفّر عمليات تنفيذ "التشغيل المتحقَّق منه" تجزئة للبيانات الوصفية الخاصة بالإصدار إلى برنامج الإقلاع، كي يتمكّن برنامج الإقلاع من توفير التجزئة إلى Keymaster.
  • يمكن boot.img مواصلة تخزين مستوى التصحيح في العنوان
  • يمكن أن يواصل system.img تخزين مستوى تصحيح الأخطاء وإصدار نظام التشغيل في مواقع للقراءة فقط
  • تخزِّن vendor.img مستوى تصحيح الأمان في السمة ro.vendor.build.version.security_patch للقراءة فقط.
  • يمكن أن يوفّر برنامج الإقلاع رمز التجزئة لجميع البيانات التي تم التحقّق من صحتها باستخدام ميزة "التشغيل المتحقّق منه" إلى Keymaster.
• في نظام التشغيل Android 9، استخدِم العلامات التالية لتوفير معلومات الإصدار للأقسام التالية:
  • VENDOR_PATCH_LEVEL: القسم vendor
  • BOOT_PATCH_LEVEL: القسم boot
  • OS_PATCH_LEVEL وOS_VERSION: القسم system (تتم إزالة OS_VERSION من عنوان boot.img.
• يجب أن تتعامل عمليات تنفيذ Keymaster مع جميع مستويات التصحيح بشكل مستقل. تكون المفاتيح قابلة للاستخدام إذا كانت جميع معلومات الإصدار تتطابق مع القيم المرتبطة بمفتاح، ويتم IKeymaster::upgradeDevice() إلى مستوى تصحيح أعلى إذا لزم الأمر.

تغييرات طبقة تجريد الأجهزة (HAL)

لإتاحة ربط الإصدار وإثبات صحة الإصدار، أضاف نظام التشغيل Android 7.1 العلامتَين Tag::OS_VERSION وTag::OS_PATCHLEVEL والطريقتَين configure وupgradeKey. تضيف عمليات تنفيذ Keymaster 2 والإصدارات الأحدث علامات الإصدار تلقائيًا إلى جميع المفاتيح التي تم إنشاؤها حديثًا (أو تعديلها). علاوةً على ذلك، يتم رفض أي محاولة لاستخدام مفتاح لا يتضمّن إصدار نظام تشغيل أو مستوى تصحيح مطابقًا لإصدار نظام التشغيل أو مستوى التصحيح الحاليين للنظام، وذلك باستخدام ErrorCode::KEY_REQUIRES_UPGRADE.

‫Tag::OS_VERSION هي قيمة UINT تمثّل الأجزاء الرئيسية والثانوية والفرعية من إصدار نظام Android بتنسيق MMmmss، حيث MM هو رقم الإصدار الرئيسي وmm هو رقم الإصدار الثانوي وss هو الإصدار الفرعي. على سبيل المثال، سيتم تمثيل الرقم 6.1.2 على النحو 060102.

‫Tag::OS_PATCHLEVEL هي قيمة UINT تمثّل السنة والشهر لآخر تحديث للنظام بالتنسيق YYYYMM، حيث يشير YYYY إلى السنة المكوّنة من أربعة أرقام وMM إلى الشهر المكوّن من رقمين. على سبيل المثال، سيتم تمثيل مارس 2016 بالرقم 201603.

UpgradeKey

للسماح بترقية المفاتيح إلى إصدار نظام التشغيل ومستوى التصحيح الجديدَين لصورة النظام، أضاف الإصدار 7.1 من نظام التشغيل Android الطريقة upgradeKey إلى طبقة HAL:

Keymaster 3

    upgradeKey(vec keyBlobToUpgrade, vec upgradeParams)
        generates(ErrorCode error, vec upgradedKeyBlob);

Keymaster 2

keymaster_error_t (*upgrade_key)(const struct keymaster2_device* dev,
    const keymaster_key_blob_t* key_to_upgrade,
    const keymaster_key_param_set_t* upgrade_params,
    keymaster_key_blob_t* upgraded_key);

• dev هي بنية الجهاز
• ‫keyBlobToUpgrade هو المفتاح الذي يجب ترقيته
• ‫upgradeParams هي مَعلمات مطلوبة لترقية المفتاح. وتشمل هذه Tag::APPLICATION_ID وTag::APPLICATION_DATA، وهما ضروريتان لفك تشفير كتلة المفتاح، إذا تم توفيرهما أثناء الإنشاء.
• ‫upgradedKeyBlob هي مَعلمة الإخراج، وتُستخدَم لعرض كائن ثنائي كبير جديد للمفتاح.

إذا تم استدعاء upgradeKey باستخدام كائن ثنائي كبير الحجم للمفتاح لا يمكن تحليله أو كان غير صالح لأي سبب آخر، سيتم عرض ErrorCode::INVALID_KEY_BLOB. إذا تم استدعاؤها باستخدام مفتاح مستوى التصحيح الخاص به أكبر من قيمة النظام الحالية، تعرض ErrorCode::INVALID_ARGUMENT. إذا تم استدعاؤها باستخدام مفتاح يكون إصدار نظام التشغيل الخاص به أكبر من قيمة النظام الحالية، وكانت قيمة النظام غير صفرية، تعرض ErrorCode::INVALID_ARGUMENT. يُسمح بالترقية من إصدار نظام تشغيل غير صفري إلى إصدار صفري. في حال حدوث أخطاء أثناء التواصل مع البيئة الآمنة، يتم عرض قيمة خطأ مناسبة (مثل ErrorCode::SECURE_HW_ACCESS_DENIED أو ErrorCode::SECURE_HW_BUSY)، وإلا يتم عرض ErrorCode::OK وعرض كائن ثنائي كبير جديد للمفتاح في upgradedKeyBlob.

يظل keyBlobToUpgrade صالحًا بعد الاتصال بـ upgradeKey، ويمكن نظريًا استخدامه مرة أخرى في حال تم الرجوع إلى إصدار أقدم من الجهاز. في التطبيق العملي، يستدعي نظام keystore عادةً deleteKey على كائن keyBlobToUpgrade الثنائي الكبير بعد وقت قصير من استدعاء upgradeKey. إذا كان keyBlobToUpgrade يتضمّن العلامة Tag::ROLLBACK_RESISTANT، يجب أن يتضمّنها upgradedKeyBlob أيضًا (ويجب أن يكون مقاومًا لعمليات الرجوع إلى الإصدار السابق).

الضبط الآمن

لتنفيذ ربط الإصدار، يجب أن يتوفّر لدى Keymaster TA طريقة لتلقّي إصدار نظام التشغيل ومستوى تصحيحه الحاليين (معلومات الإصدار) بشكل آمن، ولضمان تطابق المعلومات التي يتلقّاها بشكل كبير مع المعلومات المتعلّقة بالنظام قيد التشغيل.

لإتاحة إمكانية إرسال معلومات الإصدار بشكل آمن إلى TA، تمت إضافة OS_VERSION حقل إلى عنوان صورة التشغيل. يملأ نص برمجة إنشاء صورة التشغيل هذا الحقل تلقائيًا. على مصنّعي المعدات الأصلية ومطوّري Keymaster TA العمل معًا لتعديل برامج التحميل على الأجهزة من أجل استخراج معلومات الإصدار من صورة التشغيل وتمريرها إلى TA قبل تشغيل النظام غير الآمن. ويضمن ذلك عدم تمكّن المخترقين من التدخّل في عملية توفير معلومات الإصدار إلى البيئة التنفيذية الموثوقة.

من الضروري أيضًا التأكّد من أنّ صورة النظام تتضمّن معلومات الإصدار نفسها المتوفّرة في صورة التمهيد. لهذا السبب، تمت إضافة طريقة الضبط إلى Keymaster HAL:

keymaster_error_t (*configure)(const struct keymaster2_device* dev,
  const keymaster_key_param_set_t* params);

تحتوي الوسيطة params على Tag::OS_VERSION وTag::OS_PATCHLEVEL. يتم استدعاء هذه الطريقة من خلال برامج keymaster2 بعد فتح طبقة HAL، ولكن قبل استدعاء أي طرق أخرى. إذا تم استدعاء أي طريقة أخرى قبل configure، ستعرض البيئة الموثوقة ErrorCode::KEYMASTER_NOT_CONFIGURED.

في المرة الأولى التي يتم فيها استدعاء configure بعد تشغيل الجهاز، يجب التحقّق من أنّ معلومات الإصدار المقدَّمة تتطابق مع المعلومات التي قدّمها برنامج إقلاع. إذا لم تتطابق معلومات الإصدار، ستعرض الدالة configure القيمة ErrorCode::INVALID_ARGUMENT، وستواصل جميع دوال Keymaster الأخرى عرض القيمة ErrorCode::KEYMASTER_NOT_CONFIGURED. إذا كانت المعلومات متطابقة، تعرض configure القيمة ErrorCode::OK، وتبدأ طرق Keymaster الأخرى في العمل بشكل طبيعي.

ستعرض طلبات configure اللاحقة القيمة نفسها التي عرضها الطلب الأول، ولن تغيّر حالة Keymaster.

بما أنّ النظام هو الذي يستدعي configure، وهو الذي من المفترض أن يتحقّق من صحة محتواه، فإنّ هناك فرصة ضئيلة للمهاجمين لاختراق صورة النظام وإجبارها على تقديم معلومات الإصدار التي تتطابق مع صورة التشغيل، ولكنّها ليست الإصدار الفعلي للنظام. إنّ الجمع بين التحقّق من صحة صورة التمهيد والتحقّق من صحة محتويات صورة النظام باستخدام dm-verity، بالإضافة إلى حقيقة أنّه يتم استدعاء configure في وقت مبكر جدًا من عملية تمهيد النظام، من المفترض أن يجعل استغلال هذه الثغرة أمرًا صعبًا.