เอกสารรับรองคีย์และรหัส

คีย์สโตร์ช่วยให้สร้าง จัดเก็บ และใช้การเข้ารหัสได้อย่างปลอดภัยยิ่งขึ้น ควบคุมได้เสมอ เมื่อพื้นที่เก็บข้อมูลคีย์แบบใช้ฮาร์ดแวร์พร้อมใช้งานและ ใช้ ทำให้เนื้อหาคีย์ปลอดภัยยิ่งขึ้นจากการดึงออกจากอุปกรณ์ และ Keymaster บังคับใช้ข้อจำกัดที่ลบล้างได้ยาก

แต่จะเป็นความจริงก็ต่อเมื่อทราบว่าคีย์คีย์สโตร์อยู่ใน พื้นที่เก็บข้อมูลที่ใช้ฮาร์ดแวร์ ใน Keymaster 1 ไม่มี วิธีสำหรับแอปหรือ เซิร์ฟเวอร์ระยะไกลสำหรับตรวจสอบที่น่าเชื่อถือว่าเป็นกรณีนี้หรือไม่ Daemon ของคีย์สโตร์ โหลด HAL คีย์มาสเตอร์ที่พร้อมใช้งาน และเชื่อไม่ว่า HAL จะพูดอะไรก็ตาม ที่เกี่ยวข้องกับการ สำรองข้อมูลของฮาร์ดแวร์คีย์

Keymaster แก้ไขปัญหานี้โดยเปิดตัวเอกสารรับรองคีย์ใน Android 7.0 (Keymaster 2) และรหัส เอกสารรับรองใน Android 8.0 (Keymaster 3)

เอกสารรับรองหลักมีจุดประสงค์เพื่อให้ ดูว่าคู่คีย์อสมมาตรเป็นแบบใช้ฮาร์ดแวร์หรือไม่ คุณสมบัติ และข้อจำกัด และข้อจำกัดใดมีผลกับการใช้งาน

เอกสารรับรองรหัสช่วยให้อุปกรณ์แสดงหลักฐานของตัวระบุฮาร์ดแวร์ได้ เช่น หมายเลขซีเรียลหรือ IMEI

เอกสารรับรองคีย์

Android 7.0 ได้เปิดตัวชุดแท็ก ประเภท และ ลงใน 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 วิธี

คีย์มาสเตอร์ 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 คือโครงสร้างอุปกรณ์คีย์มาสเตอร์
• keyToAttest เป็น BLOB คีย์ที่แสดงผลจาก generateKey ที่จะสร้างเอกสารรับรอง
• attestParams คือรายการพารามิเตอร์ที่จำเป็นสำหรับ และการรับรอง ซึ่งรวมถึง Tag::ATTESTATION_CHALLENGE และ อาจเป็น Tag::RESET_SINCE_ID_ROTATION และ Tag::APPLICATION_ID และ Tag::APPLICATION_DATA 2 อย่างหลังจำเป็นต่อการถอดรหัส BLOB คีย์ หากมีการระบุ ในระหว่างการสร้างคีย์
• certChain คือพารามิเตอร์เอาต์พุต ซึ่งจะแสดงผลอาร์เรย์ของ ใบรับรอง รายการ 0 คือ ใบรับรองของเอกสารรับรอง ซึ่งหมายความว่า รับรองคีย์จาก keyToAttest และมี ของส่วนขยายเอกสารรับรอง

เมธอด attestKey ถือเป็นการดำเนินการคีย์สาธารณะใน คีย์ที่ผ่านการรับรอง เนื่องจากสามารถเรียกใช้ได้ตลอดเวลาและไม่จำเป็นต้องตรงตาม และข้อจำกัดการให้สิทธิ์ ตัวอย่างเช่น หากคีย์ที่ได้รับการรับรองต้องการผู้ใช้ การตรวจสอบสิทธิ์สำหรับการใช้งาน สามารถสร้างเอกสารรับรองได้โดยไม่ต้องมีผู้ใช้ การตรวจสอบสิทธิ์

