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 com segurança os quadros da câmera, 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 de implementações compatíveis com segurança para permitir 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 IBiometricsFace.hal , IBiometricsFaceClientCallback.hal e types.hal .
Arquitetura
A API BiometricPrompt inclui todas as autenticações biométricas, incluindo face, dedo e íris. O Face HAL interage com os seguintes componentes.
FaceManager
FaceManager é uma interface privada que mantém uma conexão com FaceService . É usado pelo Keyguard para acessar a autenticação facial com uma interface do usuário personalizada. Os aplicativos não têm acesso ao FaceManager e devem usar o 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 estado 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 nesse processo. Todo o código do fornecedor é acessado através da interface Face 1.0 HIDL .
enfrentou
Este é um executável do Linux que implementa a interface HIDL Face 1.0 usada pelo FaceService . Ele se registra como IBiometricsFace@1.0 para que o 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 ocioso após serem enviadas. A maioria das mensagens tem uma string correspondente voltada para o usuário para informar o usuário sobre o 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 a um estado ocioso após o envio de uma mensagem de erro.
Mensagens de aquisição
As mensagens de aquisição são entregues durante a inscrição ou autenticação e destinam-se a 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; 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 pode ser feito.
Hardware
Para que os dispositivos estejam em conformidade com os fortes requisitos biométricos do Android 10, eles devem ter hardware seguro para garantir a integridade dos dados de rosto e a melhor comparação de autenticação. O Documento de definição de compatibilidade do Android (CDD) descreve o nível de segurança necessário e a taxa aceitável 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, é 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 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 o 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 faced para o .
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 possíveis reinicializações do Watchdog. É recomendável ter uma fila de mensagens com vários encadeamentos 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 canalizar 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() | Finaliza a transação segura invalidando o desafio gerado por generateChallenge() . |
enroll() | Inscreve 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 muitos rostos são rejeitados, faced é necessário para 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 exibi-lo para o usuário. Assim como setFeature() , esse método requer um token de autenticação de hardware ativo (HAT) 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 interrupçã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 requer 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 do rosto 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
O faced espera que o quadro siga o diagrama de estados abaixo.
