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 fator de conhecimento, como PIN, padrão e senha) fornece o nível mais alto 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 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 se integrar com lockscreen, mas apenas 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 do Prompt Biométrico | Keystore (chave baseada em tempo) | Keystore (chave baseada em operação) |
|---|---|---|---|---|
| BIOMETRIC_STRONG (Classe 3) | Sim | Sim | Sim | Sim |
| BIOMETRIC_FRACO (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 |
A estrutura do 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 o 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 de desbloqueio biométrico .
Fonte
Androide 12
- Apresenta a API BiometricManager.Strings , que fornece strings localizadas para aplicativos que usam BiometricPrompt para autenticação. Essas strings destinam-se a reconhecer o dispositivo e fornecer mais especificidade sobre quais tipos de autenticação podem ser usados.
- Inclui suporte para sensor de impressão digital subexibido (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 foi autenticado usando uma credencial biométrica ou uma credencial de dispositivo. - Fornece suporte adicional para chaves de autenticação por uso dentro da classe BiometricPrompt.
Android 10
- Apresenta a classe
BiometricManagerque os desenvolvedores podem usar para consultar a disponibilidade de 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. - Substitui a classe FingerprintManager. Se seus aplicativos integrados e de sistema usarem essa classe, atualize-os para usar
BiometricPrompteBiometricManager. - Atualizados os testes do verificador
FingerprintManagerCTS para testarBiometricPromptusandoBiometricPromptBoundKeysTest.
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 . Dispositivos com sensores biométricos devem aderir a esses requisitos de força . 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:
- 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 suportar mais de um, esta ação deve 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 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 for compatível, 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 para o ambiente isolado seguro com uma política SELinux explícita em todos os arquivos do dispositivo.
- A aquisição biométrica, inscrição e reconhecimento devem ocorrer dentro do ambiente isolado seguro para evitar violações de dados e outros ataques. Este requisito aplica-se apenas à biometria de 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 de 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 em outro dispositivo.
- Se você precisar armazenar dados fora do TEE, use o caminho do sistema de arquivos fornecido pelo
setActiveUser() HIDL methodou 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 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 no 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 ou o dispositivo for removido é limpo. 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 o fizer, certifique-se de que todas as novas strings sejam traduzidas para todas as localidades suportadas pelo dispositivo. Além disso, certifique-se de que as seguintes propriedades sejam preservadas:
Método | Finalidade da string | Tipo(s) de autenticação a incluir | Se a(s) biometria(s) e o bloqueio de tela forem possíveis |
|---|---|---|---|
getButtonLabel() | Rótulo para um botão que aciona o BiometricPrompt | Somente tipos registrados (se possível) que satisfaçam os requisitos do autenticador | Use uma sequência apenas biométrica (como "Usar impressão digital") |
getPromptMessage() | Mensagem mostrada no BiometricPrompt durante a autenticação | Somente tipos registrados (se possível) que satisfaçam os requisitos do autenticador | Use a cadeia biométrica e de bloqueio de tela combinada (por exemplo, "Use sua impressão digital ou PIN para continuar") |
getSettingName() | Nome de uma configuração que habilita o BiometricPrompt para autenticação | Todos os tipos suportados pelo dispositivo (mesmo se não registrados) que atendem aos requisitos do autenticador | Use sequência biométrica e de bloqueio de tela combinadas (como "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 Classe 3 sem impressões digitais registradas . A tabela a seguir fornece strings de amostra para cada combinação de autenticadores permitidos e método BiometricManager.Strings invocado:
Autenticadores permitidos | getButtonLabel() | getPromptMessage() | getSettingName() |
|---|---|---|---|
Classe 3 biométrica ( BIOMETRIC_STRONG ) | "Usar impressão digital" (Apenas a impressão digital satisfaz os requisitos do autenticador) | "Use sua impressão digital para continuar" (Apenas a impressão digital satisfaz os requisitos do autenticador) | "Usar impressão digital" (Apenas a impressão digital satisfaz os requisitos do autenticador) |
Classe 2 biométrica ( BIOMETRIC_WEAK ) | "Usar rosto" (O rosto e a impressão digital atendem aos requisitos; apenas o rosto é registrado) | "Use seu rosto para continuar" (O rosto e a impressão digital atendem aos requisitos; apenas o rosto é registrado) | "Usar rosto ou impressão digital" (O rosto e a impressão digital atendem aos requisitos; o dispositivo suporta ambos) |
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) |
Classe 3 biométrica OU bloqueio de tela | "Usar PIN" (A impressão digital e qualquer bloqueio de tela atendem aos requisitos; apenas o PIN é registrado) | "Digite seu PIN para continuar" (A impressão digital e qualquer bloqueio de tela atendem aos requisitos; apenas o PIN é registrado) | "Usar impressão digital ou bloqueio de tela" (A impressão digital e qualquer bloqueio de tela atendem aos requisitos) |
Classe 2 biométrica 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 são registrados) | "Usar biometria ou bloqueio de tela" (Rosto, impressão digital e qualquer bloqueio de tela atendem aos requisitos) |
Validação
Sua implementação biométrica deve passar nos seguintes testes:
- CTS BiometricManager
- 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 )
,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 fator de conhecimento, como PIN, padrão e senha) fornece o nível mais alto 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 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 se integrar com lockscreen, mas apenas 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 do Prompt Biométrico | Keystore (chave baseada em tempo) | Keystore (chave baseada em operação) |
|---|---|---|---|---|
| BIOMETRIC_STRONG (Classe 3) | Sim | Sim | Sim | Sim |
| BIOMETRIC_FRACO (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 |
A estrutura do 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 o 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 de desbloqueio biométrico .
Fonte
Androide 12
- Apresenta a API BiometricManager.Strings , que fornece strings localizadas para aplicativos que usam BiometricPrompt para autenticação. Essas strings destinam-se a reconhecer o dispositivo e fornecer mais especificidade sobre quais tipos de autenticação podem ser usados.
- Inclui suporte para sensor de impressão digital subexibido (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 foi autenticado usando uma credencial biométrica ou uma credencial de dispositivo. - Fornece suporte adicional para chaves de autenticação por uso dentro da classe BiometricPrompt.
Android 10
- Apresenta a classe
BiometricManagerque os desenvolvedores podem usar para consultar a disponibilidade de 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. - Substitui a classe FingerprintManager. Se seus aplicativos integrados e de sistema usarem essa classe, atualize-os para usar
BiometricPrompteBiometricManager. - Atualizados os testes do verificador
FingerprintManagerCTS para testarBiometricPromptusandoBiometricPromptBoundKeysTest.
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 . Dispositivos com sensores biométricos devem aderir a esses requisitos de força . 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:
- 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 suportar mais de um, esta ação deve 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 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 for compatível, 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 para o ambiente isolado seguro com uma política SELinux explícita em todos os arquivos do dispositivo.
- A aquisição biométrica, inscrição e reconhecimento devem ocorrer dentro do ambiente isolado seguro para evitar violações de dados e outros ataques. Este requisito aplica-se apenas à biometria de 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 de 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 em outro dispositivo.
- Se você precisar armazenar dados fora do TEE, use o caminho do sistema de arquivos fornecido pelo
setActiveUser() HIDL methodou 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 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 no 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 ou o dispositivo for removido é limpo. 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 o fizer, certifique-se de que todas as novas strings sejam traduzidas para todas as localidades suportadas pelo dispositivo. Além disso, certifique-se de que as seguintes propriedades sejam preservadas:
Método | Finalidade da string | Tipo(s) de autenticação a incluir | Se a(s) biometria(s) e o bloqueio de tela forem possíveis |
|---|---|---|---|
getButtonLabel() | Rótulo para um botão que aciona o BiometricPrompt | Somente tipos registrados (se possível) que satisfaçam os requisitos do autenticador | Use uma sequência apenas biométrica (como "Usar impressão digital") |
getPromptMessage() | Mensagem mostrada no BiometricPrompt durante a autenticação | Somente tipos registrados (se possível) que satisfaçam os requisitos do autenticador | Use a cadeia biométrica e de bloqueio de tela combinada (por exemplo, "Use sua impressão digital ou PIN para continuar") |
getSettingName() | Nome de uma configuração que habilita o BiometricPrompt para autenticação | Todos os tipos suportados pelo dispositivo (mesmo se não registrados) que atendem aos requisitos do autenticador | Use sequência biométrica e de bloqueio de tela combinadas (como "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 Classe 3 sem impressões digitais registradas . A tabela a seguir fornece strings de amostra para cada combinação de autenticadores permitidos e método BiometricManager.Strings invocado:
Autenticadores permitidos | getButtonLabel() | getPromptMessage() | getSettingName() |
|---|---|---|---|
Classe 3 biométrica ( BIOMETRIC_STRONG ) | "Usar impressão digital" (Apenas a impressão digital satisfaz os requisitos do autenticador) | "Use sua impressão digital para continuar" (Apenas a impressão digital satisfaz os requisitos do autenticador) | "Usar impressão digital" (Apenas a impressão digital satisfaz os requisitos do autenticador) |
Classe 2 biométrica ( BIOMETRIC_WEAK ) | "Usar rosto" (O rosto e a impressão digital atendem aos requisitos; apenas o rosto é registrado) | "Use seu rosto para continuar" (O rosto e a impressão digital atendem aos requisitos; apenas o rosto é registrado) | "Usar rosto ou impressão digital" (O rosto e a impressão digital atendem aos requisitos; o dispositivo suporta ambos) |
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) |
Classe 3 biométrica OU bloqueio de tela | "Usar PIN" (A impressão digital e qualquer bloqueio de tela atendem aos requisitos; apenas o PIN é registrado) | "Digite seu PIN para continuar" (A impressão digital e qualquer bloqueio de tela atendem aos requisitos; apenas o PIN é registrado) | "Usar impressão digital ou bloqueio de tela" (A impressão digital e qualquer bloqueio de tela atendem aos requisitos) |
Classe 2 biométrica 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 são registrados) | "Usar biometria ou bloqueio de tela" (Rosto, impressão digital e qualquer bloqueio de tela atendem aos requisitos) |
Validação
Sua implementação biométrica deve passar nos seguintes testes:
- CTS Biometric Manager
- 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 )