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

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

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

ส่วนประกอบ Gatekeeper, ลายนิ้วมือ และไบโอเมตริกซ์ทำงานร่วมกับ Keystore และส่วนประกอบอื่นๆ เพื่อรองรับการใช้ โทเค็นการรับรองความ ถูกต้องที่สนับสนุนด้วยฮาร์ดแวร์ (AuthTokens)

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

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

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

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

การรับรองความถูกต้อง

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

รูปที่ 1. ขั้นตอนการรับรองความถูกต้อง

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

หมายเหตุ: AuthTokens จะใช้งานไม่ได้เมื่ออุปกรณ์รีบูต

รูปแบบ AuthToken

เพื่อให้มั่นใจว่ามีการแชร์โทเค็นและความเข้ากันได้ระหว่างภาษาและส่วนประกอบต่างๆ รูปแบบ AuthToken จึงอธิบายไว้ใน hw_auth_token.h รูปแบบนี้เป็นโปรโตคอลการทำให้เป็นอนุกรมอย่างง่ายพร้อมฟิลด์ขนาดคงที่

สนาม	พิมพ์	ที่จำเป็น	คำอธิบาย
เวอร์ชัน AuthToken	1 ไบต์	ใช่	แท็กกลุ่มสำหรับทุกช่องด้านล่าง
ท้าทาย	จำนวนเต็ม 64 บิตที่ไม่ได้ลงนาม	เลขที่	จำนวนเต็มแบบสุ่มเพื่อป้องกันการโจมตีซ้ำ โดยปกติแล้วจะเป็น ID ของการดำเนินการเข้ารหัสลับที่ร้องขอ ปัจจุบันใช้โดยการอนุมัติลายนิ้วมือของธุรกรรม หากมีอยู่ AuthToken จะใช้ได้กับการดำเนินการเข้ารหัสลับที่มีการท้าทายเดียวกันเท่านั้น
ผู้ใช้ SID	จำนวนเต็ม 64 บิตที่ไม่ได้ลงนาม	ใช่	ตัวระบุผู้ใช้ที่ไม่ซ้ำซึ่งเชื่อมโยงกับคีย์ทั้งหมดที่เกี่ยวข้องกับการตรวจสอบสิทธิ์อุปกรณ์แบบเข้ารหัส สำหรับรายละเอียด โปรดดูที่ ผู้รักษาประตู
รหัสตัวรับรองความถูกต้อง (ASID)	จำนวนเต็ม 64 บิตที่ไม่ได้ลงนามตามลำดับเครือข่าย	เลขที่	ตัวระบุที่ใช้ในการผูกกับนโยบายการตรวจสอบสิทธิ์เฉพาะ ผู้ตรวจสอบความถูกต้องทั้งหมดมีค่า ASID ของตัวเองซึ่งสามารถเปลี่ยนแปลงได้ตามความต้องการของตนเอง
ประเภทตัวตรวจสอบสิทธิ์	จำนวนเต็ม 32 บิตที่ไม่ได้ลงนามตามลำดับเครือข่าย	ใช่	0x00 คือผู้รักษาประตู 0x01 คือลายนิ้วมือ
การประทับเวลา	จำนวนเต็ม 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 เท่านั้น ลายนิ้วมือและผู้เฝ้าประตูขอคีย์จาก Keymaster สำหรับการใช้งานแต่ละครั้ง และไม่คงอยู่หรือแคชค่า

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