Autenticação

O Android usa o conceito de chaves criptográficas controladas por autenticação do usuário que requer os seguintes componentes:

  • Armazenamento de chave criptográfica e provedor de serviços. Armazena chaves criptográficas e fornece rotinas de criptografia padrão em cima dessas chaves. O Android oferece suporte a um Keystore e Keymaster com suporte de hardware para serviços criptográficos, incluindo criptografia com suporte de hardware para armazenamento de chaves que pode incluir um Ambiente de Execução Confiável (TEE) ou Elemento Seguro (SE), como o Strongbox.
  • Autenticadores de usuários. Atestar a presença do usuário e/ou autenticação bem-sucedida. O Android suporta Gatekeeper para autenticação de PIN/padrão/senha e Fingerprint para autenticação de impressão digital. Os dispositivos fornecidos com o Android 9 e superior podem usar o BiometricPrompt como um único ponto de integração para impressão digital e biometria adicional. Esses componentes comunicam seu estado de autenticação com o serviço keystore por meio de um canal autenticado. (O sistema Android Keystore no nível da estrutura também é apoiado pelo serviço keystore.)

Os componentes Gatekeeper, Fingerprint e Biometric funcionam com o Keystore e outros componentes para dar suporte ao uso de tokens de autenticação com suporte de hardware (AuthTokens).

Inscrição

Na primeira inicialização do dispositivo após uma redefinição de fábrica, todos os autenticadores estão preparados para receber inscrições de credenciais do usuário. Um usuário deve inicialmente registrar um PIN/padrão/senha no Gatekeeper. Essa inscrição inicial cria um identificador seguro de usuário (SID) de 64 bits gerado aleatoriamente que serve como um identificador para o usuário e como um token de ligação para o material criptográfico do usuário. Esse SID de usuário é vinculado criptograficamente à senha do usuário; autenticações bem-sucedidas no Gatekeeper resultam em AuthTokens que contêm o SID do usuário para essa senha.

Um usuário que deseja alterar uma credencial deve apresentar uma credencial existente. Se uma credencial existente for verificada com sucesso, o SID do usuário associado à credencial existente será transferido para a nova credencial, permitindo que o usuário continue acessando as chaves após alterar uma credencial. Se um usuário não apresentar uma credencial existente, a nova credencial será registrada com um SID de usuário totalmente aleatório. O usuário pode acessar o dispositivo, mas as chaves criadas sob o SID de usuário antigo são perdidas permanentemente. Isso é conhecido como um registro não confiável .

Em circunstâncias normais, a estrutura do Android não permite uma inscrição não confiável, portanto, a maioria dos usuários nunca verá essa funcionalidade. No entanto, redefinições forçadas de senha, por um administrador de dispositivo ou por um invasor, podem fazer com que isso ocorra.

Autenticação

Depois que um usuário configura uma credencial e recebe um SID de usuário, ele pode iniciar a autenticação, que começa quando um usuário fornece um PIN, padrão, senha ou impressão digital. Todos os componentes TEE compartilham uma chave secreta que eles usam para autenticar as mensagens uns dos outros.

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 daemon associado.
    • 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 Android 8.xe inferior, FingerprintService faz uma solicitação para fingerprintd ). Em dispositivos que executam o Android 9 e superior, o BiometricPrompt faz uma solicitação ao daemon biométrico apropriado (por exemplo, fingerprintd para impressões digitais ou faced para face) usando a classe Biometric Manager apropriada, 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 daemon envia dados para sua contraparte, que gera um AuthToken:
    • Para autenticação de PIN/padrão/senha, o gatekeeperd envia o PIN, padrão ou hash de senha para o Gatekeeper no TEE. Se a autenticação no TEE for bem-sucedida, o Gatekeeper no TEE enviará um AuthToken contendo o SID do usuário correspondente (assinado com a chave AuthToken HMAC) para sua contraparte no sistema operacional Android.
    • Para autenticação de impressão digital, fingerprintd escuta eventos de impressão digital e envia os dados para Fingerprint no TEE. Se a autenticação no TEE for bem-sucedida, a impressão digital no TEE enviará um AuthToken (assinado com a chave AuthToken HMAC) para sua contraparte no sistema operacional Android.
    • Para outra autenticação biométrica, o daemon biométrico apropriado escuta o evento biométrico e o envia para o componente TEE biométrico apropriado.
  3. O daemon recebe um AuthToken assinado e o passa para o serviço keystore por meio de uma extensão para a interface Binder do serviço keystore. ( gatekeeperd também notifica o serviço keystore quando o dispositivo é rebloqueado e quando a senha do dispositivo é alterada.)
  4. O serviço keystore passa os AuthTokens para o Keymaster e os verifica usando a chave compartilhada com o Gatekeeper e o componente TEE biométrico compatível. O Keymaster confia no carimbo de data/hora no token como o último horário de autenticação e baseia uma decisão de liberação de chave (para permitir que um aplicativo use a chave) no carimbo de data/hora.

