Android ใช้แนวคิดของคีย์เข้ารหัสลับที่มีการตรวจสอบสิทธิ์ผู้ใช้ซึ่งต้องการส่วนประกอบต่อไปนี้:
- ผู้ให้บริการและการจัดเก็บคีย์การเข้ารหัสลับ จัดเก็บคีย์การเข้ารหัสและจัดเตรียมรูทีนการเข้ารหัสมาตรฐานไว้ด้านบนของคีย์เหล่านั้น Android รองรับ Keystore ที่ได้รับการสนับสนุนจาก ฮาร์ดแวร์ และ Keymaster สำหรับบริการเข้ารหัส รวมถึงการเข้ารหัสที่ได้รับการสนับสนุนจากฮาร์ดแวร์สำหรับการจัดเก็บคีย์ที่อาจรวมถึง Trusted Execution Environment (TEE) หรือ Secure Element (SE) เช่น Strongbox
- ผู้ตรวจสอบสิทธิ์ผู้ใช้ รับรองการมีอยู่ของผู้ใช้และ/หรือการรับรองความถูกต้องสำเร็จ Android รองรับ Gatekeeper สำหรับการตรวจสอบ PIN/รูปแบบ/รหัสผ่าน และ ลายนิ้วมือ สำหรับการตรวจสอบลายนิ้วมือ อุปกรณ์ที่มาพร้อมกับ Android 9 ขึ้นไปสามารถใช้
BiometricPrompt
เป็นจุดผสานรวมจุดเดียวสำหรับลายนิ้วมือและไบโอเมตริกเพิ่มเติม ส่วนประกอบเหล่านี้สื่อสารสถานะการรับรองความถูกต้องกับบริการที่เก็บคีย์ผ่านช่องทางที่พิสูจน์ตัวตน (ระบบ Android Keystore ที่ระดับเฟรมเวิร์กได้รับการสนับสนุนจากบริการคีย์สโตร์ด้วย)
ส่วนประกอบ Gatekeeper, ลายนิ้วมือ และ Biometric ทำงานร่วมกับ Keystore และส่วนประกอบอื่นๆ เพื่อรองรับการใช้ โทเค็น การพิสูจน์ตัวตนที่ได้รับการสนับสนุนจากฮาร์ดแวร์ (AuthTokens)
การลงทะเบียน
ในการบูตเครื่องครั้งแรกหลังจากการรีเซ็ตเป็นค่าเริ่มต้นจากโรงงาน ผู้ตรวจสอบสิทธิ์ทั้งหมดจะเตรียมพร้อมที่จะรับการลงทะเบียนข้อมูลรับรองจากผู้ใช้ ผู้ใช้ต้องลงทะเบียน PIN/รูปแบบ/รหัสผ่านกับ Gatekeeper ในขั้นต้น การลงทะเบียนครั้งแรกนี้จะสร้างตัวระบุความปลอดภัยของผู้ใช้ 64 บิต (SID) ที่สร้างขึ้นแบบสุ่มซึ่งทำหน้าที่เป็นตัวระบุสำหรับผู้ใช้และเป็นโทเค็นการผูกมัดสำหรับเนื้อหาการเข้ารหัสของผู้ใช้ SID ผู้ใช้นี้ถูกผูกไว้กับรหัสผ่านของผู้ใช้ด้วยการเข้ารหัส การตรวจสอบสิทธิ์ที่สำเร็จไปยัง Gatekeeper ส่งผลให้ AuthTokens ที่มี SID ผู้ใช้สำหรับรหัสผ่านนั้น
ผู้ใช้ที่ต้องการเปลี่ยนข้อมูลประจำตัวต้องแสดงข้อมูลประจำตัวที่มีอยู่ หากยืนยันข้อมูลประจำตัวที่มีอยู่ได้สำเร็จ SID ผู้ใช้ที่เชื่อมโยงกับหนังสือรับรองที่มีอยู่จะถูกโอนไปยังข้อมูลประจำตัวใหม่ ทำให้ผู้ใช้สามารถเข้าถึงคีย์ต่อไปได้หลังจากเปลี่ยนข้อมูลประจำตัว ถ้าผู้ใช้ไม่แสดงข้อมูลประจำตัวที่มีอยู่ ข้อมูลประจำตัวใหม่จะถูกลงทะเบียนด้วย SID ผู้ใช้แบบสุ่มทั้งหมด ผู้ใช้สามารถเข้าถึงอุปกรณ์ได้ แต่คีย์ที่สร้างภายใต้ SID ของผู้ใช้เก่าจะสูญหายไปอย่างถาวร สิ่งนี้เรียกว่าการ ลงทะเบียนที่ไม่น่าเชื่อถือ
ภายใต้สถานการณ์ปกติ เฟรมเวิร์กของ Android จะไม่อนุญาตให้มีการลงทะเบียนที่ไม่น่าเชื่อถือ ดังนั้นผู้ใช้ส่วนใหญ่จะไม่เห็นฟังก์ชันนี้ อย่างไรก็ตาม การบังคับรีเซ็ตรหัสผ่านทั้งโดยผู้ดูแลอุปกรณ์หรือผู้โจมตี อาจทำให้เกิดสิ่งนี้ได้
การตรวจสอบสิทธิ์
หลังจากที่ผู้ใช้ตั้งค่าข้อมูลประจำตัวและได้รับ SID ผู้ใช้แล้ว พวกเขาสามารถเริ่มการตรวจสอบสิทธิ์ได้ ซึ่งจะเริ่มเมื่อผู้ใช้ระบุ PIN, รูปแบบ, รหัสผ่าน หรือลายนิ้วมือ ส่วนประกอบ TEE ทั้งหมดใช้รหัสลับร่วมกันเพื่อรับรองความถูกต้องของข้อความของกันและกัน

