Google está empenhada em fazer avançar a equidade racial para as comunidades negras. Veja como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Autenticação

Android usa o conceito de chaves criptográficas user-fechado-autenticação que exige os seguintes componentes:

  • Armazenamento de chaves criptográficas e provedor de serviços. Armazena chaves criptográficas e fornece rotinas de criptografia padrão no topo de essas chaves. Suportes Android um Keystore lastreados em hardware e Keymaster para serviços de criptografia, incluindo criptografia lastreados em hardware para armazenamento de chave que pode incluir um Trusted Execution Environment (TEE) ou elemento de segurança (SE), como Strongbox.
  • Autenticadores de usuário. Atestar a presença do usuário e / ou autenticação bem-sucedida. Suportes Android Gatekeeper para PIN / padrão / autenticação de senha e impressão digital para autenticação de impressão digital. Dispositivos que navio com 9 Android e superior podem usar BiometricPrompt como um ponto de integração única para impressões digitais e biometria adicionais. Estes componentes comunicar seu estado de autenticação com o serviço de armazenamento de chaves através de um canal autenticado. (O sistema de armazenamento de chaves Android no nível de estrutura também é apoiado pelo serviço de armazenamento de chaves.)

Gatekeeper, componentes da impressão digital, e biométricos trabalhar com armazenamento de chaves e outros componentes para suportar a utilização de hardware suportado- sinais de autenticação (AuthTokens).

Inscrição

Na primeira inicialização do dispositivo após um reset 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 com Gatekeeper. Esta adesão inicial cria um identificador protegido gerado aleatoriamente, o utilizador 64 bits (SID) que serve como um identificador para o utilizador e como uma ligação sinal para o material criptográfica do utilizador. Este SID de usuário é criptograficamente obrigado a senha do usuário; autenticações bem-sucedidas para Gatekeeper resultar em AuthTokens que contêm o SID de usuário para essa senha.

Um usuário que quer mudar uma credencial deve apresentar uma credencial existente. Se uma credencial existente é verificada com êxito, o SID do usuário associado com a credencial existente é transferido para a nova credencial, permitindo ao usuário manter as chaves que acessam depois de mudar uma credencial. Se um usuário não apresentar uma credencial existente, a nova credencial está inscrito com um SID de usuário totalmente aleatória. O usuário pode acessar o dispositivo, mas as chaves criadas sob o antigo SID usuário são perdidos para sempre. Isto é conhecido como um enroll não confiável.

Em circunstâncias normais, o quadro Android não permite uma enroll não confiável, por isso a maioria dos usuários nunca vai ver essa funcionalidade. No entanto, redefinições de senha forçadas, quer por um administrador do dispositivo ou um atacante, pode causar isso ocorra.

Autenticação

Depois que um usuário criou uma credencial e recebeu um SID de usuário, eles podem começar a autenticação, que começa quando um usuário fornece um PIN, padrão, senha ou impressão digital. Todos os componentes do T compartilham uma chave secreta que eles usam para autenticar mensagens uns dos outros.

