Android chroni dane użytkownika, w tym przechowywane w zaszyfrowanej postaci dane uwierzytelniające oraz klucze Keystore powiązane z uwierzytelnianiem, za pomocą skonfigurowanych przez użytkownika czynników wiedzy o ekranie blokady (LSKF) , takich jak kody PIN, wzory i hasła. LSKF to zwykle wartości o niskiej entropii, takie jak 4- lub 6-cyfrowe kody PIN, dlatego wymagana jest ochrona przed atakami brute force.
Android używa ograniczników szybkości w zaufanym środowisku wykonawczym (TEE) lub bezpiecznym elemencie (SE), aby spowolnić, a po wystarczającej liczbie prób zablokować hakerów przeprowadzających ataki brute force na LSKF. Dokument CDD 9.11 określa minimalne wymagania i zalecenia dotyczące zabezpieczeń w przypadku ograniczników szybkości LSKF. Android 16 QPR2 i nowsze wersje implementują znacznie bardziej rygorystyczne zasady ograniczania szybkości niż starsze wersje Androida. Więcej informacji znajdziesz w artykule Bardziej rygorystyczne domyślne zasady ograniczania szybkości w Androidzie 16 QPR2 i nowszych wersjach.
Android 17 i nowsze wersje używają bardziej rygorystycznego domyślnego ograniczania szybkości na ekranie blokady niż starsze wersje. W rzadkich przypadkach użytkownicy mogą doświadczyć długich limitów czasu na ekranie blokady, dlatego Android 17 i nowsze wersje zapewniają ulepszone opinie użytkowników na ekranie blokady.
- Ulepszone formatowanie czasu: ekran blokady wyświetla limity czasu trwające co najmniej minutę, używając większych jednostek czasu, aby zwiększyć czytelność, np. Spróbuj ponownie za 30 minut zamiast Spróbuj ponownie za 1800 sekund.
- Krótki link do odzyskiwania: ekran blokady wyświetla krótki link
(domyślnie g.co/android/unlock), który pomaga użytkownikom znaleźć
opcje odzyskiwania na innym urządzeniu. Ten link można skonfigurować za pomocą zasobu
config_lockscreenLockoutShortlink. - Opinie o duplikatach prób: na urządzeniach z implementacją Weaver system wyświetla unikalny komunikat, gdy zostanie wprowadzona zduplikowana nieprawidłowa próba. Ta konkretna opinia jest niedostępna na urządzeniach, które korzystają tylko z Gatekeepera, ponieważ nie udostępniają one oddzielnych kodów odpowiedzi na nieprawidłowe próby i inne błędy weryfikacji.
- Spójne zarządzanie wprowadzaniem danych uwierzytelniających: ekran blokady wyłącza klawiaturę do wprowadzania kodu PIN, jeśli urządzenie używa kodu PIN jako danych uwierzytelniających, podobnie jak w przypadku hasła i wzoru.
Metoda LockPatternUtils#getLockoutAttemptDeadline(int) została zmieniona na LockPatternUtils#getLockoutEndTime(int) i podaje czas zakończenia blokady z pamięci podręcznej zarządzanej przez system. Ta aktualizacja rozwiązuje problem, który powodował, że były one buforowane tylko w instancji LockPatternUtils, co błędnie wskazywało na brak aktywnego limitu czasu, jeśli został on wywołany za pomocą innej instancji. Deweloperzy systemowych promptów dotyczących danych uwierzytelniających, takich jak ekran blokady i ustawienia, muszą je zaktualizować, aby przed zezwoleniem na dalsze próby sprawdzić, czy istnieją limity czasu.
Odblokowywanie chronionych danych użytkownika za pomocą LSKF
LockSettingsService
zarządza przechowywaniem i weryfikowaniem LSKF. Użytkownik może mieć tylko 1 aktywny LSKF. Przypisanie nowego LSKF unieważnia poprzedni i rozpoczyna zasady ograniczania szybkości od początku.
Główny ogranicznik szybkości w TEE lub SE, czyli Gatekeeper
lub Weaver, wymusza ograniczanie szybkości w przypadku
aktywnego LSKF. Gdy dostępna jest implementacja, LockSettingsService preferuje Weaver.
Chronione dane użytkownika są odblokowywane tylko wtedy, gdy do głównego ogranicznika szybkości zostanie podany prawidłowy LSKF. Jeśli LSKF jest nieprawidłowy, ogranicznik szybkości zwiększa licznik błędów i wymusza limit czasu po określonej liczbie błędów. Podczas limitu czasu odrzuca wszystkie próby i podaje pozostały limit czasu.
Bardziej rygorystyczne domyślne zasady ograniczania szybkości w Androidzie 16 QPR2 i nowszych wersjach
Dokument CDD 9.11 wymaga ograniczania szybkości LSKF w Androidzie 6 i nowszych wersjach. W przeszłości wymagane zasady ograniczania szybkości były dość łagodne. Na przykład implementacja spełniająca minimalne wymagania Androida 16 pozwala na maksymalnie 10 prób w pierwszej minucie, 20 w 6 minutach, 50 w 25 minutach, 110 w 24 godzinach i 1800 prób w 5 latach.
Chociaż te zasady są dość bezpieczne w przypadku LSKF wybranych losowo, w praktyce użytkownicy nie wybierają LSKF losowo. Niektóre LSKF występują znacznie częściej niż inne. Osoby przeprowadzające ataki mogą osiągnąć znaczny wskaźnik sukcesu, próbując LSKF w kolejności malejącej częstotliwości.
Na przykład badanie This PIN Can Be Easily Guessed wykazało, że wskaźnik sukcesu w przypadku odgadywania rzeczywistych kodów PIN po 100 próbach wynosi 16,2%, a w przypadku wzorów – 35,5%. Hakerzy znający informacje o użytkowniku, takie jak data urodzenia, mogą osiągnąć jeszcze wyższy odsetek sukcesów.
Dlatego Android 16 QPR2 i nowsze wersje zapewniają bardziej rygorystyczne domyślne zasady ograniczania szybkości LSKF. Te zasady pozwalają na maksymalnie 6 prób w pierwszej minucie, 7 w 6 minutach, 8 w 25 minutach, 12 w 24 godzinach i 19 w 5 latach. Po 20 nieprawidłowych próbach nie można już próbować. Pełny harmonogram limitów czasu znajdziesz w tabeli poniżej. W przyszłych wersjach Androida może się on zmienić.
| Liczba nieprawidłowych prób | Limit czasu po nieprawidłowej próbie |
|---|---|
| 0 | Nie dotyczy |
| 1–4 | 0 sekund |
| 5 | 1 minuta |
| 6 | 5 minut |
| 7 | 15 minut |
| 8 | 30 minut |
| 9 | 90 minut |
| 10 | 4 godziny |
| 11 | 12 godzin |
| 12 | 24 godziny |
| 13 | 4 dni |
| 14 | 13 dni |
| 15 | 41 dni |
| 16 | 123 dni |
| 17 | 1 rok |
| 18 | 3 lata |
| 19 | 9 lat |
| 20+ | Nie można już próbować |
Zaktualizowane ograniczniki szybkości
Android 16 QPR2 i nowsze wersje zawierają zaktualizowane implementacje Gatekeepera i Weavera, które wymuszają zasady ograniczania szybkości w tabeli.
Ogranicznik szybkości oprogramowania
Android 16 QPR2 i nowsze wersje zawierają opcjonalny dodatkowy ogranicznik szybkości, SoftwareRateLimiter.
Jest on zaimplementowany na serwerze systemowym i umożliwia urządzeniom stosowanie bardziej rygorystycznych zasad ograniczania szybkości, gdy
nie można zaktualizować TEE lub SE.
Skonfiguruj SoftwareRateLimiter w trybie wymuszania za pomocą wartości konfiguracji config_softwareLskfRateLimiterEnforcing. W trybie wymuszania SoftwareRateLimiter stosuje swoje zasady ograniczania szybkości jednocześnie z głównym ogranicznikiem szybkości. W przypadku danej liczby nieprawidłowych prób limit czasu jest dłuższy niż wymagany przez główny ogranicznik szybkości i SoftwareRateLimiter.
W trybie niewymuszania SoftwareRateLimiter przekazuje wszystkie żądania weryfikacji do głównego ogranicznika szybkości bez stosowania dodatkowych zasad ograniczania szybkości.
Wykrywanie zduplikowanych prób
Aby zwiększyć wygodę użytkowania i umożliwić stosowanie bardziej rygorystycznych zasad ograniczania szybkości, Android 16 QPR2 i nowsze wersje obsługują wykrywanie zduplikowanych prób. Gdy ta funkcja jest włączona, użytkownicy nie są karani za wielokrotne wprowadzanie tego samego nieprawidłowego LSKF.
Prawidłowi użytkownicy czasami wielokrotnie wprowadzają ten sam nieprawidłowy LSKF. Jeśli jest to liczone jako wiele prób, powoduje to niepotrzebne limity czasu. Hakerzy nie próbują danego LSKF więcej niż raz. Zasady, które nie liczą zduplikowanych prób, zwiększają wygodę wprowadzania LSKF przez prawidłowych użytkowników, nie ułatwiając hakerom odgadywania LSKF, co pozwala na egzekwowanie bardziej rygorystycznych zasad ograniczania szybkości. Prawidłowi użytkownicy rzadziej napotykają limit czasu, ponieważ muszą wprowadzić 5 unikalnych nieprawidłowych prób zamiast 5 nieprawidłowych prób, w tym duplikatów.
Na urządzeniach z Androidem 16 QPR2 i nowszymi wersjami, implementacją Weavera i SoftwareRateLimiter skonfigurowanym w trybie wymuszania zduplikowane próby są wykrywane i odrzucane, zanim zostaną przekazane do Weavera. Takie odrzucenia nie zwiększają liczby nieprawidłowych prób. W pamięci śledzonych jest maksymalnie 5 unikalnych nieprawidłowych prób. Jeśli tracker jest pełny, najstarsza próba jest odrzucana, aby zwolnić miejsce. Wszystkie śledzone próby są odrzucane 5 minut po ostatniej nieśledzonej nieprawidłowej próbie.
Gatekeeper nie rozróżnia nieprawidłowych prób od innych błędów weryfikacji, dlatego SoftwareRateLimiter nie obsługuje wykrywania zduplikowanych prób, gdy Gatekeeper jest głównym ogranicznikiem szybkości.
Osoby implementujące Weavera mogą zdecydować się na obsługę wykrywania zduplikowanych prób w implementacji Weavera.