Mejoras en la pantalla de bloqueo y la autenticación en Android 11




(Publicación cruzada del Blog de desarrolladores de Android)

A medida que los teléfonos se vuelven más rápidos e inteligentes, juegan un papel cada vez más importante en nuestras vidas, funcionando como nuestra memoria extendida, nuestra conexión con el mundo en general y, a menudo, la interfaz principal para la comunicación con amigos, familiares y comunidades más amplias. Es natural que, como parte de esta evolución, hayamos llegado a confiar en nuestros teléfonos nuestra información más privada y, de muchas maneras, los tratemos como extensiones de nuestras identidades digitales y físicas.

Esta confianza es primordial para el equipo de seguridad de Android. El equipo se centra en garantizar que los dispositivos Android respeten la privacidad y la confidencialidad de los datos del usuario. Un aspecto fundamental de este trabajo se centra en la pantalla de bloqueo, que actúa como la proverbial puerta de entrada a nuestros dispositivos. Después de todo, la pantalla de bloqueo asegura que solo los usuarios previstos de un dispositivo pueden acceder a sus datos privados.

Esta publicación de blog describe las mejoras recientes sobre cómo los usuarios interactúan con la pantalla de bloqueo en los dispositivos Android y, en general, con la autenticación. En particular, nos centramos en dos categorías de autenticación que presentan tanto un potencial inmenso como un riesgo potencialmente inmenso si no se diseñan bien: modalidades biométricas y ambientales.

Antes de entrar en los detalles de la pantalla de bloqueo y las mejoras de autenticación, primero queremos establecer un contexto para ayudar a relacionar estas mejoras entre sí. Una buena forma de visualizar estos cambios es encajarlos en el marco de la modelo de autenticación por niveles, una clasificación conceptual de todas las diferentes modalidades de autenticación en Android, cómo se relacionan entre sí y cómo están restringidas en función de esta clasificación.

El modelo en sí es bastante simple, clasifica las modalidades de autenticación en tres grupos de niveles decrecientes de seguridad y restricciones crecientes proporcionalmente. El nivel primario es el menos restringido en el sentido de que los usuarios solo necesitan volver a ingresar a una modalidad primaria en ciertas situaciones (por ejemplo, después de cada arranque o cada 72 horas) para utilizar su capacidad. Los niveles secundario y terciario están más restringidos porque no se pueden configurar y usar sin tener una modalidad primaria inscrita primero y tienen más restricciones que restringen aún más sus capacidades.

  1. Nivel primario: factor de conocimiento: El primer nivel consta de modalidades que se basan en factores de conocimiento, o algo que el usuario conoce, por ejemplo, un PIN, patrón o contraseña. Los buenos factores de conocimiento de alta entropía, como las contraseñas complejas que son difíciles de adivinar, ofrecen la mayor garantía potencial de identidad.

    Los factores de conocimiento son especialmente útiles en Android porque los dispositivos ofrecen protección de fuerza bruta respaldada por hardware con retroceso exponencial, lo que significa que los dispositivos Android evitan que los atacantes adivinen repetidamente un PIN, patrón o contraseña al tener tiempos de espera de respaldo de hardware después de cada 5 intentos incorrectos. Los factores de conocimiento también confieren beneficios adicionales a todos los usuarios que los utilizan, como Cifrado basado en archivos (FBE) y copia de seguridad del dispositivo cifrado.

  1. Nivel secundario – Biometría: El segundo nivel consiste principalmente en datos biométricos o algo el usuario es. Las autenticaciones basadas en rostros o huellas dactilares son ejemplos de modalidades de autenticación secundarias. La biometría ofrece una forma más conveniente pero potencialmente menos segura de confirmar su identidad con un dispositivo.

