HIDL de autenticação facial

Visão geral

A autenticação facial permite que os usuários desbloqueiem o dispositivo simplesmente olhando para a parte frontal dele. O Android 10 oferece suporte a uma nova pilha de autenticação facial que pode processar de forma segura os frames da câmera, preservando a segurança e a privacidade durante a autenticação facial no hardware com suporte. O Android 10 também oferece uma maneira fácil para implementações compatíveis com a segurança permitirem a integração de apps para transações, como para internet banking ou outros serviços.

A pilha de autenticação facial do Android é uma nova implementação no Android 10. A nova implementação apresenta as interfaces IBiometricsFace.hal, IBiometricsFaceClientCallback.hal e types.hal.

Arquitetura

A API BiometricPrompt inclui toda a autenticação biométrica, incluindo face, dedo e íris. O HAL de rosto interage com os seguintes componentes.

Figura 1. Pilha biométrica.

FaceManager

FaceManager é uma interface particular que mantém uma conexão com FaceService. Ele é usado pela proteção de teclado para acessar a autenticação facial com uma IU personalizada. Os apps não têm acesso ao FaceManager e precisam usar BiometricPrompt.

FaceService

Esta é a implementação do framework que gerencia o acesso ao hardware de autenticação facial. Ele contém máquinas de estado de inscrição e autenticação básicas, além de vários outros auxiliares (por exemplo, enumeração). Por motivos de estabilidade e segurança, nenhum código do fornecedor pode ser executado nesse processo. Todo o código do fornecedor é acessado na interface HIDL do Face 1.0.

enfrentaram

Execução do Linux que implementa a interface HIDL do Face 1.0 usada por FaceService. Ele se registra como IBiometricsFace@1.0 para que FaceService possa encontrá-lo.

Implementação

HIDL de rosto

Para implementar o Face HIDL, é necessário implementar todos os métodos de IBiometricsFace.hal em uma biblioteca específica do fornecedor.

Mensagens de erro

As mensagens de erro são enviadas por um callback e retornam a máquina de estados ao estado inativo depois de serem enviadas. A maioria das mensagens tem uma string voltada ao usuário correspondente para informar o usuário sobre o erro, mas nem todos os erros têm essa string voltada ao usuário. Para mais informações sobre mensagens de erro, consulte types.hal. Todas as mensagens de erro representam um estado terminal, o que significa que o framework assume que o HAL retorna a um estado inativo após enviar uma mensagem de erro.

Mensagens de aquisição

As mensagens de aquisição são entregues durante o registro ou a autenticação e têm como objetivo orientar o usuário para uma inscrição ou autenticação bem-sucedida. Cada ordinal tem uma mensagem associada do arquivo FaceAuthenticationManager.java. Mensagens específicas do fornecedor podem ser adicionadas, desde que as strings de ajuda correspondentes sejam fornecidas. As mensagens de aquisição não são estados terminais em si mesmas. Espera-se que o HAL envie o máximo possível delas para concluir a inscrição ou autenticação atual. Se uma mensagem de aquisição resultar em um estado terminal em que nenhum progresso possa ser feito, o HAL precisará seguir as mensagens de aquisição com uma mensagem de erro, por exemplo, em que a imagem está muito escura e permanece muito escura para que o progresso seja feito. Nesse caso, é razoável enviar UNABLE_TO_PROCESS depois que várias tentativas foram feitas, mas nenhum progresso adicional pode ser feito.

Hardware

Para que os dispositivos estejam em conformidade com os requisitos de biometria forte do Android 10, eles precisam ter hardware seguro para garantir a integridade dos dados faciais e a comparação de autenticação final. O Documento de definição de compatibilidade do Android (CDD) descreve o nível de segurança necessário e a taxa de aceitação de falsificação (SAR, na sigla em inglês) aceitável. Um ambiente de execução confiável (TEE) é necessário para processamento e reconhecimento seguros. Além disso, um hardware de câmera seguro é necessário para evitar ataques de injeção na autenticação facial. Por exemplo, as páginas de memória associadas aos dados de imagem podem ser privilegiadas e marcadas como somente leitura, para que apenas o hardware da câmera possa atualizá-las. O ideal é que nenhum processo tenha acesso, exceto o TEE e o hardware.

Como o hardware de autenticação facial varia consideravelmente, é necessário desenvolver drivers específicos do hardware para ativar a autenticação facial, dependendo da arquitetura específica do dispositivo. Portanto, não há uma implementação de referência para faced.

Métodos

Os métodos a seguir são todos assíncronos e precisam retornar imediatamente ao framework. Se isso não for feito, o sistema vai ficar lento e o Watchdog pode ser redefinido. É recomendável ter uma fila de mensagens com várias linhas de execução para evitar o bloqueio do autor da chamada. Todas as solicitações GET precisam armazenar informações em cache sempre que possível para que o autor da chamada seja bloqueado por um período mínimo.

Método	Descrição
setCallback()	Chamado por FaceService para direcionar todas as mensagens de volta para si mesmo.
setActiveUser()	Define o usuário ativo, ao qual todas as operações HAL subsequentes são aplicadas. A autenticação é sempre para esse usuário até que o método seja chamado novamente.
revokeChallenge()	Conclui a transação segura invalidando o desafio gerado por generateChallenge().
enroll()	Registra o rosto de um usuário.
cancel()	Cancela a operação atual (por exemplo, registro, autenticação, remoção ou enumeração) e retorna faced ao estado inativo.
enumerate()	Enumera todos os modelos de rosto associados ao usuário ativo.
remove()	Remove um modelo de rosto ou todos os modelos de rosto associados ao usuário ativo.
authenticate()	Autentica o usuário ativo.
userActivity()	Esse método só deve ser usado quando a HAL estiver no estado de autenticação ou de espera. O uso desse método quando a HAL não está em um desses estados retorna OPERATION_NOT_SUPPORTED. Chamar esse método enquanto o HAL já está autenticando pode estender o tempo que o sistema procura um rosto.
resetLockout()	Quando muitos rostos são rejeitados, faced é necessário para entrar em um estado de bloqueio (LOCKOUT ou LOCKOUT_PERMANENT). Quando isso ocorre, é necessário enviar o tempo restante ao framework para que ele possa exibi-lo ao usuário. Assim como acontece com setFeature(), esse método requer um token de autenticação de hardware (HAT, na sigla em inglês) ativo para redefinir com segurança o estado interno. Redefinir o bloqueio apenas para o usuário atual.

Os três métodos restantes são todos síncronos e precisam ser bloqueados por um período mínimo para evitar a paralisação do framework.

Método	Descrição
generateChallenge()	Gera um token aleatório exclusivo e criptograficamente seguro usado para indicar o início de uma transação segura.
setFeature()	Ativa ou desativa um recurso para o usuário atual. Por motivos de segurança, é necessário que um HAT verifique o PIN/padrão/senha do usuário em relação ao desafio acima.
getFeature()	Recupera o estado de ativação atual do recurso, conforme determinado pelo padrão ou uma chamada para setFeature() acima. Se o ID facial for inválido, a implementação precisará retornar ILLEGAL_ARGUMENT.
getAuthenticatorId()	Retorna um identificador associado ao conjunto de rostos atual. Esse identificador precisa mudar sempre que um rosto é adicionado

Diagrama de estados

O framework espera que faced siga o diagrama de estado abaixo.

Figura 2. Fluxo de estado da autenticação facial.