O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Authentication

O Android usa o conceito de chaves criptográficas com 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 um keystore com suporte de hardware e a um Keymaster 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 um Elemento de segurança (SE), como o Strongbox.
Autenticadores do usuário. Atestar a presença do usuário e/ou autenticação bem-sucedida. O Android oferece suporte ao Gatekeeper para autenticação por PIN/padrão/senha e Impressão digital para autenticação por impressão digital. Os dispositivos que vêm com o Android 9 e 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 com o serviço de keystore por um canal autenticado. O sistema Android Keystore no nível do framework também é oferecido pelo serviço de keystore.

Os componentes de controle de acesso, impressão digital e biometria funcionam com o Keystore e outros componentes para oferecer suporte ao uso de tokens de autenticação (AuthTokens) com suporte de hardware.

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/senha com o Gatekeeper. 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 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 quer mudar uma credencial precisa apresentar uma credencial existente. 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 depois de mudar uma credencial. Se um usuário não apresentar uma credencial, 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 com o SID do usuário antigo são perdidas permanentemente. Isso é conhecido como inscrição não confiável.

Em circunstâncias normais, o framework do Android não permite uma inscrição não confiável. Por isso, a maioria dos usuários nunca vai encontrar essa funcionalidade. No entanto, redefinições de senha forçadas, por um administrador do 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, ele pode iniciar a autenticação, que começa quando o usuário fornece um PIN, padrão, senha ou impressão digital. Todos os componentes do TEE compartilham uma chave secreta que eles 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 para o daemon associado.
- 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.
O daemon envia dados para a contraparte, que gera um AuthToken:
- Para autenticação por PIN/padrão/senha, gatekeeperd envia o hash do PIN, padrão ou senha para o Gatekeeper no TEE. Se a autenticação no TEE for bem-sucedida, o Gatekeeper no TEE vai enviar um AuthToken contendo o SID do usuário correspondente (assinado com a chave HMAC AuthToken) para a contraparte no SO Android.
- Para a autenticação por impressão digital, fingerprintd detecta eventos de impressão digital e envia os dados para a impressão digital no TEE. Se a autenticação no TEE for bem-sucedida, a impressão digital no TEE vai enviar um AuthToken (assinado com a chave HMAC do AuthToken) para a contraparte no sistema operacional Android.
- Para outras autenticações biométricas, o daemon biométrico apropriado detecta o evento biométrico e o envia para o componente biométrico TEE adequado.
O daemon recebe um AuthToken assinado e o transmite ao serviço de keystore por uma extensão da interface Binder do serviço de keystore. O gatekeeperd também notifica o serviço de keystore quando o dispositivo é bloqueado novamente e quando a senha do dispositivo muda.
O serviço de keystore transmite 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 tempo de autenticação e baseia uma decisão de liberação de chave (para permitir que um app use a chave) no carimbo de data/hora.

Formato do AuthToken

Para garantir o compartilhamento e a compatibilidade de tokens entre idiomas 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 do 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 de impressão digital transacionais. Se presente, o AuthToken é válido apenas para operações de criptografia que contêm o mesmo desafio.
SID do usuário	Inteiro não assinado de 64 bits	Sim	Identificador de usuário não repetido vinculado criptograficamente a todas as chaves associadas à autenticação do dispositivo. Para mais detalhes, consulte Gatekeeper.
ID do autenticador (ASID)	Inteiro não assinado 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 um valor de ASID que pode ser alterado de acordo com os requisitos.
Tipo de autenticador	Número inteiro sem assinatura de 32 bits na ordem de rede	Sim	0x00 é o Gatekeeper. 0x01 é a impressão digital.
Carimbo de data/hora	Inteiro não assinado de 64 bits na ordem de rede	Sim	Tempo (em milissegundos) desde a inicialização mais recente do sistema.
AuthToken HMAC (SHA-256)	Blob 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 HMAC do AuthToken precisa ser gerada e compartilhada com todos os componentes do TEE (Gatekeeper, Keymaster e trustlets biométricos compatíveis). Portanto, para aumentar a proteção contra ataques de repetição, a chave HMAC precisa ser gerada aleatoriamente sempre que o dispositivo for reiniciado.

O protocolo para compartilhar essa chave HMAC com todos os componentes é um recurso de implementação dependente da plataforma. A chave nunca pode ser disponibilizada fora do TEE. Se um SO do TEE não tiver um mecanismo de comunicação interprocesso (IPC, na sigla em inglês) interno e precisar transferir os dados pelo SO não confiável, a transferência precisa ser feita por um protocolo de troca de chaves seguro.

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 Keymaster e o Gatekeeper ou o trustlet biométrico apropriado. A chave HMAC é guardada apenas no Keymaster. O Fingerprint e o Gatekeeper solicitam a chave do Keymaster para cada uso e não persistem nem armazenam em cache o valor.

Como alguns TEEs não têm uma infraestrutura de IPC, não ocorre 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, economizando um IPC potencialmente caro no TEE.