คีย์สโตร์แบบใช้ฮาร์ดแวร์

ความพร้อมใช้งานของสภาพแวดล้อมการเรียกใช้ที่เชื่อถือได้ในระบบบนชิป (SoC) เปิดโอกาสให้อุปกรณ์ Android ให้บริการรักษาความปลอดภัยที่มีประสิทธิภาพซึ่งสนับสนุนฮาร์ดแวร์ให้กับระบบปฏิบัติการ Android, บริการแพลตฟอร์ม และแม้แต่แอปของบุคคลที่สาม (ในรูปแบบของส่วนขยายสำหรับ Android โดยเฉพาะในมาตรฐาน Java Cryptography Architecture ดูKeyGenParameterSpec)

อภิธานศัพท์

ภาพรวมโดยย่อของคอมโพเนนต์ของคีย์สโตร์และความสัมพันธ์ของคอมโพเนนต์มีดังนี้

AndroidKeyStore
API และคอมโพเนนต์เฟรมเวิร์ก Android ที่แอปใช้เพื่อเข้าถึงฟังก์ชันการทำงานของ Keystore ซึ่งเป็นการใช้งาน Java Cryptography Architecture API มาตรฐาน แต่เพิ่มส่วนขยายสำหรับ Android โดยเฉพาะ และประกอบด้วยโค้ด Java ที่ทำงานในพื้นที่กระบวนการของแอปเอง AndroidKeyStore ดำเนินการตามคำขอของแอปสำหรับลักษณะการทำงานของคีย์สโตร์โดยส่งต่อไปยังเดรัมน์คีย์สโตร์
Damon ของคีย์สโตร์
เดรัมของระบบ Android ที่ให้สิทธิ์เข้าถึงฟังก์ชันการทำงานของ Keystore ทั้งหมดผ่าน Binder API ซึ่งมีหน้าที่จัดเก็บ keyblob ที่สร้างขึ้นจากการใช้งาน KeyMint (หรือ Keymaster) ที่อยู่เบื้องหลัง ซึ่งมีข้อมูลคีย์ลับที่เข้ารหัสไว้เพื่อให้ Keystore จัดเก็บได้ แต่จะไม่สามารถใช้งานหรือเปิดเผยข้อมูลดังกล่าว
บริการ HAL ของ KeyMint
เซิร์ฟเวอร์ AIDL ที่ใช้ IKeyMintDevice HAL ซึ่งให้สิทธิ์เข้าถึง TA ของ KeyMint ที่อยู่เบื้องหลัง
แอปที่เชื่อถือได้ของ KeyMint (TA)
ซอฟต์แวร์ที่ทำงานในบริบทที่ปลอดภัย ซึ่งส่วนใหญ่อยู่ใน TrustZone บน SoC ของ ARM ซึ่งให้บริการการดำเนินการเข้ารหัสที่ปลอดภัยทั้งหมด แอปนี้มีสิทธิ์เข้าถึงข้อมูลคีย์ดิบ และตรวจสอบเงื่อนไขการควบคุมการเข้าถึงทั้งหมดในคีย์ก่อนที่จะอนุญาตให้ใช้งาน
LockSettingsService
คอมโพเนนต์ของระบบ Android ที่รับผิดชอบการตรวจสอบสิทธิ์ผู้ใช้ ทั้งรหัสผ่านและลายนิ้วมือ ข้อมูลนี้ไม่ได้อยู่ในคีย์สโตร์ แต่มีความเกี่ยวข้องเนื่องจากคีย์สโตร์รองรับแนวคิดคีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ ซึ่งเป็นคีย์ที่ใช้ได้เฉพาะในกรณีที่ผู้ใช้ตรวจสอบสิทธิ์แล้ว LockSettingsService โต้ตอบกับ TA ของ Gatekeeper และ TA ของลายนิ้วมือเพื่อรับโทเค็นการตรวจสอบสิทธิ์ ซึ่งจะส่งไปยังเดรัมไนน์ของคีย์สโตร์ และ TA ของ KeyMint จะใช้โทเค็นดังกล่าว
Gatekeeper TA
คอมโพเนนต์ที่ทำงานในสภาพแวดล้อมที่ปลอดภัยซึ่งมีหน้าที่ตรวจสอบสิทธิ์รหัสผ่านของผู้ใช้และสร้างโทเค็นการตรวจสอบสิทธิ์ที่ใช้เพื่อพิสูจน์กับ TA ของ KeyMint ว่าการตรวจสอบสิทธิ์สําหรับผู้ใช้รายหนึ่งๆ เสร็จสมบูรณ์แล้ว ณ เวลาหนึ่งๆ
Fingerprint TA
คอมโพเนนต์ที่ทำงานในสภาพแวดล้อมที่ปลอดภัยซึ่งมีหน้าที่ตรวจสอบสิทธิ์ลายนิ้วมือของผู้ใช้และสร้างโทเค็นการตรวจสอบสิทธิ์ที่ใช้เพื่อพิสูจน์กับ TA ของ KeyMint ว่าการตรวจสอบสิทธิ์สําหรับผู้ใช้รายหนึ่งๆ เสร็จสมบูรณ์แล้ว ณ เวลาหนึ่งๆ

