Gatekeeper

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

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

สถาปัตยกรรม

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

• gatekeeperd (Gatekeeper daemon) - บริการ Binder ของ C++ ใน Android ซึ่งมีตรรกะที่ไม่ขึ้นอยู่กับแพลตฟอร์มที่ใช้IGateKeeperService อินเทอร์เฟซ AIDL โดยอิงจากการใช้งาน IGatekeeper ที่เฉพาะเจาะจงของผู้ให้บริการที่อยู่เบื้องหลัง
• บริการเลเยอร์การแยกฮาร์ดแวร์ (HAL) ของ Gatekeeper — การใช้งานเฉพาะผู้ให้บริการของอินเทอร์เฟซ AIDL IGatekeeper บริการ 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

Daemon 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 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 ความรับผิดชอบหลักของการติดตั้งใช้งานที่เป็นไปตามข้อกำหนดมีดังนี้

• การปฏิบัติตาม IGatekeeper HAL
• โทเค็นการตรวจสอบสิทธิ์ที่ส่งคืนต้องจัดรูปแบบตาม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 ฟังก์ชันยัง ยืนยันรหัสผ่านของผู้ใช้ (หากระบุ) และต้องมีการควบคุมอัตราในลักษณะเดียวกัน

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