Android에서는 다음 구성요소가 필요한 사용자 인증 제한이 적용된 암호화 키의 개념을 사용합니다.
- 암호화 키 저장소 및 서비스 제공업체: 암호화 키를 저장하고 이러한 키 외에 표준 암호법 루틴을 제공합니다. Android에서는 암호화 서비스를 위한 하드웨어 지원 키 저장소 및 Keymaster를 지원합니다. 여기에는 Strongbox와 같은 TTE(신뢰할 수 있는 실행 환경) 또는 SE(보안 요소)가 포함될 수 있는 키 저장소의 하드웨어 지원 암호화도 포함됩니다.
- 사용자 인증자: 사용자의 존재 및 인증 성공을
증명합니다. Android에서는 PIN/패턴/비밀번호 인증을 위한 게이트키퍼와 지문 인증을 위한 지문을 지원합니다. Android 9 이상이 기본으로 적용된 기기는
BiometricPrompt를 지문 및 추가 생체 인식을 위한 단일 통합 지점으로 사용할 수 있습니다. 이러한 구성요소는 인증 채널을 통해 인증 상태를 키 저장소 서비스와 통신합니다. 프레임워크 수준의 Android 키 저장소 시스템도 키 저장소 서비스에서 지원됩니다.
게이트키퍼, 지문 및 생체 인식 구성요소는 키 저장소 및 기타 구성요소와 함께 작동하여 하드웨어 지원 인증 토큰(AuthToken)의 사용을 지원합니다.
등록
초기화 이후에 기기가 처음 부팅되면 모든 인증이 사용자의 인증 정보 등록을 수신할 준비를 마칩니다. 사용자는 처음에 게이트키퍼에 PIN/패턴/비밀번호를 등록해야 합니다. 최초 등록 시 64비트 사용자 SID(보안 식별자)가 무작위로 생성됩니다. 사용자 SID는 사용자 ID, 그리고 사용자의 암호화 자료와 관련된 귀속 토큰으로 기능합니다. 이 사용자 SID는 사용자의 비밀번호에 암호화 방식으로 귀속됩니다. 게이트키퍼 인증에 성공하면 비밀번호의 사용자 SID를 포함하는 AuthToken이 결과물로 생성됩니다.
사용자 인증 정보를 변경하고 싶은 사용자는 기존 인증 정보를 제시해야 합니다. 기존 사용자 인증 정보가 성공적으로 확인되면 기존 사용자 인증 정보에 연결된 사용자 SID가 새로운 사용자 인증 정보로 전송되어 사용자는 사용자 인증 정보 변경 후에도 계속해서 키에 액세스할 수 있습니다. 사용자가 기존 사용자 인증 정보를 제시하지 않으면 새로운 사용자 인증 정보가 완전 임의의 사용자 SID로 등록됩니다. 사용자는 기기에 액세스할 수 있지만 기존 사용자 SID로 생성된 키는 영구적으로 손실됩니다. 이를 신뢰할 수 없는 등록이라고 합니다.
일반적인 상황에서는 Android 프레임워크에서 신뢰할 수 없는 등록을 허용하지 않습니다. 따라서 대부분의 사용자는 이 기능을 볼 수 없습니다. 하지만 기기 관리자 또는 공격자에 의한 비밀번호 강제 재설정으로 인해 신뢰할 수 없는 등록이 발생할 수 있습니다.
인증
사용자 인증 정보를 설정하고 사용자 SID를 받은 사용자는 인증을 시작할 수 있습니다. 이 과정은 사용자가 PIN, 패턴, 비밀번호나 지문을 제시하면 시작됩니다. 모든 TEE 구성요소는 서로의 메시지를 인증하는 데 사용하는 보안 비밀 키를 공유합니다.
- 사용자가 인증 방법을 제공하고 관련 서비스에서 연결된 데몬에 요청합니다.
- PIN, 패턴 또는 비밀번호의 경우
LockSettingsService에서gatekeeperd에 요청합니다. - 생체 인식 기반 인증 흐름은 Android 버전에 따라 다릅니다.
Android 8.x 이하를 실행하는 기기에서는
FingerprintService에서fingerprintd에 요청합니다. Android 9 이상을 실행하는 기기에서는FingerprintManager또는FaceManager와 같이 적절한BiometricManager클래스를 사용하여BiometricPrompt에서 적합한 생체 인식 데몬에 요청합니다. 예를 들어 지문의 경우fingerprintd또는 얼굴의 경우faced입니다. 버전과 상관없이 생체 인식 인증은 요청이 전송된 후 비동기식으로 발생합니다.
- PIN, 패턴 또는 비밀번호의 경우
- 데몬이 AuthToken을 생성하는 상응 요소에 데이터를 전송합니다.
- PIN/패턴/비밀번호 인증의 경우
gatekeeperd는 PIN, 패턴 또는 비밀번호 해시를 TEE의 게이트키퍼로 전송합니다. TEE의 인증이 성공하면 TEE의 게이트키퍼는 AuthToken HMAC 키로 서명된 상응하는 사용자 SID가 포함된 AuthToken을 Android OS의 상응 요소에 전송합니다. - 지문 인증의 경우
fingerprintd는 지문 이벤트를 수신 대기하고 데이터를 TEE의 지문으로 전송합니다. TEE의 인증이 성공하면 TEE의 지문은 AuthToken HMAC 키로 서명된 AuthToken을 Android OS의 상응 요소에 전송합니다. - 다른 생체 인식 인증의 경우 적절한 생체 인식 데몬이 생체 인식 이벤트를 수신 대기하고 이를 적절한 생체 인식 TEE 구성요소로 전송합니다.
- PIN/패턴/비밀번호 인증의 경우
- 데몬이 서명된 AuthToken을 수신하여 키 저장소 서비스의 바인더 인터페이스 확장 프로그램을 통해 키 저장소 서비스로 전달합니다.
gatekeeperd는 기기가 다시 잠금 처리되거나 기기 비밀번호가 변경될 때 키 저장소 서비스에도 알립니다. - 키 저장소 서비스는 AuthToken을 Keymaster에 전달하고 게이트키퍼 및 지원되는 생체 인식 TEE 구성요소와 공유된 키를 사용하여 확인합니다. Keymaster는 토큰의 타임스탬프를 마지막 인증 시간으로 신뢰하고 키 출시 결정(앱에서 키를 사용하도록 허용)을 타임스탬프에 기반합니다.
AuthToken 형식
언어 및 구성요소 전반에 걸친 토큰 공유 및 호환성을 확인하도록 AuthToken 형식이 hw_auth_token.h에 설명되어 있습니다.
형식은 필드 크기가 고정된 단순한 직렬화 프로토콜입니다.
| 필드 | 유형 | 필수 | 설명 |
|---|---|---|---|
| AuthToken 버전 | 1바이트 | 예 | 아래 모든 필드의 그룹 태그입니다. |
| 챌린지 | 부호 없는 64비트 정수 | 아니요 | 재전송 공격 예방을 위한 무작위 정수입니다. 요청된 암호화 작업의 ID인 경우가 일반적입니다. 현재는 트랜젝션 지문 인증에 사용됩니다. 필드가 있으면 같은 챌린지를 포함하는 암호화 작업에 대해서만 AuthToken이 유효합니다. |
| 사용자 SID | 부호 없는 64비트 정수 | 호환됨 | 기기 인증과 관련된 모든 키에 암호화 방식으로 연결된 비반복적 사용자 식별자입니다. 자세한 내용은 게이트키퍼를 참조하세요. |
| 인증자 ID(ASID) | 네트워크 순서의 부호 없는 64비트 정수 | 아니요 | 특정 인증자 정책에 귀속시키기 위해 사용되는 ID입니다. 모든 인증자에는 자체 요구사항에 따라 변경 가능한 자체 ASID 값이 있습니다. |
| 인증자 유형 | 네트워크 순서의 부호 없는 32비트 정수 | 예 |
|
| 타임스탬프 | 네트워크 순서의 부호 없는 64비트 정수 | 예 | 가장 최근의 시스템 부팅 이후의 시간(밀리초)입니다. |
| AuthToken HMAC(SHA-256) | 256비트 blob | 예 | HMAC 필드를 제외한 모든 필드의 키 SHA-256 MAC입니다. |
기기 부팅 흐름
기기가 부팅될 때마다 AuthToken HMAC 키를 생성하여 모든 TEE 구성요소(게이트키퍼, Keymaster 및 지원되는 생체 인식 trustlet)와 공유해야 합니다. 따라서 재전송 공격 방지를 강화하려면 기기가 재부팅될 때마다 HMAC 키를 무작위로 생성해야 합니다.
이 HMAC 키를 모든 구성요소와 공유하기 위한 프로토콜은 플랫폼에 구애받는 구현 기능입니다. 키는 TEE 외부에서 사용 가능해서는 안 됩니다. TEE OS에 내부 IPC(프로세스 간 통신) 메커니즘이 없고 신뢰할 수 없는 OS를 통해 데이터를 전송해야 한다면 보안 키 교환 프로토콜을 통해 전송을 실행해야 합니다.
Android 옆에서 실행되는 Trusty 운영체제는 TEE의 한 예이지만 다른 TEE를 대신 사용할 수도 있습니다. Trusty는 내부 IPC 시스템을 사용하여 Keymaster 및 게이트키퍼 또는 적절한 생체 인식 trustlet과 직접적으로 통신합니다. HMAC 키는 Keymaster에만 보관됩니다. 지문 및 게이트키퍼는 사용 시마다 Keymaster에서 키를 요청하며 값을 유지하거나 캐시하지 않습니다.
일부 TEE에는 IPC 인프라가 없으므로 TEE의 애플릿 간에 통신이 발생하지 않습니다. 따라서 시스템의 인증 표에 관한 정보가 있어서 비용이 많이 드는 IPC를 TEE에 저장하는 키 저장소 서비스에서 실패가 확실한 요청을 빠르게 거부할 수 있습니다.