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 Android CDD 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 ser integradas à tela de bloqueio, mas apenas autenticadores fortes e fracos podem ser integrados às APIs android.hardware.biometrics. Esta tabela descreve cada autenticador e a funcionalidade que eles suportam.

A estrutura Android inclui suporte para autenticação biométrica facial e de 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 e não da modalidade. Para obter mais detalhes sobre especificações de segurança biométrica, consulte Medindo a segurança do desbloqueio biométrico .

Fonte

Andróide 12

• Apresenta a API BiometricManager.Strings , que fornece strings localizadas para aplicativos que usam BiometricPrompt para autenticação. Essas strings têm como objetivo reconhecer o dispositivo e fornecer mais especificidade sobre quais tipos de autenticação podem ser usados.
• Inclui suporte para sensor de impressão digital sob display (UDFPS).

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 se 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 impressão digital e autenticação facial para BiometricPrompt

Android 9

• Inclui integração de impressão digital apenas para BiometricPrompt .
• Descontinua a classe FingerprintManager. Se seus aplicativos empacotados e de 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 com APIs BiometricPrompt , BiometricManager e ACTION_BIOMETRIC_ENROLL . Dispositivos com sensores biométricos devem atender a esses requisitos de resistência . Além disso, todas as implementações devem passar no módulo CtsBiometricsTestCases CTS.

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

1. Modifique BiometricEnrollActivity para apresentar seu fluxo de inscrição. Observe que sua biometria só poderá ser apresentada se atender à robustez solicitada. Se o seu dispositivo suportar mais de um, esta ação deverá apresentar uma lista que o usuário pode escolher.

Diretrizes de implementação HAL

Siga estas diretrizes HAL biométricas para garantir que os dados biométricos não vazem e sejam removidos quando um usuário é 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 e seguro (como o TEE ou o Elemento Seguro). Todos os dados armazenados devem ser criptografados com uma chave específica do dispositivo conhecida apenas pelo TEE (Trusted Execution Environment). Se o hardware suportar, 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 e seguro com uma política SELinux explícita em todos os arquivos do dispositivo.
• A aquisição, registro e reconhecimento biométrico devem ocorrer dentro de um ambiente isolado e seguro para evitar violações de dados e outros ataques. Este requisito se aplica 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 Advanced Encryption Standard (AES), no mínimo assine um modelo com o caminho absoluto do sistema de arquivos, grupo e ID biométrico, de forma que os arquivos do modelo fiquem inoperáveis ​​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 do 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 deverão 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 estiverem no TEE. Se isso for inviável devido aos requisitos de armazenamento do ambiente isolado e seguro, adicione ganchos para garantir a remoção dos dados quando o usuário ou o dispositivo for removido é apagado. Consulte LockSettingsService.removeBiometricsForUser()

Costumização

Se o seu dispositivo suportar múltiplas biometrias, o usuário poderá especificar um padrão nas configurações. Sua implementação BiometricPrompt deve preferir a biometria Classe 3 (anteriormente Strong) como padrão, a menos que o usuário a substitua explicitamente, então 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 por meio da API BiometricManager.Strings . Você pode personalizar os valores de recursos retornados por esta API para implementar strings específicas do dispositivo. Se fizer isso, certifique-se de que todas as novas cadeias de caracteres sejam traduzidas para todas as localidades suportadas pelo dispositivo. Além disso, certifique-se de que as seguintes propriedades sejam preservadas:

Por exemplo, considere um dispositivo que possui um sensor facial de Classe 2 com um rosto registrado , um PIN registrado e um sensor de impressão digital de Classe 3 sem impressões digitais registradas . A tabela a seguir fornece sequências de amostra para cada combinação de autenticadores permitidos e método BiometricManager.Strings invocado:

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 ( impressão digital@2.1 , impressão digital@2.2 , face1.0 ), ele deverá passar no teste VTS relevante ( impressão digital , face )