문지기

컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Gatekeeper 하위 시스템은 TEE(신뢰할 수 있는 실행 환경)에서 장치 패턴/암호 인증을 수행합니다. Gatekeeper는 하드웨어 지원 비밀 키가 있는 HMAC를 통해 암호를 등록하고 확인합니다. 또한 게이트키퍼는 연속적으로 실패한 확인 시도를 조절하고 지정된 시간 초과 및 지정된 연속 실패 시도 횟수에 따라 서비스 요청을 거부해야 합니다.

사용자가 암호를 확인하면 Gatekeeper는 TEE에서 파생된 공유 암호를 사용하여 하드웨어 지원 키 저장소 로 보낼 인증 증명에 서명합니다. 즉, Gatekeeper 증명은 인증 바인딩된 키(예: 앱에서 생성한 키)가 앱에서 사용하기 위해 해제될 수 있음을 Keystore에 알립니다.

건축물

Gatekeeper에는 세 가지 주요 구성 요소가 포함됩니다.

  • gatekeeperd (게이트키퍼 데몬). 플랫폼 독립적 논리를 포함하고 GateKeeperService Java 인터페이스에 해당하는 C++ 바인더 서비스입니다.
  • 게이트키퍼 HAL(하드웨어 추상화 계층) . hardware/libhardware/include/hardware/gatekeeper.h 의 HAL 인터페이스 및 구현 모듈.
  • 게이트키퍼(TEE) . gatekeeperd 의 TEE 대응. Gatekeeper의 TEE 기반 구현.

Gatekeeper는 Gatekeeper HAL (특히 hardware/libhardware/include/hardware/gatekeeper.h 의 기능) 및 TEE별 Gatekeeper 구성요소 ( system/gatekeeper/include/gatekeeper/gatekeeper.h 헤더 파일에 부분적으로 기반함)의 구현이 필요합니다. 키 생성/액세스 및 서명 계산을 위한 순수 가상 기능을 포함합니다.

LockSettingsService 는 Android OS의 gatekeeperd 데몬에 도달하는 요청(바인더를 통해)을 만듭니다. 그런 다음 gatekeeperd 데몬은 TEE의 해당 데몬(Gatekeeper)에 도달하는 요청을 합니다.

게이트키퍼 흐름
그림 1. GateKeeper 인증을 위한 상위 수준 데이터 흐름

gatekeeperd 데몬은 Android 프레임워크 API에 HAL에 대한 액세스 권한을 부여하고 Keystore에 기기 인증 을 보고하는 데 참여합니다. gatekeeperd 데몬은 자체 프로세스에서 실행되며 시스템 서버와 별개입니다.

HAL 구현

gatekeeperd 데몬은 HAL을 사용하여 암호 인증을 위해 gatekeeperd 데몬의 TEE 대응물과 상호 작용합니다. HAL 구현은 Blob에 서명(등록)하고 확인할 수 있어야 합니다. 모든 구현은 성공적인 암호 확인에 대해 생성된 인증 토큰(AuthToken)의 표준 형식을 준수해야 합니다. AuthToken의 내용과 의미에 대한 자세한 내용은 AuthToken 형식 을 참조하세요.

hardware/libhardware/include/hardware/gatekeeper.h 헤더 파일의 구현은 enrollverify 기능을 구현해야 합니다.

  • enroll 함수는 암호 blob을 가져와 서명하고 서명을 핸들로 반환합니다. 반환된 blob(register 호출에서)은 system/ enroll system/gatekeeper/include/gatekeeper/password_handle.h 에 표시된 구조를 가져야 합니다.
  • verify 기능은 제공된 비밀번호에 의해 생성된 서명을 비교하고 등록된 비밀번호 핸들과 일치하는지 확인해야 합니다.

등록 및 확인에 사용되는 키는 절대로 변경되지 않아야 하며 모든 장치 부팅 시 다시 파생될 수 있어야 합니다.

신뢰할 수 있는 및 기타 구현

Trusty 운영 체제는 TEE 환경을 위한 Google의 오픈 소스 신뢰할 수 있는 OS이며 승인된 GateKeeper 구현을 포함합니다. 그러나 TEE가 하드웨어 지원 키와 suspend 에서 똑딱거리는 보안 단조 시계에 액세스할 수 있는 한 모든 TEE OS 를 사용하여 Gatekeeper를 구현할 수 있습니다.

