ผู้รักษาประตู

ระบบย่อย Gatekeeper ดำเนินการตรวจสอบรูปแบบอุปกรณ์/รหัสผ่านใน Trusted Execution Environment (TEE) Gatekeeper ลงทะเบียนและยืนยันรหัสผ่านผ่าน HMAC ด้วยคีย์ลับที่ฮาร์ดแวร์สนับสนุน นอกจากนี้ Gatekeeper ยังควบคุมการพยายามตรวจสอบที่ล้มเหลวติดต่อกันและต้องปฏิเสธคำขอบริการตามระยะหมดเวลาที่กำหนดและจำนวนครั้งของความพยายามที่ล้มเหลวติดต่อกัน

เมื่อผู้ใช้ตรวจสอบรหัสผ่านของตน Gatekeeper จะใช้ความลับที่ใช้ร่วมกันที่ได้รับจาก TEE เพื่อลงนามในเอกสารรับรองความถูกต้องเพื่อส่งไปยัง Keystore ที่ได้รับการสนับสนุนจากฮาร์ดแวร์ กล่าวคือ เอกสารรับรอง Gatekeeper จะแจ้ง Keystore ว่าคีย์ที่ผูกกับการตรวจสอบสิทธิ์ (เช่น คีย์ที่แอปสร้างขึ้น) สามารถเผยแพร่ให้แอปใช้งานได้

สถาปัตยกรรม

Gatekeeper เกี่ยวข้องกับสามองค์ประกอบหลัก:

• gatekeeperd (ภูตผู้รักษาประตู) บริการตัวประสาน C++ ที่มีตรรกะที่ไม่ขึ้นกับแพลตฟอร์มและสอดคล้องกับอินเทอร์เฟซ GateKeeperService Java
• Gatekeeper Hardware Abstraction Layer (HAL) . อินเทอร์เฟซ HAL ใน hardware/libhardware/include/hardware/gatekeeper.h และโมดูลการนำไปใช้
• ผู้รักษา ประตู (TEE) . คู่ TEE ของ gatekeeperd การใช้งาน Gatekeeper แบบ TEE

Gatekeeper ต้องใช้ Gatekeeper HAL (โดยเฉพาะฟังก์ชันใน hardware/libhardware/include/hardware/gatekeeper.h ) และ ส่วนประกอบ Gatekeeper เฉพาะ TEE (ส่วนหนึ่งขึ้นอยู่กับไฟล์ส่วนหัวของ system/gatekeeper/include/gatekeeper/gatekeeper.h ที่มีฟังก์ชันเสมือนแท้จริงสำหรับการสร้าง/เข้าถึงคีย์และลายเซ็นการประมวลผล)

LockSettingsService จะส่งคำขอ (ผ่าน Binder) ที่เข้าถึง gatekeeperd daemon ในระบบปฏิบัติการ Android gatekeeperd daemon จะทำการร้องขอที่ส่งถึงคู่ของมัน (Gatekeeper) ใน TEE:

gatekeeperd daemon ให้ API เฟรมเวิร์กของ Android เข้าถึง HAL และมีส่วนร่วมในการรายงานการ ตรวจสอบ อุปกรณ์ไปยัง Keystore gatekeeperd daemon รันในกระบวนการของตัวเอง และแยกจากเซิร์ฟเวอร์ระบบ

การนำ HAL ไปใช้

gatekeeperd daemon ใช้ HAL เพื่อโต้ตอบกับคู่ TEE ของ gatekeeperd daemon สำหรับการพิสูจน์ตัวตนรหัสผ่าน การใช้งาน HAL จะต้องสามารถลงชื่อ (ลงทะเบียน) และยืนยัน Blobs ได้ การใช้งานทั้งหมดต้องเป็นไปตามรูปแบบมาตรฐานสำหรับโทเค็นการตรวจสอบความถูกต้อง (AuthToken) ที่สร้างขึ้นจากการตรวจสอบรหัสผ่านที่สำเร็จแต่ละครั้ง สำหรับรายละเอียดเกี่ยวกับเนื้อหาและความหมายของ AuthToken โปรดดู ที่รูปแบบ AuthToken

การนำไปใช้งานของไฟล์ส่วนหัว hardware/libhardware/include/hardware/gatekeeper.h ต้องใช้ฟังก์ชั่นการ enroll และ verify :

• ฟังก์ชันการ enroll ใช้รหัสผ่านหยด เซ็นชื่อ และส่งกลับลายเซ็นเป็นหมายเลขอ้างอิง blob ที่ส่งคืน (จากการเรียก enroll ) ต้องมีโครงสร้างที่แสดงใน system/gatekeeper/include/gatekeeper/password_handle.h
• ฟังก์ชัน verify ต้องเปรียบเทียบลายเซ็นที่สร้างโดยรหัสผ่านที่ให้มา และตรวจสอบให้แน่ใจว่าตรงกับตัวจัดการรหัสผ่านที่ลงทะเบียนไว้

คีย์ที่ใช้ในการลงทะเบียนและยืนยันจะต้องไม่เปลี่ยนแปลง และควรได้รับใหม่ทุกครั้งที่เปิดเครื่อง

ความน่าเชื่อถือและการใช้งานอื่น ๆ

