Android schützt Nutzerdaten, einschließlich verschlüsselter Speicher mit Anmeldedaten und Authentifizierungs-gebundene Keystore Schlüssel mit vom Nutzer konfigurierten Sperrbildschirm-Wissensfaktoren (LSKFs) wie PINs, Mustern und Passwörtern. LSKFs sind in der Regel Werte mit geringer Entropie wie 4- oder 6-stellige PINs. Daher ist ein Schutz vor Brute-Force-Angriffen erforderlich.
Android verwendet Ratenbegrenzer für die vertrauenswürdige Ausführungsumgebung (Trusted Execution Environment, TEE) oder das sichere Element (Secure Element, SE), um Brute-Force-Angriffe auf LSKFs zu verlangsamen und bei genügend Versuchen zu blockieren. In CDD 9.11 sind die Mindestsicherheitsanforderungen und ‑empfehlungen für LSKF-Ratenbegrenzer festgelegt. In Android 16 QPR2 und höher werden deutlich strengere Richtlinien zur Ratenbegrenzung als in niedrigeren Android-Versionen implementiert. Weitere Informationen finden Sie unter Strengere Standardrichtlinie zur Ratenbegrenzung in Android 16 QPR2 und höher.
In Android 17 und höher wird eine strengere Standardrichtlinie zur Ratenbegrenzung für den Sperrbildschirm als in niedrigeren Versionen verwendet. In seltenen Fällen kann es zu langen Zeitüberschreitungen auf dem Sperrbildschirm kommen. Daher bietet Android 17 und höher das folgende verbesserte Nutzerfeedback auf dem Sperrbildschirm.
- Verbesserte Zeitformatierung: Auf dem Sperrbildschirm werden Zeitüberschreitungen von einer Minute oder länger mit größeren Zeiteinheiten angezeigt, um die Lesbarkeit zu verbessern, z. B. In 30 Minuten noch einmal versuchen anstelle von In 1800 Sekunden noch einmal versuchen.
- Kurzlink zur Wiederherstellung: Auf dem Sperrbildschirm wird ein Kurzlink
angezeigt (standardmäßig g.co/android/unlock), damit Nutzer
Wiederherstellungsoptionen auf einem anderen Gerät finden können. Dieser Link kann über die
config_lockscreenLockoutShortlinkRessource konfiguriert werden. - Feedback zu doppelten Versuchen:Auf Geräten mit einer Weaver-Implementierung wird eine eindeutige Meldung angezeigt, wenn eine doppelte falsche Vermutung eingegeben wird. Dieses spezifische Feedback ist auf Gatekeeper-Geräten, die nur Gatekeeper verwenden, nicht verfügbar, da sie keine separaten Antwortcodes für falsche Vermutungen und andere Überprüfungsfehler bereitstellen.
- Konsistente Verwaltung der Anmeldedateneingabe: Auf dem Sperrbildschirm wird das PIN-Eingabefeld deaktiviert, wenn das Gerät eine PIN-Anmeldedaten verwendet, ähnlich wie bei der Eingabe von Passwort- und Muster-Anmeldedaten.
Die Methode LockPatternUtils#getLockoutAttemptDeadline(int) wurde in LockPatternUtils#getLockoutEndTime(int) umbenannt und gibt die Endzeit der Sperrung aus einem vom System verwalteten Cache zurück. Mit diesem Update wird ein Problem behoben, bei dem die Endzeit nur pro LockPatternUtils-Instanz im Cache gespeichert wurde. Dadurch wurde fälschlicherweise keine aktive Zeitüberschreitung angezeigt, wenn sie mit einer anderen Instanz ausgelöst wurde. Entwickler von Systemanmeldedatenaufforderungen wie dem Sperrbildschirm und den Einstellungen müssen diese aktualisieren, um vorhandene Zeitüberschreitungen zu überprüfen, bevor weitere Versuche zugelassen werden.
Geschützte Nutzerdaten mit LSKFs entsperren
LockSettingsService
verwaltet das Speichern und Überprüfen von LSKFs. Ein Nutzer hat jeweils nur einen aktiven LSKF. Wenn ein neuer LSKF zugewiesen wird, wird der vorherige ungültig und die Richtlinie zur Ratenbegrenzung beginnt von vorn.
Ein primärer Ratenbegrenzer in der TEE oder SE, entweder Gatekeeper
oder Weaver, erzwingt die Ratenbegrenzung für
den aktiven LSKF. LockSettingsService bevorzugt Weaver, wenn eine Implementierung verfügbar ist.
Geschützte Nutzerdaten werden nur entsperrt, wenn der korrekte LSKF an den primären Ratenbegrenzer übergeben wird. Wenn der LSKF falsch ist, erhöht der Ratenbegrenzer einen Fehlerzähler und erzwingt nach einer bestimmten Anzahl von Fehlern eine Zeitüberschreitung. Während einer Zeitüberschreitung werden alle Vermutungen abgelehnt und die verbleibende Zeitüberschreitung wird angegeben.
Strengere Standardrichtlinie zur Ratenbegrenzung in Android 16 QPR2 und höher
Gemäß CDD 9.11 ist in Android 6 und höher eine Ratenbegrenzung für LSKFs erforderlich. Bisher war die erforderliche Richtlinie zur Ratenbegrenzung relativ großzügig. Eine Implementierung, die die Mindestanforderungen von Android 16 erfüllt, lässt beispielsweise bis zu 10 Vermutungen in der ersten Minute, 20 in 6 Minuten, 50 in 25 Minuten, 110 in 24 Stunden und 1.800 Vermutungen in 5 Jahren zu.
Diese Richtlinie ist zwar für LSKFs, die zufällig ausgewählt werden, relativ sicher, in der Praxis wählen Nutzer LSKFs jedoch nicht zufällig aus. Einige LSKFs kommen viel häufiger vor als andere. Angreifer können eine hohe Erfolgsrate erzielen, indem sie LSKFs in absteigender Reihenfolge ihrer Häufigkeit ausprobieren.
In der Studie This PIN Can Be Easily Guessed wurde beispielsweise eine Erfolgsrate von 16,2% für das Erraten von PINs in der Praxis nach 100 Versuchen und 35,5% für Muster ermittelt. Angreifer, die nutzerspezifische Informationen wie Geburtstage kennen, können noch höhere Erfolgsraten erzielen.
Daher bietet Android 16 QPR2 und höher eine strengere Standardrichtlinie zur Ratenbegrenzung für LSKFs. Diese Richtlinie lässt bis zu 6 Vermutungen in der ersten Minute, 7 in 6 Minuten, 8 in 25 Minuten, 12 in 24 Stunden und 19 in 5 Jahren zu. Nach 20 falschen Vermutungen sind keine weiteren Versuche zulässig. Der vollständige Zeitplan für die Zeitüberschreitung ist in der folgenden Tabelle aufgeführt. Er kann sich in zukünftigen Android-Versionen ändern.
| Anzahl der falschen Vermutungen | Zeitüberschreitung nach falscher Vermutung |
|---|---|
| 0 | Nicht zutreffend |
| 1-4 | 0 Sekunden |
| 5 | 1 Minute |
| 6 | 5 Minuten |
| 7 | 15 Minuten |
| 8 | 30 Minuten |
| 9 | 90 Minuten |
| 10 | 4 Stunden |
| 11 | 12 Stunden |
| 12 | 36 Stunden |
| 13 | 4 Tage |
| 14 | 13 Tage |
| 15 | 41 Tage |
| 16 | 123 Tage |
| 17 | 1 Jahr |
| 18 | 3 Jahre |
| 19 | 9 Jahre |
| 20+ | Keine weiteren Versuche zulässig |
Aktualisierte Ratenbegrenzer
Android 16 QPR2 und höher enthält aktualisierte Gatekeeper und Weaver-Implementierungen, die die Richtlinie zur Ratenbegrenzung in der Tabelle erzwingen.
Software-Ratenbegrenzer
Android 16 QPR2 und höher enthält einen optionalen sekundären Ratenbegrenzer, SoftwareRateLimiter.
Er wird auf dem Systemserver implementiert und ermöglicht es Geräten, eine strengere Richtlinie zur Ratenbegrenzung anzubieten, wenn
die TEE oder SE nicht aktualisiert werden kann.
Konfigurieren Sie SoftwareRateLimiter im Erzwingungsmodus über den config_softwareLskfRateLimiterEnforcing
Konfigurationswert. Im Erzwingungsmodus wendet SoftwareRateLimiter seine Richtlinie zur Ratenbegrenzung gleichzeitig mit dem primären Ratenbegrenzer an. Bei einer bestimmten Anzahl falscher Vermutungen ist die Zeitüberschreitung die längere der beiden Zeitüberschreitungen, die vom primären Ratenbegrenzer und von SoftwareRateLimiter erforderlich sind.
Im Nicht-Erzwingungsmodus übergibt SoftwareRateLimiter alle Überprüfungsanfragen an den primären Ratenbegrenzer, ohne eine sekundäre Richtlinie zur Ratenbegrenzung anzuwenden.
Erkennung doppelter Vermutungen
Um die Nutzerfreundlichkeit zu verbessern und die Verwendung einer strengeren Richtlinie zur Ratenbegrenzung zu ermöglichen, unterstützt Android 16 QPR2 und höher die Erkennung doppelter Vermutungen. Wenn diese Funktion aktiviert ist, werden Nutzer nicht dafür bestraft, dass sie denselben falschen LSKF mehrmals eingeben.
Legitime Nutzer geben manchmal denselben falschen LSKF mehrmals ein. Wenn dies als mehrere Vermutungen gezählt wird, führt das zu unnötigen Zeitüberschreitungen. Fähige Angreifer versuchen einen bestimmten LSKF nicht mehr als einmal. Eine Richtlinie, bei der doppelte Vermutungen nicht gezählt werden, verbessert die Nutzerfreundlichkeit bei der Eingabe von LSKFs für legitime Nutzer, ohne es fähigen Angreifern zu erleichtern, die LSKFs zu erraten. So können strengere Richtlinien zur Ratenbegrenzung erzwungen werden. Legitime Nutzer werden seltener auf eine Zeitüberschreitung stoßen, da sie 5 eindeutige falsche Vermutungen eingeben müssen, anstatt 5 falsche Vermutungen einschließlich Duplikaten.
Auf Geräten mit Android 16 QPR2 und höher, einer Weaver-Implementierung und SoftwareRateLimiter, der im Erzwingungsmodus konfiguriert ist, werden doppelte Vermutungen erkannt und abgelehnt, bevor sie an Weaver übergeben werden. Solche Ablehnungen erhöhen die Anzahl der falschen Vermutungen nicht. Bis zu 5 eindeutige falsche Vermutungen werden im Arbeitsspeicher erfasst. Wenn der Tracker voll ist, wird die älteste Vermutung verworfen, um Platz zu schaffen. Alle erfassten Vermutungen werden 5 Minuten nach der letzten nicht erfassten falschen Vermutung verworfen.
Gatekeeper unterscheidet nicht zwischen falschen Vermutungen und anderen Überprüfungsfehlern. Daher unterstützt SoftwareRateLimiter die Erkennung doppelter Vermutungen nicht, wenn Gatekeeper der primäre Ratenbegrenzer ist.
Implementierer von Weaver können die Erkennung doppelter Vermutungen in der Weaver-Implementierung unterstützen.