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 PIN de 4 o 6 dígitos, por lo que se requiere protección contra ataques de fuerza bruta.
Android usa limitadores de velocidad del entorno de ejecución confiable (TEE) o del elemento seguro (SE) para ralentizar y, con suficientes intentos, bloquear a los atacantes que realizan ataques de fuerza bruta en las LSKF. El CDD 9.11 especifica los requisitos y las recomendaciones de seguridad mínimos para los limitadores de velocidad de LSKF. Android 16 QPR2 y versiones posteriores implementan políticas de limitación de velocidad significativamente más sólidas que las versiones anteriores de Android. Para obtener más detalles, consulta Política de límite de frecuencia predeterminada más sólida en Android 16 QPR2 y versiones posteriores.
Android 17 y versiones posteriores usan una limitación de velocidad predeterminada de la pantalla de bloqueo más sólida que las versiones anteriores. En casos excepcionales, los usuarios pueden experimentar tiempos de espera largos 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 los 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 corto de recuperación: La pantalla de bloqueo muestra un vínculo corto (g.co/android/unlock de forma predeterminada) para ayudar a los usuarios a encontrar opciones de recuperación en otro dispositivo. Este vínculo se puede configurar a través del recurso
config_lockscreenLockoutShortlink. - 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 los dispositivos solo para Gatekeeper, ya que no proporcionan códigos de respuesta separados para las suposiciones incorrectas y otros errores 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 un tiempo de espera activo si se activaba uno con otra instancia. Los desarrolladores de mensajes del sistema para ingresar credenciales, como las actividades de la pantalla de bloqueo y la 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 las LSKF. Un usuario solo puede tener una LSKF activa a la vez. Asignar una nueva LSKF invalida la anterior y reinicia la política de limitación de frecuencia.
Un limitador de velocidad principal en el TEE o SE, ya sea Gatekeeper o Weaver, aplica la limitación de velocidad 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 velocidad principal. Si la LSKF es incorrecta, el limitador de velocidad incrementa un contador de errores y aplica un tiempo de espera después de cierta cantidad de errores. Durante un tiempo de espera, rechaza todas las suposiciones y proporciona el tiempo de espera restante.
Política de límite de frecuencia predeterminada más sólida en Android 16 QPR2 y versiones posteriores
La sección 9.11 del CDD requiere la limitación de velocidad 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 intentos en el primer minuto, 20 en 6 minutos, 50 en 25 minutos, 110 en 24 horas y 1, 800 intentos en 5 años.
Si bien esta política es razonablemente segura para las LSKF elegidas de forma uniforme y aleatoria, en la práctica, los usuarios no eligen las LSKF de forma uniforme y aleatoria. Algunos LSKF ocurren con mucha más frecuencia que otros. Los atacantes pueden lograr un índice de éxito significativo si prueban las LSKF en orden de frecuencia decreciente.
Por ejemplo, el estudio This PIN Can Be Easily Guessed (Se puede adivinar fácilmente este PIN) reveló una tasa de éxito del 16.2% para adivinar los PIN del mundo real después de 100 intentos y del 35.5% para los patrones. Los atacantes que conocen información específica del usuario, como su fecha de nacimiento, pueden alcanzar 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 predeterminada más sólida para el LSKF. Esta política permite hasta 6 intentos 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 intentos después de 20 intentos incorrectos. En la siguiente tabla, se muestra el programa de tiempo de espera completo. Está sujeto a cambios en futuras versiones de Android.
| Recuento de suposiciones incorrectas | Tiempo de espera después de una respuesta 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 | 36 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 intentos |
Se actualizaron los limitadores de frecuencia
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 velocidad secundario opcional, SoftwareRateLimiter., que se implementa en el servidor del sistema y permite que los dispositivos ofrezcan una política de limitación de velocidad más sólida cuando no se pueden actualizar el TEE o el SE.
Configura SoftwareRateLimiter en modo de aplicación a través del valor de configuración config_softwareLskfRateLimiterEnforcing. 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 intentos incorrectos, el tiempo de espera es el más largo entre el que requiere el limitador de velocidad principal y el que requiere SoftwareRateLimiter.
En el modo sin aplicación forzosa, SoftwareRateLimiter pasa todas las solicitudes de verificación al limitador de frecuencia principal sin aplicar una política secundaria de limitación de frecuencia.
Detección de duplicados de conjeturas
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 intentos duplicados. Cuando está habilitada, los usuarios no reciben penalizaciones 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 varios intentos. Los atacantes capaces no intentan una LSKF determinada más de una vez. Una política que no cuenta los intentos duplicados mejora la usabilidad de la entrada de LSKF para los usuarios legítimos sin facilitarles a los atacantes capaces adivinar las LSKF, lo que permite aplicar políticas de limitación de frecuencia más sólidas. Es menos probable que los usuarios legítimos se encuentren con un tiempo de espera, ya que deben ingresar 5 intentos incorrectos únicos en lugar de 5 intentos incorrectos, 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, se detectan y rechazan las suposiciones duplicadas antes de pasarlas a Weaver. Estos rechazos no aumentan el recuento de intentos incorrectos. Se hace un seguimiento de hasta 5 intentos incorrectos únicos en la memoria. Si el registro está lleno, se descarta el más antiguo para dejar espacio. Todas las suposiciones registradas se descartan 5 minutos después de que se realiza la última suposición incorrecta no registrada.
Gatekeeper no separa las suposiciones incorrectas de otros errores de verificación, por lo que SoftwareRateLimiter no admite la detección de suposiciones duplicadas cuando Gatekeeper es el limitador de velocidad principal.
Los implementadores de Weaver pueden optar por admitir la detección de duplicados en la implementación de Weaver.