Profundizaremos en la biometría de Android en la siguiente sección.

  1. El nivel terciario: ambiental: El último nivel incluye modalidades que dependen de algo el usuario tiene. Esto podría ser un token físico, como con los dispositivos de confianza de Smart Lock, donde un teléfono se puede desbloquear cuando se empareja con un dispositivo bluetooth con certificación segura. O podría ser algo inherente al entorno físico alrededor del dispositivo, como los lugares de confianza de Smart Lock, donde un teléfono se puede desbloquear cuando se lo lleva a una ubicación segura.

    Mejoras en la autenticación terciaria

    Si bien tanto Trusted Places como Trusted Devices (y las modalidades terciarias en general) ofrecen formas convenientes de acceder a los contenidos de su dispositivo, el problema fundamental que comparten es que, en última instancia, son un proxy deficiente para la identidad del usuario. Por ejemplo, un atacante podría desbloquear un teléfono extraviado que usa Trusted Place simplemente conduciéndolo más allá de la casa del usuario, o con una cantidad moderada de esfuerzo, falsificando una señal de GPS usando radios definidas por software estándar y algunas secuencias de comandos suaves. De manera similar, con Trusted Device, el acceso a un dispositivo bluetooth con certificación segura también brinda acceso a todos los datos en el teléfono del usuario.

    Debido a esto, se ha realizado una mejora importante en el nivel ambiental en Android 10. El nivel terciario se cambió de un mecanismo de desbloqueo activo a un mecanismo de desbloqueo extendido en su lugar. En este nuevo modo, una modalidad de nivel terciario ya no puede desbloquear un dispositivo bloqueado. En cambio, si el dispositivo se desbloquea primero mediante una modalidad primaria o secundaria, puede continuar manteniéndolo en el estado desbloqueado durante un máximo de cuatro horas.

Las implementaciones biométricas vienen con una amplia variedad de características de seguridad, por lo que confiamos en los siguientes dos factores clave para determinar la seguridad de una implementación en particular:

  1. Seguridad arquitectónica: La resistencia de una canalización biométrica contra el compromiso del kernel o la plataforma. Una canalización se considera segura si los compromisos del kernel y la plataforma no otorgan la capacidad de leer datos biométricos sin procesar ni de inyectar datos sintéticos en la canalización para influir en una decisión de autenticación.
  2. Spoofability: Se mide utilizando la Tasa de aceptación de falsificaciones (SAR). SAR es una métrica que se introdujo por primera vez en Android P y está destinada a medir qué tan resistente es un biométrico frente a un atacante dedicado. Lea más sobre SAR y su medición en Medición de la seguridad de desbloqueo biométrico.

Usamos estos dos factores para clasificar la biometría en una de tres clases diferentes en orden decreciente de seguridad:

  • Clase 3 (anteriormente Strong)
  • Clase 2 (antes débil)
  • Clase 1 (anteriormente conveniencia)

Cada clase viene con un conjunto asociado de restricciones que tienen como objetivo equilibrar su facilidad de uso con el nivel de seguridad que ofrecen.

Estas restricciones reflejan el período de tiempo antes de que un biométrico recurra a la autenticación primaria y la integración de la aplicación permitida. Por ejemplo, un biométrico de Clase 3 disfruta de los tiempos de espera más largos y ofrece todas las opciones de integración para las aplicaciones, mientras que un biométrico de Clase 1 tiene los tiempos de espera más cortos y no tiene opciones para la integración de aplicaciones. Puede ver un resumen de los detalles en la tabla siguiente, o los detalles completos en el Documento de definición de compatibilidad de Android con Android (CDD).

1 La integración de aplicaciones significa exponer una API a las aplicaciones (por ejemplo, a través de la integración con BiometricPrompt / BiometricManager, androidx.biometric o API FIDO2)

2 La integración del almacén de claves significa integrar el almacén de claves, por ejemplo, para liberar claves vinculadas a la autenticación de aplicaciones

Beneficios y advertencias

La biometría proporciona comodidad a los usuarios al tiempo que mantiene un alto nivel de seguridad. Debido a que los usuarios necesitan configurar una modalidad de autenticación primaria para usar la biometría, esto ayuda a impulsar la adopción de la pantalla de bloqueo (vemos un promedio de adopción de la pantalla de bloqueo un 20% más alta en dispositivos que ofrecen datos biométricos en comparación con los que no lo hacen). Esto permite que más usuarios se beneficien de las características de seguridad que proporciona la pantalla de bloqueo: bloquea el acceso no autorizado a datos confidenciales del usuario y también confiere otras ventajas de una modalidad de autenticación primaria a estos usuarios, como copias de seguridad cifradas. Finalmente, la biometría también ayuda a reducir surf de hombro Ataques en los que un atacante intenta reproducir un PIN, patrón o contraseña después de observar a un usuario ingresar la credencial.

