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

porteiro

O Gatekeeper subsistema executa dispositivo de autenticação padrão / senha em um Trusted Execution Environment (TEE). Gatekeeper registra e verifica as senhas através de um HMAC com uma chave secreta lastreados em hardware. Além disso, Gatekeeper estrangula tentativas de verificação falhas consecutivas e deve recusar-se a solicitações de serviço com base em um determinado tempo limite e um determinado número de tentativas falhadas consecutivas.

Quando os usuários verificar suas senhas, Gatekeeper usa o segredo compartilhado derivada-TEE a assinar um atestado de autenticação para enviar para o armazenamento de chaves lastreados em hardware . Ou seja, um atestado Gatekeeper notifica Keystore que as chaves de autenticação-limite (por exemplo, chaves que os aplicativos tenham criado) pode ser liberada para uso por aplicativos.

Arquitetura

Gatekeeper envolve três componentes principais:

  • gatekeeperd (gatekeeper daemon). Um serviço ligante C ++ contendo lógica independente da plataforma e que corresponde ao GateKeeperService interface Java.
  • Gatekeeper camada de abstracção de hardware (HAL). A interface HAL em hardware/libhardware/include/hardware/gatekeeper.h , eo módulo de execução.
  • Gatekeeper (ETE). A contrapartida do T da gatekeeperd . implementação de Gatekeeper UM T-based.

Gatekeeper requer a implementação do gatekeeper HAL (especificamente as funções de hardware/libhardware/include/hardware/gatekeeper.h ) e o componente específico gatekeeper-T (com base, em parte, o system/gatekeeper/include/gatekeeper/gatekeeper.h ficheiro de cabeçalho que inclui funções virtuais puras para criar / acessar chaves e assinaturas de computação).

O LockSettingsService faz um pedido (via Binder) que atinge o gatekeeperd daemon no OS Android. O gatekeeperd daemon, em seguida, faz um pedido que atinge o seu homólogo (Gatekeeper) na ETE:

fluxo gatekeeper
Figura 1. dados de alto nível de fluxo para autenticação por GateKeeper

O gatekeeperd daemon dá o Android acesso APIs quadro ao HAL, e participa de relatórios de dispositivos autenticações para armazenamento de chaves. O gatekeeperd daemon executado em seu próprio processo e é separado do servidor do sistema.

implementação HAL

O gatekeeperd daemon usa o HAL para interagir com o gatekeeperd homólogo TEE do daemon para autenticação de senha. A implementação HAL deve ser capaz de assinar (registar) e verificar blobs. Todas as implementações são esperados para aderir ao formato padrão para o token de autenticação (AuthToken) gerado em cada verificação de senha bem-sucedida. Para mais detalhes sobre o conteúdo e semântica da AuthToken, consulte formato AuthToken .

Implementações do hardware/libhardware/include/hardware/gatekeeper.h arquivo de cabeçalho deve implementar a enroll e verify funções:

  • O enroll função recebe um blob de senha, assina-lo, e retorna a assinatura como um punho. A gota devolvido (a partir de uma chamada para enroll ) deve ter a estrutura mostrada em system/gatekeeper/include/gatekeeper/password_handle.h .
  • A verify função deve comparar a assinatura produzida pela senha fornecida e garantir que ele corresponda a alça senha inscritos.

A chave usada para se inscrever e verificar nunca deve mudar, e deve ser re-derivável em cada inicialização do dispositivo.

Trusty e outras implementações

O Trusty sistema operacional é open source do Google confiável OS para ambientes T e contém uma implementação aprovada de gatekeeper. No entanto, você pode usar qualquer sistema operacional TEE para implementar Gatekeeper, desde que o TEE tem acesso a uma chave de proteção por hardware e um relógio seguro, monótona que os carrapatos em suspensão.

Usos fiel um sistema IPC interna para comunicar um segredo compartilhado diretamente entre Keymaster ea implementação Trusty de Gatekeeper (a Trusty Gatekeeper). Este segredo compartilhado é usado para assinar AuthTokens enviados para armazenamento de chaves para fornecer atestados de verificação de senha. Trusty Gatekeeper solicita a chave do Keymaster para cada uso e não persiste ou armazenar em cache o valor. Implementações são livres para compartilhar esse segredo de qualquer maneira que não comprometer a segurança.

A chave HMAC utilizado para se inscrever e verificar as senhas é derivado e manteve apenas em gatekeeper.

Android fornece uma implementação genérica C ++ de GateKeeper que requer apenas a adição de rotinas específicas do dispositivo para ser concluída. Para implementar um TEE Gatekeeper com código específico do dispositivo para o TEE, referem-se às funções e comentários no system/gatekeeper/include/gatekeeper/gatekeeper.h . Para o TEE GateKeeper, as principais responsabilidades de um compliant implementação incluem:

  • A adesão ao Gatekeeper HAL.
  • AuthTokens devolvidos devem ser formatado de acordo com a especificação AuthToken (descrito em autenticação ).
  • O TEE Gatekeeper deve ser capaz de compartilhar uma chave HMAC com Keymaster, seja solicitando a chave através de um TEE IPC sob demanda ou manter um cache válido do valor em todos os momentos.

IDs de usuário seguros (SIDS)

A SID do usuário é a representação do T de um usuário (sem forte ligação com um ID de usuário Android). O SID é gerado com um gerador de números pseudo-aleatórios criptográfica (PRNG) sempre que um utilizador se inscreve uma nova palavra-passe sem fornecer uma anterior. Isto é conhecido como um re-enroll não confiável e não é permitido pelo quadro Android em circunstâncias normais. A re-inscrever confiável ocorre quando um usuário fornece uma senha válida, anterior; neste caso, o SID do usuário é migrada para o novo identificador de senha, conservando as chaves que foram ligados a ele.

O SID do usuário é HMAC'ed juntamente com a senha no punho senha quando a senha é inscrito.

SIDs de usuário são gravados no AuthToken retornado pelo verify função e associados a todas as chaves do armazenamento de chaves-bound de autenticação (para obter detalhes sobre o formato AuthToken e armazenamento de chaves, consulte Authentication ). Como uma chamada não confiável para o enroll função irá mudar o SID do usuário, a chamada irá processar as chaves vinculados a essa senha inútil. Os atacantes podem alterar a senha para o dispositivo se controlar o sistema operacional Android, mas eles vão destruir, teclas sensíveis protegidos-raiz no processo.

pedido de estrangulamento

GateKeeper deve ser capaz de tentativas de força bruta segurança do acelerador em uma credencial de usuário. Como mostrado no hardware/libhardware/include/hardware/gatekeeper.h , o HAL fornece para retornar um tempo limite em milissegundos. O tempo limite informa o cliente não chamar GateKeeper novamente até depois do tempo limite ter expirado; GateKeeper deve não serviço solicitações se houver um tempo limite pendente.

GateKeeper deve escrever um contador de falhas antes de verificar uma senha de usuário. Se a verificação da senha for bem sucedida, o contador de falhas devem ser apuradas. Isto evita ataques que impedem estrangulamento, desativando o MMC incorporado (eMMC) depois de emitir um verify chamada. O enroll função também verifica a senha do usuário (se disponível) e deve ser estrangulada da mesma forma.

Se for suportado pelo dispositivo, é altamente recomendável que o contador de falhas ser escrita para armazenamento seguro. Se o dispositivo não suporta criptografia baseada em arquivo, ou se o armazenamento seguro é muito lento, implementações podem usar Bloco de memória de repetição Protegida (RPMB) diretamente.