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
BiometricPromptcomo 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.
- 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,
LockSettingsServicefaz uma solicitação paragatekeeperd. - Os fluxos de autenticação baseados em biometria dependem da versão do Android. Em dispositivos com Android 8.xe inferior,
FingerprintServicefaz uma solicitação parafingerprintd). Em dispositivos que executam o Android 9 e superior, oBiometricPromptfaz uma solicitação ao daemon biométrico apropriado (por exemplo,fingerprintdpara impressões digitais oufacedpara face) usando a classeBiometric Managerapropriada, comoFingerprintManagerouFaceManager. Independentemente da versão, a autenticação biométrica ocorre de forma assíncrona após o envio da solicitação.
- Para PIN, padrão ou senha,
- O daemon envia dados para sua contraparte, que gera um AuthToken:
- Para autenticação de PIN/padrão/senha, o
gatekeeperdenvia 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,
fingerprintdescuta 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.
- Para autenticação de PIN/padrão/senha, o
- 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. (
gatekeeperdtambém notifica o serviço keystore quando o dispositivo é rebloqueado e quando a senha do dispositivo é alterada.) - 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 |
|
| 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.