ใบรับรอง

เอกสารรับรองคือใบรับรอง X.509 มาตรฐานที่มีตัวเลือก ส่วนขยายเอกสารรับรองที่มีคำอธิบายของคีย์ที่ผ่านการรับรอง มีการเซ็นชื่อด้วยคีย์เอกสารรับรองที่ผ่านการรับรอง คีย์เอกสารรับรอง อาจใช้อัลกอริทึมที่แตกต่างจากคีย์ที่ได้รับการรับรอง

ใบรับรองของเอกสารรับรองมีช่องในตารางด้านล่างและไม่สามารถ มีช่องอื่นๆ อีก บางช่องระบุค่าคงที่ CTS จะตรวจสอบว่าเนื้อหาของใบรับรองตรงตามที่กำหนดทุกประการ

ใบรับรอง SEQUENCE

ลำดับใบรับรอง TBS

ส่วนขยายเอกสารรับรอง

ส่วนขยาย attestation มีคำอธิบายทั้งหมดของคีย์มาสเตอร์ ที่เชื่อมโยงกับคีย์ในโครงสร้างที่เกี่ยวข้องโดยตรง ไปยังรายการการให้สิทธิ์ตามที่ใช้ใน Android และ HAL ของคีย์มาสเตอร์ แต่ละแท็กใน รายการการให้สิทธิ์จะแสดงด้วย ASN.1 SEQUENCE อย่างชัดเจน ติดแท็กด้วยหมายเลขแท็กคีย์มาสเตอร์ แต่มีข้อบ่งชี้ประเภท (สูง 4 ระดับ เรียงลำดับบิต) ที่มาสก์ออก

ตัวอย่างเช่น ใน Keymaster 3 Tag::PURPOSE จะกำหนดไว้ใน type.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,
  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 ระบุฟิลด์ ตามตำแหน่งแทนที่จะเป็นแท็ก ดังนั้นแท็กในแบบฟอร์มที่เข้ารหัสจะระบุเพียง ประเภทช่อง ฟิลด์ที่เหลือจะมีการติดแท็กโดยปริยายตามที่ระบุไว้ใน สคีมา

ช่อง AuthorizationList

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

ค่าของ securityLevel มีความหมายดังต่อไปนี้

รหัสที่ไม่ซ้ำกัน

"รหัสที่ไม่ซ้ำกัน" คือค่า 128 บิตที่ระบุอุปกรณ์ แต่จะระบุเฉพาะสำหรับ ระยะเวลาจำกัด ค่าจะคำนวณด้วย

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

สถานที่:

• T คือ "ค่าตัวนับชั่วคราว" ซึ่งคำนวณโดยการหารค่า มูลค่า Tag::CREATION_DATETIME x 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 เป็นข้อมูลลับเฉพาะซึ่งอยู่ภายใต้ฮาร์ดแวร์ซึ่งเป็นที่รู้จักของ Trusted สภาพแวดล้อมการดำเนินการและไม่เปิดเผยให้ทราบ ข้อมูลลับมีอย่างน้อย เอนโทรปี 128 บิตและไม่ซ้ำกันสำหรับแต่ละอุปกรณ์ (ความน่าจะเป็น เป็นที่ยอมรับได้โดยพิจารณาจากเอนโทรปี 128 บิต) HBK ควรเป็น ได้มาจากเนื้อหาคีย์รวมผ่าน HMAC หรือ AES_CMAC

ตัดเอาต์พุต HMAC_SHA256 ให้เหลือ 128 บิต

คีย์เอกสารรับรองและ ใบรับรอง

คีย์ 2 คีย์ ได้แก่ RSA 1 คีย์และ ECDSA 1 คีย์ และเชนใบรับรองที่เกี่ยวข้อง ได้แก่ ในอุปกรณ์อย่างปลอดภัย

