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 fornece 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 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 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 BiometricPrompt .
FaceService
Esta é a implementação da estrutura 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, 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 do 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
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 em direção a 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 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, 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 o progresso ser feito. Nesse caso, é razoável enviar UNABLE_TO_PROCESS depois de várias tentativas, mas nenhum progresso pode ser feito.
hardware
Para que os dispositivos cumpram os fortes requisitos biométricos do Android 10, eles devem ter hardware seguro para garantir a integridade dos dados faciais e a melhor comparação de autenticação. O Documento de Definição de Compatibilidade Android (CDD) descreve o nível de segurança necessário e a taxa de aceitação de falsificação aceitável (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á nenhuma implementação de referência para faced .
Métodos
Os métodos a seguir são todos assíncronos e devem retornar imediatamente ao framework. 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() | 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 face 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 espera. O uso desse 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, faced é necessária para entrar em um estado de bloqueio ( LOCKOUT ou LOCKOUT_PERMANENT ). Quando isso acontecer, é 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 (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() | Ativa ou desativa 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 ditado pelo padrão ou 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 faced seguir o diagrama de estado abaixo.
