تصديق المفتاح والهوية

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

ومع ذلك، يكون هذا صحيحًا فقط إذا كان من المعروف أن مفاتيح تخزين المفاتيح موجودة في وحدة تخزين مدعومة بالأجهزة. في Keymaster 1، لم تكن هناك طريقة للتطبيقات أو الخوادم البعيدة للتحقق بشكل موثوق مما إذا كان هذا هو الحال. قام برنامج تخزين المفاتيح بتحميل مفتاح المفاتيح المتوفر HAL وصدق كل ما قاله HAL فيما يتعلق بدعم الأجهزة للمفاتيح.

لعلاج هذه المشكلة، قدم Keymaster شهادة المفتاح في Android 7.0 (Keymaster 2) وشهادة الهوية في Android 8.0 (Keymaster 3).

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

تسمح شهادة المعرف للجهاز بتقديم دليل على معرفات الأجهزة الخاصة به، مثل الرقم التسلسلي أو IMEI.

شهادة المفتاح

لدعم تصديق المفاتيح، قدم Android 7.1 مجموعة من العلامات والنوع والطريقة إلى HAL.

العلامات

  • Tag::ATTESTATION_CHALLENGE
  • Tag::INCLUDE_UNIQUE_ID
  • Tag::RESET_SINCE_ID_ROTATION

يكتب

كي ماستر 2 وما دونه

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

طريقة AttestKey

سيد المفاتيح 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

كي ماستر 2 وما دونه

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);
  • dev هو هيكل جهاز keymaster.
  • keyToAttest هو كائن ثنائي كبير الحجم تم إرجاعه من generateKey والذي سيتم إنشاء المصادقة له.
  • attestParams هي قائمة بأي معلمات ضرورية للتصديق. يتضمن ذلك Tag::ATTESTATION_CHALLENGE وربما Tag::RESET_SINCE_ID_ROTATION ، بالإضافة إلى Tag::APPLICATION_ID و Tag::APPLICATION_DATA . الأخيران ضروريان لفك تشفير النقطة الرئيسية إذا تم تحديدهما أثناء إنشاء المفتاح.
  • certChain هي معلمة الإخراج، والتي تقوم بإرجاع مجموعة من الشهادات. الإدخال 0 هو شهادة التصديق، مما يعني أنه يصادق على المفتاح من keyToAttest ويحتوي على ملحق التصديق.

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

شهادة التصديق

شهادة التصديق هي شهادة X.509 قياسية، مع ملحق تصديق اختياري يحتوي على وصف للمفتاح المصدق. يتم توقيع الشهادة بمفتاح تصديق معتمد . قد يستخدم مفتاح التصديق خوارزمية مختلفة عن المفتاح الذي يتم التصديق عليه.

تحتوي شهادة التصديق على الحقول الموجودة في الجدول أدناه ولا يمكن أن تحتوي على أي حقول إضافية. تحدد بعض الحقول قيمة حقل ثابتة. تتحقق اختبارات CTS من أن محتوى الشهادة مطابق تمامًا لما هو محدد.

تسلسل الشهادة

اسم الحقل (انظر RFC 5280 ) قيمة
tbsCertificate تسلسل شهادة TBS
خوارزمية التوقيع معرف الخوارزمية للخوارزمية المستخدمة لتوقيع المفتاح:
ECDSA لمفاتيح EC، وRSA لمفاتيح RSA.
قيمة التوقيع BIT STRING، التوقيع محسوب على tbsCertificate بترميز ASN.1 DER.

تسلسل شهادة TBS

