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 Android Keystore no nível do framework é apoiado pelo serviço do sistema keystore2. Isso é baseado em uma implementação do KeyMint (anteriormente Keymaster) específica do fornecedor 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), como o StrongBox.
  • Autenticadores de usuário. Confirmar a autenticação do usuário. O Android é compatível com os 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 de segurança.
    • Impressão digital para autenticação por impressão digital.
    • Outros métodos de autenticação biométrica. Os dispositivos com o Android 9 ou versões mais recentes podem usar BiometricPrompt como um único ponto de integração para impressões digitais e outras biometrias.
    Esses componentes comunicam o estado de autenticação ao 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 da camada de abstração de hardware (HAL) e para passar nos testes correspondentes do pacote de testes do fornecedor (VTS).

As implementações do fornecedor também costumam ser 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 do Binder do sistema Android.
  • Um aplicativo confiável (TA, na sigla em inglês) é 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 estão preparados para receber registros de credenciais do usuário. Inicialmente, o usuário precisa registrar um PIN, padrão ou senha no 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 para o usuário e como um token de vinculação para o material criptográfico do usuário. Esse SID de usuário está vinculado criptograficamente à senha do usuário. Autenticações bem-sucedidas no Gatekeeper resultam em AuthTokens que contêm o SID de usuário para essa senha.

Um usuário que quer mudar uma credencial precisa apresentá-la. Se uma credencial atual for verificada, o SID do usuário associado a ela será transferido para a nova credencial, permitindo que o usuário continue acessando as chaves depois de mudar uma credencial.

Em algumas situações, um administrador de dispositivos pode realizar um registro não confiável para registrar uma nova credencial sem apresentar uma credencial atual. 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 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 ao serviço HAL.
    • Para PIN, padrão ou senha, LockSettingsService faz uma solicitação para gatekeeperd.
    • Os fluxos de autenticação baseados em biometria 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 ao daemon biométrico adequado (por exemplo, fingerprintd para impressões digitais ou faced para rosto) usando a classe BiometricManager adequada, como FingerprintManager ou FaceManager. Independentemente da versão, a autenticação biométrica ocorre de forma assíncrona após o envio da solicitação.
  2. O serviço HAL envia dados para o TA correspondente, que gera um AuthToken:
    • Para autenticação de PIN/padrão/senha, o gatekeeperd envia o hash do PIN, padrão ou senha para o TA do Gatekeeper no TEE, usando o serviço HAL do Gatekeeper. Se a autenticação no TEE for bem-sucedida, o TA do Gatekeeper vai emitir um AuthToken contendo o SID do usuário correspondente (assinado com a chave HMAC compartilhada).
    • Para autenticação por impressão digital, o fingerprintd detecta eventos de impressão digital e envia os dados para a TA de impressão digital no TEE, usando a HAL de impressão digital. Se a autenticação no TEE for bem-sucedida, o TA de impressão digital vai emitir um AuthToken (assinado com a chave HMAC do AuthToken).
    • Para outras autenticações biométricas, o daemon biométrico adequado detecta o evento biométrico e o envia para o serviço HAL biométrico e o TA adequados.
  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 à solicitação para que o KeyMint (anteriormente Keymaster) realize operações criptográficas. O serviço HAL do KeyMint os transmite para o TA do KeyMint, que os 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 último horário de 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 TAs no ambiente seguro: os AuthTokens fluem da TA do autenticador para o serviço keystore2 no Android, que os transmite para a TA do KeyMint. Isso também permite que o serviço keystore2 negue rapidamente solicitações que estão destinadas a falhar, já que ele tem conhecimento dos AuthTokens disponíveis no sistema, salvando uma IPC potencialmente cara 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 e TAs de biometria compatíveis). Para evitar ataques de repetição, a chave HMAC precisa ser gerada aleatoriamente sempre que o dispositivo for reinicializado.

Há duas maneiras comuns de os TAs acessarem essa chave HMAC compartilhada:

  • Acordo de chave secreta compartilhada: o serviço keystore2 executa um protocolo de acordo de chave multidirecional na inicialização do dispositivo, permitindo a derivação segura da chave HMAC entre as TAs participantes. No entanto, os TAs participantes precisam ter acesso a um secret pré-compartilhado comum.
  • Acesso direto: as TAs que residem no mesmo ambiente seguro podem usar um mecanismo interno de comunicação entre processos (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 o KeyMint e o Gatekeeper ou o TA biométrico apropriado. A chave HMAC é mantida apenas no KeyMint. O Fingerprint e o Gatekeeper solicitam a chave do KeyMint para cada uso e não mantêm nem armazenam em cache o valor.

Como alguns TEEs não têm uma infraestrutura de IPC, não há comunicação entre applets no TEE. Isso também permite que o serviço de keystore negue rapidamente solicitações que estão fadadas a falhar, já que ele tem conhecimento da tabela de autenticação no sistema, salvando uma IPC potencialmente cara no TEE.