สถาปัตยกรรม

Android Keystore API และ KeyMint HAL ที่เกี่ยวข้องมีชุดพื้นฐานของการเข้ารหัสขั้นต้นที่เพียงพอที่จะอนุญาตให้ใช้โปรโตคอลโดยใช้คีย์ที่ควบคุมการเข้าถึงและได้รับการสนับสนุนจากฮาร์ดแวร์

KeyMint HAL เป็นบริการที่ OEM ให้บริการซึ่งบริการ Keystore นำมาใช้เพื่อให้บริการการเข้ารหัสที่รองรับฮาร์ดแวร์ การใช้งาน HAL จะไม่ดำเนินการที่มีความละเอียดอ่อนในพื้นที่ผู้ใช้หรือแม้แต่ในพื้นที่เคอร์เนล เพื่อรักษาข้อมูลคีย์ส่วนตัวให้ปลอดภัย บริการ HAL ของ KeyMint ที่ทำงานใน Android จะมอบหมายการดำเนินการที่มีความละเอียดอ่อนให้กับ TA ที่ทำงานในสภาพแวดล้อมที่ปลอดภัย โดยปกติจะดำเนินการโดยการจัดระเบียบและการจัดระเบียบคําขอในรูปแบบการติดต่อที่กำหนดโดยการใช้งาน

สถาปัตยกรรมที่ได้จะมีลักษณะดังนี้

การเข้าถึง KeyMint

รูปที่ 1 สิทธิ์เข้าถึง KeyMint

KeyMint HAL API เป็น API ระดับต่ำที่ใช้โดยคอมโพเนนต์ภายในแพลตฟอร์ม และไม่ได้เปิดเผยต่อนักพัฒนาแอป คุณสามารถดูคำอธิบาย Java API ระดับที่สูงขึ้นซึ่งพร้อมให้บริการสำหรับแอปได้ในเว็บไซต์ของนักพัฒนาแอป Android

การควบคุมการเข้าถึง

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

โดเมนคีย์สโตร์

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

แอป Android จะเข้าถึง Keystore โดยใช้ Java Cryptography Architecture มาตรฐาน ซึ่งจะระบุคีย์ด้วยนามแฝงสตริง วิธีการระบุตัวตนนี้จะแมปกับโดเมน APP ของคีย์สโตร์ภายใน รวมถึงรวม UID ของผู้เรียกด้วยเพื่อแยกแยะคีย์จากแอปต่างๆ เพื่อป้องกันไม่ให้แอปหนึ่งเข้าถึงคีย์ของแอปอื่น

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

อย่างไรก็ตาม แอปหนึ่งๆ สามารถให้สิทธิ์ใช้คีย์แก่แอปอื่นได้ (ตามที่ระบุโดย UID) การดำเนินการให้สิทธิ์นี้จะแสดงผลตัวระบุการให้สิทธิ์ที่ไม่ซ้ำกัน ซึ่งจะใช้เป็นตัวระบุสำหรับข้อบ่งชี้คีย์ภายในโดเมน GRANT โปรดทราบว่าระบบจะยังคงใช้การควบคุมการเข้าถึงอยู่ แม้ว่าแอปของบุคคลที่สามจะค้นพบรหัสการให้สิทธิ์สำหรับคีย์ของผู้รับก็ตาม แต่แอปดังกล่าวจะใช้คีย์ดังกล่าวไม่ได้

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

  • โดเมน BLOB บ่งบอกว่าไม่มีตัวระบุสำหรับคีย์ในคีย์ดีสคริปเตอร์ แต่คีย์ดีสคริปเตอร์จะเก็บคีย์บล็อกไว้เองและไคลเอ็นต์จะจัดการพื้นที่เก็บข้อมูลคีย์บล็อก ซึ่งไคลเอ็นต์ (เช่น vold) ต้องใช้เพื่อเข้าถึงคีย์สโตร์ก่อนที่จะมีการต่อเชื่อมพาร์ติชันข้อมูล
  • โดเมน SELINUX อนุญาตให้คอมโพเนนต์ของระบบแชร์คีย์ โดยมีสิทธิ์เข้าถึงที่ควบคุมโดยตัวระบุตัวเลขที่สอดคล้องกับป้ายกำกับ SELinux (ดูนโยบาย SELinux สำหรับ keystore_key)

