تصديق المفتاح والمعرف

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

هذا صحيح فقط ، ومع ذلك ، إذا كان من المعروف أن مفاتيح تخزين المفاتيح موجودة في التخزين المدعوم من الأجهزة. في Keymaster 1 ، لم تكن هناك طريقة للتطبيقات أو الخوادم البعيدة للتحقق بشكل موثوق مما إذا كانت هذه هي الحالة. قام برنامج keystore بتحميل مدير المفاتيح المتوفر 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

يكتب

Keymaster 2 وما دون

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

طريقة AttestKey

Keymaster 3

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

Keymaster 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 هو مفتاح blob الذي تم إرجاعه من 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 ) قيمة
شهادة تسلسل شهادة TBS
التوقيع الخوارزمية الخوارزمية معرف الخوارزمية المستخدمة لتوقيع المفتاح:
ECDSA لمفاتيح EC ، RSA لمفاتيح RSA.
التوقيعالقيمة سلسلة BIT ، التوقيع المحسوب على شهادة 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 Key" (القيمة الثابتة: نفس الشيء في جميع الشهادات)
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 ، حسب هذا الجدول:

نوع Keymaster نوع ASN.1
ENUM عدد صحيح
ENUM_REP مجموعة INTEGER
UINT عدد صحيح
UINT_REP مجموعة INTEGER
ULONG عدد صحيح
ULONG_REP مجموعة INTEGER
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),
}

حقول KeyDescription

يتم تحديد حقلي 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 ملخص لجميع البيانات المحمية بواسطة نظام التشغيل المتحقق منه. بالنسبة للأجهزة التي تستخدم تنفيذ Android Verified Boot لـ Verified Boot ، تحتوي هذه القيمة على ملخص لهيكل VBMeta ، أو بنية بيانات التعريف التي تم التحقق منها. لمعرفة المزيد حول كيفية حساب هذه القيمة ، راجع ملخص VBMeta

قيم VerifiedBootState

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

قيمة معنى
Verified يشير إلى وجود سلسلة ثقة كاملة تمتد من أداة تحميل التشغيل إلى الأقسام التي تم التحقق منها ، بما في ذلك أداة تحميل التشغيل وقسم التمهيد وجميع الأقسام التي تم التحقق منها.
في هذه الحالة ، تكون قيمة verifiedBootKey هي تجزئة الشهادة المضمنة ، مما يعني نسخ الشهادة غير القابلة للتغيير في ذاكرة القراءة فقط.
تتوافق هذه الحالة مع حالة التمهيد الأخضر كما هو موثق في وثائق تدفق التمهيد التي تم التحقق منها .
SelfSigned يشير إلى أنه تم التحقق من قسم التمهيد باستخدام الشهادة المضمنة ، وأن التوقيع صالح. يعرض برنامج bootloader تحذيرًا وبصمة المفتاح العام قبل السماح لعملية التمهيد بالاستمرار.
في هذه الحالة ، تكون قيمة verifiedBootKey هي تجزئة شهادة التوقيع الذاتي.
تتوافق هذه الحالة مع حالة التمهيد الأصفر كما هو موثق في وثائق تدفق التمهيد التي تم التحقق منها .
Unverified يشير إلى إمكانية تعديل الجهاز بحرية. يتم ترك سلامة الجهاز للمستخدم للتحقق من خارج النطاق. يعرض برنامج bootloader تحذيرًا للمستخدم قبل السماح لعملية التمهيد بالاستمرار.
في هذه الحالة ، تكون قيمة 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 توفير المفتاح البعيد ، ويتطلب Android 13 أن تقوم الأجهزة بتطبيقه. يوفر Remote Key Provisioning للأجهزة في الميدان شهادات تصديق ECDSA P256 لكل تطبيق. هذه الشهادات هي أقصر عمرا من الشهادات التي يوفرها المصنع.

تصديق الهوية

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

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

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

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

يحتاج التخزين الذي يحتوي على معرّفات الجهاز إلى هذه الخصائص:

  • يتم نسخ القيم المشتقة من معرّفات الجهاز الأصلية إلى التخزين قبل مغادرة الجهاز للمصنع.
  • يمكن أن يؤدي أسلوب destroyAttestationIds() إلى تدمير هذه النسخة من البيانات المشتقة من المعرف بشكل دائم. يعني التدمير الدائم أن البيانات تمت إزالتها تمامًا ، لذلك لا يمكن استعادة البيانات من قبل إعادة ضبط المصنع أو أي إجراء آخر يتم تنفيذه على الجهاز. هذا مهم بشكل خاص للأجهزة التي قام فيها المستخدم بإلغاء تأمين أداة تحميل التشغيل وتغيير برنامج النظام وتعديل المعرفات التي يتم إرجاعها بواسطة أطر عمل Android.
  • يجب أن تتمتع مرافق RMA بالقدرة على إنشاء نسخ جديدة من البيانات المشتقة من معرّفات الأجهزة. بهذه الطريقة ، يمكن للجهاز الذي يمر عبر RMA إجراء المصادقة على الهوية مرة أخرى. يجب حماية الآلية التي تستخدمها مرافق RMA بحيث لا يستطيع المستخدمون استدعاءها بأنفسهم ، لأن ذلك من شأنه أن يسمح لهم بالحصول على شهادات المعرفات المخادعة.
  • لا يوجد رمز بخلاف تطبيق Keymaster الموثوق به في TEE قادر على قراءة البيانات المشتقة من المعرف المحفوظة في التخزين.
  • التخزين واضح للعبث: إذا تم تعديل محتوى التخزين ، فإن TEE يعامله كما لو تم إتلاف نسخ المحتوى ويرفض جميع محاولات التصديق على الهوية. يتم تنفيذ ذلك عن طريق التوقيع أو MACing للتخزين كما هو موضح أدناه .
  • لا يحتوي التخزين على المعرفات الأصلية. نظرًا لأن التصديق على الهوية يتضمن تحديًا ، يقوم المتصل دائمًا بتوفير المعرفات ليتم التصديق عليها. يحتاج 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 على الأجهزة الستة الأولى وهي ضرورية حتى تعمل هذه الميزة. إذا كان الجهاز يحتوي على أي أجهزة راديو خلوية متكاملة ، فيجب أن يدعم الجهاز أيضًا شهادة IMEIs و / أو 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 . وهي صالحة لتزويد نفس العلامة عدة مرات. يمكن أن يكون هذا مفيدًا ، على سبيل المثال ، عند التصديق على IMEIs: قد يحتوي الجهاز على أجهزة راديو متعددة مع IMEIs متعددة. يكون طلب التصديق صالحًا إذا كانت القيمة المقدمة مع كل ATTESTATION_ID_IMEI تتطابق مع أحد أجهزة الراديو للجهاز. الأمر نفسه ينطبق على جميع العلامات الأخرى.

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

جافا API

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