Gatekeeper

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

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

สถาปัตยกรรม

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

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

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

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

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

การใช้งาน HAL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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