การรับรองคีย์และ ID

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

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

เพื่อแก้ไขปัญหานี้ Keymaster ได้แนะนำการรับรองคีย์ ใน Android 7.0 (Keymaster 2) และการรับรอง ID ใน 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 คือโครงสร้างอุปกรณ์คีย์มาสเตอร์
• 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 จะตรวจสอบว่าเนื้อหาใบรับรองตรงตามที่กำหนดไว้ทุกประการ

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

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

การขยายเวลารับรอง

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

ตัวอย่างเช่น ใน 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 เป็นทางเลือกทั้งหมดและระบุด้วยค่าแท็กคีย์มาสเตอร์ โดยมีบิตประเภทถูกพรางไว้ การติดแท็กที่ชัดเจนถูกใช้เพื่อให้ฟิลด์ต่างๆ มีแท็กที่ระบุประเภท ASN.1 เพื่อให้แยกวิเคราะห์ได้ง่ายขึ้น

สำหรับรายละเอียดเกี่ยวกับค่าของแต่ละฟิลด์ โปรดดูที่ types.hal สำหรับ Keymaster 3 และ keymaster_defs.h สำหรับ Keymaster 2 และด้านล่าง ชื่อแท็กคีย์มาสเตอร์ถูกแปลงเป็นชื่อฟิลด์โดยละเว้นคำนำหน้า KM_TAG และเปลี่ยนส่วนที่เหลือเป็นตัวพิมพ์แบบคาเมล ดังนั้น Tag::KEY_SIZE จึงกลายเป็น keySize

ฟิลด์ RootOfTrust

ฟิลด์ RootOfTrust ถูกระบุตำแหน่ง

ค่า VerifiedBootState

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

ค่าระดับความปลอดภัย

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

ID ไม่ซ้ำกัน

รหัสเฉพาะคือค่า 128 บิตที่ใช้ระบุอุปกรณ์ แต่ในระยะเวลาที่จำกัดเท่านั้น ค่าจะถูกคำนวณด้วย:

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

ที่ไหน:

• T คือ "ค่าตัวนับชั่วคราว" ซึ่งคำนวณโดยการหารค่าของ Tag::CREATION_DATETIME ด้วย 2592000000 โดยให้ทิ้งเศษที่เหลือ T เปลี่ยนทุกๆ 30 วัน (2592000000 = 30 * 24 * 60 * 60 * 1,000)
• C คือค่าของ Tag::APPLICATION_ID
• R คือ 1 หาก Tag::RESET_SINCE_ID_ROTATION มีอยู่ในพารามิเตอร์ attest_params ของการเรียก attest_key หรือ 0 หากไม่มีแท็ก
• HBK เป็นความลับเฉพาะที่เชื่อมโยงกับฮาร์ดแวร์ซึ่งเป็นที่รู้จักใน Trusted Execution Environment และไม่เคยเปิดเผยโดยสิ่งนี้ ข้อมูลลับประกอบด้วยเอนโทรปีอย่างน้อย 128 บิตและไม่ซ้ำกันในแต่ละอุปกรณ์ (ความน่าจะเป็นที่ไม่ซ้ำใครเป็นที่ยอมรับได้เมื่อมีเอนโทรปี 128 บิต) HBK ควรได้มาจากวัสดุหลักที่หลอมรวมผ่าน HMAC หรือ AES_CMAC

ตัดทอนเอาต์พุต HMAC_SHA256 ให้เป็น 128 บิต

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

สองคีย์, หนึ่ง RSA และหนึ่ง ECDSA และห่วงโซ่ใบรับรองที่เกี่ยวข้อง ได้รับการจัดเตรียมอย่างปลอดภัยในอุปกรณ์

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

IMEI หลายรายการ

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

OEM จำเป็นต้องมี IMEI รอง หากมีอยู่ในอุปกรณ์ เพื่อจัดเตรียมการใช้งาน KeyMint เพื่อให้การใช้งานเหล่านั้นสามารถยืนยันได้ในลักษณะเดียวกับที่พวกเขายืนยันกับ IMEI แรก

การรับรองบัตรประจำตัว

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

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

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

คุณสมบัติการจัดเก็บ

พื้นที่จัดเก็บข้อมูลที่เก็บตัวระบุอุปกรณ์จะต้องมีคุณสมบัติเหล่านี้:

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

การก่อสร้าง

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

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 คือค่า ID ดั้งเดิม การเชื่อมโยงค่าเฉพาะกับดัชนีเฉพาะนั้นขึ้นอยู่กับการใช้งาน เนื่องจากอุปกรณ์ที่แตกต่างกันจะมีจำนวนตัวระบุที่แตกต่างกัน
• || แสดงถึงการต่อข้อมูล

เนื่องจากเอาต์พุต HMAC มีขนาดคงที่ จึงไม่จำเป็นต้องมีส่วนหัวหรือโครงสร้างอื่นเพื่อให้สามารถค้นหาแฮช ID แต่ละรายการหรือ HMAC ของ D นอกเหนือจากการตรวจสอบค่าที่ให้มาเพื่อดำเนินการรับรองแล้ว การใช้งานจำเป็นต้องตรวจสอบความถูกต้องของ S โดยแยก D ออกจาก S , คำนวณ HMAC(HBK, D) และเปรียบเทียบกับค่าใน S เพื่อตรวจสอบว่าไม่มีการแก้ไข/เสียหาย ID แต่ละรายการ นอกจากนี้ การใช้งานต้องใช้การเปรียบเทียบเวลาคงที่สำหรับองค์ประกอบ ID แต่ละรายการและการตรวจสอบความถูกต้องของ S เวลาในการเปรียบเทียบจะต้องคงที่โดยไม่คำนึงถึงจำนวน ID ที่ให้มา และการจับคู่ที่ถูกต้องของส่วนใด ๆ ของการทดสอบ

ตัวระบุฮาร์ดแวร์

การรับรอง ID รองรับตัวระบุฮาร์ดแวร์ต่อไปนี้:

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 มีหกเครื่องแรกและจำเป็นสำหรับคุณสมบัตินี้ในการทำงาน หากอุปกรณ์มีวิทยุเซลลูลาร์ในตัว อุปกรณ์นั้นจะต้องรองรับการรับรอง IMEI และ/หรือ MEID ของวิทยุด้วย

มีการร้องขอการรับรอง ID โดยดำเนินการรับรองคีย์และรวมถึงตัวระบุอุปกรณ์เพื่อยืนยันในคำขอ ตัวระบุถูกแท็กเป็น:

• 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

หากอุปกรณ์รองรับการรับรอง ID และมีแท็กข้างต้นอย่างน้อยหนึ่งแท็กรวมอยู่ในคำขอการรับรองคีย์ 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].