ความพร้อมใช้งานของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ในระบบวงจรรวมบนชิป (SoC) เปิดโอกาสให้อุปกรณ์ Android มอบบริการรักษาความปลอดภัยที่แข็งแกร่งซึ่งอิงฮาร์ดแวร์ให้กับระบบปฏิบัติการ Android, บริการของแพลตฟอร์ม และแม้แต่แอปของบุคคลที่สาม (ในรูปแบบของส่วนขยายเฉพาะ Android สำหรับมาตรฐาน Java Cryptography Architecture ดู KeyGenParameterSpec)
อภิธานศัพท์
ภาพรวมโดยย่อของคอมโพเนนต์ Keystore และความสัมพันธ์ของคอมโพเนนต์มีดังนี้
AndroidKeyStore- API และคอมโพเนนต์ของเฟรมเวิร์ก Android ที่แอปใช้เพื่อเข้าถึงฟังก์ชันการทำงานของ Keystore ซึ่งเป็นการใช้งาน API ของ Java Cryptography Architecture มาตรฐาน
แต่ยังเพิ่มส่วนขยายเฉพาะของ Android
และประกอบด้วยโค้ด Java ที่ทำงานในพื้นที่
กระบวนการของแอปเอง
AndroidKeyStoreจะดำเนินการตามคำขอแอปสำหรับลักษณะการทำงานของ Keystore โดยการส่งต่อคำขอไปยัง Daemon ของ Keystore - daemon คลังคีย์
- Daemon ของระบบ Android ที่ให้สิทธิ์เข้าถึงฟังก์ชันทั้งหมดของ Keystore ผ่าน API ของ Binder Daemon นี้มีหน้าที่จัดเก็บ keyblobs ที่สร้างขึ้นโดยการติดตั้งใช้งาน KeyMint (หรือ Keymaster) ที่อยู่เบื้องหลัง ซึ่งมีเนื้อหาคีย์ลับที่เข้ารหัสไว้เพื่อให้ Keystore จัดเก็บได้ แต่จะใช้หรือเปิดเผยไม่ได้
- บริการ HAL ของ KeyMint
- เซิร์ฟเวอร์ AIDL ที่ใช้
HAL ของ
IKeyMintDeviceซึ่งให้สิทธิ์เข้าถึง TA ของ KeyMint ที่อยู่เบื้องหลัง - แอปที่เชื่อถือได้ (TA) ของ KeyMint
- ซอฟต์แวร์ที่ทำงานในบริบทที่ปลอดภัย ซึ่งส่วนใหญ่มักอยู่ใน TrustZone บน ARM SoC ที่ให้การดำเนินการเข้ารหัสลับที่ปลอดภัยทั้งหมด แอปนี้มีสิทธิ์เข้าถึงเนื้อหาคีย์ดิบและตรวจสอบ เงื่อนไขการควบคุมการเข้าถึงทั้งหมดในคีย์ก่อนที่จะอนุญาตให้ใช้
LockSettingsService- คอมโพเนนต์ของระบบ Android ที่รับผิดชอบการตรวจสอบสิทธิ์ผู้ใช้ ทั้งรหัสผ่านและ
ลายนิ้วมือ แม้จะไม่ได้เป็นส่วนหนึ่งของ Keystore แต่ก็มีความเกี่ยวข้องเนื่องจาก Keystore รองรับแนวคิดของคีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ ซึ่งเป็นคีย์ที่ใช้ได้ก็ต่อเมื่อผู้ใช้ได้รับการตรวจสอบสิทธิ์แล้วเท่านั้น
LockSettingsServiceจะโต้ตอบกับ TA ของ Gatekeeper และ TA ของลายนิ้วมือเพื่อรับโทเค็นการตรวจสอบสิทธิ์ ซึ่งจะส่งไปยัง Daemon ของที่เก็บคีย์ และ TA ของ KeyMint จะใช้โทเค็นดังกล่าว - Gatekeeper TA
- คอมโพเนนต์ที่ทำงานในสภาพแวดล้อมที่ปลอดภัยซึ่งมีหน้าที่ตรวจสอบสิทธิ์รหัสผ่านของผู้ใช้ และสร้างโทเค็นการตรวจสอบสิทธิ์ที่ใช้เพื่อพิสูจน์ต่อ TA ของ KeyMint ว่ามีการ ตรวจสอบสิทธิ์สำหรับผู้ใช้รายหนึ่งๆ ณ เวลาใดเวลาหนึ่ง
- Fingerprint TA
- คอมโพเนนต์ที่ทำงานในสภาพแวดล้อมที่ปลอดภัยซึ่งมีหน้าที่ตรวจสอบสิทธิ์ลายนิ้วมือของผู้ใช้ และสร้างโทเค็นการตรวจสอบสิทธิ์ที่ใช้เพื่อพิสูจน์ต่อ TA ของ KeyMint ว่ามีการ ตรวจสอบสิทธิ์สำหรับผู้ใช้รายหนึ่งๆ ณ เวลาใดเวลาหนึ่ง
สถาปัตยกรรม
Android Keystore API และ KeyMint HAL ที่อยู่เบื้องหลัง มีชุดไพรมิตีฟการเข้ารหัสพื้นฐานแต่เพียงพอที่จะอนุญาตให้ ใช้โปรโตคอลที่ใช้คีย์ที่ควบคุมการเข้าถึงและได้รับการสนับสนุนจากฮาร์ดแวร์
KeyMint HAL เป็นบริการที่ OEM จัดหาให้ซึ่งบริการ Keystore ใช้เพื่อให้บริการเข้ารหัสที่อิงฮาร์ดแวร์ การติดตั้งใช้งาน HAL จะไม่ดำเนินการที่ละเอียดอ่อนในพื้นที่ผู้ใช้หรือแม้แต่ในพื้นที่เคอร์เนล เพื่อรักษาความปลอดภัยของเนื้อหาคีย์ส่วนตัว แต่บริการ KeyMint HAL ที่ทำงานใน Android จะมอบหมาย การดำเนินการที่ละเอียดอ่อนให้กับ TA ที่ทำงานในสภาพแวดล้อมที่ปลอดภัย บางประเภท โดยปกติจะทำโดยการจัดรูปแบบและยกเลิกการจัดรูปแบบคำขอในรูปแบบการส่งผ่านข้อมูลที่ กำหนดไว้ในการติดตั้งใช้งานบางอย่าง
สถาปัตยกรรมที่ได้จะมีลักษณะดังนี้
รูปที่ 1 สิทธิ์เข้าถึง KeyMint
API ของ KeyMint HAL เป็น API ระดับต่ำที่ใช้โดยคอมโพเนนต์ภายในแพลตฟอร์ม และ ไม่ได้แสดงแก่นักพัฒนาแอป API Java ระดับสูงกว่าที่พร้อมใช้งานสำหรับแอปมีคำอธิบายอยู่ในเว็บไซต์ของนักพัฒนาแอป Android
การควบคุมการเข้าถึง
ที่เก็บคีย์ของ Android มีคอมโพเนนต์ส่วนกลางสำหรับการจัดเก็บและการใช้คีย์การเข้ารหัสที่อิงฮาร์ดแวร์ ทั้งสำหรับแอปและคอมโพเนนต์อื่นๆ ของระบบ ดังนั้น โดยปกติแล้ว สิทธิ์เข้าถึงคีย์แต่ละรายการจะจำกัดไว้สำหรับ แอปหรือคอมโพเนนต์ของระบบที่สร้างคีย์นั้น
โดเมนคีย์สโตร์
ระบบจะระบุคีย์ไปยังที่เก็บคีย์ด้วยตัวอธิบายคีย์เพื่อรองรับการควบคุมการเข้าถึงนี้ ตัวอธิบายคีย์นี้ระบุโดเมนที่ตัวอธิบายเป็นของโดเมนนั้น พร้อมกับข้อมูลประจำตัวภายในโดเมนนั้น
แอป Android เข้าถึง Keystore โดยใช้ Java Cryptography
Architecture มาตรฐาน ซึ่งระบุคีย์ด้วยนามแฝงสตริง วิธีการระบุตัวตนนี้จะแมปกับโดเมน APP ของ Keystore ภายใน ส่วน UID ของผู้เรียกจะรวมอยู่ด้วยเพื่อแยกความแตกต่างของคีย์จากแอปต่างๆ ซึ่งจะป้องกันไม่ให้แอปหนึ่งเข้าถึงคีย์ของอีกแอปหนึ่ง
ภายใน โค้ดเฟรมเวิร์กจะได้รับรหัส
คีย์ที่เป็นตัวเลขที่ไม่ซ้ำกันหลังจากโหลดคีย์แล้ว ระบบจะใช้รหัสตัวเลขนี้เป็นตัวระบุ
สำหรับตัวอธิบายคีย์ภายในโดเมน KEY_ID อย่างไรก็ตาม ระบบจะยังคงควบคุมการเข้าถึง
ต่อไป แม้ว่าแอปหนึ่งจะค้นพบรหัสคีย์ของคีย์ของแอปอื่น
แต่ก็ไม่สามารถใช้รหัสคีย์นั้นได้ในสถานการณ์ปกติ
อย่างไรก็ตาม แอปสามารถให้สิทธิ์การใช้คีย์แก่แอปอื่นได้
(ตามที่ระบุโดย UID) การดำเนินการให้สิทธิ์นี้จะแสดงตัวระบุการให้สิทธิ์ที่ไม่ซ้ำกัน
ซึ่งใช้เป็นตัวระบุสำหรับตัวอธิบายคีย์ภายใน
โดเมน GRANT อีกครั้งที่การควบคุมการเข้าถึงยังคงดำเนินการอยู่ แม้ว่าแอปของบุคคลที่สามจะค้นพบรหัสการให้สิทธิ์สำหรับคีย์ของผู้รับสิทธิ์ แต่ก็ใช้รหัสดังกล่าวไม่ได้
นอกจากนี้ Keystore ยังรองรับโดเมนอื่นๆ อีก 2 โดเมนสำหรับตัวอธิบายคีย์ ซึ่งใช้ สำหรับคอมโพเนนต์อื่นๆ ของระบบและไม่พร้อมใช้งานสำหรับคีย์ที่แอปสร้างขึ้น
- โดเมน
BLOBแสดงว่าไม่มีตัวระบุสำหรับคีย์ในตัวอธิบายคีย์ แต่ตัวอธิบายคีย์จะเก็บ keyblob ไว้เอง และไคลเอ็นต์จะจัดการพื้นที่เก็บข้อมูล keyblob ไคลเอ็นต์ (เช่นvold) ที่ต้องเข้าถึง Keystore ก่อนที่จะมีการติดตั้งพาร์ติชันข้อมูลจะใช้พารามิเตอร์นี้ - โดเมน
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 เพื่อรองรับการกลับมาทำงานต่อเมื่อรีบูต |
เวกเตอร์การเข้าถึง
Keystore ช่วยให้ควบคุมการดำเนินการที่ทำกับคีย์ได้ นอกเหนือจากการควบคุมการเข้าถึงคีย์โดยรวม keystore2_key
อธิบายสิทธิ์ไว้ใน
ไฟล์ KeyPermission.aidl
สิทธิ์ของระบบ
นอกเหนือจากการควบคุมการเข้าถึงต่อคีย์ที่อธิบายไว้ในนโยบาย SELinux สำหรับ keystore_key แล้ว ตารางต่อไปนี้ จะอธิบายสิทธิ์ SELinux อื่นๆ ที่จำเป็นต่อการดำเนินการต่างๆ ของระบบและการบำรุงรักษา
| สิทธิ์ | ความหมาย |
|---|---|
add_auth
|
ต้องใช้ในการเพิ่มโทเค็นการตรวจสอบสิทธิ์ลงในที่เก็บคีย์ โดยผู้ให้บริการตรวจสอบสิทธิ์ เช่น Gatekeeper
หรือ BiometricManager จะใช้โทเค็นนี้ |
clear_ns
|
ต้องระบุเพื่อลบคีย์ทั้งหมดในเนมสเปซที่เฉพาะเจาะจง ใช้เป็นการดำเนินการบำรุงรักษา เมื่อถอนการติดตั้งแอป |
list
|
ระบบกำหนดให้ต้องระบุเพื่อแจงนับคีย์ตามพร็อพเพอร์ตี้ต่างๆ เช่น
ความเป็นเจ้าของหรือผูกกับการตรวจสอบสิทธิ์หรือไม่ ผู้โทรไม่จำเป็นต้องมีสิทธิ์นี้
เพื่อแจงนับเนมสเปซของตนเอง (ซึ่งครอบคลุมโดยสิทธิ์ get_info) |
lock
|
ต้องใช้เพื่อแจ้งให้ Keystore ทราบว่าอุปกรณ์ถูกล็อก ซึ่งจะทำให้ระบบนำ คีย์หลักออกเพื่อให้แน่ใจว่าคีย์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์จะไม่พร้อมใช้งาน |
unlock
|
ต้องแจ้งให้ที่เก็บคีย์ทราบว่าอุปกรณ์ได้รับการปลดล็อกแล้ว เพื่อกู้คืนสิทธิ์เข้าถึง คีย์หลักที่ปกป้องคีย์ที่ผูกกับการตรวจสอบสิทธิ์ |
reset
|
จำเป็นสำหรับการรีเซ็ต Keystore เป็นค่าเริ่มต้นจากโรงงาน การลบคีย์ทั้งหมดที่ ไม่สำคัญต่อการทำงานของระบบปฏิบัติการ 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 ได้เพิ่ม Primitive การเข้ารหัสแบบสมมาตร 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 แบบหนึ่งต่อหนึ่ง
นอกจากจะปรับปรุงอินเทอร์เฟซนี้แล้ว Android 8.0 ยังขยายฟีเจอร์การรับรองของ Keymaster 2 เพื่อรองรับการรับรอง ID ด้วย การรับรองรหัสเป็นกลไกที่จำกัดและไม่บังคับสำหรับการรับรอง ตัวระบุฮาร์ดแวร์อย่างเข้มงวด เช่น หมายเลขซีเรียลของอุปกรณ์ ชื่อผลิตภัณฑ์ และรหัสโทรศัพท์ (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 เพิ่ม KeyMint HAL เวอร์ชัน 2 ซึ่งเพิ่มการรองรับ Curve25519 สำหรับการลงนามและข้อตกลงเกี่ยวกับคีย์