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

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

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

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

สถาปัตยกรรม

Gatekeeper ประกอบด้วยองค์ประกอบหลัก 3 ส่วน ได้แก่

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

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

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

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

การใช้งาน HAL

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

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

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

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

Trusty และการใช้งานอื่นๆ

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

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

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

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

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

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

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

SID ของผู้ใช้จะได้รับ HMAC พร้อมกับรหัสผ่านในตัวแฮนเดิลรหัสผ่านเมื่อลงทะเบียนรหัสผ่าน

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

การควบคุมคำขอ

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

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

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