Android protège les données utilisateur, y compris le stockage chiffré par identifiants et les clés Keystore liées à l'authentification, avec des facteurs de connaissance de l'écran de verrouillage (LSKF) configurés par l'utilisateur, tels que les codes, les schémas et les mots de passe. Les LSKF sont généralement des valeurs à faible entropie, telles que des codes à quatre ou six chiffres. Il est donc nécessaire de se protéger contre les attaques par force brute.
Android utilise des limiteurs de débit d'environnement d'exécution sécurisé (TEE) ou d'élément sécurisé (SE) pour ralentir et, après un nombre suffisant de tentatives, bloquer les pirates informatiques qui effectuent des attaques par force brute sur les LSKF. La section 9.11 du CDD spécifie les exigences et recommandations de sécurité minimales pour les limiteurs de débit LSKF. Android 16 QPR2 et les versions ultérieures implémentent des règles de limitation du débit beaucoup plus strictes que les versions antérieures d'Android. Pour en savoir plus, consultez Politique de limitation du débit par défaut renforcée dans Android 16 QPR2 et versions ultérieures.
Déverrouiller les données utilisateur protégées avec des LSKF
LockSettingsService gère le stockage et la validation des LSKF. Un utilisateur ne peut avoir qu'une seule clé LSKF active à la fois. L'attribution d'une nouvelle clé LSKF invalide la précédente et relance la règle de limitation du débit depuis le début.
Un limiteur de débit principal dans le TEE ou SE, Gatekeeper ou Weaver,applique une limitation du débit pour la clé LSKF active. LockSettingsService préfère Weaver lorsqu'une implémentation est disponible.
Les données utilisateur protégées ne sont déverrouillées que lorsque le LSKF correct est fourni au limiteur de débit principal. Si le LSKF est incorrect, le limiteur de fréquence incrémente un compteur d'échecs et applique un délai d'expiration après un certain nombre d'échecs. En cas de délai avant expiration, il refuse toutes les suggestions et indique le délai avant expiration restant.
Règle de limitation du débit par défaut plus stricte dans Android 16 QPR2 et versions ultérieures
La section 9.11 du CDD exige une limitation du débit LSKF dans Android 6 et versions ultérieures. Historiquement, la règle de limitation du débit requise était assez souple. Par exemple, une implémentation répondant aux exigences minimales d'Android 16 autorise jusqu'à 10 tentatives en une minute, 20 en six minutes, 50 en 25 minutes, 110 en 24 heures et 1 800 tentatives en cinq ans.
Bien que cette règle soit raisonnablement sécurisée pour les LSKF choisis de manière aléatoire et uniforme, en pratique, les utilisateurs ne choisissent pas les LSKF de manière aléatoire et uniforme. Certains LSKF se produisent beaucoup plus souvent que d'autres. Les pirates informatiques peuvent obtenir un taux de réussite important en essayant les LSKF par ordre de fréquence décroissante.
Par exemple, l'étude This PIN Can Be Easily Guessed a révélé un taux de réussite de 16,2% pour deviner les codes secrets réels après 100 tentatives et de 35,5% pour les schémas. Les pirates informatiques qui connaissent des informations spécifiques aux utilisateurs, comme leur date de naissance, peuvent obtenir des taux de réussite encore plus élevés.
Par conséquent, Android 16 QPR2 et versions ultérieures fournissent une stratégie de limitation du débit LSKF par défaut plus efficace. Cette règle autorise jusqu'à six tentatives au cours de la première minute, sept en six minutes, huit en 25 minutes, 12 en 24 heures et 19 en cinq ans. Aucune autre tentative n'est autorisée après 20 tentatives incorrectes. Le calendrier complet des délais d'inactivité est indiqué dans le tableau suivant. Elle est susceptible d'évoluer dans les futures versions d'Android.
| Nombre de devinettes incorrectes | Délai d'inactivité après une réponse incorrecte |
|---|---|
| 0 | Non applicable |
| 1-4 | 0 seconde |
| 5 | 1 minute |
| 6 | 5 minutes |
| 7 | 15 minutes |
| 8 | 30 minutes |
| 9 | 90 minutes |
| 10 | 4 heures |
| 11 | 12 heures |
| 12 | 36 heures |
| 13 | 4 jours |
| 14 | 13 jours |
| 15 | 41 jours |
| 16 | 123 jours |
| 17 | 1 an |
| 18 | 3 ans |
| 19 | 9 ans |
| Plus de 20 | Aucune autre prédiction autorisée |
Limiteurs de débit mis à jour
Android 16 QPR2 et versions ultérieures incluent des implémentations Gatekeeper et Weaver mises à jour qui appliquent la règle de limitation du débit dans le tableau.
Limiteur de débit logiciel
Android 16 QPR2 et versions ultérieures incluent un limiteur de débit secondaire facultatif, SoftwareRateLimiter.. Il est implémenté dans le serveur système et permet aux appareils d'offrir une stratégie de limitation de débit plus stricte lorsque le TEE ou l'élément sécurisé ne peuvent pas être mis à jour.
Configurez SoftwareRateLimiter en mode d'application à l'aide de la valeur de configuration config_softwareLskfRateLimiterEnforcing. En mode d'application, SoftwareRateLimiter applique sa règle de limitation du débit en même temps que le limiteur de débit principal. Pour un nombre donné de tentatives incorrectes, le délai d'expiration correspond à la durée la plus longue entre celle requise par le limiteur de débit principal et celle requise par SoftwareRateLimiter.
En mode non appliqué, SoftwareRateLimiter transmet toutes les demandes de validation au limiteur de débit principal sans appliquer de règle de limitation de débit secondaire.
Détection des doublons de suppositions
Pour améliorer la facilité d'utilisation et permettre l'utilisation d'une règle de limitation du débit plus stricte, Android 16 QPR2 et les versions ultérieures prennent en charge la détection des devinettes en double. Lorsqu'elle est activée, les utilisateurs ne sont pas pénalisés s'ils saisissent plusieurs fois le même code LSKF incorrect.
Il arrive que des utilisateurs légitimes saisissent plusieurs fois de suite le même code LSKF incorrect. Cela entraîne des délais d'attente inutiles si les tentatives sont comptabilisées comme plusieurs devinettes. Les pirates informatiques compétents ne tentent pas d'utiliser un LSKF donné plus d'une fois. Une règle qui ne comptabilise pas les tentatives en double améliore l'usabilité des entrées LSKF pour les utilisateurs légitimes sans faciliter la tâche des pirates informatiques compétents pour deviner les LSKF, ce qui permet d'appliquer des règles de limitation du débit plus strictes. Les utilisateurs légitimes sont moins susceptibles de rencontrer un délai d'attente, car ils doivent saisir cinq réponses incorrectes uniques au lieu de cinq réponses incorrectes, y compris les doublons.
Sur les appareils équipés d'Android 16 QPR2 ou version ultérieure, d'une implémentation Weaver et de SoftwareRateLimiter configuré en mode d'application, les doublons de tentatives de saisie sont détectés et refusés avant d'être transmis à Weaver. Ces refus n'augmentent pas le nombre de réponses incorrectes. Jusqu'à cinq devinettes incorrectes uniques sont enregistrées en mémoire. Si le tracker est plein, le plus ancien est supprimé pour faire de la place. Toutes les tentatives suivies sont supprimées cinq minutes après la dernière tentative incorrecte non suivie.
Gatekeeper ne fait pas la distinction entre les mauvaises réponses et les autres échecs de validation. Par conséquent, SoftwareRateLimiter ne prend pas en charge la détection des réponses en double lorsque Gatekeeper est le principal limiteur de débit.
Les implémenteurs Weaver peuvent choisir de prendre en charge la détection des devinettes en double dans l'implémentation Weaver.