Android 12 เปิดตัวการจัดสรรคีย์ระยะไกล และ Android 13 ต้องใช้อุปกรณ์ ที่ลงมือทำจริงๆ การจัดสรรคีย์ระยะไกลเป็นการจัดเตรียมอุปกรณ์ในภาคสนามด้วย ตามแอปพลิเคชัน ใบรับรองเอกสารรับรอง ECDSA P256 ใบรับรองเหล่านี้ มีอายุสั้นกว่าใบรับรองที่โรงงานจัดสรร

IMEI หลายหมายเลข

Android 14 เพิ่มการรองรับ IMEI หลายหมายเลขใน บันทึกเอกสารรับรองคีย์ Android OEM ใช้ฟีเจอร์นี้ได้โดยการเพิ่มแท็ก KeyMint สำหรับ IMEI ที่ 2 อุปกรณ์ต่างๆ มีสัญญาณโทรศัพท์มือถือหลายสัญญาณ เริ่มมีการใช้มากขึ้นเรื่อยๆ และ OEM รองรับอุปกรณ์ที่มี IMEI 2 หมายเลขแล้ว

OEM ต้องมี IMEI รอง (หากมีในอุปกรณ์) ให้กับการใช้งาน KeyMint เพื่อให้การติดตั้งใช้งานดังกล่าวสามารถ โดยใช้วิธีเดียวกันกับที่ใช้รับรองใน IMEI แรก

เอกสารรับรองรหัส

Android 8.0 มีการสนับสนุนที่ไม่บังคับสำหรับเอกสารรับรองรหัสสำหรับอุปกรณ์ที่มี Keymaster 3 เอกสารรับรองรหัสช่วยให้อุปกรณ์แสดงหลักฐานของฮาร์ดแวร์ได้ เช่น หมายเลขซีเรียลหรือ IMEI แม้ว่าจะเป็นฟีเจอร์เสริม แต่ ขอแนะนำให้การใช้ Keymaster 3 ทั้งหมดให้การสนับสนุน เนื่องจากความสามารถในการพิสูจน์ตัวตนของอุปกรณ์ทำให้มีการใช้งานกรณีการใช้งานต่างๆ เช่น true การกำหนดค่ารีโมตอุปกรณ์พร้อมใช้แบบรวมกลุ่มเพื่อให้ปลอดภัยยิ่งขึ้น (เนื่องจากอุปกรณ์ระยะไกลสามารถ มั่นใจว่ากำลังพูดกับอุปกรณ์ที่ถูกต้อง ไม่ใช่การปลอมแปลงอุปกรณ์ ตัวตน)

เอกสารรับรองรหัสทำงานโดยการสร้างสำเนาของตัวระบุฮาร์ดแวร์ของอุปกรณ์ ซึ่งมีเฉพาะสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เท่านั้นที่เข้าถึงได้ก่อนอุปกรณ์ จะออกจากโรงงาน ผู้ใช้สามารถปลดล็อก Bootloader ของอุปกรณ์และเปลี่ยนแปลง ซอฟต์แวร์ระบบและตัวระบุที่รายงานโดยเฟรมเวิร์ก Android สำเนาของตัวระบุที่ TEE เก็บไว้จะไม่ได้รับอนุญาตในลักษณะนี้ การตรวจสอบว่าเอกสารรับรองรหัสอุปกรณ์จะต้องรับรองกับอุปกรณ์เท่านั้น ตัวระบุฮาร์ดแวร์ต้นฉบับ ซึ่งจะป้องกันความพยายามในการปลอมแปลง

