사용자는 지문 센서가 달린 기기에 1개 이상의 지문을 등록할 수 있으며 등록한 지문을 사용하여 기기를 잠금 해제하고 다른 작업을 실행할 수 있습니다. Android는 지문 HIDL(하드웨어 인터페이스 정의 언어)을 사용하여 공급업체별 라이브러리와 지문 하드웨어(예: 지문 센서)를 연결합니다.
기기의 지문 센서는 보통 유휴 상태로 유지됩니다. 하지만 authenticate 또는 enroll에 대한 응답으로 지문 센서가 터치를 수신 대기합니다. 또한 사용자가 지문 센서를 터치하면 화면 절전 모드가 해제될 수도 있습니다. 상위 수준의 지문 일치 흐름에는 다음과 같은 단계가 포함됩니다.
사용자가 지문 센서에 손가락을 댑니다.
공급업체별 라이브러리에서 현재 등록된 지문 템플릿 모음에 일치하는 지문이 있는지 파악합니다.
일치하는 결과가 FingerprintService로 전달됩니다.
이 흐름에서는 지문이 이미 기기에 등록되었다고 가정합니다. 즉, 공급업체별 라이브러리에서 지문의 템플릿을 등록했습니다. 자세한 내용은
인증을 참조하세요.
아키텍처
지문 HAL은 다음 구성요소와 상호작용합니다.
BiometricManager는 앱 프로세스의 앱과 직접적으로 상호작용합니다.
각 앱에는 IBiometricsFingerprint.hal의 인스턴스가 있습니다.
FingerprintService는 지문 HAL로 통신을 처리하는 시스템 프로세스에서 작동합니다.
지문 HAL은 IBiometricsFingerprint HIDL 인터페이스의 CC++ 구현입니다. 여기에는 기기 전용 하드웨어와 통신하는
공급업체별 라이브러리가 포함되어 있습니다.
Keystore API 및 KeyMint (이전 Keymaster) 구성요소는 TEE (신뢰할 수 있는 실행 환경)와 같은 보안 환경의 보안 키 저장소를 위한 하드웨어 지원 암호법을 제공합니다.
그림 1. 지문 인증과 관련된 높은 수준의 데이터 흐름
공급업체별 HAL 구현에는 TEE에서 요구하는 통신 프로토콜을 사용해야 합니다. 원본 이미지와 처리된 지문 기능은 신뢰할 수 없는 메모리로 전달되면 안 됩니다. 이러한 생체 인식 데이터는 TEE와 같은 보안 하드웨어에 저장해야 합니다. 루팅은 생체 인식 데이터에 손상을 입힐 수 없어야 합니다.
FingerprintService 및 fingerprintd는 지문 HAL을 통해 공급업체별 라이브러리를 호출하여 지문을 등록하고 다른 작업을 수행합니다.
그림 2. 지문 데몬 및 지문 공급업체별 라이브러리 간의 상호작용
구현 가이드
다음 지문 HAL 가이드는 사용자가 기기에서 제거되었을 때 지문 데이터가 삭제되고유출되지 않도록 하는 데 목적이 있습니다.
원시 지문 데이터나 파생물(예: 템플릿)은 센서 드라이버나 TEE 외부에서 액세스할 수 없어야 합니다. 하드웨어에서 TEE를 지원하는 경우 하드웨어 액세스가 TEE로 제한되고 SELinux 정책으로 보호받아야 합니다. SPI(직렬 주변기기 인터페이스) 채널은 TEE에만 액세스할 수 있어야 하며 모든 기기 파일에 대한 명시적인 SELinux 정책이어야 합니다.
지문 획득, 등록 및 인식은 TEE 내에서 발생해야 합니다.
파일 시스템에는 암호화된 형식의 지문 데이터만 저장할 수 있습니다. 파일 시스템
자체가 암호화되어 있는 경우에도 마찬가지입니다.
지문 템플릿은 기기 전용 비공개 키로 서명해야 합니다.
고급 암호화 표준(AES)의 경우 템플릿 파일이 다른 기기에서 또는 같은 기기에 등록한 다른 사용자에 의해 작동되지 않도록 최소 한 개의 템플릿을 절대 파일 시스템 경로, 그룹 및 지문 ID로 서명해야 합니다. 예를 들어 같은 기기의 다른 사용자 계정에서 또는 다른 기기에서 지문 데이터를 복사하는 등의 작업 자체가 불가능해야 합니다.
구현은 setActiveGroup() 함수에 의해 제공된 파일 시스템 경로를 사용하거나 사용자가 제거되었을 때 모든 사용자 템플릿 데이터를 삭제할 수 있는 방법을 제공해야 합니다. 지문 템플릿 파일은 제공된 경로에 암호화된 상태로 저장하는 것이 좋습니다. TEE 저장소
요구사항 때문에 이렇게 할 수 없는 경우에는 구현자가 후크를 추가하여
사용자가 제거되었을 때 데이터가 삭제되도록 하는 것이 좋습니다.
지문 템플릿 수집 및 저장을 시작하도록
HAL 상태 시스템을 전환합니다. 등록이 완료되거나 시간 제한이
경과하면 HAL 상태 시스템이 유휴 상태로 돌아갑니다.
preEnroll()
지문 등록 시작을 나타내는 고유 토큰을 생성합니다. enroll 함수에 토큰을 제공하여 비밀번호 사용과 같은 이전 인증이 있었는지 확인합니다. 기기의 사용자 인증 정보가 확인된 후에는 조작 방지를 위해 토큰이 래핑됩니다. 등록 도중에는 토큰이 아직 유효한지 확인해야
합니다.
getAuthenticatorId()
현재의 지문 모음과 관련된
토큰을 반환합니다.
cancel()
대기 중인 등록이나 인증 작업을 취소합니다. HAL
상태 시스템이 유휴 상태로 돌아갑니다.
enumerate()
알려진 모든 지문 템플릿을 열거하기 위한
동기 호출입니다.
remove()
지문 템플릿을 삭제합니다.
setActiveGroup()
HAL 작업을 GID(그룹 식별자)로 식별되는 지정된 그룹에 속하는 지문 모음으로 제한합니다.
authenticate()
작업 ID로 식별되는 지문 관련 작업을 인증합니다.
setNotify()
HAL에서 알림을 수신하는 사용자 함수를 등록합니다. HAL 상태 시스템이 Busy 상태인 경우 HAL이 Busy 상태를 벗어날 때까지 함수가 차단됩니다.
postEnroll()
등록 작업을 마무리하고 preEnroll()에서 생성된 문제를 무효화합니다. 이 메서드는 다중 지문 등록 세션이 끝날 때 호출되어 더 이상 지문을 추가할 수 없음을 나타내야 합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 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,["# Fingerprint HIDL\n\nOn devices with a fingerprint sensor, users can enroll one or more\nfingerprints and use those fingerprints to unlock the device and perform other\ntasks. Android uses the Fingerprint Hardware Interface Definition Language\n(HIDL) to connect to a vendor-specific library and fingerprint hardware (for\nexample, a fingerprint sensor).\n\nTo implement the Fingerprint HIDL, you must implement [`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal)\nin a vendor-specific library.\n\nFingerprint matching\n--------------------\n\nThe fingerprint sensor of a device is generally idle. However, in response to\na call to `authenticate` or `enroll`, the\nfingerprint sensor listens for a touch (the screen might also wake when a user\ntouches the fingerprint sensor). The high-level flow of fingerprint matching\nincludes the following steps:\n\n1. User places a finger on the fingerprint sensor.\n2. The vendor-specific library determines if there is a fingerprint match in the current set of enrolled fingerprint templates.\n3. Matching results are passed to `FingerprintService`.\n\nThis flow assumes that a fingerprint has already been enrolled on the device, that is,\nthe vendor-specific library has enrolled a template for the fingerprint. For more\ndetails, see [Authentication](/docs/security/features/authentication).\n| **Note:** The more fingerprint templates stored on a device, the more time required for fingerprint matching.\n\nArchitecture\n------------\n\nThe Fingerprint HAL interacts with the following components.\n\n- `BiometricManager` interacts directly with an app in an app process. Each app has an instance of `IBiometricsFingerprint.hal`\n- `FingerprintService` operates in the system process, which handles communication with fingerprint HAL.\n- **Fingerprint HAL** is a C/C++ implementation of the IBiometricsFingerprint HIDL interface. This contains the vendor-specific library that communicates with the device-specific hardware.\n- **Keystore API and KeyMint (previously Keymaster)** components provide hardware-backed cryptography for secure key storage in a secure environment, such as the Trusted Execution Environment (TEE).\n\n**Figure 1.** High-level data flow for fingerprint authentication\n\nA vendor-specific HAL implementation must use the communication protocol\nrequired by a TEE. Raw images and processed fingerprint features must not\nbe passed in untrusted memory. All such biometric data needs to be stored\nin the secure hardware such as the TEE. Rooting **must not**\nbe able to compromise biometric data.\n\n`FingerprintService` and `fingerprintd` make calls through the Fingerprint HAL to\nthe vendor-specific library to enroll fingerprints and perform other\noperations.\n**Figure 2.** Interaction of the fingerprint daemon with the fingerprint vendor-specific library\n\nImplementation guidelines\n-------------------------\n\nThe following Fingerprint HAL guidelines are designed to ensure that\nfingerprint data is **not leaked** and is **removed**\nwhen a user is removed from a device:\n\n- Raw fingerprint data or derivatives (for example, templates) must never be accessible from outside the sensor driver or TEE. If the hardware supports a TEE, hardware access must be limited to the TEE and protected by an SELinux policy. The Serial Peripheral Interface (SPI) channel must be accessible only to the TEE and there must be an explicit SELinux policy on all device files.\n- Fingerprint acquisition, enrollment, and recognition must occur inside the TEE.\n- Only the encrypted form of the fingerprint data can be stored on the file system, even if the file system itself is encrypted.\n- Fingerprint templates must be signed with a private, device-specific key. For Advanced Encryption Standard (AES), at a minimum a template must be signed with the absolute file-system path, group, and finger ID such that template files are inoperable on another device or for anyone other than the user that enrolled them on the same device. For example, copying fingerprint data from a different user on the same device or from another device must not work.\n- Implementations must either use the file-system path provided by the `setActiveGroup()` function or provide a way to erase all user template data when the user is removed. It's strongly recommended that fingerprint template files be stored as encrypted and stored in the path provided. If this is infeasible due to TEE storage requirements, the implementer must add hooks to ensure removal of the data when the user is removed.\n\nFingerprint methods\n-------------------\n\nThe Fingerprint HIDL interface contains the following major methods in\n[`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal).\n\n| Method | Description |\n|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `enroll()` | Switches the HAL state machine to start the collection and storage of a fingerprint template. When enrollment is complete, or after a timeout, the HAL state machine returns to the idle state. |\n| `preEnroll()` | Generates a unique token to indicate the start of a fingerprint enrollment. Provides a token to the `enroll` function to ensure there was prior authentication, for example, using a password. To prevent tampering, the token is wrapped after the device credential is confirmed. The token must be checked during enrollment to verify that it's still valid. |\n| `getAuthenticatorId()` | Returns a token associated with the current fingerprint set. |\n| `cancel()` | Cancels pending enroll or authenticate operations. The HAL state machine is returned to the idle state. |\n| `enumerate()` | Synchronous call for enumerating all known fingerprint templates. |\n| `remove()` | Deletes a fingerprint template. |\n| `setActiveGroup()` | Restricts a HAL operation to a set of fingerprints that belong to a specified group, identified by a group identifier (GID). |\n| `authenticate()` | Authenticates a fingerprint-related operation (identified by an operation ID). |\n| `setNotify()` | Registers a user function that receives notifications from the HAL. If the HAL state machine is in a busy state, the function is blocked until the HAL leaves the busy state. |\n| `postEnroll()` | Finishes the enroll operation and invalidates the `preEnroll()` generated challenge. This must be called at the end of a multifinger enrollment session to indicate that no more fingers may be added. |\n\nFor more details on these, refer to the comments in [`IBiometricsFingerprint.hal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/biometrics/fingerprint/2.1/IBiometricsFingerprint.hal)."]]