اسم الحقل (انظر RFC 5280 ) قيمة
version عدد صحيح 2 (يعني شهادة v3)
serialNumber عدد صحيح 1 (قيمة ثابتة: نفسها في جميع الشهادات)
signature معرف الخوارزمية للخوارزمية المستخدمة لتوقيع المفتاح: ECDSA لمفاتيح EC، وRSA لمفاتيح RSA.
issuer نفس حقل الموضوع لمفتاح التصديق الدفعي.
validity SEQUENCE من تاريخين، يحتوي على قيم Tag::ACTIVE_DATETIME و Tag::USAGE_EXPIRE_DATETIME . هذه القيم موجودة بالمللي ثانية منذ 1 يناير 1970. راجع RFC 5280 للحصول على تمثيلات التاريخ الصحيحة في الشهادات.
في حالة عدم وجود Tag::ACTIVE_DATETIME ، استخدم قيمة Tag::CREATION_DATETIME . في حالة عدم وجود Tag::USAGE_EXPIRE_DATETIME ، استخدم تاريخ انتهاء صلاحية شهادة مفتاح تصديق الدُفعة.
subject CN = "مفتاح Android Keystore" (قيمة ثابتة: نفسها في جميع الشهادات)
subjectPublicKeyInfo SubjectPublicKeyInfo الذي يحتوي على المفتاح العام المعتمد.
extensions/Key Usage التوقيع الرقمي: اضبط ما إذا كان المفتاح له غرض KeyPurpose::SIGN أو KeyPurpose::VERIFY . جميع البتات الأخرى غير مضبوطة.
extensions/CRL Distribution Points سيتم تحديد القيمة لاحقًا
extensions/"attestation" معرف الكائن هو 1.3.6.1.4.1.11129.2.1.17؛ يتم تعريف المحتوى في قسم ملحق الشهادة أدناه. كما هو الحال مع جميع امتدادات شهادات X.509، يتم تمثيل المحتوى على هيئة OCTET_STRING يحتوي على تشفير DER لتسلسل المصادقة.

تمديد الشهادة

يحتوي ملحق attestation على وصف كامل لتفويضات مدير المفاتيح المرتبطة بالمفتاح، في بنية تتوافق مباشرة مع قوائم التفويض كما هي مستخدمة في Android وKeymaster HAL. يتم تمثيل كل علامة في قائمة الترخيص بواسطة إدخال ASN.1 SEQUENCE ، موسوم بشكل صريح برقم علامة keymaster، ولكن مع إخفاء واصف النوع (أربع بتات عالية الترتيب).

على سبيل المثال، في Keymaster 3، يتم تعريف Tag::PURPOSE في Types.hal كـ ENUM_REP | 1 . بالنسبة لامتداد التصديق، تتم إزالة قيمة ENUM_REP ، مع ترك العلامة 1 . (بالنسبة إلى Keymaster 2 والإصدارات الأقدم، يتم تعريف KM_TAG_PURPOSE في keymaster_defs.h.)

تتم ترجمة القيم بطريقة مباشرة إلى أنواع ASN.1، وفقًا لهذا الجدول:

نوع المفتاح الرئيسي نوع ASN.1
ENUM عدد صحيح
ENUM_REP مجموعة من عدد صحيح
UINT عدد صحيح
UINT_REP مجموعة من عدد صحيح
ULONG عدد صحيح
ULONG_REP مجموعة من عدد صحيح
DATE عدد صحيح (ملي ثانية منذ 1 يناير 1970 00:00:00 بتوقيت جرينتش)
BOOL NULL (في keymaster، العلامة موجودة تعني صحيح، غائبة تعني خطأ.
تنطبق نفس الدلالات على ترميز ASN.1)
BIGNUM غير مستخدم حاليًا، لذا لم يتم تحديد أي تعيين
BYTES OCTET_STRING

مخطط

يتم وصف محتوى ملحق الشهادة بواسطة مخطط ASN.1 التالي.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  applicationId               [601] EXPLICIT OCTET_STRING OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

حقول وصف المفتاح

يتم تعريف حقلي keymasterVersion و attestationChallenge موضعيًا، بدلاً من العلامة، لذا فإن العلامات الموجودة في النموذج المشفر تحدد نوع الحقل فقط. يتم وضع علامة على الحقول المتبقية ضمنيًا كما هو محدد في المخطط.

اسم الحقل يكتب قيمة
attestationVersion عدد صحيح إصدار مخطط التصديق: 1، 2، أو 3.
attestationSecurity مستوى الأمان المستوى الأمني ​​لهذه الشهادة. من الممكن الحصول على شهادات البرامج للمفاتيح المدعومة بالأجهزة. لا يمكن الوثوق بمثل هذه الشهادات إذا تم اختراق نظام Android.
keymasterVersion عدد صحيح إصدار جهاز keymaster: 0، 1، 2، 3، أو 4.
keymasterSecurity مستوى الأمان مستوى الأمان لتطبيق keymaster.
attestationChallenge OCTET_STRING قيمة Tag::ATTESTATION_CHALLENGE ، المحددة لطلب التصديق.
uniqueId OCTET_STRING معرف فريد اختياري، موجود إذا كان المفتاح يحتوي على Tag::INCLUDE_UNIQUE_ID
softwareEnforced قائمة التفويض تفويضات مدير المفاتيح الاختيارية التي لا يتم فرضها بواسطة TEE، إن وجدت.
teeEnforced قائمة التفويض تفويضات Keymaster الاختيارية التي يتم فرضها بواسطة TEE، إن وجدت.

