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 principal (ou seja, 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 entre 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 o CDD acima para mais detalhes. Todas as três classes podem ser integradas à tela de bloqueio, mas somente autenticadores fortes e fracos podem ser integrados às APIs android.hardware.biometrics. Esta tabela descreve cada autenticador e a funcionalidade que eles oferecem.

Authenticator (em inglês) Tela de bloqueio Integração do BiometricPrompt Keystore (chave baseada em tempo) Keystore (chave baseada em operação)
BIOMETRIC_STRONG (classe 3) Sim Sim Sim Sim
BIOMETRIC_WEAK (Classe 2) Sim Sim Não Não
BIOMETRIC_CONVENIENCE
(Classe 1)
Sim Não Não Não
DEVICE_CREDENTIAL Sim Sim Sim Sim

O framework do Android inclui suporte para autenticação biométrica facial e por impressão digital. O Android pode ser personalizado para oferecer suporte a outras modalidades biométricas, como íris. No entanto, a integração biométrica depende 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 do desbloqueio biométrico.

Origem

Android 12

  • Apresenta a API BiometricManager.Strings, que fornece strings localizadas para apps que usam BiometricPrompt para autenticação. Essas strings são projetadas para serem compatíveis com dispositivos e fornecer mais especificidade sobre quais tipos de autenticação podem ser usados.
  • Inclui suporte para sensor de impressão digital sob a tela (UDFPS).

Android 11

  • Apresenta a interface BiometricManager.Authenticators, que fornece constantes que os desenvolvedores podem usar para especificar os tipos de autenticação aceitos pelos apps deles.
  • 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.
  • Adiciona 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

  • Apresenta a classe BiometricManager que os desenvolvedores podem usar para consultar a disponibilidade da autenticação biométrica.
  • Inclui a integração da autenticação por impressão digital e reconhecimento facial para BiometricPrompt

Android 9

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

Implementação

Para garantir que usuários e desenvolvedores tenham uma experiência biométrica perfeita, 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 segurança.Além disso, todas as implementações precisam passar no módulo CtsBiometricsTestCases do CTS.

Para integrar sua pilha biométrica à API ACTION_BIOMETRIC_ENROLL:

  1. Modifique a BiometricEnrollActivity para apresentar seu fluxo de inscrição. Sua biometria só poderá ser apresentada se atender à força solicitada. Se o dispositivo for compatível com mais de uma opção, essa ação vai apresentar uma lista para o usuário escolher.
Arquitetura BiometricPrompt
Figura 1. Arquitetura do BiometricPrompt

Diretrizes de implementação da HAL

Siga estas diretrizes da HAL biométrica para garantir que os dados biométricos não sejam vazados e sejam removidos quando um usuário for removido de um dispositivo:

  • Verifique se os dados biométricos brutos ou derivados (como modelos) nunca estão acessíveis fora do ambiente isolado seguro (como o TEE ou o elemento seguro). 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 for compatível, limite o acesso 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 explícita do SELinux em todos os arquivos do dispositivo.
  • A aquisição, o registro 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 às biometrias de Classe 3 (antes Forte) e Classe 2 (antes Fraca).
  • Para se proteger contra ataques de repetição, assine 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 possam ser usados em outro dispositivo ou por qualquer pessoa que não seja o usuário que os registrou no mesmo dispositivo. Por exemplo, evite copiar dados biométricos de outro usuário 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 de modelo do usuário quando ele for removido. O motivo é proteger contra vazamentos de dados do usuário. Os dispositivos que não usam esse caminho precisam fazer uma limpeza depois que o usuário é removido. O CDD exige que os dados biométricos e os arquivos derivados sejam armazenados criptografados, principalmente se não estiverem no TEE. Se isso for inviável devido aos requisitos de armazenamento do ambiente isolado seguro, adicione hooks para garantir a remoção dos dados quando o usuário for removido ou o dispositivo for redefinido. Consulte LockSettingsService.removeBiometricsForUser()

Personalização

Se o dispositivo for compatível com várias biometrias, o usuário poderá especificar uma opção padrão nas configurações. Sua implementação de BiometricPrompt deve preferir a biometria de classe 3 (antiga "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 aos desenvolvedores pela API BiometricManager.Strings. É possível personalizar os valores de recursos retornados por essa API para implementar strings específicas do dispositivo. Se você fizer isso, traduza todas as novas strings para todos os locais compatíveis com o dispositivo. Além disso, verifique se as seguintes propriedades foram preservadas:


Método

Finalidade da string

Tipos de autenticação a serem incluídos

Se for possível usar biometria e bloqueio de tela

getButtonLabel()

Rótulo de um botão que aciona o BiometricPrompt

Use apenas tipos registrados (se possível) que atendam aos requisitos do autenticador.

Use a string somente biométrica (por exemplo, "Usar impressão digital")

getPromptMessage()

Mensagem mostrada no BiometricPrompt durante a autenticação

Use apenas tipos registrados (se possível) que atendam aos requisitos do autenticador.

Use a string combinada de biometria e bloqueio de tela (por exemplo, "Use sua impressão digital ou PIN para continuar")

getSettingName()

Nome de uma configuração que ativa o BiometricPrompt para autenticação

Todos os tipos compatíveis com o dispositivo (mesmo que não estejam registrados) que atendam aos requisitos do autenticador

Use a string combinada de biometria e bloqueio de tela (por exemplo, "Usar impressão digital ou bloqueio de tela")

Por exemplo, considere um dispositivo que tenha um sensor facial de classe 2 com um rosto registrado, um PIN registrado e um sensor de impressão digital de classe 3 com nenhuma impressão digital registrada. A tabela a seguir fornece exemplos de strings para cada combinação de autenticadores permitidos e método BiometricManager.Strings invocado:


Autenticadores permitidos

getButtonLabel()

getPromptMessage()

getSettingName()

Biometria de classe 3 (BIOMETRIC_STRONG)

"Usar impressão digital"
(Somente a impressão digital atende aos requisitos do autenticador)

"Use sua impressão digital para continuar"
(Somente a impressão digital atende aos requisitos do autenticador)

"Usar impressão digital"
(Somente a impressão digital atende aos requisitos do autenticador)

Biometria de classe 2 (BIOMETRIC_WEAK)

"Usar rosto"
(Rosto e impressão digital atendem aos requisitos; apenas o rosto está registrado)

"Use seu rosto para continuar"
(Rosto e impressão digital atendem aos requisitos; apenas o rosto está registrado)

"Usar rosto ou impressão digital"
(O rosto e a impressão digital atendem aos requisitos; o dispositivo é compatível com os dois)

Bloqueio de tela (DEVICE_CREDENTIAL)

"Usar PIN"
(Qualquer bloqueio de tela atende aos requisitos; o PIN está registrado)

"Digite seu PIN para continuar"
(Qualquer bloqueio de tela atende aos requisitos; o PIN está registrado)

"Usar bloqueio de tela"
(Qualquer bloqueio de tela atende aos requisitos)

Biometria de classe 3 OU bloqueio de tela

"Usar PIN"
(Impressão digital e qualquer bloqueio de tela atendem aos requisitos; apenas o PIN é registrado)

"Digite seu PIN para continuar"
(Impressão digital e qualquer bloqueio de tela atendem aos requisitos; apenas o PIN está registrado)

"Usar impressão digital ou bloqueio de tela"
(Impressão digital e qualquer bloqueio de tela atendem aos requisitos)

Biometria de classe 2 OU bloqueio de tela

"Usar rosto"
(Rosto, impressão digital e qualquer bloqueio de tela atendem aos requisitos; o rosto é registrado e substitui o PIN)

"Use seu rosto ou PIN para continuar"
(Rosto, impressão digital e qualquer bloqueio de tela atendem aos requisitos. Rosto e PIN estão registrados)

"Usar biometria ou bloqueio de tela"
(Desbloqueio facial, por impressão digital e qualquer bloqueio de tela atendem aos requisitos)

Validação

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

  • CTS BiometricManager
  • CTS BiometricPrompt (integridade, testes detalhados dependem do verificador)
  • Seção do teste biométrico do CtsVerifier: precisa ser aprovada individualmente com cada modalidade compatível com o dispositivo

Além disso, se o dispositivo for compatível com uma biometria que tenha um HIDL do AOSP ([email protected], [email protected], face1.0), ele precisará passar no teste VTS relevante (fingerprint, face).