ระบบปฏิบัติการ Trusty เป็นระบบปฏิบัติการโอเพ่นซอร์สที่เชื่อถือได้ของ Google สำหรับสภาพแวดล้อม TEE และมีการใช้งาน GateKeeper ที่ได้รับอนุมัติ อย่างไรก็ตาม คุณสามารถใช้ TEE OS ใดๆ เพื่อใช้งาน Gatekeeper ได้ ตราบใดที่ TEE สามารถเข้าถึงคีย์ที่ได้รับการสนับสนุนจากฮาร์ดแวร์และนาฬิกาแบบโมโนโทนิกที่ปลอดภัยซึ่งทำ เครื่องหมายใน suspend

Trusty ใช้ระบบ IPC ภายในเพื่อสื่อสารความลับที่ใช้ร่วมกันโดยตรงระหว่าง Keymaster และการนำ Trusty ไปใช้งานของ Gatekeeper ( Trusty Gatekeeper ) ความลับที่ใช้ร่วมกันนี้ใช้สำหรับลงนาม AuthTokens ที่ส่งไปยัง Keystore เพื่อให้การรับรองการตรวจสอบรหัสผ่าน Trusty Gatekeeper ขอคีย์จาก Keymaster สำหรับการใช้งานแต่ละครั้งและไม่คงอยู่หรือแคชค่า การใช้งานมีอิสระที่จะแบ่งปันความลับนี้ในลักษณะที่ไม่กระทบต่อความปลอดภัย

คีย์ HMAC ที่ใช้ในการลงทะเบียนและยืนยันรหัสผ่านนั้นได้รับมาและเก็บไว้ใน GateKeeper เท่านั้น

Android มีการใช้งาน C++ ทั่วไปของ GateKeeper ซึ่งต้องการเพียงการเพิ่มรูทีนเฉพาะอุปกรณ์เท่านั้นจึงจะเสร็จสมบูรณ์ ในการใช้งาน TEE Gatekeeper ด้วยรหัสเฉพาะอุปกรณ์สำหรับ TEE ของคุณ โปรดดูฟังก์ชันและความคิดเห็นใน system/gatekeeper/include/gatekeeper/gatekeeper.h สำหรับ TEE GateKeeper ความรับผิดชอบหลักของการปฏิบัติตามข้อกำหนด ได้แก่:

• การปฏิบัติตาม Gatekeeper HAL
• AuthToken ที่ส่งคืนต้องมีรูปแบบตามข้อกำหนด AuthToken (อธิบายไว้ใน Authentication )
• TEE Gatekeeper จะต้องสามารถแชร์คีย์ HMAC กับ Keymaster โดยการร้องขอคีย์ผ่าน TEE IPC ตามคำขอ หรือรักษาแคชของค่าที่ถูกต้องตลอดเวลา

ID ที่ปลอดภัยของผู้ใช้ (SID)

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

User SID เป็น HMAC'ed พร้อมกับรหัสผ่านในการจัดการรหัสผ่านเมื่อลงทะเบียนรหัสผ่าน

SID ของผู้ใช้จะถูกเขียนลงใน AuthToken ที่ส่งคืนโดยฟังก์ชันการ verify และเชื่อมโยงกับคีย์สโตร์ที่ผูกกับการตรวจสอบสิทธิ์ทั้งหมด (สำหรับรายละเอียดเกี่ยวกับรูปแบบ AuthToken และ Keystore โปรดดูที่ Authentication ) เนื่องจากการเรียกฟังก์ชันการ enroll ที่ไม่น่าเชื่อถือจะเปลี่ยน User SID การเรียกจะทำให้คีย์ที่ผูกกับรหัสผ่านนั้นไร้ประโยชน์ ผู้โจมตีสามารถเปลี่ยนรหัสผ่านของอุปกรณ์ได้หากพวกเขาควบคุมระบบปฏิบัติการ Android แต่พวกเขาจะทำลายคีย์ที่ละเอียดอ่อนซึ่งได้รับการปกป้องโดยรูทและในกระบวนการ

ขอการควบคุมปริมาณ

GateKeeper ต้องสามารถเค้นความพยายามเดรัจฉานบนข้อมูลรับรองผู้ใช้ได้อย่างปลอดภัย ตามที่แสดงใน hardware/libhardware/include/hardware/gatekeeper.h HAL กำหนดให้ส่งคืนการหมดเวลาเป็นมิลลิวินาที การหมดเวลาจะแจ้งให้ไคลเอ็นต์ไม่เรียก GateKeeper อีกจนกว่าจะหมดเวลา GateKeeper ไม่ควรให้บริการตามคำขอหากมีการหมดเวลารอดำเนินการ

GateKeeper ต้องเขียนตัวนับความล้มเหลวก่อนที่จะตรวจสอบรหัสผ่านของผู้ใช้ หากการตรวจสอบรหัสผ่านสำเร็จ ควรล้างตัวนับความล้มเหลว ซึ่งป้องกันการโจมตีที่ป้องกันการควบคุมปริมาณโดยการปิดใช้งาน MMC แบบฝัง (eMMC) หลังจากออกการโทร verify ฟังก์ชันการ enroll ยังตรวจสอบรหัสผ่านของผู้ใช้ (หากมี) และต้องควบคุมในลักษณะเดียวกัน

หากอุปกรณ์รองรับ ขอแนะนำเป็นอย่างยิ่งให้เขียนตัวนับความล้มเหลวลงในที่เก็บข้อมูลที่ปลอดภัย หากอุปกรณ์ไม่รองรับการเข้ารหัสแบบไฟล์ หรือหากที่เก็บข้อมูลที่ปลอดภัยช้าเกินไป การใช้งานอาจใช้ Replay Protected Memory Block (RPMB) โดยตรง