Gatekeeper

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

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

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

สถาปัตยกรรม

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

• gatekeeperd (Damon ของ Gatekeeper) — บริการ Binder ของ C++ ใน Android ที่มีตรรกะที่ไม่ขึ้นอยู่กับแพลตฟอร์มซึ่งใช้อินเทอร์เฟซ IGateKeeperService ของ AIDL โดยอิงตามการใช้งาน IGatekeeper ของผู้ให้บริการที่เฉพาะเจาะจง
• บริการเลเยอร์การแยกแยะฮาร์ดแวร์ (HAL) ของ Gatekeeper - การใช้งานอินเทอร์เฟซ IGatekeeper AIDL ที่เจาะจงผู้ให้บริการ บริการ HAL นี้ทำงานใน Android แต่ฟังก์ชันหลักของ Gatekeeper ต้องทำงานในสภาพแวดล้อมที่ปลอดภัย ดังนั้นโดยทั่วไปแล้วจึงสื่อสารกับ TA ของ Gatekeeper
• แอปพลิเคชันที่เชื่อถือได้ของ Gatekeeper (TA) - การติดตั้งใช้งานเฉพาะผู้ให้บริการที่ทำงานใน TEE และทำการยืนยันรหัสผ่านหรือรูปแบบจริง

LockSettingsService ส่งคําขอ (ผ่าน Binder) ที่ไปถึง Daemon gatekeeperd ในระบบปฏิบัติการ Android จากนั้น gatekeeperd daemon จะส่งคําขอบริการ IGatekeeper HAL ซึ่งจะติดต่อ TA Gatekeeper ที่สอดคล้องกันใน TEE

รูปที่ 1 การรับส่งข้อมูลระดับสูงสําหรับการตรวจสอบสิทธิ์โดย GateKeeper

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

การใช้งาน HAL

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

การใช้งาน IGatekeeper HAL ของผู้ให้บริการต้องติดตั้งใช้งานฟังก์ชัน enroll และ verify ดังนี้

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

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

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

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

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

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

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

• การปฏิบัติตาม IGatekeeper HAL
• โทเค็นการตรวจสอบสิทธิ์ที่ส่งคืนต้องอยู่ในรูปแบบตามข้อกําหนดของ HardwareAuthToken (อธิบายไว้ใน HardwareAuthToken.aidl)
• TEE Gatekeeper ต้องแชร์คีย์ HMAC กับ KeyMint ได้โดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
  • ข้อตกลงลับที่แชร์: Gatekeeper สามารถเข้าร่วมการเจรจาต่อรองคีย์ HMAC ต่อการบูตแต่ละครั้งได้โดยใช้ ISharedSecret HAL ซึ่งกำหนดให้ทั้ง Gatekeeper และ KeyMint มีสิทธิ์เข้าถึงความลับที่แชร์ล่วงหน้าร่วมกัน
  • การเข้าถึงโดยตรง: Gatekeeper สามารถดึงข้อมูลคีย์ HMAC จาก KeyMint โดยใช้กลไกการสื่อสารระหว่างกระบวนการภายใน TEE ตามคําขอหรือเมื่อใช้งานครั้งแรก (แคชไว้หลังจากนั้น)

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

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

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

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

SID ของผู้ใช้จะรวมอยู่ใน HardwareAuthToken ที่แสดงผลโดยฟังก์ชัน verify() และเชื่อมโยงกับคีย์คีย์สโตร์ที่เชื่อมโยงกับการตรวจสอบสิทธิ์ทั้งหมด (ดูรายละเอียดเกี่ยวกับรูปแบบ HardwareAuthToken และคีย์สโตร์ที่หัวข้อการตรวจสอบสิทธิ์)

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

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

Gatekeeper ต้องสามารถควบคุมการพยายามใช้กำลัง brute force กับข้อมูลเข้าสู่ระบบของผู้ใช้ได้อย่างปลอดภัย ดังที่แสดงใน GatekeeperVerifyResponse.aidl HAL จะแสดงผลเวลาหมดเวลาเป็นมิลลิวินาที การหมดเวลาจะแจ้งให้ไคลเอ็นต์ไม่เรียก Gatekeeper อีกครั้งจนกว่าจะหมดเวลา Gatekeeper ไม่ควรให้บริการคำขอหากมีการหมดเวลารอดำเนินการ

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

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