Authentication

O Android tem o conceito de autenticadores de usuário que são usados para desbloquear o dispositivo e controlar o acesso a chaves criptográficas. Isso envolve os seguintes componentes:

  • Armazenamento de chaves criptográficas e provedor de serviços. O Android Keystore oferece serviços criptográficos com suporte de hardware para apps. O sistema de keystore do Android no nível do framework é apoiado pelo serviço de sistema keystore2. Isso é baseado em uma implementação específica do fornecedor do KeyMint (anteriormente Keymaster) que garante que o material da chave só seja acessível em um ambiente seguro com suporte de hardware, como um ambiente de execução confiável (TEE) ou um Elemento de segurança (SE).
  • Autenticadores do usuário. Atestar a autenticação do usuário. O Android oferece suporte aos seguintes componentes de autenticação:
    • Gatekeeper para autenticação de PIN, padrão ou senha no TEE.
    • (Opcional) Weaver para autenticação de PIN, padrão ou senha em um elemento seguro.
    • Impressão digital para autenticação por impressão digital.
    • Outros métodos de autenticação biométrica. Dispositivos com o Android 9 ou versões mais recentes podem usar BiometricPrompt como um único ponto de integração para impressão digital e outros dados biométricos.
    Esses componentes comunicam o estado de autenticação com o serviço keystore2 usando tokens de autenticação (AuthTokens) com suporte de hardware .

Cada um desses componentes é específico do fornecedor, mas a implementação do fornecedor é necessária para atender a uma especificação de interface de camada de abstração de hardware (HAL) e para passar nos testes do conjunto de teste do fornecedor (VTS, na sigla em inglês) correspondente.

As implementações do fornecedor geralmente também são divididas em duas partes, conectadas por um mecanismo de comunicação específico do fornecedor :

  • Um serviço HAL é executado como um processo do sistema Android, recebendo solicitações de vinculação do sistema Android.
  • Um aplicativo confiável (TA) é executado no ambiente seguro, realizando as operações de segurança reais.

Registro

Na primeira inicialização do dispositivo após uma redefinição de fábrica, todos os autenticadores são preparados para receber as inscrições de credenciais do usuário. O usuário precisa registrar inicialmente um PIN, padrão ou senha com o Gatekeeper (ou Weaver, se disponível). Essa inscrição inicial cria um identificador seguro de usuário (SID, na sigla em inglês) de 64 bits gerado aleatoriamente que serve como um identificador do usuário e como um token de vinculação para o material criptográfico do usuário. Esse SID do usuário é vinculado criptograficamente à senha do usuário. As autenticações bem-sucedidas no Gatekeeper resultam em AuthTokens que contêm o SID do usuário para essa senha.

Um usuário que quiser mudar uma credencial precisa apresentar essa credencial. Se uma credencial for verificada, o SID do usuário associado a ela será transferido para a nova credencial, permitindo que o usuário continue acessando chaves após a mudança.

Em algumas situações, um administrador do dispositivo pode realizar uma inscrição não confiável para registrar uma nova credencial sem apresentar uma credencial existente. Isso permite que o usuário acesse o dispositivo, mas as chaves criadas com o SID do usuário antigo são perdidas permanentemente.

Autenticação

Esta seção descreve um fluxo de autenticação típico, que envolve interações entre vários componentes no Android e no ambiente seguro. Todos os componentes seguros compartilham uma chave HMAC secreta (por inicialização) que eles usam para autenticar as mensagens uns dos outros.

Depois que um usuário configura uma credencial e recebe um SID, ele pode iniciar a autenticação, que começa quando o usuário fornece um PIN, padrão, senha, impressão digital ou outra biometria forte. Fluxo de autenticação

