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

يوفر 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 من أن محتوى الشهادة مطابق تمامًا لما هو محدد.

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

تسلسل شهادة TBS

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

يحتوي ملحق 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 التالي.

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 موضعيًا، بدلاً من العلامة، لذا فإن العلامات الموجودة في النموذج المشفر تحدد نوع الحقل فقط. يتم وضع علامة على الحقول المتبقية ضمنيًا كما هو محدد في المخطط.

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

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

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

حقول RootOfTrust

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

قيم VerifiedBootState

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

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

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

معرف فريد

المعرف الفريد عبارة عن قيمة 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. يتم توفير ذلك لمساعدة المنفذين على فهم كيفية استخدام التطبيقات لهذه الميزة. قد تستخدمها مكونات النظام بشكل مختلف، ولهذا السبب من المهم عدم التعامل مع هذا القسم على أنه معياري.

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].