fluxo de autenticação
Fluxo Figura 1. autenticação
  1. Um usuário fornece um método de autenticação e o serviço associado faz uma solicitação para o servidor associado.
    • Para PIN, padrão ou senha, LockSettingsService faz uma solicitação para gatekeeperd .
    • fluxos de autenticação baseados em biometria dependem da versão do Android. Em dispositivos que executam o 8.x e menor Android, FingerprintService faz uma solicitação para fingerprintd ). Em dispositivos com Android 9 e superior, BiometricPrompt faz um pedido para o servidor biométrico apropriado (por exemplo, fingerprintd para impressões digitais ou faced para o rosto), utilizando o apropriado Biometric Manager classe, tal como FingerprintManager ou FaceManager . Independentemente da versão, autenticação biométrica ocorre de forma assíncrona após o pedido é enviado.
  2. O daemon envia dados para o seu homólogo, o que gera um AuthToken:
    • Para PIN / padrão / autenticação de senha, gatekeeperd envia o PIN, padrão ou hash de senha para Gatekeeper no TEE. Se a autenticação na ETE é bem sucedido, Gatekeeper no TEE envia um AuthToken contendo o SID de usuário correspondente (assinado com a chave AuthToken HMAC) para sua contraparte no sistema operacional Android.
    • Para autenticação de impressão digital, fingerprintd escutas para eventos de impressões digitais e envia os dados para impressão digital na ETE. Se a autenticação na ETE é bem sucedido, Fingerprint no TEE envia um AuthToken (assinado com a chave AuthToken HMAC) para sua contraparte no sistema operacional Android.
    • Por outro autenticação biométrica, o daemon biométrica apropriado ouve o evento biométrica e envia-o para o componente TEE biométrica apropriado.
  3. O daemon recebe um AuthToken assinado e passa para o serviço de armazenamento de chaves através de uma extensão à interface Binder do serviço de armazenamento de chaves. ( gatekeeperd também notifica o serviço de armazenamento de chaves quando o dispositivo é relocked e quando as mudanças de senha no dispositivo.)
  4. O serviço de armazenamento de chaves passa os AuthTokens para Keymaster e verifica-los usando a chave compartilhada com o Gatekeeper e componente TEE biométrica suportados. Keymaster confia no timestamp no token como a última vez autenticação e bases uma decisão a libertação da tecla (para permitir um aplicativo para usar a chave) na timestamp.

formato AuthToken

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

Campo Tipo Requeridos Descrição
AuthToken Versão 1 byte sim tag grupo para todos os campos abaixo.
Desafio 64-bit inteiro sem sinal Não Um número inteiro aleatório para evitar ataques de repetição. Normalmente, o ID de uma operação de criptografia solicitado. Atualmente usado por autorizações de impressão digital transacionais. Se estiver presente, o AuthToken só é válida para operações de criptografia que contêm o mesmo desafio.
SID de usuário 64-bit inteiro sem sinal sim identificador do usuário não repetidos amarrado cryptographically a todas as chaves associadas a autenticação do dispositivo. Para mais detalhes, consulte Gatekeeper .
Autenticador ID (ASID) 64-bit inteiro sem sinal em forma de rede Não Identificador usado para vincular a uma política específica autenticador. Todos os autenticadores têm seu próprio valor da ASID que eles podem mudar de acordo com suas próprias necessidades.
tipo de autenticador 32-bit inteiro sem sinal em forma de rede sim
  • 0x00 é Gatekeeper.
  • 0x01 é Fingerprint.
timestamp 64-bit inteiro sem sinal em forma de rede sim Tempo (em milissegundos) desde a inicialização do sistema mais recente.
AuthToken HMAC (SHA-256) 256-bit blob sim Com chave SHA-256 MAC 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 gerado e compartilhado com todos os componentes do T (Gatekeeper, Keymaster, e apoiado biometria trustlets). Assim, para maior proteção contra ataques de repetição, a chave HMAC devem ser gerados aleatoriamente a cada vez que o dispositivo for reinicializado.

O protocolo para a partilha desta chave HMAC com todos os componentes é uma característica implementação depende da plataforma. A chave nunca deve ser disponibilizado fora do TEE. Se um T OS carece de um mecanismo e necessidades para transferir os dados através da OS não confiável comunicação entre interno (IPC), a transferência deverá ser feito através de um protocolo de troca de chave de segurança.

O Trusty sistema operacional, que corre ao lado de Android, é um exemplo de uma ETE, mas outros T pode ser usado em seu lugar. Fiel utiliza um sistema interno IPC para comunicar directamente entre Keymaster e gatekeeper ou o trustlet biométrica apropriada. A chave HMAC é mantido apenas em Keymaster; Fingerprint e Gatekeeper solicitar a chave do Keymaster para cada uso e não persistem ou armazenar em cache o valor.

Como alguns TEEs falta uma infra-estrutura IPC, nenhuma comunicação ocorre entre applets no TEE. Isso também permite que o serviço de armazenamento de chaves para negar rapidamente as solicitações que estão vinculados a falhar, pois tem conhecimento da tabela de autenticação no sistema, economizando um IPC potencialmente caro para o TEE.