Android protège les données utilisateur, y compris le stockage chiffré par identifiants et les clés Keystore liées à l'authentification, à l'aide de facteurs de connaissance de l'écran de verrouillage (LSKF) configurés par l'utilisateur, tels que des codes, des schémas et des 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. Le CDD 9.11 spécifie les exigences et recommandations de sécurité minimales pour les limiteurs de débit LSKF. Android 16 QPR2 et versions ultérieures mettent en œuvre des règles de limitation du débit beaucoup plus strictes que les versions Android antérieures. Pour en savoir plus, consultez la section Règle de limitation du débit par défaut plus stricte dans Android 16 QPR2 et versions ultérieures.
Android 17 et versions ultérieures utilisent une limitation du débit par défaut plus stricte pour l'écran de verrouillage que les versions antérieures. Dans de rares cas, les utilisateurs peuvent être confrontés à de longs délais d'inactivité de l'écran de verrouillage. Android 17 et versions ultérieures fournissent donc les commentaires utilisateur améliorés suivants sur l'écran de verrouillage.
- Formatage de l'heure amélioré : l'écran de verrouillage affiche les délais d'inactivité d'une minute ou plus à l'aide d'unités de temps plus grandes pour une meilleure lisibilité, par exemple Réessayez dans 30 minutes au lieu de Réessayez dans 1 800 secondes.
- Lien court de récupération : l'écran de verrouillage affiche un lien court
(par défaut, g.co/android/unlock) pour aider les utilisateurs à trouver
des options de récupération sur un autre appareil. Ce lien est configurable via la
config_lockscreenLockoutShortlinkressource. - Commentaires sur les tentatives en double : sur les appareils avec une implémentation Weaver, le système affiche un message unique lorsqu'une tentative incorrecte en double est saisie. Ces commentaires spécifiques ne sont pas disponibles sur Gatekeeper uniquement, car ils ne fournissent pas de codes de réponse distincts pour les tentatives incorrectes et les autres échecs de validation.
- Gestion cohérente de la saisie des identifiants : l'écran de verrouillage désactive le pavé de saisie du code si l'appareil utilise un identifiant de code, comme pour la saisie d'un mot de passe et d'un schéma.
La méthode LockPatternUtils#getLockoutAttemptDeadline(int) est renommée LockPatternUtils#getLockoutEndTime(int) et fournit l'heure de fin du verrouillage à partir d'un cache géré par le système. Cette mise à jour résout un problème où ils n'étaient mis en cache que par instance LockPatternUtils, ce qui affichait par erreur aucun délai d'inactivité actif si l'un d'eux était déclenché à l'aide d'une autre instance. Les développeurs d'invites d'identifiants système, telles que l'écran de verrouillage et les activités de paramètres, doivent les mettre à jour pour vérifier les délais d'inactivité existants avant d'autoriser d'autres tentatives.
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 dispose que d'un seul LSKF actif à la fois. L'attribution d'un nouveau LSKF invalide le précédent et redémarre la règle de limitation du débit depuis le début.
Un limiteur de débit principal dans le TEE ou le SE, l'un des Gatekeeper
ou Weaver, applique la limitation du débit pour
le LSKF actif. 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 débit incrémente un compteur d'échecs et applique un délai d'inactivité après un certain nombre d'échecs. Pendant un délai d'inactivité, il rejette toutes les tentatives et fournit le délai d'inactivité restant.
Règle de limitation du débit par défaut plus stricte dans Android 16 QPR2 et versions ultérieures
Le CDD 9.11 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 au cours de la première minute, 20 en 6 minutes, 50 en 25 minutes, 110 en 24 heures et 1 800 tentatives en 5 ans.
Bien que cette règle soit raisonnablement sécurisée pour les LSKF choisis de manière uniforme et aléatoire, dans la pratique, les utilisateurs ne choisissent pas les LSKF de manière uniforme et aléatoire. Certains LSKF se produisent beaucoup plus souvent que d'autres. Les pirates informatiques peuvent obtenir un taux de réussite significatif 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 réels après 100 tentatives et de 35,5% pour les schémas. Les pirates informatiques connaissant des informations spécifiques à l'utilisateur, telles que les dates d'anniversaire, peuvent obtenir des taux de réussite encore plus élevés.
Par conséquent, Android 16 QPR2 et versions ultérieures fournissent une règle de limitation du débit LSKF par défaut plus stricte. Cette règle autorise jusqu'à 6 tentatives au cours de la première minute, 7 en 6 minutes, 8 en 25 minutes, 12 en 24 heures et 19 en 5 ans. Aucune autre tentative n'est autorisée après 20 tentatives incorrectes. Le calendrier complet des délais d'inactivité est présenté dans le tableau suivant. Il est susceptible d'être modifié dans les futures versions d'Android.
| Nombre de tentatives incorrectes | Délai d'inactivité après une tentative 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 | Plus aucune tentative autorisée |
Limiteurs de débit mis à jour
Android 16 QPR2 et versions ultérieures incluent des implémentations mises à jour de Gatekeeper et Weaver 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 règle de limitation du débit plus stricte lorsque
le TEE ou le SE ne peuvent pas être mis à jour.
Configure SoftwareRateLimiter en mode d'application via la config_softwareLskfRateLimiterEnforcing
valeur de configuration. 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'inactivité est le plus long entre celui requis par le limiteur de débit principal et celui requis par SoftwareRateLimiter.
En mode de non-application, SoftwareRateLimiter transmet toutes les requêtes de validation au limiteur de débit principal sans appliquer de règle de limitation du débit secondaire.
Détection des tentatives en double
Pour améliorer la convivialité et permettre l'utilisation d'une règle de limitation du débit plus stricte, Android 16 QPR2 et versions ultérieures prennent en charge la détection des tentatives en double. Lorsque cette option est activée, les utilisateurs ne sont pas pénalisés s'ils saisissent plusieurs fois le même LSKF incorrect.
Les utilisateurs légitimes saisissent parfois plusieurs fois le même LSKF incorrect. Cela entraîne des délais d'inactivité inutiles si ces tentatives sont comptabilisées comme plusieurs tentatives. Les pirates informatiques compétents ne tentent pas un LSKF donné plus d'une fois. Une règle qui ne comptabilise pas les tentatives en double améliore la convivialité de la saisie des 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'inactivité, car ils doivent saisir cinq tentatives incorrectes uniques au lieu de cinq tentatives incorrectes, y compris les doublons.
Sur les appareils équipés d'Android 16 QPR2 et versions ultérieures, d'une implémentation Weaver et de SoftwareRateLimiter configuré en mode d'application, les tentatives en double sont détectées et rejetées avant d'être transmises à Weaver. Ces rejets n'augmentent pas le nombre de tentatives incorrectes. Jusqu'à cinq tentatives incorrectes uniques sont suivies en mémoire. Si le suivi est complet, le plus ancien est supprimé pour libérer de l'espace. Toutes les tentatives suivies sont supprimées cinq minutes après la dernière tentative incorrecte non suivie.
Gatekeeper ne sépare pas les tentatives incorrectes des autres échecs de validation. Par conséquent, SoftwareRateLimiter ne prend pas en charge la détection des tentatives en double lorsque Gatekeeper est le limiteur de débit principal.
Les implémenteurs Weaver peuvent choisir de prendre en charge la détection des tentatives en double dans l'implémentation Weaver.