- ผู้ใช้จัดเตรียมวิธีการพิสูจน์ตัวตน และบริการที่เกี่ยวข้องส่งคำขอไปยัง daemon ที่เกี่ยวข้อง
- สำหรับ PIN, รูปแบบ หรือรหัสผ่าน
LockSettingsService
จะส่งคำขอไปยังgatekeeperd
- ขั้นตอนการพิสูจน์ตัวตนแบบไบโอเมตริกขึ้นอยู่กับเวอร์ชัน Android บนอุปกรณ์ที่ใช้ Android 8.x และต่ำกว่า
FingerprintService
จะร้องขอfingerprintd
) บนอุปกรณ์ที่ใช้ Android 9 ขึ้นไปBiometricPrompt
จะส่งคำขอไปยังไบโอเมตริกซ์ daemon ที่เหมาะสม (เช่นfingerprintd
สำหรับลายนิ้วมือหรือfaced
) โดยใช้คลาสBiometric Manager
ที่เหมาะสม เช่นFingerprintManager
หรือFaceManager
ไม่ว่าจะเป็นเวอร์ชันใด การตรวจสอบไบโอเมตริกซ์จะเกิดขึ้นแบบอะซิงโครนัสหลังจากส่งคำขอ
- สำหรับ PIN, รูปแบบ หรือรหัสผ่าน
- daemon ส่งข้อมูลไปยังคู่ของมัน ซึ่งสร้าง AuthToken:
- สำหรับการตรวจสอบ PIN/รูปแบบ/รหัสผ่าน
gatekeeperd
จะส่ง PIN, รูปแบบ หรือแฮชรหัสผ่านไปยัง Gatekeeper ใน TEE หากการตรวจสอบสิทธิ์ใน TEE สำเร็จ Gatekeeper ใน TEE จะส่ง AuthToken ที่มี SID ผู้ใช้ที่เกี่ยวข้อง (ลงนามด้วยคีย์ AuthToken HMAC) ไปยังคู่กันในระบบปฏิบัติการ Android - สำหรับการตรวจสอบ
fingerprintd
จะฟังเหตุการณ์ลายนิ้วมือและส่งข้อมูลไปยังลายนิ้วมือใน TEE หากการตรวจสอบสิทธิ์ใน TEE สำเร็จ ลายนิ้วมือใน TEE จะส่ง AuthToken (ลงนามด้วยคีย์ AuthToken HMAC) ไปยังเครื่องคู่กันในระบบปฏิบัติการ Android - สำหรับการพิสูจน์ตัวตนไบโอเมตริกอื่น ๆ biometric daemon ที่เหมาะสมจะรับฟังเหตุการณ์ไบโอเมตริกซ์และส่งไปยังส่วนประกอบไบโอเมตริกซ์ TEE ที่เหมาะสม
- สำหรับการตรวจสอบ PIN/รูปแบบ/รหัสผ่าน
- daemon ได้รับ AuthToken ที่ลงชื่อแล้วและส่งผ่านไปยังบริการที่เก็บคีย์ผ่านส่วนขยายไปยังอินเทอร์เฟซ Binder ของบริการที่เก็บคีย์ (
gatekeeperd
จะแจ้งบริการ keystore เมื่ออุปกรณ์ถูกล็อกอีกครั้งและเมื่อรหัสผ่านของอุปกรณ์เปลี่ยน) - บริการที่เก็บคีย์จะส่ง AuthTokens ไปยัง Keymaster และยืนยันโดยใช้คีย์ที่แชร์กับ Gatekeeper และคอมโพเนนต์ TEE ไบโอเมตริกที่รองรับ Keymaster เชื่อถือการประทับเวลาในโทเค็นว่าเป็นเวลาการตรวจสอบสิทธิ์ครั้งสุดท้ายและยึดตามการตัดสินใจปล่อยคีย์ (เพื่ออนุญาตให้แอปใช้คีย์) บนการประทับเวลา
รูปแบบ AuthToken
เพื่อให้แน่ใจว่ามีการแบ่งปันโทเค็นและความเข้ากันได้ในภาษาและส่วนประกอบต่างๆ รูปแบบ AuthToken ได้อธิบายไว้ใน hw_auth_token.h
รูปแบบนี้เป็นโปรโตคอลการซีเรียลไลซ์เซชั่นอย่างง่ายพร้อมฟิลด์ขนาดคงที่
สนาม | พิมพ์ | ที่จำเป็น | คำอธิบาย |
---|---|---|---|
เวอร์ชัน AuthToken | 1 ไบต์ | ใช่ | แท็กกลุ่มสำหรับทุกฟิลด์ด้านล่าง |
ท้าทาย | เลขจำนวนเต็มไม่มีเครื่องหมาย 64 บิต | ไม่ | จำนวนเต็มสุ่มเพื่อป้องกันการโจมตีซ้ำ โดยปกติ ID ของการดำเนินการเข้ารหัสลับที่ร้องขอ ปัจจุบันใช้โดยการอนุมัติลายนิ้วมือในการทำธุรกรรม หากมี AuthToken จะใช้ได้กับการดำเนินการเข้ารหัสลับที่มีความท้าทายเหมือนกันเท่านั้น |
ผู้ใช้SID | เลขจำนวนเต็มไม่มีเครื่องหมาย 64 บิต | ใช่ | ตัวระบุผู้ใช้ที่ไม่ซ้ำซึ่งผูกกับรหัสทั้งหมดที่เกี่ยวข้องกับการตรวจสอบสิทธิ์อุปกรณ์ด้วยการเข้ารหัสลับ สำหรับรายละเอียด โปรดดูที่ Gatekeeper |
รหัสรับรองความถูกต้อง (ASID) | เลขจำนวนเต็ม 64 บิตที่ไม่ได้ลงนามในลำดับเครือข่าย | ไม่ | ตัวระบุที่ใช้ในการผูกกับนโยบายตัวรับรองความถูกต้องเฉพาะ ผู้ตรวจสอบสิทธิ์ทุกคนมีค่า ASID ของตนเองซึ่งสามารถเปลี่ยนแปลงได้ตามความต้องการของตนเอง |
ประเภทตัวรับรองความถูกต้อง | เลขจำนวนเต็มไม่มีเครื่องหมาย 32 บิตในลำดับเครือข่าย | ใช่ |
|
การประทับเวลา | เลขจำนวนเต็ม 64 บิตที่ไม่ได้ลงนามในลำดับเครือข่าย | ใช่ | เวลา (เป็นมิลลิวินาที) นับตั้งแต่การบู๊ตระบบครั้งล่าสุด |
AuthToken HMAC (SHA-256) | หยด 256 บิต | ใช่ | คีย์ SHA-256 MAC ของทุกฟิลด์ยกเว้นฟิลด์ HMAC |
ขั้นตอนการบูตอุปกรณ์
ในการบู๊ตอุปกรณ์ทุกครั้ง จะต้องสร้างคีย์ AuthToken HMAC และแชร์กับส่วนประกอบ TEE ทั้งหมด (Gatekeeper, Keymaster และ trustlets ไบโอเมตริกซ์ที่รองรับ) ดังนั้น สำหรับการป้องกันเพิ่มเติมจากการโจมตีแบบเล่นซ้ำ คีย์ HMAC ต้องถูกสร้างแบบสุ่มทุกครั้งที่อุปกรณ์รีบูต
โปรโตคอลสำหรับการแชร์คีย์ HMAC นี้กับส่วนประกอบทั้งหมดเป็นคุณลักษณะการใช้งานที่ขึ้นกับแพลตฟอร์ม คีย์ต้อง ไม่ เปิดเผยนอก TEE หาก TEE OS ไม่มีกลไกการสื่อสารระหว่างกระบวนการภายใน (IPC) และจำเป็นต้องถ่ายโอนข้อมูลผ่านระบบปฏิบัติการที่ไม่น่าเชื่อถือ การถ่ายโอนจะต้องดำเนินการผ่านโปรโตคอลการแลกเปลี่ยนคีย์ที่ปลอดภัย
ระบบปฏิบัติการ Trusty ซึ่งทำงานถัดจาก Android เป็นตัวอย่างของ TEE แต่สามารถใช้ TEE อื่นแทนได้ Trusty ใช้ระบบ IPC ภายในเพื่อสื่อสารโดยตรงระหว่าง Keymaster และ Gatekeeper หรือ trustlet ไบโอเมตริกซ์ที่เหมาะสม คีย์ HMAC ถูกเก็บไว้ใน Keymaster เท่านั้น ลายนิ้วมือและ Gatekeeper ขอคีย์จาก Keymaster สำหรับการใช้งานแต่ละครั้ง และไม่คงอยู่หรือแคชค่า
เนื่องจาก TEE บางตัวไม่มีโครงสร้างพื้นฐาน IPC จึงไม่มีการสื่อสารระหว่างแอปเพล็ตใน TEE นอกจากนี้ยังอนุญาตให้บริการที่เก็บคีย์สามารถปฏิเสธคำขอที่อาจต้องล้มเหลวได้อย่างรวดเร็ว เนื่องจากมีความรู้เกี่ยวกับตารางการรับรองความถูกต้องในระบบ ซึ่งช่วยประหยัด IPC ที่อาจมีค่าใช้จ่ายสูงลงใน TEE