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 facial que pode processar quadros de câmera com segurança, preservando a segurança e a privacidade durante a autenticação facial em hardware compatível. O Android 10 também oferece uma maneira fácil para implementações compatíveis com segurança permitirem a integração de aplicativos para transações, como serviços bancários on-line 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 Face HAL interage com os seguintes componentes.
FaceManager
FaceManager é uma interface privada que mantém conexão com FaceService . É usado pelo Keyguard para acessar a autenticação facial com uma UI 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 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 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 encontrá-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
As mensagens de erro são enviadas por um retorno de chamada e retornam a máquina de estado ao estado inativo após serem enviadas. A maioria das mensagens tem uma string correspondente voltada ao usuário para informar o usuário sobre o erro, mas nem todos os erros têm essa string voltada ao 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 ao estado inativo 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; espera-se que o HAL envie quantos forem necessários para completar 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 deverá 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 enviar UNABLE_TO_PROCESS após várias tentativas, mas nenhum progresso adicional pode ser feito.
Hardware
Para que os dispositivos cumpram os rigorosos 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 definitiva. 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) aceitável necessária. Um ambiente de execução confiável (TEE) é necessário para processamento e reconhecimento seguros. Além disso, é necessário um 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 somente o hardware da câmera possa atualizá-las. Idealmente, nenhum processo deveria ter acesso, exceto o TEE e o hardware.
Como o hardware de autenticação facial varia consideravelmente, é necessário desenvolver drivers específicos de hardware para permitir a autenticação facial, dependendo da arquitetura específica do dispositivo. Como tal, não existe uma implementação de referência para o faced .
Métodos
Os métodos a seguir são todos assíncronos e devem retornar imediatamente ao framework. Não fazer isso resulta em um sistema lento e possíveis redefinições do Watchdog. É recomendado 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 pelo FaceService para encaminhar todas as mensagens para si mesmo. |
setActiveUser() | Define o usuário ativo ao qual todas as operações HAL subsequentes serão aplicadas. A autenticação é sempre para este usuário até que este método seja chamado novamente. |
revokeChallenge() | Finaliza 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, registrar, autenticar, remover ou enumerar) e retorna ao estado faced . |
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() | Este método só deve ser usado quando o HAL estiver 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 rejeitadas, é necessário que faced entre em um estado de bloqueio ( LOCKOUT ou LOCKOUT_PERMANENT ). Quando isso acontece, é necessário enviar o tempo restante ao framework para que ele possa exibi-lo ao usuário. Tal como acontece 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 exclusivo 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 motivos de segurança, isso exige que um HAT verifique o pin/padrão/senha do usuário em relação ao desafio acima |
getFeature() | Recupera o estado atual de ativação do recurso, conforme determinado pelo padrão ou por uma chamada para setFeature() acima. Se o ID facial for inválido, a implementação deverá retornar ILLEGAL_ARGUMENT |
getAuthenticatorId() | Retorna um identificador associado ao conjunto de faces atual. Este identificador deve mudar sempre que um rosto é adicionado |
Diagrama de Estado
A estrutura espera que faced sigam o diagrama de estado abaixo.
