2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
Authentication
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android에는 기기를 잠금 해제하고 암호화 키에 대한 액세스를 제한하는 데 사용되는 사용자 인증자라는 개념이 있습니다. 여기에는 다음 구성요소가 포함됩니다.
- 암호화 키 저장소 및 서비스 제공업체: 암호화 키를
저장하고 이러한 키 외에 표준 암호법 루틴을 제공합니다.
Android에서는 암호화 서비스를 위한 하드웨어 지원 키 저장소 및 KeyMint (이전 명칭: Keymaster)를 지원합니다. 여기에는 StrongBox와 같은 TTE(신뢰할 수 있는 실행 환경) 또는 SE (보안 요소)가 포함될 수 있는 키 저장소의 하드웨어 지원 암호화도 포함됩니다.
- 사용자 인증자: 사용자의 존재 및 인증 성공을
증명합니다. Android에서는 PIN/패턴/비밀번호 인증을 위한 게이트키퍼와 지문 인증을 위한 지문을 지원합니다. Android 9 이상이 기본으로 적용된 기기는
BiometricPrompt를 지문 및 추가 생체 인식을 위한 단일 통합 지점으로 사용할 수 있습니다. 이러한 구성요소는 인증 채널을 통해 인증 상태를 키 저장소 서비스와 통신합니다.
프레임워크 수준의 Android 키 저장소 시스템도 키 저장소 서비스에서 지원됩니다.
이러한 각 구성요소는 공급업체별이지만 공급업체 구현은 하드웨어 추상화 계층 (HAL) 인터페이스 사양을 충족하고 해당 공급업체 테스트 모음 (VTS) 테스트를 통과해야 합니다.
공급업체 구현도 일반적으로 공급업체별 통신 메커니즘으로 연결된 두 부분으로 나뉩니다.
- HAL 서비스는 Android 시스템 프로세스로 실행되며 Android 시스템에서 바인더 요청을 수신합니다.
- 신뢰할 수 있는 애플리케이션 (TA)은 보안 환경에서 실행되어 실제 보안 작업을 실행합니다.
등록
초기화 이후에 기기가 처음 부팅되면 모든 인증이 사용자의 인증 정보 등록을
수신할 준비를 마칩니다. 사용자는 처음에 게이트키퍼 (또는 Weaver, 사용 가능한 경우)에 PIN, 패턴 또는 비밀번호를 등록해야 합니다. 이 최초 등록 시 64비트 사용자 보안 식별자(SID)가 무작위로 생성됩니다. 사용자 보안 식별자는 사용자 식별자 및 사용자 암호화 자료의 바인딩 토큰으로 사용됩니다. 이 사용자 SID는 사용자의 비밀번호에 암호화 방식으로 바인딩됩니다. 게이트키퍼 인증에 성공하면 비밀번호의 사용자 SID를 포함하는 AuthToken이 결과물로 생성됩니다.
기존 사용자 인증 정보를 변경하려는 사용자는 해당 사용자 인증 정보를 제시해야 합니다. 기존 사용자 인증 정보가 성공적으로 확인되면 기존 사용자 인증 정보에 연결된 사용자 SID가 새로운 사용자 인증 정보로 전송되어 사용자는 사용자 인증 정보 변경 후에도 계속해서 키에 액세스할 수 있습니다.
경우에 따라 기기 관리자는 신뢰할 수 없는 등록을 실행하여 기존 사용자 인증 정보를 표시하지 않고 새 사용자 인증 정보를 등록할 수 있습니다. 이렇게 하면 사용자가 기기에 액세스할 수 있지만 기존 사용자 SID로 생성된 키는 영구적으로 손실됩니다.
인증
이 섹션에서는 Android와 보안 환경 모두에서 여러 구성요소 간의 상호작용이 포함된 일반적인 인증 흐름을 설명합니다. 모든 보안 구성요소는 서로의 메시지를 인증하는 데 사용하는 부팅별 보안 HMAC 키를 공유합니다.
사용자가 사용자 인증 정보를 설정하고 사용자 SID가 할당되면 인증을 시작할 수 있습니다. 인증은 사용자가 PIN, 패턴, 비밀번호, 지문 또는 기타 강력한 생체 인식을 제공하면 시작됩니다.
그림 1. 인증 흐름
- 사용자가 인증 방법을 제공하고 관련 서비스에서 HAL 서비스에 요청합니다.
- PIN, 패턴 또는 비밀번호의 경우
LockSettingsService에서 gatekeeperd에 요청합니다.
- 생체 인식 기반 인증 흐름은 Android 버전에 따라 다릅니다.
Android 8.x 이하를 실행하는 기기에서는
FingerprintService에서 fingerprintd에 요청합니다. Android 9 이상을 실행하는 기기에서는 FingerprintManager 또는 FaceManager와 같이 적절한 BiometricManager 클래스를 사용하여 BiometricPrompt에서 적합한 생체 인식 데몬에 요청합니다. 예를 들어 지문의 경우 fingerprintd 또는 얼굴의 경우 faced입니다. 버전과 상관없이 생체 인식 인증은 요청이 전송된 후 비동기식으로 발생합니다.
- HAL 서비스는 AuthToken을 생성하는 상응 TA에 데이터를 전송합니다.
- PIN/패턴/비밀번호 인증의 경우
gatekeeperd는 게이트키퍼 HAL 서비스를 통해 PIN, 패턴 또는 비밀번호 해시를 TEE의 게이트키퍼 TA로 전송합니다. TEE의 인증이 성공하면 게이트키퍼 TA는 상응하는 사용자 SID가 포함된 AuthToken을 내보냅니다(공유 HMAC 키로 서명됨).
- 지문 인증의 경우
fingerprintd는 지문 이벤트를 수신 대기하고 지문 HAL을 통해 데이터를 TEE의 지문 TA로 전송합니다. TEE의 인증이 성공하면 지문 TA가 AuthToken HMAC 키로 서명된 AuthToken을 내보냅니다.
- 다른 생체 인식 인증의 경우 적절한 생체 인식 데몬이 생체 인식 이벤트를 수신 대기하고 이를 적절한 생체 인식 HAL 서비스 및 TA로 전송합니다.
- 데몬이 서명된 AuthToken을 수신하여 키 저장소 서비스의 바인더 인터페이스 확장 프로그램을 통해 키 저장소 서비스로 전달합니다.
gatekeeperd는 기기가 다시 잠금 처리되거나 기기 비밀번호가 변경될 때 키 저장소 서비스에도 알립니다.
- 키 저장소 서비스는 AuthToken을 KeyMint에 전달하고 게이트키퍼 및 지원되는 생체 인식 TEE 구성요소와 공유된 키를 사용하여 확인합니다. KeyMint는 토큰의 타임스탬프를 마지막 인증 시간으로 신뢰하고 키 출시 결정 (앱에서 키를 사용하도록 허용)을 타임스탬프에 기반합니다.
인증 흐름에는 보안 환경의 TA 간 직접 통신이 필요하지 않습니다. AuthToken은 인증자 TA에서 Android의 keystore2 서비스로 흐르고, 이 서비스는 다시 KeyMint TA로 전달합니다.
또한 시스템에서 사용 가능한 AuthToken에 관한 정보가 있으므로 keystore2 서비스에서 실패가 확실한 요청을 빠르게 거부하여 비용이 많이 드는 IPC를 TEE에 저장하지 않아도 됩니다.
AuthToken 형식은 HardwareAuthToken.aidl의 AIDL 사양에 나와 있습니다.
기기 부팅 흐름
기기가 부팅될 때마다 AuthToken HMAC 키를 생성하여 모든 TEE 구성요소 (게이트키퍼, KeyMint, 지원되는 생체 인식 trustlet)와 공유해야 합니다. 따라서 재전송 공격 방지를 강화하려면 기기가 재부팅될 때마다
HMAC 키를 무작위로 생성해야 합니다.
TA가 이 공유 HMAC 키에 액세스하는 일반적인 방법은 두 가지입니다.
- 공유 보안 비밀 계약:
keystore2 서비스는 기기 시작 시 다자간 키 계약 프로토콜을 실행하여 참여하는 TA 간에 HMAC 키의 보안 파생을 허용합니다.
하지만 참여 TA는 공통 사전 공유 보안 비밀에 액세스할 수 있어야 합니다.
- 직접 액세스: 동일한 보안 환경 내에 있는 TA는 내부 프로세스 간 통신 메커니즘(플랫폼에 따라 다름)을 사용하여 HMAC 키를 공유할 수 있습니다.
어떤 경우든 HMAC 키는 TEE 외부에서 사용 가능해서는 안 됩니다.
Android 옆에서 실행되는 Trusty 운영체제는 TEE의 한 예이지만 다른 TEE를 대신 사용할 수도 있습니다. Trusty는 내부 IPC 시스템을 사용하여 KeyMint와 게이트키퍼 또는 적절한 생체 인식 trustlet 간에 직접 통신합니다. HMAC 키는 KeyMint에만 보관됩니다. 지문 및 게이트키퍼는 사용 시마다 KeyMint에서 키를 요청하며 값을 유지하거나 캐시하지 않습니다.
일부 TEE에는 IPC 인프라가 없으므로 TEE의 애플릿 간에 통신이 발생하지 않습니다. 따라서 시스템의 인증 표에 관한 정보가 있는 키 저장소 서비스에서 실패가 확실한 요청을 빠르게 거부하여 비용이 많이 드는 IPC를 TEE에 저장하지 않아도 됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 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,["# 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."]]
