Biometria

A biometria oferece uma maneira mais conveniente, mas potencialmente menos segura, de confirmar sua identidade com um dispositivo. No modelo de autenticação em níveis, a autenticação primária (por exemplo, modalidades baseadas em fatores de conhecimento, como PIN, padrão e senha) oferece o mais alto nível de segurança. A biometria está no nível secundário de autenticação, oferecendo um equilíbrio de conveniência e segurança. O CDD do Android define três classes de força biométrica: Classe 3 (antes forte), Classe 2 (antes fraca) e Classe 1 (antes conveniência). Cada classe tem um conjunto de pré-requisitos, privilégios e restrições. Consulte a CDD acima para mais detalhes. Todas as três classes podem ser integradas à tela de bloqueio, mas somente os autenticadores fortes e fracos podem ser integrados às APIs android.hardware.biometrics. Esta tabela descreve cada autenticador e as funcionalidades compatíveis.

O framework do Android oferece suporte à autenticação biométrica facial e de impressão digital. O Android pode ser personalizado para oferecer suporte a outras modalidades biométricas (como a íris). No entanto, a integração biométrica vai depender da segurança biométrica, não da modalidade. Para mais detalhes sobre as especificações de segurança biométrica, consulte Como medir a segurança de desbloqueio biométrico.

Origem

Android 12

• Introdução da API BiometricManager.Strings, que fornece strings localizadas para apps que usam o BiometricPrompt para autenticação. Essas strings são destinadas a detectar o dispositivo e fornecer mais especificidade sobre quais tipos de autenticação podem ser usados.
• Inclui suporte ao sensor de impressão digital sob a tela (UDFPS).

Android 11

• Introdução à interface BiometricManager.Authenticators, que fornece constantes que os desenvolvedores podem usar para especificar os tipos de autenticação aceitos pelos apps.
• Adiciona a ação de intent ACTION_BIOMETRIC_ENROLL, que os desenvolvedores podem usar para direcionar o usuário a registrar um método de autenticação que atenda aos requisitos dos apps.
• Foi adicionado o método AuthenticationResult#getAuthenticationType(), que os desenvolvedores podem usar para verificar se o usuário foi autenticado usando uma credencial biométrica ou de dispositivo.
• Oferece suporte adicional para chaves de autenticação ao uso na classe BiometricPrompt.

Android 10

• Introdução à classe BiometricManager que os desenvolvedores podem usar para consultar a disponibilidade de autenticação biométrica.
• Inclui integração com impressão digital e autenticação facial para BiometricPrompt

Android 9

• Inclui a integração de impressão digital apenas para BiometricPrompt.
• A classe FingerprintManager foi descontinuada. Se os apps agrupados e do sistema usarem essa classe, atualize-os para usar BiometricPrompt e BiometricManager.
• Os testes do verificador CTS FingerprintManager foram atualizados para testar BiometricPrompt usando BiometricPromptBoundKeysTest.

Implementação

Para garantir que usuários e desenvolvedores tenham uma experiência biométrica integrada, integre sua pilha biométrica às APIs BiometricPrompt, BiometricManager e ACTION_BIOMETRIC_ENROLL. Os dispositivos com sensores biométricos precisam obedecer a esses requisitos de força.Além disso, todas as implementações precisam passar no módulo CTS CtsBiometricsTestCases.

Para integrar sua pilha biométrica à API ACTION_BIOMETRIC_ENROLL:

1. Modifique a BiometricEnrollActivity para apresentar seu fluxo de registro. Sua biometria só pode ser apresentada se atender ao nível de segurança solicitado. Se o dispositivo oferecer suporte a mais de um, essa ação vai apresentar uma lista para o usuário escolher.

Diretrizes de implementação do HAL

Siga estas diretrizes do HAL biométrico para garantir que os dados biométricos não sejam vazados e sejam excluídos quando um usuário for removido de um dispositivo:

• Verifique se os dados biométricos brutos ou derivados (como modelos) nunca podem ser acessados de fora do ambiente isolado seguro (como o TEE ou o Elemento de segurança). Todos os dados armazenados precisam ser criptografados com uma chave específica do dispositivo conhecida apenas pelo ambiente de execução confiável (TEE). Se o hardware oferecer suporte, limite o acesso do hardware ao ambiente isolado seguro e proteja-o com uma política do SELinux. Faça com que o canal de comunicação (por exemplo, SPI, I2C) seja acessível apenas ao ambiente isolado seguro com uma política SELinux explícita em todos os arquivos do dispositivo.
• A aquisição, a inscrição e o reconhecimento biométricos precisam ocorrer dentro do ambiente isolado seguro para evitar violações de dados e outros ataques. Esse requisito se aplica apenas à biometria de Classe 3 (anteriormente Strong) e Classe 2 (anteriormente fraca).
• Para se proteger contra ataques de repetição, assine os modelos biométricos com uma chave privada específica do dispositivo. Para o padrão de criptografia avançada (AES), no mínimo, assine um modelo com o caminho absoluto do sistema de arquivos, o grupo e o ID biométrico, para que os arquivos de modelo não funcionem em outro dispositivo ou para qualquer pessoa que não seja o usuário que os registrou no mesmo dispositivo. Por exemplo, evite copiar dados biométricos de um usuário diferente no mesmo dispositivo ou em outro.
• Se você precisar armazenar dados fora do TEE, use o caminho do sistema de arquivos fornecido pelo setActiveUser() HIDL method ou ofereça outra maneira de apagar todos os dados do modelo do usuário quando ele for removido. O motivo é proteger o vazamento de dados do usuário. Os dispositivos que não usam esse caminho precisam ser limpos depois que o usuário é removido. O CDD exige que os dados biométricos e arquivos derivados sejam armazenados criptografados, especialmente se não estiverem no TEE. Se isso for inviável devido aos requisitos de armazenamento do ambiente seguro, adicione ganchos para garantir a remoção dos dados quando o usuário for removido ou o dispositivo for apagado. Consulte LockSettingsService.removeBiometricsForUser()

Personalização

Se o dispositivo oferecer suporte a várias biometrias, o usuário poderá especificar um padrão nas configurações. A implementação de BiometricPrompt precisa preferir a biometria Classe 3 (anteriormente forte) como padrão, a menos que o usuário a substitua explicitamente. Nesse caso, uma mensagem de aviso precisa ser exibida explicando os riscos associados à biometria (por exemplo, uma foto sua pode desbloquear seu dispositivo).

Strings de autenticação específicas do dispositivo

A partir do Android 12, as strings de autenticação contextual são disponibilizadas para os desenvolvedores pela API BiometricManager.Strings. É possível personalizar os valores de recurso retornados por essa API para implementar strings específicas do dispositivo. Se fizer isso, confira se as novas strings foram traduzidas para todas as localidades compatíveis com o dispositivo. Além disso, verifique se as propriedades a seguir são preservadas:

Por exemplo, considere um dispositivo com um sensor de reconhecimento facial de classe 2 com uma face registrada, um PIN registrado e um sensor de impressão digital de classe 3 sem impressões digitais registradas. A tabela a seguir mostra exemplos de strings para cada combinação de autenticadores permitidos e método BiometricManager.Strings invocado:

Validação

A implementação biométrica precisa passar nos seguintes testes:

• BiometricManager do CTS
• BiometricPrompt do CTS (verificação, testes detalhados dependem do verificador)
• Seção do teste biométrico do CtsVerifier: é necessário passar individualmente em cada modalidade com suporte do dispositivo.

Além disso, se o dispositivo for compatível com uma biometria que tenha um HIDL do AOSP (fingerprint@2.1, fingerprint@2.2, face1.0), ele precisa ser aprovado no teste VTS relevante (impressão digital, rosto).