في Keymaster 1، كانت كل مفاتيح التحكم الرئيسية مرتبطة بالجهاز بطريقة مشفّرة. جذر الثقة أو مفتاح التشغيل الذي تم التحقّق منه. في Keymaster 2 و3، أيضًا بنظام التشغيل ومستوى التصحيح لصورة النظام. وهذا يضمن أن المهاجم الذي يكتشف نقطة ضعف في لا يمكن لإصدار النظام أو برنامج بيئة التنفيذ الموثوقة (TEE) إعادة الجهاز إلى الثغرات الأمنية. الإصدار واستخدام المفاتيح التي تم إنشاؤها مع الإصدار الأحدث. بالإضافة إلى ذلك، عندما لا يتم باستخدام إصدار معيّن ومستوى رمز التصحيح على جهاز تمت ترقيته إلى إصدار أحدث أو مستوى تصحيح، تتم ترقية المفتاح قبل استخدامه، والإصدار السابق من المفتاح غير صالح. بهذه الطريقة، ونظرًا لأن الجهاز عندما تتم ترقية المفاتيح، سوف "تتزايد" المفاتيح قدمًا مع الجهاز، ولكن عودة الجهاز إلى إصدار سابق إلى أن يتم تحويل المفاتيح غير قابل للاستخدام.
لدعم الهيكل النموذجي لـ Treble وكسر ربط system.img بـ Boot.img، غيّر Keymaster 4 نموذج ربط إصدار المفتاح ليصبح مستويات التصحيح لكل قسم. يتيح هذا الإجراء تحديث كل قسم. كل على حدة، مع الاستمرار في توفير الحماية من العودة إلى الحالة السابقة.
في نظام التشغيل Android 9، boot
وsystem
وvendor
لكل قسم مستوى تصحيح خاص به.
- يمكن للأجهزة المزوَّدة بميزة "التشغيل المتحقّق منه على Android" (AVB) وضع جميع مستويات التصحيح.
وإصدار النظام في vbmeta، لذلك يمكن أن تتيح أداة الإقلاع
مدير المفاتيح. بالنسبة إلى الأقسام المتسلسلة، ستظهر لك معلومات إصدار القسم
في vbmeta المتسلسلة. بشكل عام، يجب أن تكون معلومات الإصدار في
vbmeta struct
الذي يحتوي على بيانات التحقق (تجزئة أو التجزئة) لقسم معين. - على الأجهزة التي لا تتضمّن AVB:
- ينبغي أن توفر عمليات تنفيذ "التشغيل المتحقّق منه" تجزئة للإصدار البيانات الوصفية إلى برنامج الإقلاع لكي يوفّر برنامج الإقلاع التجزئة إلى برنامج Keymaster.
- بإمكان
boot.img
مواصلة تخزين مستوى رمز التصحيح في العنوان. - بإمكان
system.img
مواصلة تخزين مستوى رمز التصحيح وإصدار نظام التشغيل في وضع القراءة فقط. المواقع - يخزِّن
vendor.img
مستوى رمز التصحيح في الموقع المخصّص للقراءة فقط.ro.vendor.build.version.security_patch
- يمكن أن يوفّر برنامج الإقلاع تجزئة لجميع البيانات التي تم التحقّق من صحتها. إلى مدير المفاتيح.
- في نظام التشغيل 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 بتنسيق MMmms،
حيث يكون MM هو الإصدار الرئيسي، ويكون mm هو الإصدار الثانوي وss هو صغير
. على سبيل المثال، سيتم تمثيل 6.1.2 كـ 060102.
Tag::OS_PATCHLEVEL
هي قيمة UINT
تمثل
السنة والشهر آخر تحديث للنظام بالصيغة YYYYMM، حيث يشير YYYY إلى
السنة المكونة من أربعة أرقام وMM إلى الشهر المكوّن من رقمين. على سبيل المثال، سيكون شهر مارس 2016
ممثلة في 201603.
مفتاح الترقية
للسماح بترقية المفاتيح إلى إصدار نظام التشغيل الجديد ومستوى تصحيح النظام
صورة، أضاف Android 7.1 طريقة 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
باستخدام الكائن الثنائي الكبير (blob) الرئيسي الذي لا يمكن تحليله أو
غير صالح بخلاف ذلك، فسيعرض القيمة ErrorCode::INVALID_KEY_BLOB
. إذا كان
بمفتاح يكون مستوى تصحيحه أكبر من قيمة النظام الحالية،
فإنها تُرجع ErrorCode::INVALID_ARGUMENT
. فإذا تم استدعاؤها بمفتاح
الذي يكون إصدار نظام التشغيل له أكبر من قيمة النظام الحالية، وقيمة النظام
قيمة غير صفرية، فيكون الناتج ErrorCode::INVALID_ARGUMENT
. إصدار نظام التشغيل
يُسمح بالترقية من الصفر إلى الصفر. في حال حدوث أخطاء
عند الاتصال بالعالم الآمن، فإنه يعرض قيمة خطأ مناسبة (على سبيل المثال
ErrorCode::SECURE_HW_ACCESS_DENIED
,
ErrorCode::SECURE_HW_BUSY
). بخلاف ذلك، تعرض
ErrorCode::OK
وعرض كائن ثنائي كبير (blob) رئيسي جديد في
upgradedKeyBlob
سيظل keyBlobToUpgrade
صالحًا بعد upgradeKey
ويمكن استخدامه نظريًا مرة أخرى إذا تم إرجاع الجهاز إلى إصدار سابق. ضِمن
تدريبًا، يستدعي ملف تخزين المفاتيح عمومًا deleteKey
على
keyBlobToUpgrade
نقطة ثنائية بعد وقت قصير من الاتصال
upgradeKey
في حال وجود علامة في keyBlobToUpgrade
Tag::ROLLBACK_RESISTANT
، ثم upgradedKeyBlob
يجب
امتلكه أيضًا (ويجب أن يكون مقاومًا للعودة).
الإعداد الآمن
لتنفيذ ربط الإصدار، يحتاج Keymaster TA إلى طريقة لاستقبال إصدار نظام التشغيل الحالي ومستوى التصحيح (معلومات الإصدار)، وللتأكد من أن المعلومات التي يتلقّاها تطابق إلى حد كبير المعلومات المتعلقة .
لدعم التسليم الآمن لمعلومات الإصدار إلى TA، يمكن أن تتضمن OS_VERSION
تمت إضافة الحقل إلى عنوان صورة التشغيل. إصدار صورة التشغيل
يملأ البرنامج النصي هذا الحقل تلقائيًا. المصنّعون الأصليون للأجهزة ومقدّمو البرامج المخصّصة للمحترفين الرئيسيين
إلى العمل معًا لتعديل برامج إقلاع الجهاز واستخراج الإصدار
من صورة التمهيد وتمريرها إلى TA قبل الملفات غير
تم تشغيل النظام. يضمن ذلك عدم تمكن المهاجمين من التدخل في توفير المتطلبات اللازمة
من معلومات الإصدار إلى TA.
من الضروري أيضًا التأكد من أن صورة النظام لها النسخة ذاتها المعلومات مثل صورة التشغيل. لذلك، تمت إضافة طريقة الإعداد إلى 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، ولكن قبل استدعاء أي طرق أخرى. إذا كانت هناك أي طريقة أخرى
قبل التهيئة، فإن TA يعرض
ErrorCode::KEYMASTER_NOT_CONFIGURED
في المرة الأولى التي يتم فيها استدعاء "configure
" بعد تشغيل الجهاز، يتم تشغيل
التحقق من أن معلومات الإصدار المقدمة تتطابق مع المعلومات التي تم تقديمها بواسطة
برنامج الإقلاع. إذا لم تتطابق معلومات الإصدار،
تُرجع configure
ErrorCode::INVALID_ARGUMENT
، وجميع
طرق رئيسية أخرى تستمر في عرض
ErrorCode::KEYMASTER_NOT_CONFIGURED
إذا تطابقت المعلومات،
إرجاع "configure
": ErrorCode::OK
ومفتاح رئيسي آخر
تبدأ الطرق في العمل بشكل طبيعي.
تعرض الاستدعاءات اللاحقة على configure
القيمة نفسها التي تعرضها
الاتصال الأول، وعدم تغيير حالة مفتاح التحكم. لاحظ أن هذه العملية
تتطلب تحديث جميع وكالات السفر عبر الإنترنت لكل من صور النظام والتشغيل؛ لا يمكن تحديثها
بشكل منفصل للحفاظ على مزامنة معلومات الإصدار.
لأنّه سيتم استدعاء configure
بواسطة النظام الذي يحتوي على المحتوى
التي تهدف إلى التحقق، تكون هناك فرصة ضيقة للمهاجم
اختراق صورة النظام وإجبارها على تقديم معلومات الإصدار التي
مع صورة التشغيل، ولكنها ليست الإصدار الفعلي من النظام. تشير رسالة الأشكال البيانية
الجمع بين التحقق من صورة التمهيد والتحقق من صحة dm-verity لصورة النظام
المحتوى، وأنه يُطلق على configure
اسم مبكر جدًا من
أن يؤدي تشغيل النظام إلى جعل نافذة الفرصة هذه من الصعب استغلالها.