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 los 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.
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 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 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 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 incorrectos. El programa de tiempo de espera completo se muestra en la siguiente tabla. Está sujeto a cambios en versiones futuras 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 puede 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 de no 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 la misma LSKF incorrecta. 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 las suposiciones duplicadas 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 límite 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. En la memoria, se hace un seguimiento de hasta 5 intentos incorrectos únicos. Si el registro está lleno, se descarta el menos reciente para liberar 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.