Trusty는 내부 IPC 시스템을 사용하여 Keymaster와 Gatekeeper의 Trusty 구현( Trusty Gatekeeper ) 간에 공유 비밀을 직접 전달합니다. 이 공유 암호는 암호 확인 증명을 제공하기 위해 Keystore로 전송된 AuthToken에 서명하는 데 사용됩니다. Trusty Gatekeeper는 사용할 때마다 Keymaster에서 키를 요청하며 값을 유지하거나 캐시하지 않습니다. 구현은 보안을 손상시키지 않는 방식으로 이 비밀을 자유롭게 공유할 수 있습니다.

비밀번호를 등록하고 확인하는 데 사용되는 HMAC 키는 GateKeeper에서만 파생되고 보관됩니다.

Android는 기기별 루틴만 추가하면 되는 GateKeeper의 일반 C++ 구현을 제공합니다. TEE에 대한 장치별 코드로 TEE 게이트키퍼를 구현하려면 system/gatekeeper/include/gatekeeper/gatekeeper.h 의 기능 및 주석을 참조하십시오. TEE GateKeeper의 경우 규정 준수 구현의 주요 책임은 다음과 같습니다.

  • 게이트키퍼 HAL 준수.
  • 반환된 AuthToken은 AuthToken 사양에 따라 형식이 지정되어야 합니다( Authentication 에서 설명).
  • TEE Gatekeeper는 요청 시 TEE IPC를 통해 키를 요청하거나 항상 값의 유효한 캐시를 유지함으로써 HMAC 키를 Keymaster와 공유할 수 있어야 합니다.

사용자 보안 ID(SID)

사용자 SID는 사용자의 TEE 표현입니다(Android 사용자 ID에 대한 강력한 연결 없음). SID는 사용자가 이전 암호를 제공하지 않고 새 암호를 등록할 때마다 PRNG(암호화 의사 난수 생성기)로 생성됩니다. 이를 신뢰할 수 없는 재등록이라고 하며 일반적인 상황에서는 Android 프레임워크에서 허용하지 않습니다. 신뢰할 수 있는 재등록은 사용자가 유효한 이전 암호를 제공할 때 발생합니다. 이 경우 사용자 SID는 바인딩된 키를 보존하여 새 암호 핸들로 마이그레이션됩니다.

사용자 SID는 암호가 등록될 때 암호 핸들의 암호와 함께 HMAC됩니다.

사용자 SID는 verify 기능에서 반환된 AuthToken에 기록되고 모든 인증 바인딩 키 저장소 키와 연결됩니다(AuthToken 형식 및 키 저장소에 대한 자세한 내용은 인증 참조). enroll 기능에 대한 신뢰할 수 없는 호출은 사용자 SID를 변경하므로 호출은 해당 암호에 바인딩된 키를 쓸모 없게 만듭니다. 공격자는 Android OS를 제어하는 ​​경우 기기의 비밀번호를 변경할 수 있지만 이 과정에서 루트로 보호되는 민감한 키를 파괴합니다.

조절 요청

GateKeeper는 사용자 자격 증명에 대한 무차별 대입 시도를 안전하게 제한할 수 있어야 합니다. hardware/libhardware/include/hardware/gatekeeper.h 에 표시된 것처럼 HAL은 밀리초 단위의 시간 초과 반환을 제공합니다. 시간 초과는 시간 초과가 경과할 때까지 GateKeeper를 다시 호출하지 않도록 클라이언트에 알립니다. 보류 중인 시간 초과가 있는 경우 GateKeeper는 요청을 처리하지 않아야 합니다.

GateKeeper는 사용자 암호를 확인하기 전에 실패 카운터를 작성해야 합니다. 암호 확인이 성공하면 실패 카운터를 지워야 합니다. 이는 verify 호출을 발행한 후 내장형 MMC(eMMC)를 비활성화하여 조절을 방지하는 공격을 방지합니다. enroll 기능은 사용자 암호(제공된 경우)도 확인하며 동일한 방식으로 조절해야 합니다.

장치에서 지원하는 경우 보안 저장소에 오류 카운터를 작성하는 것이 좋습니다. 장치가 파일 기반 암호화를 지원하지 않거나 보안 저장소가 너무 느린 경우 구현에서 RPMB(Replay Protected Memory Block)를 직접 사용할 수 있습니다.