Figura 1. Fluxo de autenticação

  1. Um usuário fornece um método de autenticação, e o serviço associado faz uma solicitação para o serviço HAL.
    • Para PIN, padrão ou senha, LockSettingsService faz uma solicitação para gatekeeperd.
    • Os fluxos de autenticação biométrica dependem da versão do Android. Em dispositivos com o Android 8.x e versões anteriores, FingerprintService faz uma solicitação para fingerprintd. Em dispositivos com o Android 9 e versões mais recentes, BiometricPrompt faz uma solicitação para o daemon biométrico apropriado (por exemplo, fingerprintd para impressões digitais ou faced para rosto) usando a classe BiometricManager apropriada, como FingerprintManager ou FaceManager. Independentemente da versão, a autenticação biométrica ocorre de forma assíncrona depois que a solicitação é enviada.
  2. O serviço HAL envia dados para o TA correspondente, que gera um AuthToken:
    • Para autenticação por PIN/padrão/senha, gatekeeperd envia o hash do PIN, padrão ou senha para o TA do Gatekeeper no TEE pelo serviço HAL do Gatekeeper. Se a autenticação no TEE for bem-sucedida, o gatekeeper TA vai emitir um AuthToken contendo o SID do usuário correspondente (assinado com a chave HMAC compartilhada).
    • Para a autenticação por impressão digital, o fingerprintd detecta eventos de impressão digital e envia os dados para o TA de impressão digital no TEE, pela HAL de impressão digital. Se a autenticação no TEE for bem-sucedida, o TA de impressão digital emitirá um AuthToken (assinado com a chave HMAC do AuthToken).
    • Para outras autenticações biométricas, o daemon biométrico apropriado detecta o evento biométrico e o envia para o serviço HAL e o TA biométrico apropriado.
  3. O AuthToken assinado resultante é transmitido ao serviço do sistema keystore2 por uma interface do Binder.
  4. O serviço keystore2 anexa os AuthTokens para solicitar que o KeyMint (anteriormente Keymaster) realize operações criptográficas. O serviço HAL do KeyMint as transmite ao TA do KeyMint, que as verifica usando a chave HMAC compartilhada com o Gatekeeper e os componentes de TEE biométricos compatíveis. O KeyMint confia no carimbo de data/hora no token como o horário da última autenticação e decide se permite o uso da chave com base no carimbo de data/hora.

O fluxo de autenticação não exige comunicação direta entre os TAs no ambiente seguro: os AuthTokens fluem do TA do autenticador para o serviço keystore2 no Android, que os transmite para o TA do KeyMint. Isso também permite que o serviço keystore2 negue rapidamente solicitações que estão fadadas a falhar, já que ele tem conhecimento dos AuthTokens disponíveis no sistema, economizando um IPC potencialmente caro no TEE.

Formato do AuthToken

O formato do AuthToken é fornecido pela especificação AIDL em HardwareAuthToken.aidl.

Fluxo de inicialização do dispositivo

Em cada inicialização de um dispositivo, a chave HMAC do AuthToken precisa ser gerada e compartilhada com todos os componentes do TEE (Gatekeeper, KeyMint/Keymaster e TAs de biometria com suporte). Para evitar ataques de repetição, a chave HMAC precisa ser gerada aleatoriamente sempre que o dispositivo é reinicializado.

Há duas maneiras comuns de os TAs adquirirem acesso a essa chave HMAC compartilhada:

  • Contrato de segredo compartilhado:o serviço keystore2 executa um protocolo de contrato de chave de vários canais na inicialização do dispositivo, permitindo a derivação segura da chave HMAC entre os TAs participantes. No entanto, os TAs participantes precisam ter acesso a um secret predefinido comum.
  • Acesso direto:as TAs que residem no mesmo ambiente seguro podem usar um mecanismo de comunicação interprocesso interno (que depende da plataforma) para compartilhar a chave HMAC.

Em ambos os casos, a chave HMAC nunca pode ser disponibilizada fora do TEE.

O sistema operacional Trusty, que é executado ao lado do Android, é um exemplo de TEE, mas outros TEEs podem ser usados. O Trusty usa um sistema IPC interno para se comunicar diretamente entre KeyMint e Gatekeeper ou o TA biométrico apropriado. A chave HMAC é guardada apenas no KeyMint. O Fingerprint e o Gatekeeper solicitam a chave do KeyMint para cada uso e não persistem nem armazenam em cache o valor.