นโยบาย SELinux สําหรับ keystore_key

ค่าตัวระบุที่ใช้สำหรับDomain::SELINUXตัวบ่งชี้คีย์ ได้รับการกำหนดค่าไว้ในไฟล์นโยบาย SELinux ของ keystore2_key_context แต่ละบรรทัดในไฟล์เหล่านี้จะแมปตัวเลขกับป้ายกำกับ SELinux ดังตัวอย่างต่อไปนี้

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

คอมโพเนนต์ที่ต้องการเข้าถึงคีย์ที่มีรหัส 102 ในโดเมน SELINUX ต้องมีนโยบาย SELinux ที่เกี่ยวข้อง เช่น หากต้องการอนุญาตให้ wpa_supplicant รับและใช้คีย์เหล่านี้ ให้เพิ่มบรรทัดต่อไปนี้ลงใน hal_wifi_supplicant.te

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

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

พาร์ติชัน ช่วง ไฟล์การกําหนดค่า
ระบบ 0 ... 9,999 /system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
ระบบแบบขยาย 10,000 ... 19,999 /system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
ผลิตภัณฑ์ 20,000 ... 29,999 /product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
ตัวแทนจำหน่ายรายย่อย 30,000 ... 39,999 /vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

ระบบได้กําหนดค่าที่เฉพาะเจาะจงต่อไปนี้สําหรับพาร์ติชันระบบ

รหัส Namespace ป้ายกำกับ SEPolicy UID คำอธิบาย
0 su_key ไม่มี คีย์ผู้ใช้ขั้นสูง ใช้สำหรับการทดสอบในบิลด์ userdebug และ eng เท่านั้น ไม่เกี่ยวข้องกับบิลด์ของผู้ใช้
1 shell_key ไม่มี เนมสเปซที่ใช้ได้ในเชลล์ ส่วนใหญ่ใช้สำหรับการทดสอบ แต่สามารถใช้กับบิลด์ของผู้ใช้จากบรรทัดคำสั่งได้เช่นกัน
100 vold_key ไม่มี มีไว้สำหรับใช้โดย vold
101 odsign_key ไม่มี ใช้โดย Daemon การลงนามในอุปกรณ์
102 wifi_key AID_WIFI(1010) ใช้โดยระบบย่อย Wi-Fi ของ Android ซึ่งรวมถึง wpa_supplicant
103 locksettings_key ไม่มี ใช้โดย LockSettingsService
120 resume_on_reboot_key AID_SYSTEM(1000) ใช้โดยเซิร์ฟเวอร์ระบบของ Android เพื่อรองรับการกลับมาทำงานต่อเมื่อรีบูต

เวกเตอร์การเข้าถึง

คีย์สโตร์ช่วยให้ควบคุมการดำเนินการที่สามารถทำได้กับคีย์ได้ นอกเหนือจากการควบคุมการเข้าถึงคีย์โดยรวม สิทธิ์ keystore2_keyอธิบายไว้ในไฟล์ KeyPermission.aidl

สิทธิ์ของระบบ

นอกเหนือจากการควบคุมการเข้าถึงต่อคีย์ที่อธิบายไว้ในนโยบาย SELinux สําหรับ keystore_key แล้ว ตารางต่อไปนี้ยังอธิบายสิทธิ์ SELinux อื่นๆ ที่จําเป็นต่อการดำเนินการต่างๆ ของระบบและการบำรุงรักษา

