Android protege los datos del usuario, incluido el almacenamiento encriptado con credenciales y las claves de Keystore vinculadas a la autenticación, con factores de conocimiento de la pantalla de bloqueo (LSKF) configurados por el usuario, como PINs, patrones y contraseñas. Por lo general, los LSKF son valores de baja entropía, como PINs de 4 o 6 dígitos, por lo que se requiere protección contra ataques de fuerza bruta.
Android usa limitadores de frecuencia del entorno de ejecución confiable (TEE) o del elemento seguro (SE) para ralentizar y, si se realizan suficientes intentos, bloquear a los atacantes que realizan ataques de fuerza bruta en los LSKF. El CDD 9.11 especifica los requisitos y las recomendaciones de seguridad mínimos para los limitadores de frecuencia de LSKF. Android 16 QPR2 y versiones posteriores implementan políticas de limitación de frecuencia significativamente más sólidas que las versiones anteriores de Android. Para obtener más detalles, consulta Política de limitación de frecuencia predeterminada más sólida en Android 16 QPR2 y versiones posteriores.
Android 17 y versiones posteriores usan una limitación de frecuencia de pantalla de bloqueo predeterminada más sólida que las versiones anteriores. En casos excepcionales, los usuarios pueden experimentar tiempos de espera prolongados en la pantalla de bloqueo, por lo que Android 17 y versiones posteriores proporcionan los siguientes comentarios mejorados del usuario en la pantalla de bloqueo.
- Formato de hora mejorado: La pantalla de bloqueo muestra tiempos de espera de un minuto o más con unidades de tiempo más grandes para mejorar la legibilidad, como Vuelve a intentarlo en 30 minutos en lugar de Vuelve a intentarlo en 1,800 segundos.
- Vínculo directo de recuperación: La pantalla de bloqueo muestra un vínculo directo
(que, de forma predeterminada, es g.co/android/unlock) para ayudar a los usuarios a encontrar
opciones de recuperación en otro dispositivo. Este vínculo se puede configurar a través del
config_lockscreenLockoutShortlinkrecurso. - Comentarios sobre intentos duplicados: En dispositivos con una implementación de Weaver, el sistema muestra un mensaje único cuando se ingresa una suposición incorrecta duplicada. Estos comentarios específicos no están disponibles en Gatekeeper dispositivos, ya que no proporcionan códigos de respuesta separados para suposiciones incorrectas y otras fallas de verificación.
- Administración coherente de la entrada de credenciales: La pantalla de bloqueo inhabilita el teclado de entrada de PIN si el dispositivo usa una credencial de PIN, de manera similar a la entrada de credenciales de contraseña y patrón.
Se cambió el nombre del método LockPatternUtils#getLockoutAttemptDeadline(int) a LockPatternUtils#getLockoutEndTime(int) y proporciona la hora de finalización del bloqueo desde una caché administrada por el sistema. Esta actualización resuelve un problema por el que se almacenaban en caché solo por instancia de LockPatternUtils, lo que mostraba erróneamente que no había tiempo de espera activo si se activaba con otra instancia. Los desarrolladores de mensajes de credenciales del sistema, como la pantalla de bloqueo y las actividades de configuración, deben actualizarlos para verificar los tiempos de espera existentes antes de permitir más intentos.
Desbloquea los datos protegidos del usuario con LSKF
LockSettingsService
administra el almacenamiento y la verificación de LSKF. Un usuario solo tiene un LSKF activo a la vez. Si se asigna un LSKF nuevo, se invalida el anterior y se inicia la política de limitación de frecuencia desde el principio.
Un limitador de frecuencia principal en el TEE o SE, uno de Gatekeeper
o Weaver, aplica la limitación de frecuencia para
el LSKF activo. LockSettingsService prefiere Weaver cuando hay una implementación disponible.
Los datos protegidos del usuario solo se desbloquean cuando se proporciona el LSKF correcto al limitador de frecuencia principal. Si el LSKF es incorrecto, el limitador de frecuencia incrementa un contador de fallas y aplica un tiempo de espera después de ciertos recuentos de fallas. Durante un tiempo de espera, rechaza todas las suposiciones y proporciona el tiempo de espera restante.
Política de limitación de frecuencia predeterminada más sólida en Android 16 QPR2 y versiones posteriores
El CDD 9.11 requiere la limitación de frecuencia de LSKF en Android 6 y versiones posteriores. Históricamente, la política de limitación de frecuencia requerida ha sido bastante flexible. Por ejemplo, una implementación que cumple con los requisitos mínimos de Android 16 permite hasta 10 suposiciones en el primer minuto, 20 en 6 minutos, 50 en 25 minutos, 110 en 24 horas y 1, 800 suposiciones en 5 años.
Si bien esta política es razonablemente segura para los LSKF elegidos de forma uniforme y aleatoria, en la práctica, los usuarios no eligen LSKF de forma uniforme y aleatoria. Algunos LSKF ocurren con mucha más frecuencia que otros. Los atacantes pueden lograr una tasa de éxito significativa si prueban los LSKF en orden de frecuencia decreciente.
Por ejemplo, el estudio This PIN Can Be Easily Guessed encontró una tasa de éxito del 16.2% para adivinar PINs del mundo real después de 100 suposiciones y del 35.5% para patrones. Los atacantes que conocen información específica del usuario, como cumpleaños, pueden lograr tasas de éxito aún más altas.
Por lo tanto, Android 16 QPR2 y versiones posteriores proporcionan una política de limitación de frecuencia de LSKF predeterminada más sólida. Esta política permite hasta 6 suposiciones en el primer minuto, 7 en 6 minutos, 8 en 25 minutos, 12 en 24 horas y 19 en 5 años. No se permiten más suposiciones después de 20 suposiciones incorrectas. En la siguiente tabla, se muestra el cronograma completo de tiempo de espera. Está sujeto a cambios en versiones futuras de Android.
| Cantidad de suposiciones incorrectas | Tiempo de espera después de una suposición incorrecta |
|---|---|
| 0 | No aplicable |
| 1 a 4 | 0 segundos |
| 5 | 1 minuto |
| 6 | 5 minutos |
| 7 | 15 minutos |
| 8 | 30 minutos |
| 9 | 90 minutos |
| 10 | 4 horas |
| 11 | 12 horas |
| 12 | 24 horas |
| 13 | 4 días |
| 14 | 13 días |
| 15 | 41 días |
| 16 | 123 días |
| 17 | 1 año |
| 18 | 3 años |
| 19 | 9 años |
| Más de 20 | No se permiten más suposiciones |
Limitadores de frecuencia actualizados
Android 16 QPR2 y versiones posteriores incluyen implementaciones actualizadas de Gatekeeper y Weaver que aplican la política de limitación de frecuencia en la tabla.
Limitador de frecuencia de software
Android 16 QPR2 y versiones posteriores incluyen un limitador de frecuencia secundario opcional, SoftwareRateLimiter.
Se implementa en el servidor del sistema y permite que los dispositivos ofrezcan una política de limitación de frecuencia más sólida cuando
no se puede actualizar el TEE o el SE.
Configura SoftwareRateLimiter en modo de aplicación a través del config_softwareLskfRateLimiterEnforcing
valor de configuración. En el modo de aplicación, SoftwareRateLimiter aplica su política de limitación de frecuencia de forma simultánea con el limitador de frecuencia principal. Para una cantidad determinada de suposiciones incorrectas, el tiempo de espera es el más largo entre el que requiere el limitador de frecuencia principal y el que requiere SoftwareRateLimiter.
En el modo no de aplicación, SoftwareRateLimiter pasa todas las solicitudes de verificación al limitador de frecuencia principal sin aplicar una política de limitación de frecuencia secundaria.
Detección de suposiciones duplicadas
Para mejorar la usabilidad y permitir el uso de una política de limitación de frecuencia más sólida, Android 16 QPR2 y versiones posteriores admiten la detección de suposiciones duplicadas. Cuando está habilitada, los usuarios no son penalizados por ingresar el mismo LSKF incorrecto varias veces.
A veces, los usuarios legítimos ingresan varias veces el mismo LSKF incorrecto. Esto genera tiempos de espera innecesarios si se cuentan como varias suposiciones. Los atacantes capaces no intentan un LSKF determinado más de una vez. Una política que no cuenta las suposiciones duplicadas mejora la usabilidad de la entrada de LSKF para los usuarios legítimos sin que sea más fácil para los atacantes capaces adivinar los LSKF, lo que permite aplicar políticas de limitación de frecuencia más sólidas. Es menos probable que los usuarios legítimos incluso se encuentren con un tiempo de espera, ya que el usuario debe ingresar 5 suposiciones incorrectas únicas en lugar de 5 suposiciones incorrectas, incluidos los duplicados.
En dispositivos con Android 16 QPR2 y versiones posteriores, una implementación de Weaver y SoftwareRateLimiter configurado en modo de aplicación, las suposiciones duplicadas se detectan y rechazan antes de pasarlas a Weaver. Estos rechazos no aumentan el recuento de suposiciones incorrectas. Se realiza un seguimiento de hasta 5 suposiciones incorrectas únicas en la memoria. Si el rastreador está lleno, se descarta el más reciente para dejar espacio. Todas las suposiciones rastreadas se descartan 5 minutos después de que se realiza la última suposición incorrecta no rastreada.
Gatekeeper no separa las suposiciones incorrectas de otras fallas de verificación, por lo que SoftwareRateLimiter no admite la detección de suposiciones duplicadas cuando Gatekeeper es el limitador de frecuencia principal.
Los implementadores de Weaver pueden optar por admitir la detección de suposiciones duplicadas en la implementación de Weaver.