Esta página foi traduzida pela API Cloud Translation.

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 chaves criptográficas e provedor de serviços. Armazena chaves criptográficas e fornece rotinas criptográficas padrão sobre essas chaves. O Android oferece suporte a Keystore e Keymaster apoiados por hardware para serviços criptográficos, incluindo criptografia apoiada por 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ário. 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 Impressão digital para autenticação de impressão digital. Os dispositivos fornecidos com Android 9 e superior podem usar 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 de armazenamento de chaves 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 Keystore e outros componentes para oferecer suporte ao uso de tokens de autenticação baseados em 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 registros de credenciais do usuário. Um usuário deve inicialmente registrar um PIN/padrão/senha no Gatekeeper. Esse registro 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. Este SID de usuário está vinculado criptograficamente à senha do usuário; autenticações bem-sucedidas para o Gatekeeper resultam em AuthTokens que contêm o SID do usuário para essa senha.

Um usuário que queira alterar uma credencial deverá apresentar uma credencial existente. Se uma credencial existente for verificada com êxito, 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á inscrita com um SID de usuário totalmente aleatório. O usuário pode acessar o dispositivo, mas as chaves criadas no SID do usuário antigo serão perdidas permanentemente. Isso é conhecido como inscrição 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, seja por um administrador de dispositivo ou por um invasor, podem fazer com que isso ocorra.

Autenticação

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

Figura 1. Fluxo de autenticação

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 ao 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 com Android 9 e versões posteriores, BiometricPrompt faz uma solicitação ao daemon biométrico apropriado (por exemplo, fingerprintd para impressões digitais ou faced para rosto) 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.
O daemon envia dados para sua contraparte, que gera um AuthToken:
- Para autenticação de PIN/padrão/senha, 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 envia 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, o Fingerprint no TEE envia 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.
O daemon recebe um AuthToken assinado e o passa para o serviço de armazenamento de chaves por meio de uma extensão para a interface Binder do serviço de armazenamento de chaves. ( gatekeeperd também notifica o serviço de armazenamento de chaves quando o dispositivo é bloqueado novamente 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 horário da última 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 de token e a compatibilidade 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	Tipo	Obrigatório	Descrição
Versão AuthToken	1 byte	Sim	Tag de grupo para todos os campos abaixo.
Desafio	Inteiro não assinado de 64 bits	Não	Um número inteiro aleatório para evitar ataques de repetição. Geralmente o ID de uma operação criptográfica solicitada. Atualmente usado por autorizações transacionais de impressão digital. Se presente, o AuthToken é válido apenas para operações criptográficas contendo o mesmo desafio.
SID do usuário	Inteiro não assinado 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 não assinado de 64 bits na ordem da rede	Não	Identificador usado para vincular-se 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 não assinado de 32 bits na ordem da rede	Sim	0x00 é o porteiro. 0x01 é impressão digital.
Carimbo de data e hora	Inteiro não assinado de 64 bits na ordem da rede	Sim	Tempo (em milissegundos) desde a inicialização mais recente do sistema.
AuthToken HMAC (SHA-256)	Bolha de 256 bits	Sim	MAC SHA-256 codificado 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 biométricos suportados). Assim, para proteção adicional contra ataques de repetição, a chave HMAC deve ser gerada aleatoriamente sempre que o dispositivo for reinicializado.

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

O sistema operacional Trusty , que roda junto com o Android, é um exemplo de TEE, mas outros TEEs podem ser usados. Trusty usa um sistema IPC interno para se comunicar diretamente entre Keymaster e 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 em cache o valor.

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