แพลตฟอร์ม API หลักสำหรับบิลด์เอกสารรับรองรหัสแทนคีย์ที่มีอยู่ เปิดตัวกลไกเอกสารรับรองใน Keymaster 2 เมื่อส่งคำขอ ใบรับรองของคีย์ซึ่งเก็บไว้โดยคีย์มาสเตอร์ ผู้โทรอาจขอ มีการระบุตัวระบุฮาร์ดแวร์ของอุปกรณ์ในเอกสารรับรอง ข้อมูลเมตาของใบรับรอง หากเก็บคีย์ไว้ใน TEE ใบรับรองจะ ห่วงโซ่กลับไปยังฐานรากของความไว้วางใจที่เป็นที่รู้จัก ผู้รับใบรับรองดังกล่าวสามารถ ตรวจสอบว่าใบรับรองและเนื้อหาภายในนั้น รวมถึงฮาร์ดแวร์ ซึ่งเขียนโดย TEE เมื่อระบบขอให้รวมฮาร์ดแวร์ ในใบรับรอง ซึ่ง TEE รับรองเฉพาะ ที่เก็บไว้ในพื้นที่เก็บข้อมูล ตามที่ป้อนในพื้นที่โรงงาน

คุณสมบัติของพื้นที่เก็บข้อมูล

พื้นที่เก็บข้อมูลที่มีตัวระบุของอุปกรณ์ต้องมีพร็อพเพอร์ตี้ต่อไปนี้

• ระบบจะคัดลอกค่าที่ได้จากตัวระบุดั้งเดิมของอุปกรณ์ไปยัง ก่อนที่อุปกรณ์จะออกจากโรงงาน
• เมธอด destroyAttestationIds() สามารถทําลายอย่างถาวร สำเนาข้อมูลที่ตัวระบุได้มานี้ การทำลายอย่างถาวรหมายถึง ข้อมูลจะถูกนำออกโดยสมบูรณ์ ดังนั้นทั้งการรีเซ็ตเป็นค่าเริ่มต้นหรือข้อมูลใดๆ บนอุปกรณ์จะสามารถกู้คืนได้ โดยเฉพาะอย่างยิ่ง สำคัญสำหรับอุปกรณ์ที่ผู้ใช้ปลดล็อก Bootloader และเปลี่ยนแปลง ซอฟต์แวร์ระบบและแก้ไขตัวระบุที่ Android แสดงผล ของ Google
• หน่วยงาน RMA ควรที่จะสามารถ สร้างสำเนาใหม่ของข้อมูลที่ตัวระบุฮาร์ดแวร์ได้รับ วิธีนี้ทำให้ อุปกรณ์ที่ผ่าน RMA จะใช้เอกสารรับรองของบัตรประจำตัวได้อีกครั้ง กลไก RMA ที่ใช้ต้องได้รับการปกป้อง เพื่อไม่ให้ผู้ใช้ เรียกใช้ด้วยตนเอง เนื่องจากจะช่วยให้พวกเขาได้รับเอกสารรับรองของ รหัสที่ถูกปลอมแปลง
• ไม่มีโค้ดใดนอกจากแอป Keymaster ที่เชื่อถือได้ใน TEE ที่อ่าน เก็บข้อมูลที่ได้จากตัวระบุไว้ในพื้นที่เก็บข้อมูล
• พื้นที่เก็บข้อมูลมีการงัดแงะ ถ้าเนื้อหาของพื้นที่เก็บข้อมูลถูกดัดแปลง แก้ไขแล้ว TEE ปฏิบัติเช่นเดียวกันหากสำเนาเนื้อหาได้ ถูกทำลายและปฏิเสธความพยายามในเอกสารรับรองรหัสทั้งหมด เรานำวิธีนี้มาใช้ โดยการลงชื่อหรือการใช้ MAC ที่จัดเก็บข้อมูลตามที่อธิบายไว้ ที่ด้านล่าง
• พื้นที่เก็บข้อมูลจะไม่เก็บตัวระบุเดิม เนื่องจากเอกสารรับรองรหัส ต้องเผชิญกับความท้าทาย โดยผู้โทรมักจะให้ตัวระบุที่จะเป็น ได้รับการรับรอง TEE เพียงแค่ต้องยืนยันว่าค่าเหล่านี้ตรงกับค่าที่พวกเขา แต่เดิมมี การจัดเก็บแฮชที่ปลอดภัยของค่าดั้งเดิม ค่าต่างๆ จะเปิดใช้การยืนยันนี้

