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. Armazena chaves criptográficas e fornece rotinas de criptografia padrão com base nelas. O Android oferece suporte a um keystore com suporte de hardware e ao KeyMint (antigo 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 de usuário. Atestar a presença do usuário e/ou autenticação bem-sucedida. O Android é compatível com o Gatekeeper para autenticação de PIN/padrão/senha e Impressão digital para autenticação de impressão digital. Dispositivos enviados com o Android 9 e versões mais recentes podem usar BiometricPrompt como um único ponto de integração para impressão digital 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 é compatível com o serviço keystore.

Cada um desses componentes é específico do fornecedor, mas a implementação do fornecedor precisa atender a uma especificação de interface da camada de abstração de hardware (HAL) e passar nos testes correspondentes do conjunto de testes do fornecedor (VTS).

As implementações do fornecedor também são 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) é executado no ambiente seguro, realizando as operações seguras reais.

Registro

Na primeira inicialização do dispositivo após uma redefinição de fábrica, todos os autenticadores são preparados para receber registros de credenciais do usuário. Inicialmente, um usuário precisa registrar um PIN, padrão ou senha com o Gatekeeper (ou o Weaver, se disponível). 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 vinculação para o material criptográfico do usuário. Esse SID do usuário está criptograficamente vinculado à 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 quer mudar uma credencial precisa apresentar essa credencial. Se uma credencial atual for verificada com sucesso, 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 existente. 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 um 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, o FingerprintService faz uma solicitação para fingerprintd. Em dispositivos com o Android 9 e versões mais recentes, o 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 adequada, como FingerprintManager ou FaceManager. Independente 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 por PIN/padrão/senha, o gatekeeperd envia o hash de PIN, padrão ou senha para a TA do Gatekeeper no TEE, pelo serviço HAL do Gatekeeper. Se a autenticação no TEE for bem-sucedida, a 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, via a HAL de impressão digital. Se a autenticação no TEE for bem-sucedida, a 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 apropriado fica aguardando o evento biométrico e o envia para o serviço HAL biométrico e a TA adequados.
  3. O daemon recebe um AuthToken assinado e o transmite ao serviço keystore por uma extensão da interface Binder do serviço keystore. O gatekeeperd também notifica o serviço de keystore quando o dispositivo é bloqueado novamente e quando a senha do dispositivo muda.
  4. O serviço Keystore transmite os AuthTokens para o KeyMint e os verifica usando a chave compartilhada com o Gatekeeper e o componente TEE biométrico compatível. O KeyMint 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 app use a chave) 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, por sua vez, os transmite para a TA do KeyMint. Isso também permite que o serviço keystore2 negue rapidamente solicitações que vão falhar, já que ele tem conhecimento dos AuthTokens disponíveis no sistema, economizando uma IPC potencialmente cara no TEE.

Formato 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 trustlets biométricos compatíveis). Assim, para aumentar a proteção contra ataques de repetição, a chave HMAC precisa ser gerada aleatoriamente sempre que o dispositivo for reinicializado.

Há duas maneiras comuns de os TAs adquirirem acesso a essa chave HMAC compartilhada:

  • Contrato de segredo compartilhado:o serviço keystore2 executa um protocolo de contrato de chave múltipla na inicialização do dispositivo, permitindo a derivação segura da chave HMAC entre as TAs participantes. No entanto, os assistentes de ensino participantes precisam ter acesso a um segredo pré-compartilhado comum.
  • Acesso direto:as TAs que residem no mesmo ambiente seguro podem usar um mecanismo interno de comunicação entre processos (dependente da plataforma) para compartilhar a chave HMAC.

Em qualquer caso, 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 trustlet 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 vão falhar, já que ele tem conhecimento da tabela de autenticação no sistema, economizando uma IPC potencialmente cara no TEE.