حقول قائمة التفويض

تعتبر حقول AuthorizationList كلها اختيارية ويتم تحديدها بواسطة قيمة علامة keymaster، مع إخفاء بتات النوع. يتم استخدام العلامات الصريحة بحيث تحتوي الحقول أيضًا على علامة تشير إلى نوع ASN.1 الخاص بها، لتسهيل التحليل.

للحصول على تفاصيل حول قيم كل حقل، راجع types.hal لـ Keymaster 3 و keymaster_defs.h لـ Keymaster 2 وما يليه. تم تحويل أسماء علامات Keymaster إلى أسماء حقول عن طريق حذف البادئة KM_TAG وتغيير الباقي إلى حالة الجمل، لذلك أصبح Tag::KEY_SIZE هو keySize .

حقول RootOfTrust

يتم تحديد حقول RootOfTrust موضعيًا.

اسم الحقل يكتب قيمة
verifiedBootKey OCTET_STRING تجزئة آمنة للمفتاح المستخدم للتحقق من صورة النظام. يوصى باستخدام SHA-256.
deviceLocked منطقية صحيح إذا تم قفل أداة تحميل التشغيل، مما يعني أنه يمكن وميض الصور الموقعة فقط، ويتم التحقق من التحقق من التمهيد.
verifiedBootState VerifiedBootState حالة التمهيد الذي تم التحقق منه.
verifiedBootHash OCTET_STRING ملخص لجميع البيانات المحمية بواسطة Verified Boot. بالنسبة للأجهزة التي تستخدم تطبيق Android Verified Boot لـ Verified Boot، تحتوي هذه القيمة على ملخص بنية VBMeta ، أو بنية البيانات التعريفية Verified Boot. لمعرفة المزيد حول كيفية حساب هذه القيمة، راجعملخص VBMeta

قيم VerifiedBootState

قيم verifiedBootState لها المعاني التالية:

قيمة معنى
Verified يشير إلى سلسلة ثقة كاملة تمتد من أداة تحميل التشغيل إلى الأقسام التي تم التحقق منها، بما في ذلك أداة تحميل التشغيل وقسم التمهيد وجميع الأقسام التي تم التحقق منها.
في هذه الحالة، تكون قيمة verifiedBootKey هي تجزئة الشهادة المضمنة، مما يعني حرق الشهادة غير القابلة للتغيير في ذاكرة القراءة فقط (ROM).
تتوافق هذه الحالة مع حالة التمهيد الخضراء كما هو موثق في وثائق تدفق التمهيد التي تم التحقق منها .
SelfSigned يشير إلى أنه تم التحقق من قسم التمهيد باستخدام الشهادة المضمنة، وأن التوقيع صالح. يعرض برنامج تحميل التشغيل تحذيرًا وبصمة المفتاح العام قبل السماح بمواصلة عملية التمهيد.
في هذه الحالة، تكون قيمة verifiedBootKey هي تجزئة شهادة التوقيع الذاتي.
تتوافق هذه الحالة مع حالة التمهيد الصفراء كما هو موثق في وثائق تدفق التمهيد التي تم التحقق منها .
Unverified يشير إلى إمكانية تعديل الجهاز بحرية. يتم ترك سلامة الجهاز للمستخدم للتحقق خارج النطاق. يعرض برنامج تحميل التشغيل تحذيرًا للمستخدم قبل السماح بمواصلة عملية التمهيد.
في هذه الحالة، تكون قيمة verifiedBootKey فارغة.
تتوافق هذه الحالة مع حالة التمهيد البرتقالية كما هو موثق في وثائق تدفق التمهيد التي تم التحقق منها .
Failed يشير إلى فشل الجهاز في التحقق. لا توجد شهادة تصديق تحتوي فعليًا على هذه القيمة، لأنه في هذه الحالة يتوقف أداة تحميل التشغيل. لقد تم تضمينه هنا من أجل اكتماله.
تتوافق هذه الحالة مع حالة التمهيد الحمراء كما هو موثق في وثائق تدفق التمهيد التي تم التحقق منها .

