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

ระบบย่อย 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) ที่เข้าถึง daemon gatekeeperd ในระบบปฏิบัติการ Android ภูต gatekeeperd จะทำการร้องขอที่ไปถึงคู่ของมัน (ผู้เฝ้าประตู) ใน TEE:

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

การใช้ HAL

ภูต gatekeeperd ใช้ HAL เพื่อโต้ตอบกับ TEE ของผู้ gatekeeperd ประตูสำหรับการตรวจสอบรหัสผ่าน การใช้งาน HAL จะต้องสามารถลงนาม (ลงทะเบียน) และตรวจสอบ Blob ได้ การใช้งานทั้งหมดคาดว่าจะเป็นไปตามรูปแบบมาตรฐานสำหรับโทเค็นการตรวจสอบสิทธิ์ (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 มีการนำ GateKeeper ไปใช้ C++ ทั่วไปซึ่งต้องการเพียงการเพิ่มรูทีนเฉพาะอุปกรณ์เท่านั้นจึงจะเสร็จสมบูรณ์ หากต้องการใช้งาน TEE Gatekeeper ด้วยโค้ดเฉพาะอุปกรณ์สำหรับ TEE ของคุณ โปรดดูฟังก์ชันและความคิดเห็นใน system/gatekeeper/include/gatekeeper/gatekeeper.h สำหรับ TEE GateKeeper ความรับผิดชอบหลักของการดำเนินการตามข้อกำหนด ได้แก่:

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

User Secure ID (SID)

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

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

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

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

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

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

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