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 compatível. O Android 10 também oferece uma maneira fácil para que implementações seguras permitam a integração de aplicativos para transações, como 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 rosto, 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. Usado pelo Keyguard para acessar a autenticação facial com uma interface personalizada. Os apps não têm acesso ao FaceManager e precisam usar BiometricPrompt.

FaceService

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

enfrentou

É um executável do Linux que implementa a interface HIDL do Face 1.0 usada pelo FaceService. Ele se registra como IBiometricsFace@1.0 para que o FaceService possa encontrá-lo.

Implementação

HIDL de rosto

Para implementar o HIDL de rosto, é preciso 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 idle depois de serem enviadas. A maioria das mensagens tem uma string correspondente voltada ao usuário para informar sobre o erro, mas nem todos os erros têm essa string. Para mais informações sobre mensagens de erro, consulte types.hal. Todas as mensagens de erro representam um estado terminal, ou seja, a estrutura pressupõe que a HAL retorna a um estado ocioso após enviar uma mensagem de erro.

Mensagens de aquisição

As mensagens de aquisição são enviadas durante a inscrição ou autenticação e orientam 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 finais por si só. Espera-se que a HAL envie quantas forem necessárias para concluir a inscrição ou autenticação atual. Se uma mensagem de aquisição resultar em um estado terminal em que não é possível fazer progresso, a HAL deverá seguir as mensagens de aquisição com uma mensagem de erro, por exemplo, quando a imagem está muito escura e permanece assim para que o progresso seja feito. Nesse caso, é razoável enviar UNABLE_TO_PROCESS depois de várias tentativas sem sucesso.

Hardware

Para que os dispositivos atendam aos requisitos de biometria avançada do Android 10, eles precisam ter hardware seguro para garantir a integridade dos dados faciais e a comparação final de autenticação. O Documento de definição de compatibilidade (CDD) do Android descreve o nível de segurança exigido 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 o processamento e o reconhecimento seguros. Além disso, é necessário hardware de câmera seguro 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 para ativar a autenticação facial, dependendo da arquitetura específica do dispositivo. Assim, não há uma implementação de referência para faced.

Métodos

Os métodos a seguir são assíncronos e precisam retornar imediatamente ao framework. Se isso não acontecer, o sistema ficará lento e poderá haver redefinições do Watchdog. Recomendamos ter uma fila de mensagens com várias linhas de execução para evitar o bloqueio do caller. Todas as solicitações GET devem armazenar informações em cache sempre que possível para que o chamador seja bloqueado por um período mínimo.

Método	Descrição
setCallback()	Chamado por FaceService para encaminhar todas as mensagens de volta para si mesmo.
setActiveUser()	Define o usuário ativo, a que todas as operações HAL subsequentes são aplicadas. A autenticação é sempre para esse usuário até que esse método seja chamado novamente.
revokeChallenge()	Finaliza a transação segura invalidando o desafio gerado pelo generateChallenge().
enroll()	Registra o rosto de um usuário.
cancel()	Cancela a operação atual (por exemplo, registrar, autenticar, remover ou enumerar) 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 em espera. Usar esse método quando a HAL não está em um desses estados retorna OPERATION_NOT_SUPPORTED. Chamar esse método enquanto a HAL já está autenticando pode aumentar o tempo que o sistema leva para procurar um rosto.
resetLockout()	Quando muitas faces são rejeitadas, o faced precisa entrar em um estado de bloqueio (LOCKOUT ou LOCKOUT_PERMANENT). Quando isso acontece, é necessário enviar o tempo restante para o framework para que ele possa exibir para o usuário. Assim como setFeature(), esse método exige um token de autenticação de hardware (HAT, na sigla em inglês) ativo para redefinir o estado interno com segurança. Redefine o bloqueio apenas para o usuário atual.

Os três métodos restantes são síncronos e devem bloquear pelo tempo mínimo para evitar a paralisação da estrutura.

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, isso exige um HAT para verificar 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 Face ID 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 estado

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

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