قيم مستوى الأمان

قيم securityLevel لها المعاني التالية:

قيمة معنى
Software يتم تنفيذ الكود الذي ينشئ أو يدير العنصر ذي الصلة (الشهادة أو المفتاح) في نظام Android ويمكن تغييره في حالة اختراق هذا النظام.
TrustedEnvironment يتم تنفيذ التعليمات البرمجية التي تنشئ أو تدير العنصر ذي الصلة (الشهادة أو المفتاح) في بيئة تنفيذ موثوقة (TEE). يمكن تغييره إذا تم اختراق TEE، لكن TEE مقاوم للغاية للتسوية عن بعد ومقاوم بشكل معتدل للتسوية عن طريق الهجوم المباشر على الأجهزة.
StrongBox يتم تنفيذ الكود الذي ينشئ أو يدير العنصر ذي الصلة (الشهادة أو المفتاح) في وحدة أمان الأجهزة المخصصة. يمكن تغييرها في حالة تعرض وحدة أمان الأجهزة للاختراق، ولكنها شديدة المقاومة للاختراق عن بعد ومقاومة للغاية للاختراق عن طريق الهجوم المباشر على الأجهزة.

معرف فريد

المعرف الفريد عبارة عن قيمة 128 بت تحدد الجهاز، ولكن لفترة زمنية محدودة فقط. يتم حساب القيمة باستخدام:

HMAC_SHA256(T || C || R, HBK)

أين:

  • T هي "قيمة العداد الزمني"، ويتم حسابها عن طريق قسمة قيمة Tag::CREATION_DATETIME على 2592000000، مع إسقاط أي باقي. يتغير T كل 30 يومًا (2592000000 = 30 * 24 * 60 * 60 * 1000).
  • C هي قيمة Tag::APPLICATION_ID
  • R تكون 1 إذا كانت Tag::RESET_SINCE_ID_ROTATION موجودة في المعلمة attest_params لاستدعاء attest_key، أو 0 إذا كانت العلامة غير موجودة.
  • يعد HBK سرًا فريدًا مرتبطًا بالأجهزة ومعروفًا ببيئة التنفيذ الموثوقة ولم تكشف عنه أبدًا. يحتوي السر على 128 بت على الأقل من الإنتروبيا وهو فريد بالنسبة للجهاز الفردي (التفرد الاحتمالي مقبول بالنظر إلى 128 بت من الإنتروبيا). يجب أن يتم اشتقاق HBK من مادة رئيسية مدمجة عبر HMAC أو AES_CMAC.

قم باقتطاع إخراج HMAC_SHA256 إلى 128 بت.

مفاتيح التصديق والشهادات

يتم توفير مفتاحين، أحدهما RSA وواحد ECDSA، وسلاسل الشهادات المقابلة، بشكل آمن في الجهاز.

يقدم Android 12 ميزة Remote Key Provisioning، ويتطلب Android 13 أن تقوم الأجهزة بتنفيذها. يوفر Remote Key Provisioning للأجهزة الموجودة في الميدان شهادات تصديق ECDSA P256 لكل تطبيق. تكون هذه الشهادات أقصر عمرًا من الشهادات المقدمة من المصنع.

عدة IMEIs

يضيف Android 14 دعمًا لرموز IMEI المتعددة في سجل Android Key Attestation. يمكن لمصنعي المعدات الأصلية تنفيذ هذه الميزة عن طريق إضافة علامة KeyMint لرقم IMEI ثانٍ. لقد أصبح من الشائع بشكل متزايد أن تحتوي الأجهزة على أجهزة راديو خلوية متعددة ويمكن لمصنعي المعدات الأصلية الآن دعم الأجهزة التي تحتوي على اثنين من IMEIs.

يُطلب من مصنعي المعدات الأصلية أن يكون لديهم IMEI ثانوي، إذا كان موجودًا على أجهزتهم، ليتم توفيره لتطبيق (تطبيقات) KeyMint بحيث يمكن لتلك التطبيقات أن تشهد عليه بنفس الطريقة التي تشهد بها على IMEI الأول

شهادة الهوية

