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 camadas, a autenticação primária (ou seja, modalidades baseadas em fatores de conhecimento, como PIN, padrão e senha) fornece o mais alto nível de segurança. A biometria está na camada secundária 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 (anteriormente Forte), Classe 2 (anteriormente Fraca) e Classe 1 (anteriormente Conveniência). Cada classe tem um conjunto de pré-requisitos, privilégios e restrições - consulte o CDD acima para obter mais detalhes. Todas as três classes podem se integrar com a tela de bloqueio, mas somente autenticadores fortes e fracos podem se integrar com as APIs android.hardware.biometrics. Esta tabela descreve cada autenticador e a funcionalidade que eles suportam.

Autenticador Tela de bloqueio Integração de prompt biométrico Armazenamento de chaves (chave baseada em tempo) Armazenamento de chaves (chave baseada em operação)
BIOMETRIC_STRONG (Classe 3) Sim Sim Sim Sim
BIOMETRIC_WEAK (Classe 2) Sim Sim Não Não
BIOMÉTRICA_CONVENIÊNCIA
(Classe 1)
Sim Não Não Não
DEVICE_CREDENCIAL Sim Sim Sim Sim (1)
  1. Esta funcionalidade foi adicionada no Android 11, veja isto para mais detalhes

A estrutura do Android inclui suporte para autenticação biométrica de rosto e impressão digital. O Android pode ser personalizado para suportar outras modalidades biométricas (como Iris). No entanto, a integração biométrica dependerá da segurança biométrica, não da modalidade. Para obter mais detalhes sobre as especificações de segurança biométrica, consulte Medindo a segurança do desbloqueio biométrico .

Fonte

Android 11

  • Apresenta a interface BiometricManager.Authenticators , que fornece constantes que os desenvolvedores podem usar para especificar os tipos de autenticação aceitos por seus aplicativos.
  • Adiciona aação de intenção 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 de seus aplicativos.
  • Adiciona o método AuthenticationResult #getAuthenticationType () , que os desenvolvedores podem usar para verificar se o usuário autenticou usando uma credencial biométrica ou uma credencial de dispositivo.
  • Fornece suporte adicional para chaves de autenticação por 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 integração de autenticação de impressão digital e facial para BiometricPrompt

Android 9

  • Inclui integração de impressão digital apenas para BiometricPrompt .
  • Desaprova a classe FingerprintManager. Se seus aplicativos empacotados e do sistema usarem essa classe, atualize-os para usar BiometricPrompt e BiometricManager .
  • Atualizados os testes do verificador FingerprintManager CTS 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 devem atender a esses requisitos de resistência .
Para integrar sua pilha biométrica com as BiometricManager APIs BiometricPrompt

  1. Certifique-se de que seu <Modality>Service esteja registrado corretamente com BiometricService por meio do método IBiometricService#registerAuthenticator e implemente a interface IBiometricAuthenticator . Modalidades comuns (impressão digital, face) se estendem de uma superclasse comum. Se você precisar integrar uma modalidade não suportada, siga o exemplo de impressão digital / face e as diretrizes do CDD para biometria.
  2. Certifique-se de que sua nova modalidade tenha suporte adequado no SystemUI . Existem interfaces de usuário padrão do BiometricPrompt para impressão digital e rosto. Isso deve incluir qualquer alteração de layout ou tema necessária para o seu dispositivo. Ou seja, alterações de layout correspondentes para um sensor de impressão digital na tela.

Para integrar sua pilha biométrica com a API ACTION_BIOMETRIC_ENROLL:

  1. Modifique o BiometricEnrollActivity para apresentar seu fluxo de inscrição. Observe que sua biometria pode ser apresentada apenas se atender à força solicitada. Se o seu dispositivo suporta mais de um, esta ação deve apresentar uma lista que o usuário pode escolher.
Arquitetura BiometricPrompt
Figura 1. Arquitetura BiometricPrompt

Diretrizes de implementação de HAL

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

  • Certifique-se de que os dados biométricos brutos ou derivados (como modelos) nunca sejam acessíveis de fora do ambiente isolado seguro (como o TEE ou Secure Element). Todos os dados armazenados devem ser criptografados com uma chave específica do dispositivo conhecida apenas pelo TEE (Trusted Execution Environment). Se o hardware oferecer suporte, limite o acesso do hardware ao ambiente isolado seguro e proteja-o com uma política SELinux. Torne o canal de comunicação (por exemplo, SPI, I2C) acessível apenas ao ambiente isolado seguro com uma política SELinux explícita em todos os arquivos do dispositivo.
  • A aquisição, registro e reconhecimento biométricos devem ocorrer dentro do ambiente seguro e isolado para evitar violações de dados e outros ataques. Este requisito aplica-se apenas à biometria Classe 3 (anteriormente Forte) e Classe 2 (anteriormente Fraca) .
  • Para se proteger contra ataques de repetição, assine modelos biométricos com uma chave privada específica do dispositivo. Para o Advanced Encryption Standard (AES), no mínimo, assine um modelo com o caminho absoluto do sistema de arquivos, grupo e ID biométrico, de modo que os arquivos de modelo fiquem inoperantes 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 de outro dispositivo.
  • Se você precisar armazenar dados fora do TEE, use o caminho do sistema de arquivos fornecido pelo setActiveUser() HIDL method ou forneça outra maneira de apagar todos os dados do modelo de usuário quando o usuário for removido. O motivo é proteger o vazamento de dados do usuário. Os dispositivos que não usam esse caminho devem ser limpos após a remoção do usuário. É exigido pelo CDD que os dados biométricos e arquivos derivados sejam armazenados criptografados - especialmente se não for em TEE Se isso for inviável devido aos requisitos de armazenamento do ambiente isolado seguro, adicione ganchos para garantir a remoção dos dados quando o usuário for removido é apagado. Consulte LockSettingsService.removeBiometricsForUser()

Costumização

Se o seu dispositivo for compatível com várias biometrias, o usuário poderá especificar um padrão nas configurações. Sua implementação do BiometricPrompt deve preferir a biometria Classe 3 (anteriormente Strong) como padrão, a menos que o usuário a substitua explicitamente . )

Validação

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

  • Gerente Biométrico CTS
  • CTS BiometricPrompt (sanidade, testes aprofundados dependem do verificador)
  • Seção de teste biométrico CtsVerifier : Deve passar individualmente com cada modalidade que o dispositivo suporta

Além disso, se o seu dispositivo suportar uma biometria que tenha um AOSP HIDL ( fingerprint@2.1 , fingerprint@2.2 , face1.0 ), ele deverá passar no teste VTS relevante ( fingerprint , face )