Visão geral
A autenticação facial permite que os usuários desbloqueiem o dispositivo simplesmente olhando para a parte frontal dele. O Android 10 oferece suporte a uma nova pilha de autenticação facial que pode processar de forma segura os frames da câmera, preservando a segurança e a privacidade durante a autenticação facial no hardware com suporte. O Android 10 também oferece uma maneira fácil para implementações compatíveis com a segurança permitirem a integração de apps para transações, como internet banking 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 a de rosto, de dedo e de íris. O HAL de rosto interage com os seguintes componentes.
Figura 1. Pilha biométrica.
FaceManager
FaceManager é uma interface particular que mantém uma
conexão com FaceService. Ele é usado pela proteção de chave para
acessar a autenticação facial com uma IU personalizada. Os apps não
têm acesso ao FaceManager e precisam usar BiometricPrompt.
FaceService
Esta é a implementação do framework que gerencia o acesso ao hardware de autenticação facial. Ele contém máquinas de estado de inscrição e autenticação básicas, além de vários outros auxiliares (por exemplo, enumeração). Por motivos de estabilidade e segurança, nenhum código do fornecedor pode ser executado nesse processo. Todo o código do fornecedor é acessado pela interface HIDL Face 1.0.
enfrentaram
Execução do Linux que implementa a interface HIDL do Face 1.0 usada
por FaceService. Ele se registra como IBiometricsFace@1.0 para que FaceService
possa encontrá-lo.
Implementação
HIDL de rosto
Para implementar o Face HIDL, é necessário 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 callback e retornam a máquina de estados ao estado
inativo depois de serem enviadas. A maioria das mensagens tem uma
string voltada ao usuário correspondente para informar o usuário sobre o erro, mas nem todos
os erros têm essa string voltada ao 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 o framework assume que o
HAL retorna a um estado inativo após enviar uma mensagem de erro.
Mensagens de aquisição
As mensagens de aquisição são enviadas durante o registro ou a autenticação e
têm como objetivo orientar o usuário para que ele conclua o processo.
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
mesmas. Espera-se que o HAL envie o máximo possível delas para
concluir a inscrição ou autenticação atual. Se uma mensagem de aquisição
resultar em um estado terminal em que nenhum progresso possa ser feito, o HAL precisará
seguir as mensagens de aquisição com uma mensagem de erro, por exemplo, em que a
imagem está muito escura e permanece muito escura para que o progresso seja feito. Nesse caso, é
razoável enviar UNABLE_TO_PROCESS depois que várias tentativas foram feitas,
mas nenhum progresso adicional pode ser feito.
Hardware
Para que os dispositivos estejam em conformidade com os requisitos de biometria forte do Android 10, eles precisam ter hardware seguro para garantir a integridade dos dados faciais e a comparação final 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 de aceitação de falsificação (SAR, na sigla em inglês) aceitável. 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 impedir 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 apenas o hardware da câmera possa atualizá-las. O ideal é que nenhum processo tenha acesso, exceto o TEE e o hardware.
Como o hardware de autenticação facial varia consideravelmente, é necessário
desenvolver drivers específicos do hardware para ativar a autenticação facial, dependendo da
arquitetura específica do dispositivo. Portanto, não há uma implementação
de referência para faced.
Métodos
Os métodos a seguir são assíncronos e precisam retornar imediatamente ao framework. Se isso não for feito, o sistema ficará lento e o Watchdog poderá ser redefinido. É recomendável ter uma fila de mensagens com várias linhas de execução para evitar o bloqueio do autor da chamada. Todas as solicitações GET precisam armazenar informações em cache sempre que possível para que o autor da chamada seja bloqueado por um período mínimo.
| Método | Descrição |
|---|---|
setCallback() |
Chamado por FaceService para direcionar todas as mensagens de volta para ele mesmo. |
setActiveUser() |
Define o usuário ativo, em que todas as operações HAL subsequentes são aplicadas. A autenticação é sempre para esse usuário até que o 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 atual (por exemplo, registro, autenticação,
remoção ou enumeração) e retorna faced ao estado inativo. |
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() |
Esse método só deve ser usado quando o HAL estiver no estado de autenticação ou
de 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 um rosto. |
resetLockout() |
Quando muitas faces são rejeitadas, o faced é necessário para entrar em um estado de bloqueio (LOCKOUT ou LOCKOUT_PERMANENT). Quando isso
acontece, é necessário enviar o tempo restante para a estrutura para que ela possa
mostrar para o usuário. Como em setFeature(), esse método requer um
token de autenticação de hardware (HAT) ativo para redefinir o estado interno com segurança. Redefine o bloqueio
apenas para o usuário atual. |
Os três métodos restantes são todos síncronos e precisam ser bloqueados por um tempo mínimo para evitar a paralisação do framework.
| 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, é necessário 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 facial for inválido, a
implementação precisará retornar ILLEGAL_ARGUMENT. |
getAuthenticatorId() |
Retorna um identificador associado ao conjunto de rostos atual. Esse identificador precisa mudar sempre que um rosto for adicionado |
Diagrama de estados
O framework espera que faced siga o diagrama de estado abaixo.
Figura 2. Fluxo de estado da autenticação facial.