O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.
Esta página foi traduzida pela API Cloud Translation.
Switch to English

Autenticação facial HIDL

visão global

A autenticação facial permite que os usuários desbloqueiem seus dispositivos simplesmente olhando para a frente do dispositivo. O Android 10 adiciona suporte para uma nova pilha de autenticação de rosto que pode processar quadros de câmera com segurança, preservando a segurança e a privacidade durante a autenticação de rosto em hardware compatível. O Android 10 também oferece uma maneira fácil de implementações em conformidade com a segurança para permitir a integração de aplicativos para transações, como banco online 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 IBiometricsFace.hal , IBiometricsFaceClientCallback.hal e types.hal .

Arquitetura

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

Pilha biométrica
Figura 1. Pilha biométrica

FaceManager

FaceManager é uma interface privada que mantém uma conexão com FaceService . É usado pelo Keyguard para acessar a autenticação facial com uma IU personalizada. Os aplicativos não têm acesso ao FaceManager e devem usar BiometricPrompt .

FaceService

Esta é a implementação da estrutura que gerencia o acesso ao hardware de autenticação facial. Ele contém máquinas básicas de registro e estado de autenticação, bem como vários outros auxiliares (por exemplo, enumeração). Por questões de estabilidade e segurança, nenhum código de fornecedor tem permissão para ser executado neste processo. Todo o código do fornecedor é acessado por meio da interface Face 1.0 HIDL .

enfrentou

Este é um executável Linux que implementa a interface Face 1.0 HIDL usada pelo FaceService . Ele se registra como IBiometricsFace@1.0 para que FaceService possa localizá-lo.

Implementação

Rosto HIDL

Para implementar o Face HIDL, você deve implementar todos os métodos de IBiometricsFace.hal em uma biblioteca específica do fornecedor.

Mensagens de erro

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

Mensagens de aquisição

As mensagens de aquisição são entregues durante a inscrição ou autenticação e têm como objetivo orientar o usuário para uma inscrição ou autenticação bem-sucedida. Cada ordinal possui 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 quantos deles forem necessários para concluir o registro ou autenticação atual. Se uma mensagem de aquisição resultar em um estado terminal onde nenhum progresso pode ser feito, então o HAL deve seguir as mensagens de aquisição com uma mensagem de erro, por exemplo, onde a imagem está muito escura e permanece muito escura para que o progresso seja feito. Nesse caso, é razoável enviar UNABLE_TO_PROCESS após várias tentativas, mas nenhum progresso posterior pode ser feito.

Hardware

Para que os dispositivos estejam em conformidade com os rígidos requisitos biométricos do Android 10, eles devem ter hardware seguro para garantir a integridade dos dados faciais e a comparação de autenticação final. O Android Compatibility Definition Document (CDD) descreve o nível de segurança exigido e a taxa de aceitação de spoofing (SAR) aceitável exigida. Um ambiente de execução confiável (TEE) é necessário para processamento e reconhecimento seguros. Além disso, o hardware da câmera segura é necessário para evitar ataques de injeção na autenticação facial. Por exemplo, as páginas de memória associadas para dados de imagem podem ser privilegiadas e marcadas como somente leitura para que apenas o hardware da câmera possa atualizá-las. Idealmente, nenhum processo deve ter acesso, exceto TEE e o hardware.

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

Métodos

Os métodos a seguir são todos assíncronos e devem retornar imediatamente à estrutura. Deixar de fazer isso resulta em um sistema lento e reinicializações potenciais do Watchdog. É recomendável ter uma fila de mensagens com vários threads para evitar o bloqueio do chamador. 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 de tempo.

Método Descrição
setCallback() Chamado por FaceService para FaceService 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 este usuário até que este 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 actual (por exemplo, se inscrever, autenticar, remover ou enumerar) e retorna faced para o estado ocioso.
enumerate() Enumera todos os modelos de face associados ao usuário ativo.
remove() Remove um template de face ou todos os templates de face associados ao usuário ativo.
authenticate() Autentica o usuário ativo.
userActivity() Este método só deve ser usado quando o HAL está no estado de autenticação ou de espera. Usar este método quando o 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 por um rosto.
resetLockout() Quando muitas faces são rejeitados, faced é obrigado a entrar em um estado de bloqueio ( LOCKOUT ou LOCKOUT_PERMANENT ). Ao fazer isso, é necessário enviar o tempo restante para a estrutura para que ela possa exibi-lo para o usuário. Como com setFeature() , este método requer um token de autenticação de hardware (HAT) ativo para redefinir com segurança o estado interno. Redefine o bloqueio apenas para o usuário atual.

Os três métodos restantes são todos síncronos e devem ser bloqueados por um período mínimo de tempo para evitar a paralisação da estrutura.

Método Descrição
generateChallenge() Gera um token aleatório único e criptograficamente seguro usado para indicar o início de uma transação segura.
setFeature() Habilita ou desabilita um recurso para o usuário atual. Por razões de segurança, isso requer 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 indicado pelo padrão ou uma chamada para setFeature() acima. Se o ID do rosto for inválido, a implementação deve retornar ILLEGAL_ARGUMENT
getAuthenticatorId() Retorna um identificador associado ao conjunto de faces atual. Este identificador deve mudar sempre que um rosto for adicionado

Diagrama de Estado

Os espera-quadro faced a seguir o diagrama de estado abaixo.

Diagrama de Estado
Figura 2. Fluxo de estado de autenticação facial