Sin embargo, es importante que los usuarios comprendan las compensaciones involucradas con el uso de la biometría. El principal de estos es que ningún sistema biométrico es infalible. Esto es cierto no solo en Android, sino en todos los sistemas operativos, factores de forma y tecnologías. Por ejemplo, una implementación biométrica facial puede ser engañada por miembros de la familia que se parecen al usuario o una máscara 3D del usuario. Una implementación biométrica de huellas dactilares podría potencialmente ser evitada por una falsificación hecha a partir de huellas dactilares latentes del usuario. Aunque las tecnologías anti-spoofing o Presentation Attack Detection (PAD) se han desarrollado activamente para mitigar tales ataques de spoofing, son mitigaciones, no prevenciones.

Un esfuerzo que ha hecho Android para mitigar el riesgo potencial de usar datos biométricos es el modo de bloqueo introducido en Android P. Los usuarios de Android pueden usar esta función para deshabilitar temporalmente la biometría, junto con Smart Lock (por ejemplo, Trusted Places y Trusted Devices) también. como notificaciones en la pantalla de bloqueo, cuando sientan la necesidad de hacerlo.

Para usar el modo de bloqueo, los usuarios primero deben configurar una modalidad de autenticación primaria y luego habilitarla en la configuración. La configuración exacta en la que se puede habilitar el modo de bloqueo varía según el modelo de dispositivo, y en un dispositivo Google Pixel 4 se encuentra en Configuración> Pantalla> Pantalla de bloqueo> Mostrar opción de bloqueo. Una vez habilitado, los usuarios pueden activar el modo de bloqueo manteniendo presionado el botón de encendido y luego haciendo clic en el icono de Bloqueo en el menú de encendido. Un dispositivo en modo de bloqueo volverá al estado de no bloqueo después de que se utilice una modalidad de autenticación primaria (como un PIN, patrón o contraseña) para desbloquear el dispositivo.

Para que los desarrolladores se beneficien de la garantía de seguridad proporcionada por la biometría de Android e integren fácilmente la autenticación biométrica en sus aplicaciones para proteger mejor los datos confidenciales del usuario, presentamos el BiometricPrompt API en Android P.

Existen varios beneficios de utilizar las API de BiometricPrompt. Lo más importante es que estas API permiten a los desarrolladores de aplicaciones apuntar a la biometría de una manera independiente de la modalidad en diferentes dispositivos Android (es decir, BiometricPrompt se puede usar como un único punto de integración para varias modalidades biométricas compatibles con los dispositivos), mientras se controlan las garantías de seguridad que el la autenticación debe proporcionar (por ejemplo, los requisitos biométricos de Clase 3 o Clase 2, con la credencial del dispositivo como alternativa). De esta manera, ayuda a proteger los datos de la aplicación con una segunda capa de defensas (además de la pantalla de bloqueo) y, a su vez, respeta la sensibilidad de los datos del usuario. Además, BiometricPrompt proporciona una interfaz de usuario persistente con opciones de personalización para cierta información (por ejemplo, título y descripción), ofreciendo una experiencia de usuario consistente en todas las modalidades biométricas y en todos los dispositivos Android.

Como se muestra en el siguiente diagrama de arquitectura, las aplicaciones pueden integrarse con datos biométricos en dispositivos Android a través de la API de marco o la biblioteca de soporte (es decir, androidx.biometric para compatibilidad con versiones anteriores). Una cosa a tener en cuenta es que FingerprintManager está en desuso porque se anima a los desarrolladores a migrar a BiometricPrompt para autenticaciones independientes de la modalidad.

Mejoras en BiometricPrompt

Android 10 presentó el BiometricManager clase que los desarrolladores pueden usar para consultar la disponibilidad de autenticación biométrica e integración de autenticación de huellas dactilares y cara incluida para BiometricPrompt.

En Android 11, presentamos nuevas funciones como la BiometricManager.Authenticators interfaz que permite a los desarrolladores especificar los tipos de autenticación aceptados por sus aplicaciones, así como soporte adicional para claves de autenticación por uso dentro del BiometricPrompt clase.

Se pueden encontrar más detalles en el Vista previa de Android 11 y Biometría de Android documentación. Leer más sobre BiometricPrompt Uso de API en nuestra publicación de blog Uso de BiometricPrompt con CryptoObject: cómo y por qué y nuestro codelab Iniciar sesión con Biometrics en Android.



Enlace a la noticia original