ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
Authentication
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Android มีแนวคิดเกี่ยวกับเครื่องมือตรวจสอบสิทธิ์ของผู้ใช้ซึ่งใช้เพื่อปลดล็อกอุปกรณ์และควบคุมการเข้าถึงคีย์การเข้ารหัส ซึ่งเกี่ยวข้องกับคอมโพเนนต์ต่อไปนี้
คอมโพเนนต์แต่ละรายการเหล่านี้เป็นของเฉพาะผู้ให้บริการ แต่ผู้ให้บริการต้องใช้งานเพื่อให้เป็นไปตาม
ข้อกำหนดของอินเทอร์เฟซHardware Abstraction Layer (HAL)
และผ่านการทดสอบชุดทดสอบของผู้ให้บริการ (VTS) ที่เกี่ยวข้อง
โดยปกติแล้ว การติดตั้งใช้งานของผู้ให้บริการจะแบ่งออกเป็น 2 ส่วนเช่นกัน ซึ่งเชื่อมต่อกัน
ด้วยกลไกการสื่อสารเฉพาะของผู้ให้บริการ ดังนี้
- บริการ HAL จะทํางานเป็นกระบวนการของระบบ Android และรับคําขอ Binder จากระบบ Android
- แอปพลิเคชันที่เชื่อถือได้ (TA) จะทำงานในสภาพแวดล้อมที่ปลอดภัย
เพื่อดำเนินการที่ปลอดภัยจริง
การลงทะเบียน
เมื่อบูตอุปกรณ์เป็นครั้งแรกหลังจากรีเซ็ตเป็นค่าเริ่มต้น ระบบจะเตรียมตัวตรวจสอบสิทธิ์ทั้งหมด
เพื่อรับการลงทะเบียนข้อมูลเข้าสู่ระบบจากผู้ใช้ ผู้ใช้ต้องลงทะเบียน PIN, รูปแบบ หรือรหัสผ่านกับ Gatekeeper (หรือ Weaver หากมี) ในตอนแรก
การลงทะเบียนครั้งแรกนี้จะสร้างตัวระบุที่ปลอดภัยของผู้ใช้ (SID) แบบ 64 บิตที่สร้างขึ้นแบบสุ่ม
ซึ่งทำหน้าที่เป็นตัวระบุสำหรับผู้ใช้และเป็นโทเค็นการเชื่อมโยงสำหรับ
เนื้อหาการเข้ารหัสของผู้ใช้ SID ของผู้ใช้นี้เชื่อมโยงกับรหัสผ่านของผู้ใช้ด้วยการเข้ารหัส การตรวจสอบสิทธิ์ที่สำเร็จใน Gatekeeper จะส่งผลให้ได้ AuthToken
ที่มี SID ของผู้ใช้สำหรับรหัสผ่านนั้น
ผู้ใช้ที่ต้องการเปลี่ยนข้อมูลเข้าสู่ระบบที่มีอยู่จะต้องแสดงข้อมูลเข้าสู่ระบบนั้น
หากยืนยันข้อมูลเข้าสู่ระบบที่มีอยู่สำเร็จ ระบบจะโอน SID ของผู้ใช้
ที่เชื่อมโยงกับข้อมูลเข้าสู่ระบบที่มีอยู่ไปยังข้อมูลเข้าสู่ระบบใหม่
เพื่อให้ผู้ใช้เข้าถึงคีย์ต่อไปได้หลังจากเปลี่ยนข้อมูลเข้าสู่ระบบ
ในบางกรณี ผู้ดูแลระบบอุปกรณ์สามารถลงทะเบียนที่ไม่น่าเชื่อถือเพื่อลงทะเบียนข้อมูลเข้าสู่ระบบใหม่โดยไม่ต้องแสดงข้อมูลเข้าสู่ระบบที่มีอยู่
ซึ่งจะช่วยให้ผู้ใช้เข้าถึงอุปกรณ์ได้ แต่คีย์ที่สร้างขึ้นภายใต้
SID ของผู้ใช้เดิมจะหายไปอย่างถาวร
การตรวจสอบสิทธิ์
ส่วนนี้จะอธิบายขั้นตอนการตรวจสอบสิทธิ์ทั่วไป ซึ่งเกี่ยวข้องกับการโต้ตอบระหว่างคอมโพเนนต์หลายรายการทั้งใน Android และสภาพแวดล้อมที่ปลอดภัย โปรดทราบว่าคอมโพเนนต์ที่ปลอดภัยทั้งหมดใช้คีย์ HMAC ลับ (ต่อการบูต) ร่วมกัน
ซึ่งใช้เพื่อตรวจสอบสิทธิ์ข้อความของกันและกัน
หลังจากที่ผู้ใช้ตั้งค่าข้อมูลเข้าสู่ระบบและได้รับ SID ของผู้ใช้แล้ว ผู้ใช้จะเริ่มการตรวจสอบสิทธิ์ได้ ซึ่งจะเริ่มต้นเมื่อผู้ใช้ระบุ PIN, รูปแบบ, รหัสผ่าน, ลายนิ้วมือ หรือไบโอเมตริกที่มีความปลอดภัยสูงอื่นๆ
รูปที่ 1 ขั้นตอนการตรวจสอบสิทธิ์
- ผู้ใช้ระบุวิธีการตรวจสอบสิทธิ์และบริการที่เกี่ยวข้อง
ส่งคำขอไปยังบริการ HAL
- สำหรับ PIN, รูปแบบ หรือรหัสผ่าน
LockSettingsService
จะส่งคำขอไปยัง gatekeeperd
- ขั้นตอนการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกจะขึ้นอยู่กับเวอร์ชันของ Android
ในอุปกรณ์ที่ใช้ Android 8.x และต่ำกว่า
FingerprintService
จะส่งคำขอไปยัง fingerprintd) ในอุปกรณ์
ที่ใช้ Android 9 ขึ้นไป BiometricPrompt จะส่งคำขอไปยัง
daemon ไบโอเมตริกที่เหมาะสม (เช่น fingerprintd สำหรับลายนิ้วมือหรือ faced สำหรับ
ใบหน้า) โดยใช้คลาส BiometricManager ที่เหมาะสม
เช่น FingerprintManager หรือ FaceManager ไม่ว่าจะเป็นเวอร์ชันใด การตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก
จะเกิดขึ้นแบบไม่พร้อมกันหลังจากส่งคำขอ
- บริการ HAL จะส่งข้อมูลไปยัง TA ที่เกี่ยวข้อง ซึ่งจะสร้าง AuthToken ดังนี้
AuthToken:
- สำหรับการตรวจสอบสิทธิ์ด้วย PIN/รูปแบบ/รหัสผ่าน
gatekeeperd จะส่งแฮช PIN, รูปแบบ หรือรหัสผ่านไปยัง TA ของ Gatekeeper ใน TEE ผ่านบริการ HAL ของ Gatekeeper หากการตรวจสอบสิทธิ์ใน TEE สำเร็จ Gatekeeper TA จะปล่อย AuthToken ที่มี SID ของผู้ใช้ที่เกี่ยวข้อง
(ลงนามด้วยคีย์ HMAC ที่แชร์)
- สำหรับการตรวจสอบลายนิ้วมือ
fingerprintd จะรอรับ
เหตุการณ์ลายนิ้วมือและส่งข้อมูลไปยัง TA ลายนิ้วมือใน TEE ผ่าน
HAL ลายนิ้วมือ หาก
การตรวจสอบสิทธิ์ใน TEE สำเร็จ TA ลายนิ้วมือจะปล่อย
AuthToken (ลงนามด้วยคีย์ HMAC ของ AuthToken)
- สำหรับการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกอื่นๆ ไดมอนไบโอเมตริกที่เหมาะสม
จะรอรับฟังเหตุการณ์ไบโอเมตริกและส่งไปยังบริการ HAL ไบโอเมตริกที่เหมาะสม
และ TA
- Daemon จะรับ AuthToken ที่ลงชื่อแล้วและส่งไปยังบริการ Keystore
ผ่านส่วนขยายไปยังอินเทอร์เฟซ Binder ของบริการ Keystore
(
gatekeeperd ยังแจ้งเตือนบริการที่เก็บคีย์เมื่ออุปกรณ์
ถูกล็อกอีกครั้งและเมื่อรหัสผ่านของอุปกรณ์มีการเปลี่ยนแปลงด้วย)
- บริการ Keystore จะส่ง AuthToken ไปยัง KeyMint และยืนยันโทเค็นเหล่านั้น
โดยใช้คีย์ที่แชร์กับ Gatekeeper และคอมโพเนนต์ TEE ไบโอเมตริกที่รองรับ
KeyMint จะเชื่อถือการประทับเวลาในโทเค็นเป็นเวลาการตรวจสอบสิทธิ์ล่าสุด
และใช้การประทับเวลาเป็นเกณฑ์ในการตัดสินใจว่าจะอนุญาตให้แอปใช้คีย์หรือไม่
โฟลว์การตรวจสอบสิทธิ์ไม่จำเป็นต้องมีการสื่อสารโดยตรงระหว่าง TA ใน
สภาพแวดล้อมที่ปลอดภัย: AuthToken จะไหลจาก TA ของเครื่องมือตรวจสอบสิทธิ์ไปยัง
keystore2 บริการใน Android ซึ่งจะส่งต่อโทเค็นไปยัง TA ของ KeyMint
ซึ่งยังช่วยให้keystore2ปฏิเสธคำขอที่อาจล้มเหลวได้อย่างรวดเร็ว เนื่องจากทราบว่ามี AuthToken ใดบ้างในระบบ จึงช่วยประหยัด IPC ที่อาจมีค่าใช้จ่ายสูงใน TEE
รูปแบบของ AuthToken จะกำหนดโดยข้อกำหนด AIDL ใน
HardwareAuthToken.aidl
โฟลว์การเปิดเครื่องอุปกรณ์
ทุกครั้งที่บูตอุปกรณ์ ระบบจะต้องสร้างคีย์ HMAC ของโทเค็นการให้สิทธิ์และ
แชร์กับคอมโพเนนต์ TEE ทั้งหมด (Gatekeeper, KeyMint และ Trustlet ของไบโอเมตริกที่รองรับ
) ดังนั้น เพื่อเพิ่มการป้องกันการโจมตีแบบรีเพลย์ คีย์ HMAC
ต้องสร้างแบบสุ่มทุกครั้งที่อุปกรณ์รีบูต
โดย TA จะได้รับสิทธิ์เข้าถึงคีย์ HMAC ที่แชร์นี้ได้ 2 วิธีที่นิยมใช้กัน
- ข้อตกลงเกี่ยวกับข้อมูลลับที่แชร์:
keystore2 บริการ
จะใช้โปรโตคอลข้อตกลงเกี่ยวกับคีย์แบบหลายทางเมื่ออุปกรณ์เริ่มต้นระบบ ซึ่งจะช่วยให้
สามารถสร้างคีย์ HMAC ระหว่าง TA ที่เข้าร่วมได้อย่างปลอดภัย
อย่างไรก็ตาม TA ที่เข้าร่วมต้องมีสิทธิ์เข้าถึงข้อมูลลับที่ใช้ร่วมกันซึ่งมีการแชร์ล่วงหน้า
- การเข้าถึงโดยตรง: TA ที่อยู่ในสภาพแวดล้อมที่ปลอดภัยเดียวกัน
สามารถใช้กลไกการสื่อสารระหว่างกระบวนการภายใน
(ซึ่งขึ้นอยู่กับแพลตฟอร์ม) เพื่อแชร์คีย์ HMAC
ไม่ว่าในกรณีใดก็ตาม คีย์ HMAC ต้องไม่พร้อมใช้งาน
นอก TEE
ระบบปฏิบัติการ Trusty
ซึ่งทำงานควบคู่กับ Android เป็นตัวอย่างของ TEE แต่คุณจะใช้ TEE อื่นแทนก็ได้
Trusty ใช้ระบบ IPC ภายในเพื่อสื่อสารโดยตรงระหว่าง KeyMint กับ Gatekeeper หรือ Trustlet ไบโอเมตริกที่เหมาะสม คีย์ HMAC จะ
จัดเก็บไว้ใน KeyMint เท่านั้น โดย Fingerprint และ Gatekeeper จะขอคีย์จาก
KeyMint สำหรับการใช้งานแต่ละครั้ง และจะไม่จัดเก็บหรือแคชค่า
เนื่องจาก TEE บางรายการไม่มีโครงสร้างพื้นฐาน IPC จึงไม่มีการสื่อสารระหว่าง
แอปเพล็ตใน TEE นอกจากนี้ยังช่วยให้บริการที่เก็บคีย์ปฏิเสธคำขอที่อาจล้มเหลวได้อย่างรวดเร็ว เนื่องจากบริการนี้ทราบตารางการตรวจสอบสิทธิ์ในระบบ จึงช่วยประหยัด IPC ที่อาจมีค่าใช้จ่ายสูงไปยัง TEE
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 2025-07-27 UTC"],[],[],null,["# Authentication\n\nAndroid has the concept of user authenticators that are used to unlock the\ndevice and to gate access to cryptographic keys. This involves the following\ncomponents:\n\n- **Cryptographic key storage and service provider.** Stores cryptographic keys and provides standard crypto routines on top of those keys. Android supports a [hardware-backed\n Keystore](/docs/security/features/keystore) and KeyMint (previously Keymaster) for cryptographic services, including hardware-backed cryptography for key storage that might include a Trusted Execution Environment (TEE) or Secure Element (SE), such as StrongBox.\n- **User authenticators.** Attest to the user's presence and/or successful authentication. Android supports [Gatekeeper](/docs/security/features/authentication/gatekeeper) for PIN/pattern/password authentication and [Fingerprint](/docs/security/features/authentication/fingerprint-hal) for fingerprint authentication. Devices that ship with Android 9 and higher can use [`BiometricPrompt`](https://developer.android.com/reference/android/hardware/biometrics/BiometricPrompt) as a single integration point for fingerprint and additional biometrics. These components communicate their authentication state with the keystore service through an authenticated channel. (The [Android Keystore system](https://developer.android.com/training/articles/keystore.html) at the framework level is also backed by the keystore service.)\n\nEach of these components is vendor-specific, but the vendor implementation is required to satisfy\na [Hardware Abstraction Layer (HAL)](/docs/core/architecture/hal) interface\nspecification, and to pass the corresponding vendor test suite (VTS) tests.\n\nVendor implementations are typically also divided into two parts, connected\nby a vendor-specific communication mechanism :\n\n- A *HAL service* runs as an Android system process, receiving Binder requests from the Android system.\n- A *trusted application (TA)* runs in the secure environment, performing the actual secure operations.\n\nEnrollment\n----------\n\nOn first boot of the device after a factory reset, all authenticators are\nprepared to receive credential enrollments from the user. A user must initially\nenroll a PIN, pattern, or password with Gatekeeper (or Weaver, if available). This\ninitial enrollment creates a randomly generated, 64-bit user secure identifier\n(SID) that serves as an identifier for the user and as a binding token for the\nuser's cryptographic material. This user SID is cryptographically bound to the\nuser's password; successful authentications to Gatekeeper result in AuthTokens\nthat contain the user SID for that password.\n\nA user who wants to change an existing credential must present that\ncredential. If an existing credential is verified successfully, the user SID\nassociated with the existing credential is transferred to the new credential,\nenabling the user to keep accessing keys after changing a credential.\n\nIn some situations, a device administrator can perform an *untrusted\nenroll* to enroll a new credential without presenting an existing\ncredential. This allows the user to access the device, but keys created under\nthe old user SID are permanently lost.\n\nAuthentication\n--------------\n\nThis section describes a typical authentication flow, which involves\ninteractions between multiple components in both Android and the secure\nenvironment. Note that all secure components share a (per-boot) secret HMAC key\nthat they use to authenticate each other's messages.\n\nAfter a user has set up a credential and been assigned a user SID, they can\nstart authentication, which begins when a user provides a PIN, pattern,\npassword, fingerprint, or other strong biometric.\n\n\n**Figure 1.** Authentication flow\n\n1. A user provides an authentication method and the associated service makes a request to the HAL service.\n - For PIN, pattern, or password, `LockSettingsService` makes a request to `gatekeeperd`.\n - Biometrics-based authentication flows depend on the Android version. On devices running Android 8.x and lower, `FingerprintService` makes a request to `fingerprintd`). On devices running Android 9 and higher, `BiometricPrompt` makes a request to the appropriate biometric daemon (for example, `fingerprintd` for fingerprints or `faced` for face) using the appropriate \u003cvar translate=\"no\"\u003eBiometric\u003c/var\u003e`Manager` class, such as `FingerprintManager` or `FaceManager`. Regardless of version, biometric authentication occurs asynchronously after the request is sent.\n2. The HAL service sends data to its counterpart TA, which generates an AuthToken:\n - For PIN/pattern/password authentication, `gatekeeperd` sends the PIN, pattern, or password hash to the Gatekeeper TA in the TEE, via the Gatekeeper HAL service. If authentication in the TEE is successful, the Gatekeeper TA emits an AuthToken containing the corresponding user SID (signed with the shared HMAC key).\n - For fingerprint authentication, `fingerprintd` listens for fingerprint events and sends the data to the Fingerprint TA in the TEE, via the Fingerprint HAL. If authentication in the TEE is successful, the Fingerprint TA emits an AuthToken (signed with the AuthToken HMAC key).\n - For other biometric authentication, the appropriate biometric daemon listens for the biometric event and sends it to the appropriate biometric HAL service and TA.\n3. The daemon receives a signed AuthToken and passes it to the keystore service through an extension to the keystore service's Binder interface. (`gatekeeperd` also notifies the keystore service when the device is relocked and when the device password changes.)\n4. The Keystore service passes the AuthTokens to KeyMint and verifies them using the key shared with the Gatekeeper and supported biometric TEE component. KeyMint trusts the timestamp in the token as the last authentication time and bases a key release decision (to allow an app to use the key) on the timestamp.\n\nThe authentication flow does not require direct communication between TAs in\nthe secure environment: AuthTokens flow from the authenticator TA to the\n`keystore2` service in Android, which in turn passes them on to the KeyMint TA.\nThis also permits the `keystore2` service to quickly deny requests\nthat are bound to fail, as it has knowledge of the available AuthTokens in the\nsystem, saving a potentially costly IPC into the TEE.\n\nAuthToken format\n----------------\n\nThe format of the AuthToken is given by the AIDL specification in\n[`HardwareAuthToken.aidl`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/security/keymint/aidl/android/hardware/security/keymint/HardwareAuthToken.aidl).\n\nDevice boot flow\n----------------\n\nOn every boot of a device, the AuthToken HMAC key must be generated and\nshared with all TEE components (Gatekeeper, KeyMint, and supported biometrics\ntrustlets). Thus, for added protection against replay attacks, the HMAC key\nmust be randomly generated every time the device reboots.\n\nThere are two common ways that TAs acquire access to this shared HMAC\nkey:\n\n- *Shared secret agreement:* The `keystore2` service performs a multi-way key agreement protocol at device startup, allowing secure derivation of the HMAC key between those TAs that participate. However, participating TAs must have access to a common preshared secret.\n- *Direct access:* TAs that reside within the same secure environment can use an internal interprocess communication mechanism (which is platform-dependent) to share the HMAC key.\n\n\u003cbr /\u003e\n\nIn either case, the HMAC key must **never** be made available\noutside the TEE.\n\nThe [Trusty](/docs/security/features/trusty) operating system,\nwhich runs next to Android, is an example of a TEE, but other TEEs can be used\ninstead. Trusty uses an internal IPC system to communicate directly between\nKeyMint and Gatekeeper or the appropriate biometric trustlet. The HMAC key is\nkept solely in KeyMint; Fingerprint and Gatekeeper request the key from\nKeyMint for each use and don't persist or cache the value.\n\nAs some TEEs lack an IPC infrastructure, no communication occurs between\napplets in the TEE. This also permits the keystore service to quickly deny\nrequests that are bound to fail as it has knowledge of the authentication table\nin the system, saving a potentially costly IPC into the TEE."]]