สิทธิ์ ความหมาย
add_auth ต้องระบุเพื่อเพิ่มโทเค็นการตรวจสอบสิทธิ์ลงในคีย์สโตร์ ซึ่งผู้ให้บริการการตรวจสอบสิทธิ์ เช่น Gatekeeper หรือ BiometricManager จะใช้
clear_ns ต้องระบุสำหรับลบคีย์ทั้งหมดในเนมสเปซที่เฉพาะเจาะจง ใช้สำหรับการดำเนินการบำรุงรักษาเมื่อมีการถอนการติดตั้งแอป
list ระบบต้องใช้เพื่อแจกแจงคีย์ตามพร็อพเพอร์ตี้ต่างๆ เช่น ความเป็นเจ้าของ หรือมีการเชื่อมโยงการตรวจสอบสิทธิ์หรือไม่ ผู้เรียกใช้ไม่จำเป็นต้องมีสิทธิ์นี้หากต้องการแสดงรายการเนมสเปซของตนเอง (ซึ่งครอบคลุมโดยสิทธิ์ get_info)
lock ต้องระบุเพื่อแจ้งให้คีย์สโตร์ทราบว่าอุปกรณ์ถูกล็อก ซึ่งจะเป็นการลบคีย์ซุปเปอร์ออกเพื่อให้คีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ใช้งานไม่ได้
unlock ต้องแจ้งให้คีย์สโตร์ทราบว่าอุปกรณ์ปลดล็อกแล้ว เพื่อกู้คืนสิทธิ์เข้าถึงคีย์หลักที่ปกป้องคีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์
reset ต้องใช้ในการรีเซ็ตคีย์สโตร์เป็นค่าเริ่มต้น ซึ่งจะลบคีย์ทั้งหมดที่ไม่จำเป็นต่อการทำงานของระบบปฏิบัติการ Android

ประวัติ

ใน Android 5 และต่ำกว่า Android มี API บริการการเข้ารหัสที่ทำงานร่วมกับฮาร์ดแวร์อย่างง่าย ซึ่งให้บริการโดยเลเยอร์การแยกแยะฮาร์ดแวร์ (HAL) ของ Keymaster เวอร์ชัน 0.2 และ 0.3 Keystore มีการดำเนินการการรับรองและการยืนยันแบบดิจิทัล รวมถึงการสร้างและนําเข้าคู่คีย์การรับรองแบบไม่สมมาตร การดำเนินการนี้นำมาใช้ในอุปกรณ์หลายเครื่องแล้ว แต่มีเป้าหมายด้านความปลอดภัยหลายอย่างที่ทำได้ยากด้วย Signature API เพียงอย่างเดียว Android 6.0 ขยายการให้บริการ Keystore API เพื่อเพิ่มความสามารถที่หลากหลาย

Android 6.0

ใน Android 6.0 นั้น Keymaster 1.0 ได้เพิ่มองค์ประกอบพื้นฐานของการเข้ารหัสแบบสมมาตร, AES และ HMAC รวมถึงระบบการควบคุมการเข้าถึงสำหรับคีย์ที่สำรองข้อมูลไว้ในฮาร์ดแวร์ การควบคุมการเข้าถึงจะระบุในระหว่างการสร้างคีย์และบังคับใช้ตลอดอายุการใช้งานของคีย์ คุณสามารถจํากัดให้ใช้คีย์ได้หลังจากผู้ใช้ได้รับการตรวจสอบสิทธิ์แล้วเท่านั้น และเพื่อวัตถุประสงค์ที่ระบุหรือใช้กับพารามิเตอร์การเข้ารหัสที่ระบุเท่านั้น

นอกจากการขยายช่วงขององค์ประกอบพื้นฐานการเข้ารหัสแล้ว Keystore ใน Android 6.0 ยังมีการเพิ่มสิ่งต่อไปนี้ด้วย

  • รูปแบบการควบคุมการใช้งานเพื่อจำกัดการใช้งานคีย์ เพื่อลดความเสี่ยงที่จะมีช่องโหว่ด้านความปลอดภัยเนื่องจากการใช้คีย์ในทางที่ผิด
  • รูปแบบการควบคุมการเข้าถึงเพื่อเปิดใช้การจํากัดคีย์สําหรับผู้ใช้ที่ระบุ ลูกค้า และช่วงเวลาที่กําหนด

Android 7.0

ใน Android 7.0 นั้น Keymaster 2 ได้เพิ่มการรองรับการรับรองคีย์และการเชื่อมโยงเวอร์ชัน

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

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

