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

Gatekeeper

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

Quando os usuários verificam suas senhas, o Gatekeeper usa o segredo compartilhado derivado de TEE para assinar um atestado de autenticação e enviar para o Keystore suportado por hardware . Ou seja, um atestado do Gatekeeper notifica o Keystore que as chaves vinculadas à autenticação (por exemplo, chaves que os aplicativos criaram) podem ser liberadas para uso pelos aplicativos.

Arquitetura

O Gatekeeper envolve três componentes principais:

  • gatekeeperd (daemon do Gatekeeper). Um serviço de GateKeeperService C ++ contendo lógica independente de plataforma e correspondente à interface Java GateKeeperService .
  • Camada de abstração de hardware do gatekeeper (HAL) . A interface HAL em hardware/libhardware/include/hardware/gatekeeper.h e o módulo de implementação.
  • Gatekeeper (TEE) . A contraparte TEE de gatekeeperd . Uma implementação baseada em TEE do Gatekeeper.

O Gatekeeper requer a implementação do Gatekeeper HAL (especificamente as funções em hardware/libhardware/include/hardware/gatekeeper.h ) e o componente Gatekeeper específico de TEE (baseado em parte no arquivo de cabeçalho system/gatekeeper/include/gatekeeper/gatekeeper.h que inclui funções puras virtuais para criar / acessar chaves e computar assinaturas).

O LockSettingsService faz uma solicitação (via Binder) que chega ao daemon do gatekeeperd no sistema operacional Android. O daemon do gatekeeperd então faz uma solicitação que atinge sua contraparte (Gatekeeper) no TEE:

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

O daemon gatekeeperd fornece às APIs da estrutura do Android acesso ao HAL e participa da geração de relatórios de autenticações do dispositivo para o Keystore. O daemon gatekeeperd é executado em seu próprio processo e é separado do servidor do sistema.

Implementação HAL

O daemon gatekeeperd usa o HAL para interagir com a contraparte TEE do daemon gatekeeperd para autenticação de senha. A implementação HAL deve ser capaz de assinar (registrar) e verificar blobs. Espera-se que todas as implementações sigam o formato padrão para o token de autenticação (AuthToken) gerado em cada verificação de senha bem-sucedida. Para obter detalhes sobre o conteúdo e a semântica do AuthToken, consulte o formato AuthToken .

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

  • A função de enroll pega um blob de senha, assina e retorna a assinatura como um identificador. O blob retornado (de uma chamada para enroll ) deve ter a estrutura mostrada em system/gatekeeper/include/gatekeeper/password_handle.h .
  • A função de verify deve comparar a assinatura produzida pela senha fornecida e garantir que corresponda ao identificador de senha registrada.

A chave usada para registrar e verificar nunca deve ser alterada e deve ser derivada a cada inicialização do dispositivo.

Trusty e outras implementações

O sistema operacional Trusty é o sistema operacional confiável de código aberto do Google para ambientes TEE e contém uma implementação aprovada do GateKeeper. No entanto, você pode usar qualquer TEE OS para implementar o Gatekeeper, desde que o TEE tenha acesso a uma chave apoiada por hardware e a um relógio monotônico e seguro que fica suspenso .

O Trusty usa um sistema IPC interno para comunicar um segredo compartilhado diretamente entre o Keymaster e a implementação do Trusty do Gatekeeper (o Trusty Gatekeeper ). Este segredo compartilhado é usado para assinar AuthTokens enviado ao Keystore para fornecer atestados de verificação de senha. O Trusty Gatekeeper solicita a chave do Keymaster para cada uso e não persiste ou armazena o valor em cache. As implementações são livres para compartilhar esse segredo de qualquer maneira que não comprometa a segurança.

A chave HMAC usada para registrar e verificar as senhas é derivada e mantida exclusivamente no GateKeeper.

O Android fornece uma implementação C ++ genérica do 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 de dispositivo para seu TEE, consulte as funções e comentários em system/gatekeeper/include/gatekeeper/gatekeeper.h . Para o TEE GateKeeper, as principais responsabilidades de uma implementação compatível incluem:

  • Adesão ao Gatekeeper HAL.
  • Os AuthTokens retornados devem ser formatados de acordo com a especificação do AuthToken (descrita em Autenticação ).
  • O TEE Gatekeeper deve ser capaz de compartilhar uma chave HMAC com o Keymaster, seja solicitando a chave por meio de um TEE IPC sob demanda ou mantendo um cache válido do valor o tempo todo.

User Secure IDs (SIDs)

Um SID de usuário é a representação TEE de um usuário (sem conexão forte com um ID de usuário Android). O SID é gerado com um gerador de números pseudo-aleatórios criptográficos (PRNG) sempre que um usuário inscreve uma nova senha sem fornecer uma anterior. Isso é conhecido como uma nova inscrição não confiável e não é permitido pela estrutura do Android em circunstâncias normais. Uma nova inscrição confiável ocorre quando um usuário fornece uma senha anterior válida; neste caso, o SID do usuário é migrado para o novo identificador de senha, conservando as chaves a ele vinculadas.

O SID do usuário é HMAC'ed junto com a senha no identificador de senha quando a senha é registrada.

Os SIDs do usuário são gravados no AuthToken retornado pela função de verify e associados a todas as chaves do Keystore vinculadas à autenticação (para obter detalhes sobre o formato AuthToken e o Keystore, consulte Autenticação ). Como uma chamada não confiável para a função de enroll alterará o SID do usuário, a chamada tornará as chaves vinculadas a essa senha inúteis. Os invasores podem alterar a senha do dispositivo se controlarem o sistema operacional Android, mas destruirão as chaves confidenciais protegidas por root no processo.

Solicitar limitação

O GateKeeper deve ser capaz de controlar com segurança as tentativas de força bruta em uma credencial de usuário. Conforme mostrado em hardware/libhardware/include/hardware/gatekeeper.h , o HAL fornece para retornar um tempo limite em milissegundos. O tempo limite informa o cliente para não chamar o GateKeeper novamente até que o tempo limite tenha decorrido; O GateKeeper não deve atender a solicitações se houver um tempo limite pendente.

O GateKeeper deve escrever um contador de falhas antes de verificar a senha do usuário. Se a verificação da senha for bem-sucedida, o contador de falhas deve ser apagado. Isso evita ataques que impedem a limitação, desativando o MMC integrado (eMMC) após emitir uma chamada de verify . A função de enroll também verifica a senha do usuário (se fornecida) e deve ser controlada da mesma maneira.

Se for compatível com o dispositivo, é altamente recomendável que o contador de falhas seja gravado em um armazenamento seguro. Se o dispositivo não suportar criptografia baseada em arquivo ou se o armazenamento seguro for muito lento, as implementações podem usar o Replay Protected Memory Block (RPMB) diretamente.