Ratenbegrenzung

Android schützt Nutzerdaten, einschließlich mit Anmeldedaten verschlüsselter Speicher und authentifizierungsgebundener Keystore-Schlüssel, mit vom Nutzer konfigurierten LSKFs (Lockscreen Knowledge Factors) wie PINs, Mustern und Passwörtern. LSKFs sind in der Regel Werte mit niedriger 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 nach einer bestimmten Anzahl von Versuchen zu blockieren. CDD 9.11 enthält die Mindestsicherheitsanforderungen und Empfehlungen für LSKF-Ratenbegrenzer. In Android 16 QPR2 und höher werden deutlich strengere Ratenbegrenzungsrichtlinien als in niedrigeren Android-Versionen implementiert. Weitere Informationen finden Sie unter Stärkere Standardrichtlinie zur Ratenbegrenzung in Android 16 QPR2 und höher.

Geschützte Nutzerdaten mit LSKFs entsperren

LockSettingsService verwaltet das Speichern und Überprüfen von LSKFs. Ein Nutzer kann jeweils nur einen aktiven LSKF haben. Durch Zuweisen eines neuen LSKF wird der vorherige ungültig und die Ratenbegrenzungsrichtlinie beginnt von vorn.

Ein primärer Ratenbegrenzer im 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 dem primären Ratenbegrenzer der richtige LSKF bereitgestellt wird. Wenn der LSKF falsch ist, erhöht der Ratenbegrenzer einen Fehlerzähler und erzwingt nach einer bestimmten Anzahl von Fehlern ein Zeitlimit. Während eines Timeouts werden alle Vermutungen abgelehnt und das verbleibende Timeout wird angegeben.

Stärkere Standardrichtlinie für die Ratenbegrenzung in Android 16 QPR2 und höher

CDD 9.11 erfordert die Ratenbegrenzung von LSKF in Android 6 und höher. Bisher war die erforderliche Ratenbegrenzungsrichtlinie relativ kulant. Bei einer Implementierung, die die Mindestanforderungen von Android 16 erfüllt, sind beispielsweise in der ersten Minute bis zu 10 Versuche, in 6 Minuten 20 Versuche, in 25 Minuten 50 Versuche, in 24 Stunden 110 Versuche und in 5 Jahren 1.800 Versuche möglich.

Diese Richtlinie ist für LSKFs, die gleichmäßig zufällig ausgewählt werden, relativ sicher. In der Praxis wählen Nutzer LSKFs jedoch nicht gleichmäßig 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 der Häufigkeit ausprobieren.

In der Studie This PIN Can Be Easily Guessed (Diese PIN kann leicht erraten werden) wurde beispielsweise eine Erfolgsrate von 16,2% beim Erraten von realen PINs nach 100 Versuchen und 35,5% beim Erraten von Mustern ermittelt. Wenn Angreifer nutzerspezifische Informationen wie Geburtstage kennen, können sie noch höhere Erfolgsraten erzielen.

Daher bietet Android 16 QPR2 und höher eine strengere Standardrichtlinie zur Ratenbegrenzung für LSKF. Diese Richtlinie erlaubt bis zu 6 Versuche in der ersten Minute, 7 Versuche in 6 Minuten, 8 Versuche in 25 Minuten, 12 Versuche in 24 Stunden und 19 Versuche in 5 Jahren. Nach 20 falschen Vermutungen sind keine weiteren Vermutungen mehr zulässig. Der vollständige Zeitüberschreitungsplan ist in der folgenden Tabelle aufgeführt. Dies kann sich in zukünftigen Android-Versionen ändern.

Anzahl der falschen Vermutungen Zeitüberschreitung nach falscher Antwort
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 mehr möglich

Aktualisierte Ratenbegrenzer

Android 16 QPR2 und höher enthält aktualisierte Gatekeeper- und Weaver-Implementierungen, die die Ratenbegrenzungsrichtlinie in der Tabelle erzwingen.

Software-Ratenbegrenzer

Android 16 QPR2 und höher enthält einen optionalen sekundären Ratenbegrenzer, SoftwareRateLimiter.. Er ist im Systemserver implementiert und ermöglicht es Geräten, eine strengere Ratenbegrenzungsrichtlinie anzubieten, wenn das TEE oder SE nicht aktualisiert werden kann.

Konfigurieren Sie SoftwareRateLimiter im Erzwingungsmodus über den Konfigurationswert config_softwareLskfRateLimiterEnforcing. Im Erzwingungsmodus wendet SoftwareRateLimiter seine Ratenbegrenzungsrichtlinie gleichzeitig mit dem primären Ratenbegrenzer an. Bei einer bestimmten Anzahl falscher Vermutungen ist das Zeitlimit das längere der beiden Zeitlimits, die vom primären Ratenbegrenzer und von SoftwareRateLimiter erforderlich sind. Im Modus „Nicht erzwingen“ werden alle Überprüfungsanfragen von SoftwareRateLimiter an die primäre Ratenbegrenzung weitergeleitet, ohne dass eine sekundäre Ratenbegrenzungsrichtlinie angewendet wird.

Erkennung von doppelten Vermutungen

Um die Nutzerfreundlichkeit zu verbessern und die Verwendung einer strengeren Ratenbegrenzungsrichtlinie zu ermöglichen, unterstützt Android 16 QPR2 und höher die Erkennung doppelter Vermutungen. Wenn diese Option aktiviert ist, werden Nutzer nicht dafür bestraft, dass sie mehrmals denselben falschen LSKF eingeben.

Es kann vorkommen, dass legitime Nutzer mehrmals denselben falschen LSKF eingeben. Wenn sie als mehrere Versuche gezählt werden, 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 Benutzerfreundlichkeit der LSKF-Eingabe für legitime Nutzer, ohne dass es für fähige Angreifer einfacher wird, die LSKFs zu erraten. So können stärkere Ratenbegrenzungsrichtlinien durchgesetzt werden. Bei legitimen Nutzern ist es weniger wahrscheinlich, dass es zu einem Zeitüberschreitungsfehler kommt, da sie fünf eindeutige falsche Vermutungen eingeben müssen und nicht fünf falsche Vermutungen, die auch Duplikate enthalten können.

Auf Geräten mit Android 16 QPR2 und höher, einer Weaver-Implementierung und SoftwareRateLimiter, die 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. Im Arbeitsspeicher werden bis zu fünf verschiedene falsche Vermutungen gespeichert. Wenn der Tracker voll ist, wird der älteste Eintrag gelöscht, 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 wird die Erkennung doppelter Vermutungen nicht unterstützt, wenn Gatekeeper der primäre Ratenbegrenzer ist.SoftwareRateLimiter

Weaver-Implementierer können die Erkennung doppelter Vermutungen in der Weaver-Implementierung unterstützen.