Authentication

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

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

คอมโพเนนต์แต่ละรายการเหล่านี้เป็นของเฉพาะผู้ให้บริการ แต่ผู้ให้บริการต้องใช้งานเพื่อให้เป็นไปตาม ข้อกำหนดของอินเทอร์เฟซHardware Abstraction Layer (HAL) และผ่านการทดสอบชุดทดสอบของผู้ให้บริการ (VTS) ที่เกี่ยวข้อง

โดยปกติแล้ว การติดตั้งใช้งานของผู้ให้บริการจะแบ่งออกเป็น 2 ส่วนเช่นกัน ซึ่งเชื่อมต่อกัน ด้วยกลไกการสื่อสารเฉพาะของผู้ให้บริการ ดังนี้

• บริการ HAL จะทํางานเป็นกระบวนการของระบบ Android และรับคําขอ Binder จากระบบ Android
• แอปพลิเคชันที่เชื่อถือได้ (TA) จะทำงานในสภาพแวดล้อมที่ปลอดภัย เพื่อดำเนินการที่ปลอดภัยจริง

การลงทะเบียน

เมื่อบูตอุปกรณ์เป็นครั้งแรกหลังจากรีเซ็ตเป็นค่าเริ่มต้น ระบบจะเตรียมเครื่องมือตรวจสอบสิทธิ์ทั้งหมด เพื่อรับการลงทะเบียนข้อมูลเข้าสู่ระบบจากผู้ใช้ ผู้ใช้ต้องลงทะเบียน PIN, รูปแบบ หรือรหัสผ่านกับ Gatekeeper (หรือ Weaver หากมี) ในตอนแรก การลงทะเบียนครั้งแรกนี้จะสร้างตัวระบุที่ปลอดภัยของผู้ใช้ (SID) แบบ 64 บิตที่สร้างขึ้นแบบสุ่ม ซึ่งทำหน้าที่เป็นตัวระบุสำหรับผู้ใช้และเป็นโทเค็นการเชื่อมโยงสำหรับ เนื้อหาการเข้ารหัสของผู้ใช้ SID ของผู้ใช้นี้เชื่อมโยงกับรหัสผ่านของผู้ใช้ด้วยการเข้ารหัส การตรวจสอบสิทธิ์ที่สำเร็จใน Gatekeeper จะส่งผลให้ได้ AuthToken ที่มี SID ของผู้ใช้สำหรับรหัสผ่านนั้น

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

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

การตรวจสอบสิทธิ์

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

หลังจากที่ผู้ใช้ตั้งค่าข้อมูลเข้าสู่ระบบและได้รับ SID ของผู้ใช้แล้ว ผู้ใช้จะ เริ่มการตรวจสอบสิทธิ์ได้ ซึ่งจะเริ่มต้นเมื่อผู้ใช้ระบุ PIN, รูปแบบ, รหัสผ่าน, ลายนิ้วมือ หรือไบโอเมตริกที่มีความปลอดภัยสูงอื่นๆ

รูปที่ 1 ขั้นตอนการตรวจสอบสิทธิ์

1. ผู้ใช้ระบุวิธีการตรวจสอบสิทธิ์และบริการที่เกี่ยวข้อง จะส่งคำขอไปยังบริการ HAL
   • สำหรับ PIN, รูปแบบ หรือรหัสผ่าน LockSettingsService จะส่งคำขอไปยัง gatekeeperd
   • ขั้นตอนการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกจะขึ้นอยู่กับเวอร์ชันของ Android ในอุปกรณ์ที่ใช้ Android 8.x ลงมา FingerprintService จะส่งคำขอไปยัง fingerprintd) ในอุปกรณ์ ที่ใช้ Android 9 ขึ้นไป BiometricPrompt จะส่ง คำขอไปยัง Daemon ไบโอเมตริกที่เหมาะสม (เช่น fingerprintd สำหรับลายนิ้วมือหรือ faced สำหรับ ใบหน้า) โดยใช้คลาส BiometricManager ที่เหมาะสม เช่น FingerprintManager หรือ FaceManager ไม่ว่าจะเป็นเวอร์ชันใด การตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก จะเกิดขึ้นแบบไม่พร้อมกันหลังจากส่งคำขอ