Android 8.0

ใน Android 8.0 นั้น Keymaster 3 ได้เปลี่ยนจาก HAL โครงสร้าง C แบบเก่าไปใช้อินเทอร์เฟซ HAL ของ C++ ที่สร้างขึ้นจากคำจำกัดความในภาษาที่ใช้สื่อสารข้อมูลระหว่างคอมโพเนนต์ของฮาร์ดแวร์ (HIDL) รูปแบบใหม่ การเปลี่ยนแปลงนี้ทำให้ประเภทอาร์กิวเมนต์หลายประเภทมีการเปลี่ยนแปลง แม้ว่าประเภทและเมธอดจะสอดคล้องกับประเภทเดิมและเมธอดของโครงสร้าง HAL แบบ 1:1

นอกจากการแก้ไขอินเทอร์เฟซนี้แล้ว Android 8.0 ยังขยายฟีเจอร์การรับรองของ Keymaster 2 เพื่อรองรับการรับรองผ่านบัตรประจำตัวด้วย การรับรองผ่านบัตรประจำตัวเป็นกลไกที่ไม่บังคับและจํากัดสําหรับการรับรองตัวระบุฮาร์ดแวร์อย่างเข้มงวด เช่น หมายเลขซีเรียลของอุปกรณ์ ชื่อผลิตภัณฑ์ และรหัสโทรศัพท์ (IMEI หรือ MEID) Android 8.0 ได้เปลี่ยนสคีมาการรับรอง ASN.1 เพื่อเพิ่มการรับรองผ่านบัตรประจำตัวเพื่อนำมาใช้กับการเพิ่มนี้ การติดตั้งใช้งาน Keymaster ต้องหาวิธีที่ปลอดภัยในการดึงข้อมูลรายการที่เกี่ยวข้อง รวมถึงกำหนดกลไกในการปิดใช้ฟีเจอร์อย่างปลอดภัยและถาวร

Android 9

ใน Android 9 การอัปเดตจะมีดังนี้

  • อัปเดตเป็นKeymaster 4
  • การรองรับองค์ประกอบที่ปลอดภัยแบบฝัง
  • การรองรับการนําเข้าคีย์ที่ปลอดภัย
  • การรองรับการเข้ารหัส 3DES
  • การเปลี่ยนแปลงการเชื่อมโยงเวอร์ชันเพื่อให้ boot.img และ system.img มีเวอร์ชันที่ตั้งค่าแยกกันเพื่อให้อัปเดตแยกกันได้

Android 10

Android 10 เปิดตัว Keymaster HAL เวอร์ชัน 4.1 ซึ่งเพิ่มสิ่งต่อไปนี้

  • การรองรับกุญแจที่ใช้ได้เฉพาะเมื่ออุปกรณ์ปลดล็อกอยู่
  • การรองรับคีย์ที่ใช้ได้ในขั้นตอนการบูตช่วงต้นเท่านั้น
  • การรองรับคีย์พื้นที่เก็บข้อมูลที่รวมอยู่ในฮาร์ดแวร์ (ไม่บังคับ)
  • การรองรับเอกสารรับรองที่ไม่ซ้ำกันของอุปกรณ์ใน StrongBox (ไม่บังคับ)

Android 12

Android 12 ได้เปิดตัว KeyMint HAL ใหม่ ซึ่งมาแทนที่ Keymaster HAL แต่ให้ฟังก์ชันการทำงานที่คล้ายกัน นอกจากฟีเจอร์ทั้งหมดข้างต้นแล้ว HAL ของ KeyMint ยังมีฟีเจอร์ต่อไปนี้ด้วย

  • รองรับข้อตกลงเกี่ยวกับคีย์ ECDH
  • การรองรับคีย์การรับรองที่ผู้ใช้ระบุ
  • รองรับคีย์ที่มีจำนวนการใช้งานจํากัด

Android 12 ยังมี Daemon ของระบบคีย์สโตร์เวอร์ชันใหม่ด้วย ซึ่งเขียนใหม่ด้วย Rust และเรียกว่า keystore2

Android 13

Android 13 เพิ่ม HAL ของ KeyMint เวอร์ชัน 2 ซึ่งเพิ่มการรองรับ Curve25519 ทั้งสำหรับการลงนามและการตกลงเกี่ยวกับคีย์