يتضمن Android 8.0 دعمًا اختياريًا لتصديق الهوية للأجهزة التي تستخدم Keymaster 3. وتسمح شهادة الهوية للجهاز بتقديم دليل على معرفات الأجهزة الخاصة به، مثل الرقم التسلسلي أو IMEI. على الرغم من أنها ميزة اختيارية، فمن المستحسن بشدة أن توفر جميع تطبيقات Keymaster 3 الدعم لها لأن القدرة على إثبات هوية الجهاز تتيح حالات الاستخدام مثل التكوين الحقيقي عن بعد بدون لمس أن تكون أكثر أمانًا (لأن الجانب البعيد يمكن أن يكون متأكدًا من ذلك) يتحدث إلى الجهاز الصحيح، وليس جهازًا ينتحل هويته).

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

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

خصائص التخزين

يجب أن تحتوي وحدة التخزين التي تحتوي على معرفات الجهاز على هذه الخصائص:

  • يتم نسخ القيم المشتقة من المعرفات الأصلية للجهاز إلى وحدة التخزين قبل مغادرة الجهاز للمصنع.
  • يمكن للأسلوب destroyAttestationIds() تدمير هذه النسخة من البيانات المشتقة من المعرف بشكل دائم. ويعني التدمير الدائم أن البيانات قد تمت إزالتها بالكامل، لذا لا يمكن إعادة ضبط المصنع أو أي إجراء آخر يتم إجراؤه على الجهاز لاستعادتها. يعد هذا مهمًا بشكل خاص للأجهزة التي قام المستخدم فيها بإلغاء قفل أداة تحميل التشغيل وتغيير برنامج النظام وتعديل المعرفات التي تم إرجاعها بواسطة أطر عمل Android.
  • يجب أن تتمتع مرافق RMA بالقدرة على إنشاء نسخ جديدة من البيانات المشتقة من معرف الأجهزة. بهذه الطريقة، يمكن للجهاز الذي يمر عبر RMA إجراء تصديق الهوية مرة أخرى. يجب حماية الآلية التي تستخدمها مرافق RMA بحيث لا يتمكن المستخدمون من استدعاءها بأنفسهم، لأن ذلك سيسمح لهم بالحصول على شهادات المعرفات المخادعة.
  • لا يوجد رمز آخر غير تطبيق Keymaster الموثوق به في TEE قادر على قراءة البيانات المشتقة من المعرف المحفوظة في وحدة التخزين.
  • التخزين واضح للتلاعب: إذا تم تعديل محتوى التخزين، فإن TEE يعامله بنفس الطريقة كما لو تم إتلاف نسخ المحتوى ويرفض جميع محاولات التصديق على الهوية. ويتم تنفيذ ذلك عن طريق التوقيع على وحدة التخزين أو تشغيلها كما هو موضح أدناه .
  • لا يحتفظ التخزين بالمعرفات الأصلية. نظرًا لأن تصديق الهوية ينطوي على تحدي، يقوم المتصل دائمًا بتوفير المعرفات المراد تصديقها. يحتاج TEE فقط إلى التحقق من تطابق هذه القيم مع القيم الموجودة في الأصل. يؤدي تخزين التجزئة الآمنة للقيم الأصلية بدلاً من القيم إلى تمكين هذا التحقق.

بناء

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

S = D || HMAC(HBK, D)

أين:

  • D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
  • HMAC هو بناء HMAC مع تجزئة آمنة مناسبة (يوصى باستخدام SHA-256)
  • HBK هو مفتاح مرتبط بالأجهزة ولا يستخدم لأي غرض آخر
  • ID 1 ...ID n هي قيم المعرف الأصلية؛ يعتمد ربط قيمة معينة بفهرس معين على التنفيذ، حيث سيكون للأجهزة المختلفة أعداد مختلفة من المعرفات
  • || يمثل التسلسل

نظرًا لأن مخرجات HMAC ذات حجم ثابت، فلا يلزم وجود رؤوس أو بنية أخرى لتتمكن من العثور على تجزئات معرف فردية، أو HMAC لـ D. بالإضافة إلى التحقق من القيم المقدمة لإجراء المصادقة، تحتاج التطبيقات إلى التحقق من صحة S عن طريق استخراج D من S ، حساب HMAC(HBK, D) ومقارنتها بالقيمة الموجودة في S للتحقق من عدم تعديل/إتلاف معرفات فردية. كما يجب أن تستخدم التطبيقات مقارنات زمنية ثابتة لجميع عناصر المعرفات الفردية والتحقق من صحة S. ويجب أن يكون وقت المقارنة ثابتًا بغض النظر عن عدد المعرفات المقدمة والمطابقة الصحيحة لأي جزء من الاختبار.