2. บริการ HAL จะส่งข้อมูลไปยัง TA ที่เกี่ยวข้อง ซึ่งจะสร้าง AuthToken ดังนี้ AuthToken:
   • สำหรับการตรวจสอบสิทธิ์ด้วย PIN/รูปแบบ/รหัสผ่าน gatekeeperd จะส่งแฮช PIN, รูปแบบ หรือรหัสผ่านไปยัง TA ของ Gatekeeper ใน TEE ผ่านบริการ HAL ของ Gatekeeper หากการตรวจสอบสิทธิ์ใน TEE สำเร็จ Gatekeeper TA จะปล่อย AuthToken ที่มี SID ของผู้ใช้ที่เกี่ยวข้อง (ลงนามด้วยคีย์ HMAC ที่แชร์)
   • สำหรับการตรวจสอบลายนิ้วมือ fingerprintd จะรอรับ เหตุการณ์ลายนิ้วมือและส่งข้อมูลไปยัง TA ลายนิ้วมือใน TEE ผ่าน HAL ลายนิ้วมือ หาก การตรวจสอบสิทธิ์ใน TEE สำเร็จ TA ลายนิ้วมือจะปล่อย AuthToken (ลงนามด้วยคีย์ HMAC ของ AuthToken)
   • สำหรับการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกอื่นๆ Daemon ไบโอเมตริกที่เหมาะสมจะรอรับเหตุการณ์ไบโอเมตริกและส่งไปยังบริการ HAL และ TA ของไบโอเมตริกที่เหมาะสม
3. Daemon จะรับ AuthToken ที่ลงชื่อแล้วและส่งไปยังบริการที่เก็บคีย์ ผ่านส่วนขยายไปยังอินเทอร์เฟซ Binder ของบริการที่เก็บคีย์ (gatekeeperd ยังแจ้งเตือนบริการที่เก็บคีย์เมื่ออุปกรณ์ ถูกล็อกอีกครั้งและเมื่อรหัสผ่านของอุปกรณ์มีการเปลี่ยนแปลงด้วย)
4. บริการ Keystore จะส่ง AuthToken ไปยัง KeyMint และยืนยันโทเค็นเหล่านั้น โดยใช้คีย์ที่แชร์กับ Gatekeeper และคอมโพเนนต์ TEE ไบโอเมตริกที่รองรับ KeyMint จะเชื่อถือการประทับเวลาในโทเค็นเป็นเวลาการตรวจสอบสิทธิ์ล่าสุด และใช้การประทับเวลาในการตัดสินใจว่าจะอนุญาตให้แอปใช้คีย์หรือไม่

โฟลว์การตรวจสอบสิทธิ์ไม่จำเป็นต้องมีการสื่อสารโดยตรงระหว่าง TA ใน สภาพแวดล้อมที่ปลอดภัย: AuthToken จะไหลจาก TA ของเครื่องมือตรวจสอบสิทธิ์ไปยัง keystore2 บริการใน Android ซึ่งจะส่งต่อโทเค็นไปยัง TA ของ KeyMint นอกจากนี้ยังช่วยให้keystore2ปฏิเสธคำขอที่อาจไม่สำเร็จได้อย่างรวดเร็ว เนื่องจากทราบ AuthToken ที่พร้อมใช้งานในระบบ ซึ่งช่วยประหยัด IPC ที่อาจมีค่าใช้จ่ายสูงใน TEE

รูปแบบ AuthToken

รูปแบบของ AuthToken จะกำหนดโดยข้อกำหนด AIDL ใน HardwareAuthToken.aidl

โฟลว์การเปิดเครื่องอุปกรณ์

ทุกครั้งที่บูตอุปกรณ์ ระบบจะต้องสร้างคีย์ HMAC ของ AuthToken และ แชร์กับคอมโพเนนต์ TEE ทั้งหมด (Gatekeeper, KeyMint และ Trustlet ของไบโอเมตริกที่รองรับ) ดังนั้น เพื่อเพิ่มการป้องกันการโจมตีแบบรีเพลย์ คีย์ HMAC ต้องสร้างแบบสุ่มทุกครั้งที่อุปกรณ์รีบูต

โดย TA จะได้รับสิทธิ์เข้าถึงคีย์ HMAC ที่แชร์นี้ได้ 2 วิธีที่นิยมใช้กัน ดังนี้

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

ไม่ว่าในกรณีใดก็ตาม คีย์ HMAC ต้องไม่พร้อมใช้งาน นอก TEE

ระบบปฏิบัติการ Trusty ซึ่งทำงานควบคู่กับ Android เป็นตัวอย่างของ TEE แต่คุณจะใช้ TEE อื่นแทนก็ได้ Trusty ใช้ระบบ IPC ภายในเพื่อสื่อสารโดยตรงระหว่าง KeyMint กับ Gatekeeper หรือ Trustlet ไบโอเมตริกที่เหมาะสม ระบบจะเก็บคีย์ HMAC ไว้ใน KeyMint เท่านั้น โดย Fingerprint และ Gatekeeper จะขอคีย์จาก KeyMint สำหรับการใช้งานแต่ละครั้ง และจะไม่เก็บค่าไว้หรือแคชค่า

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