การก่อสร้าง

หากต้องการสร้างการใช้งานที่มีพร็อพเพอร์ตี้ตามรายการด้านบน ให้จัดเก็บ ค่าที่มาจากรหัสในโครงสร้าง S ต่อไปนี้ ไม่ต้องจัดเก็บสำเนาอื่นๆ ของ ยกเว้นตำแหน่งปกติในระบบซึ่งเจ้าของอุปกรณ์ อาจแก้ไขด้วยการรูท:

S = D || HMAC(HBK, D)

โดยมี

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC เป็นโครงสร้าง HMAC ที่มีแฮชที่ปลอดภัยที่เหมาะสม (แนะนำให้ใช้ SHA-256)
• HBK เป็นคีย์ที่ผูกกับฮาร์ดแวร์ซึ่งไม่ได้ใช้เพื่อวัตถุประสงค์อื่น
• ID1...IDn คือค่ารหัสเดิม การเชื่อมโยงของ ค่าเฉพาะของดัชนีหนึ่งๆ จะขึ้นอยู่กับการใช้งาน เช่น อุปกรณ์ต่างๆ จะมีจำนวนตัวระบุที่แตกต่างกัน
• || แสดงถึงการต่อ

เนื่องจากเอาต์พุต HMAC มีขนาดคงที่ จึงไม่มีส่วนหัวหรือโครงสร้างอื่นๆ เพื่อค้นหาแฮช ID แต่ละรายการ หรือ 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. IMEI ของวิทยุทั้งหมด
8. MEID ของวิทยุทั้งหมด

อุปกรณ์จะรับรองตัวระบุเหล่านี้เพื่อรองรับเอกสารรับรองรหัสอุปกรณ์ ทั้งหมด อุปกรณ์ที่ใช้ Android จะมี 6 อย่างแรกและจำเป็นต้องใช้ ฟีเจอร์ที่ใช้งานได้ หากอุปกรณ์มีสัญญาณวิทยุมือถือในตัว ต้องรองรับเอกสารรับรองสำหรับ 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

หากอุปกรณ์รองรับเอกสารรับรองรหัสและแท็กข้างต้นอย่างน้อย 1 แท็กมี รวมอยู่ในคำขอเอกสารรับรองคีย์แล้ว TEE เป็นผู้ยืนยันตัวระบุ ที่ให้มากับแต่ละแท็กตรงกับสำเนาของตัวระบุฮาร์ดแวร์ ถ้า ตัวระบุอย่างน้อย 1 รายการไม่ตรงกัน การรับรองทั้งหมดล้มเหลว ErrorCode::CANNOT_ATTEST_IDS แท็กเดียวกันสามารถใช้เป็น ระบุหลายครั้ง ซึ่งจะเป็นประโยชน์ เช่น เมื่อรับรอง IMEI ดังนี้ อุปกรณ์อาจมีวิทยุหลายตัวที่มี IMEI หลายหมายเลข คำขอเอกสารรับรองคือ ถูกต้องหากค่าที่ระบุพร้อมกับ ATTESTATION_ID_IMEI แต่ละรายการตรงกัน วิทยุของอุปกรณ์ แท็กอื่นๆ ทั้งหมดจะมีผลในลักษณะเดียวกัน

หากเอกสารรับรองสำเร็จ ระบบจะเพิ่มรหัสที่ยืนยันแล้วลงใน ส่วนขยายเอกสารรับรอง (OID 1.3.6.1.4.1.11129.2.1.17) ของใบรับรองเอกสารรับรองที่ออก โดยใช้สคีมาจากด้านบน การเปลี่ยนแปลงจาก Keymaster 2 สคีมาเอกสารรับรองจะเป็นตัวหนาพร้อมความคิดเห็น

API ของ Java

ส่วนนี้เป็นเพียงการให้ข้อมูลเท่านั้น ทั้งผู้ใช้ 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].