معرفات الأجهزة

تدعم شهادة المعرف معرفات الأجهزة التالية:

  1. اسم العلامة التجارية، كما تم إرجاعه بواسطة Build.BRAND في Android
  2. اسم الجهاز، كما تم إرجاعه بواسطة Build.DEVICE في Android
  3. اسم المنتج، كما تم إرجاعه بواسطة Build.PRODUCT في Android
  4. اسم الشركة المصنعة، كما تم إرجاعه بواسطة Build.MANUFACTURER في Android
  5. اسم النموذج، كما تم إرجاعه بواسطة Build.MODEL في Android
  6. رقم سري
  7. IMEIs لجميع أجهزة الراديو
  8. MEIDs لجميع أجهزة الراديو

لدعم شهادة معرف الجهاز، يشهد الجهاز على هذه المعرفات. تحتوي جميع الأجهزة التي تعمل بنظام Android على الستة الأولى وهي ضرورية لكي تعمل هذه الميزة. إذا كان الجهاز يحتوي على أي أجهزة راديو خلوية مدمجة، فيجب أن يدعم الجهاز أيضًا مصادقة أرقام IMEI و/أو معرفات MEID الخاصة بأجهزة الراديو.

يتم طلب شهادة الهوية عن طريق إجراء شهادة رئيسية وتضمين معرفات الجهاز للتصديق عليها في الطلب. يتم وضع علامة على المعرفات على النحو التالي:

  • ATTESTATION_ID_BRAND
  • ATTESTATION_ID_DEVICE
  • ATTESTATION_ID_PRODUCT
  • ATTESTATION_ID_MANUFACTURER
  • ATTESTATION_ID_MODEL
  • ATTESTATION_ID_SERIAL
  • ATTESTATION_ID_IMEI
  • ATTESTATION_ID_MEID

المعرف المطلوب التصديق عليه هو سلسلة بايت مشفرة بترميز UTF-8. ينطبق هذا التنسيق على المعرفات الرقمية أيضًا. يتم التعبير عن كل معرف يتم التصديق عليه كسلسلة مشفرة UTF-8.

إذا كان الجهاز لا يدعم تصديق المعرف (أو تم استدعاء destroyAttestationIds() مسبقًا ولم يعد الجهاز قادرًا على تصديق المعرفات الخاصة به)، فسيفشل أي طلب تصديق مفتاح يتضمن واحدة أو أكثر من هذه العلامات مع ErrorCode::CANNOT_ATTEST_IDS .

إذا كان الجهاز يدعم شهادة المعرف وتم تضمين واحدة أو أكثر من العلامات المذكورة أعلاه في طلب شهادة المفتاح، فإن TEE تتحقق من أن المعرف المزود مع كل علامة من العلامات يطابق نسخته من معرفات الأجهزة. إذا لم يتطابق معرف واحد أو أكثر، فستفشل المصادقة بأكملها مع ErrorCode::CANNOT_ATTEST_IDS . من الصالح أن يتم توفير نفس العلامة عدة مرات. قد يكون هذا مفيدًا، على سبيل المثال، عند التصديق على هويات IMEI: قد يحتوي الجهاز على أجهزة راديو متعددة بها هويات IMEI متعددة. يكون طلب التصديق صالحًا إذا كانت القيمة المقدمة مع كل ATTESTATION_ID_IMEI تتطابق مع أحد أجهزة الراديو الخاصة بالجهاز. وينطبق الشيء نفسه على جميع العلامات الأخرى.

في حالة نجاح التصديق، تتم إضافة المعرفات المصدقة إلى ملحق التصديق (OID 1.3.6.1.4.1.11129.2.1.17) لشهادة التصديق الصادرة، باستخدام المخطط الوارد أعلاه . التغييرات التي تم إجراؤها على مخطط تصديق Keymaster 2 تظهر بالخط العريض مع التعليقات.

جافا API

هذا القسم إعلامي فقط. لا يقوم منفذو Keymaster بتنفيذ أو استخدام Java API. يتم توفير ذلك لمساعدة المنفذين على فهم كيفية استخدام التطبيقات لهذه الميزة. قد تستخدمها مكونات النظام بشكل مختلف، ولهذا السبب من المهم عدم التعامل مع هذا القسم على أنه معياري.