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

Autenticação facial HIDL

Visão geral

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 on-line ou outros serviços.

A pilha de autenticação rosto Android é uma nova aplicação no Android 10. Os novos introduz implementação das IBiometricsFace.hal , IBiometricsFaceClientCallback.hal e types.hal interfaces.

Arquitetura

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

Pilha biométrica
Pilha Figura 1. biométrico

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. Apps não tem acesso a FaceManager e deve usar BiometricPrompt vez.

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). Devido a questões de estabilidade e segurança, nenhum código de fornecedor pode ser executado neste processo. Todo o código do fornecedor é acessado através da interface de HIDL Rosto 1.0 .

enfrentou

Este é um executável Linux que implementa a interface HIDL Rosto 1.0 usado por FaceService . Ele se registra como IBiometricsFace@1.0 para que FaceService pode encontrá-lo.

Implementação

Rosto HIDL

Para implementar o HIDL Cara, 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 uma chamada de retorno e devolver a máquina de estado para o estado ocioso depois de serem enviados. A maioria das mensagens tem uma string voltada para o usuário correspondente para informar o usuário sobre o erro, mas nem todos os erros têm essa string voltada para o 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 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 tem uma mensagem associada do FaceAuthenticationManager.java arquivo. 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 por 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. Neste caso, é razoável para enviar UNABLE_TO_PROCESS depois de várias tentativas foram feitas, mas nenhum progresso pode ser feito.

Hardware

Para dispositivos de respeitar as fortes exigências biométricos para Android 10, eles devem ter hardware seguro para garantir a integridade dos dados rosto e a comparação de autenticação final. O Android Compatibility Definition Document (CDD) descreve o nível de segurança necessário e a taxa de aceitação de falsificação (SAR) necessária. 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 do dispositivo específico. Como tal, não há nenhuma aplicação de referência para 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 sondar 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() Termina a transação segura, invalidando o desafio gerado pelo 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. Usando este método quando o HAL não está em um desses estados retornos 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 muitos rostos 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. Tal como acontece com setFeature() , este método requer uma autenticação de hardware token de activo (HAT) para repor de forma segura o estado interno. Redefine lockout somente 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 habilitação atual do recurso, como ditado pelo padrão ou uma chamada para setFeature() acima. Se o ID rosto é 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 é adicionada

Diagrama de Estado

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

Diagrama de Estado
Figura fluxo estado de autenticação 2. Cara