Gatekeeper

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

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

สถาปัตยกรรม

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

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

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

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

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

การติดตั้งใช้งาน HAL

Daemon gatekeeperd ใช้ HAL IGatekeeper เพื่อโต้ตอบกับ Gatekeeper TA ที่สำคัญสำหรับการตรวจสอบสิทธิ์ด้วยรหัสผ่าน การติดตั้งใช้งาน Gatekeeper TA ต้องสามารถลงชื่อ (ลงทะเบียน) และยืนยัน 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 ใดๆ สามารถใช้ Gatekeeper ได้ตราบใดที่ TEE มีสิทธิ์เข้าถึงคีย์อิงฮาร์ดแวร์แบบถาวรและนาฬิกาแบบโมโนโทนิกที่ปลอดภัยซึ่งทำงานในโหมดระงับ

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

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

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

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

รหัสความปลอดภัยของผู้ใช้ (SID)

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

การลงทะเบียนซ้ำที่เชื่อถือได้จะเกิดขึ้นเมื่อผู้ใช้ระบุรหัสผ่านเดิมที่ถูกต้อง เช่น เมื่อเปลี่ยนรหัสผ่าน ในกรณีนี้ ระบบจะย้ายข้อมูล 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) โดยตรง