Formato AuthToken

Para garantir o compartilhamento e a compatibilidade de token entre linguagens e componentes, o formato AuthToken é descrito em hw_auth_token.h . O formato é um protocolo de serialização simples com campos de tamanho fixo.

Campo Modelo Requeridos Descrição
Versão do token de autenticação 1 byte Sim Tag de grupo para todos os campos abaixo.
Desafio inteiro sem sinal de 64 bits Não Um número inteiro aleatório para evitar ataques de repetição. Geralmente o ID de uma operação de criptografia solicitada. Atualmente usado por autorizações de impressão digital transacional. Se presente, o AuthToken é válido apenas para operações de criptografia que contenham o mesmo desafio.
SID do usuário inteiro sem sinal de 64 bits Sim Identificador de usuário não repetitivo vinculado criptograficamente a todas as chaves associadas à autenticação do dispositivo. Para obter detalhes, consulte Gatekeeper .
ID do autenticador (ASID) Inteiro sem sinal de 64 bits na ordem de rede Não Identificador usado para vincular a uma política de autenticador específica. Todos os autenticadores têm seu próprio valor de ASID que podem ser alterados de acordo com seus próprios requisitos.
Tipo de autenticador Inteiro sem sinal de 32 bits na ordem de rede Sim
  • 0x00 é o porteiro.
  • 0x01 é impressão digital.
Carimbo de data e hora Inteiro sem sinal de 64 bits na ordem de rede Sim Tempo (em milissegundos) desde a inicialização do sistema mais recente.
AuthToken HMAC (SHA-256) bolha de 256 bits Sim MAC SHA-256 com chave de todos os campos, exceto o campo HMAC.

Fluxo de inicialização do dispositivo

Em cada inicialização de um dispositivo, a chave AuthToken HMAC deve ser gerada e compartilhada com todos os componentes TEE (Gatekeeper, Keymaster e trustlets de biometria suportados). Assim, para proteção adicional contra ataques de repetição, a chave HMAC deve ser gerada aleatoriamente toda vez que o dispositivo for reinicializado.

O protocolo para compartilhar essa chave HMAC com todos os componentes é um recurso de implementação dependente da plataforma. A chave nunca deve ser disponibilizada fora do TEE. Se um TEE OS não tiver um mecanismo de comunicação interna entre processos (IPC) e precisar transferir os dados por meio do sistema operacional não confiável, a transferência deverá ser feita por meio de um protocolo de troca de chave segura.

O sistema operacional Trusty , que roda 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 Keymaster e o Gatekeeper ou o trustlet biométrico apropriado. A chave HMAC é mantida exclusivamente no Keymaster; Fingerprint e Gatekeeper solicitam a chave do Keymaster para cada uso e não persistem ou armazenam o valor em cache.

Como alguns TEEs não possuem infraestrutura IPC, nenhuma comunicação ocorre entre applets no TEE. Isso também permite que o serviço de armazenamento de chaves negue rapidamente solicitações que provavelmente falharão, pois ele tem conhecimento da tabela de autenticação no sistema, economizando um IPC potencialmente caro no TEE.