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

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

อภิธานศัพท์

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

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

สถาปัตยกรรม

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

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

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

การเข้าถึง KeyMint

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

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

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

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

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

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

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

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

ประวัติ

ใน Android 5 และต่ำกว่า Android มี API บริการเข้ารหัสที่เรียบง่ายและได้รับการสนับสนุนจากฮาร์ดแวร์ ซึ่งให้บริการโดย Keymaster เวอร์ชัน 0.2 และ 0.3 เลเยอร์การแยกฮาร์ดแวร์ (HAL) 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) ใหม่ การเปลี่ยนแปลงนี้ส่งผลให้ประเภทอาร์กิวเมนต์หลายรายการเปลี่ยนไป แต่ประเภทและเมธอดจะยังคงสอดคล้องกับประเภทเก่าและเมธอด struct ของ 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 ทั้งสำหรับการลงชื่อและการตกลงคีย์