W Androidzie 11 aktualizacje OTA można stosować przy użyciu aktualizacji A/B. lub wirtualnej aktualizacji A/B w połączeniu z przy użyciu systemu RecoverySystem i metod klas. Gdy urządzenie zrestartuje się i zainstaluje aktualizację OTA, Funkcja wznawiania przy ponownym uruchomieniu (RoR) odblokowuje pamięć szyfrowaną za pomocą danych uwierzytelniających (CE).
Partnerzy mogą połączyć ten proces z funkcją systemu OTA, która ma zastosowanie jest aktualizowany, gdy urządzenie z Androidem 11 jest bezczynne, w Partnerzy Androida 12 nie potrzebują dodatkowego systemu OTA funkcji. Proces RoR zapewnia dodatkową ochronę i wygodę dla użytkowników, ponieważ aktualizacje mogą być przeprowadzane w czasie bezczynności urządzenia, a funkcje aktualizacji na wielu klientach i serwerach w Androidzie 12 zapewniają ochronę na poziomie sprzętu.
chociaż musisz udzielić zgody na korzystanie z urządzenia android.hardware.reboot_escrow
obsługuje RoR w Androidzie 11, nie musisz tego robić,
oparte na serwerach RoR w Androidzie 12 i nowszych, ponieważ
nie używaj HAL.
Tło
Począwszy od Androida 7 system obsługuje Direct Boot, który umożliwia uruchamianie aplikacji na urządzeniu przed odblokowaniem pamięci przez użytkownika. Wdrożenie funkcji bezpośredniego rozruchu zapewniło użytkownikom przed podaniem współczynnika wiedzy na ekranie blokady (LSKF). po rozruchu.
dyrektywa RoR umożliwia odblokowanie pamięci CE wszystkich aplikacji na urządzeniu, w tym tych, które nie obsługują bezpośredniego rozruchu, po zainicjowaniu ponownego uruchomienia po aktualizacja OTA. Funkcja ta umożliwia użytkownikom otrzymywanie powiadomień ze wszystkich swoich zainstalowane aplikacje, po ponownym uruchomieniu.
Model zagrożeń
Wdrożenie funkcji odzyskiwania danych musi zapewniać, że gdy urządzenie wpadnie w ręce atakującego, będzie on miał bardzo ograniczone możliwości odzyskania zaszyfrowanych danych użytkownika, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana, a urządzenie zostało odblokowane przez użytkownika po otrzymaniu aktualizacji OTA. Zespół wewnętrzny odporność na atak musi być skuteczna, nawet jeśli atakujący uzyska dostęp do przesyłanie kryptograficznych kluczy podpisywania.
W szczególności pamięć CE nie może być odczytywana przez osobę przeprowadzającą atak, która fizycznie oraz ma te możliwości i ograniczenia:
Potencjał
- Może używać klucza podpisywania dowolnego dostawcy lub firmy do podpisywania dowolnych wiadomości.
- Może powodować otrzymywanie aktualizacji OTA.
- Może modyfikować działanie dowolnego sprzętu (np. procesora aplikacji lub pamięci flash) – z wyjątkiem opisanych poniżej ograniczeń. (Taka modyfikacja wiąże się jednak zarówno z opóźnieniem co najmniej godzinnym, jak i cykl zasilania, który niszczy zawartość pamięci RAM).
Ograniczenia
- Nie mogą zmienić działania sprzętu odpornego na manipulacje (np. Titan M).
- Nie można odczytać pamięci RAM na urządzeniu.
- nie jest w stanie odgadnąć danych logowania użytkownika (kodu PIN, wzoru, hasła) ani z innych powodów ich dane.
Rozwiązanie
System aktualizacji Androida 12 RoR zapewnia bezpieczeństwo przed bardzo zaawansowanymi atakami. Czyli tylko hasła na urządzeniu Kody PIN pozostają na urządzeniu – nigdy nie są wysyłane na serwery Google ani na nich przechowywane. Ten Omówienie procesu, który zapewnia poziom zabezpieczeń podobny do sprzętowego systemu RoR na poziomie urządzenia:
- Android stosuje zabezpieczenia kryptograficzne do danych przechowywanych na urządzeniu.
- Wszystkie dane są chronione przez klucze przechowywane w zaufanym środowisku wykonawczym (TEE).
- TEE zwalnia klucze tylko wtedy, gdy uruchomiony system operacyjny spełnia wymagania uwierzytelnianie kryptograficzne (weryfikacja podczas uruchamiania).
- Usługa RoR działająca na serwerach Google chroni dane CE, przechowując tajne dane, które można pobrać tylko przez ograniczony czas. Działa to w całym ekosystemie Androida.
- Klucz kryptograficzny chroniony kodem PIN użytkownika służy do odblokowywania urządzenia i odszyfrowywania pamięci CE.
- Gdy zaplanowane jest ponowne uruchomienie urządzenia w nocy, Android prosi użytkownika o podanie kodu PIN, a następnie oblicza hasło syntetyczne (SP).
- Następnie szyfruje SP dwukrotnie: raz za pomocą klucza
K_sprzechowywanego w pamięci RAM, a następnie za pomocą kluczaK_kprzechowywanego w TEE. - Podwójnie szyfrowany dostawca usług jest przechowywany na dysku, który jest usuwany z pamięci RAM. Oba klucze są generowane na bieżąco i służą tylko do jednego restartu.
- Przy ponownym uruchomieniu Android powierza
K_sserwerowi. Paragon z danymiK_ksą szyfrowane przed zapisaniem ich na dysku. - Po ponownym uruchomieniu Android używa
K_kdo odszyfrowania potwierdzenia, a następnie wysyła je na serwer, aby pobraćK_s.K_kiK_ssłużą do odszyfrowywania SP zapisanego na dysku.- Android korzysta z dostawcy usług, aby odblokować pamięć CE i umożliwić normalne uruchamianie aplikacji.
- Wartości
K_kiK_ssą odrzucane.
Aktualizacje, które chronią telefon, mogą nastąpić w dogodnym czasie dla Ciebie: podczas snu.
Ponowne odtwarzanie kodu PIN z karty SIM
W pewnych warunkach kod PIN karty SIM jest weryfikowany z pamięci podręcznej, To proces nazywany ponownym odtwarzaniem karty SIM z kodem PIN.
Karta SIM z włączonym kodem PIN również musi przejść kod PIN bez zakłóceń. weryfikacja (ponowne odtworzenie kodu SIM i kodu PIN) po ponownym uruchomieniu bez nadzoru w celu przywrócenia sieci komórkowej; połączenia (wymagane do połączeń telefonicznych, SMS-ów i usług transmisji danych); Kod PIN karty SIM i odpowiadające mu informacje o karcie SIM (numer ICCID i numer gniazda karty SIM) są przechowywane razem w bezpiecznym miejscu. Zdjęty kod PIN można pobrać i użyć do weryfikacji tylko po bezproblemowym ponownym uruchomieniu urządzenia. Jeśli urządzenie jest kod PIN do karty SIM jest przechowywany wraz z kluczami chronionymi przez LSKF. Jeśli na karcie SIM kod PIN jest włączony, interakcja z serwerem RoR wymaga połączenia Wi-Fi dla aktualizacji OTA i wskaźnika RoR opartego na serwerze, co zapewnia podstawowe działanie połączenia komórkowego) po zrestartowaniu urządzenia.
Kod PIN do karty SIM jest ponownie szyfrowany i przechowywany za każdym razem, gdy użytkownik go włączy, zweryfikuje lub zmodyfikuje. Kod PIN karty SIM jest odrzucany, jeśli wystąpi jedno z tych zdarzeń:
- Karta SIM została wyjęta lub zresetowana.
- użytkownik wyłączy kod PIN;
- Wystąpił restart nieinicjowany przez RoR.
Zapisany kod PIN karty SIM może zostać użyty raz po zrestartowaniu zainicjowanym przez RoR. tylko przez bardzo krótki czas (20 sekund) – jeśli dane karty SIM są szczegółowe. są takie same. Zapisany kod PIN do karty SIM nigdy nie opuszcza aplikacji TelephonyManager. nie mogą być odczytywane przez moduły zewnętrzne.
Wytyczne dotyczące implementacji
Na Androidzie 12 multiklient i serwerowy wskaźnik RoR zmniejsza obciążenie partnerom podczas przekazywania aktualizacji OTA. Niezbędne aktualizacje mogą wystąpić podczas dogodnych przerw w działaniu urządzenia, np. w określonych godzinach snu.
Aby mieć pewność, że aktualizacje OTA w takich okresach nie będą przeszkadzać użytkownikom,
wdrożyliśmy tryb ciemny w celu ograniczenia emisji światła. Aby to zrobić, sprawdź, czy program rozruchowy urządzenia wyszukuje ciąg znaków reason unattended. Jeśli unattended to true,
ustawić na urządzeniu tryb ciemny. Pamiętaj, że obowiązkiem każdego producenta OEM jest
zredukować emisję dźwięku i światła.
Jeśli przechodzisz na Androida 12 lub wprowadzasz na rynek urządzenia z Androidem 12, nie musisz nic robić, aby wdrożyć nową funkcję RoR.
W procesie wieloklientowym isPreparedForUnattendedUpdate jest 1 nowe wywołanie:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
Nie musisz tego wdrażać, ponieważ HAL został wycofany w Androidzie 12.
TelephonyManager
Klient OTA wywołuje systemowy interfejs API TelephonyManager, gdy zbliża się ponowne uruchomienie
na Androidzie 12. Ten interfejs API przenosi wszystkie zapisane w pamięci podręcznej kody PIN z stanu AVAILABLE do stanu REBOOT_READY. Interfejs API systemu TelephonyManager jest chroniony przez istniejące uprawnienie pliku manifestu REBOOT.
/**
* The unattended reboot was prepared successfully.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;
/**
* The unattended reboot was prepared, but the user will need to manually
* enter the PIN code of at least one SIM card present in the device.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;
/**
* The unattended reboot was not prepared due to generic error.
* @hide
*/
@SystemApi
public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;
/** @hide */
@Retention(RetentionPolicy.SOURCE)
@IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
value = {
PREPARE_UNATTENDED_REBOOT_SUCCESS,
PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
PREPARE_UNATTENDED_REBOOT_ERROR
})
public @interface PrepareUnattendedRebootResult {}
/**
* Prepare TelephonyManager for an unattended reboot. The reboot is
* required to be done shortly after the API is invoked.
*
* Requires system privileges.
*
* <p>Requires Permission:
* {@link android.Manifest.permission#REBOOT}
*
* @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
* {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
* at least one SIM card for which the user needs to manually enter the PIN
* code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
* of error.
* @hide
*/
@SystemApi
@RequiresPermission(android.Manifest.permission.REBOOT)
@PrepareUnattendedRebootResult
public int prepareForUnattendedReboot()
Interfejs systemowy TelephonyManager API jest używany przez uprawnione pliki APK.
Testowanie
Aby przetestować nowy interfejs API, uruchom to polecenie:
adb shell cmd phone unattended-rebootTo polecenie działa tylko wtedy, gdy powłoka jest uruchomiona jako użytkownik root (adb root).
Tylko Android 11
Pozostała część tej strony dotyczy Androida 11.
W lipcu 2020 r. implementacje RoR HAL dzielą się na 2 kategorie:
- Jeśli sprzęt SoC obsługuje trwałość pamięci RAM po ponownym uruchomieniu, producenci OEM mogą korzystać z domyślnej implementacji w AOSP (domyślny RAM Escrow).
- Jeśli urządzenie lub układ SOC obsługuje bezpieczną enklawę sprzętową (oddzielną
przez współprocesora zabezpieczeń z własną pamięcią RAM i ROM), dodatkowo musi wykonać
:
- wykryć ponowne uruchomienie głównego procesora;
- Mieć sprzętowe źródło licznika czasu, które pozostaje ustawione po ponownym uruchomieniu. Oznacza to, że enklawa musi mieć możliwość wykrycia ponownego uruchomienia i wygaśnięcia licznika czasu ustawionego przed i uruchomić ponownie.
- Obsługa przechowywania zdekodowanego klucza w pamięci RAM/ROM enklawy, tak aby nie można było z niego korzystać które można odzyskać za pomocą ataków offline. Klucz RoR musi być przechowywany w taki sposób, nie będzie można go odzyskać osobom wtajemniczonym lub przeprowadzającym atak.
Domyślny depozyt pamięci RAM
AOSP ma wdrożenie algorytmu RoR HAL na podstawie trwałości pamięci RAM. Aby to działało, producenci OEM muszą zadbać o to, aby ich układy SoC obsługiwały trwałość pamięci RAM po ponownym uruchomieniu. Niektóre układy SOC nie są w stanie utrwalać zawartości pamięci RAM po ponownym uruchomieniu, Zalecamy producentom OEM, aby skonsultowali się ze swoimi partnerami SoC przed włączeniem tej domyślnej wartości HAL. Pełna informacja na ten temat znajduje się w następnej sekcji.
Przebieg aktualizacji OTA przy użyciu RoR
Aby wywołać niezbędne metody do implementacji RoR, aplikacja klienta OTA na telefonie musi mieć uprawnienia Manifest.permission.REBOOT i Manifest.permission.RECOVERY. Po spełnieniu tego wymogu proces aktualizacji przebiega w ten sposób:
- Aplikacja kliencka OTA pobiera aktualizację.
- Aplikacja klienta OTA wywołuje funkcję
RecoverySystem#prepareForUnattendedUpdate, która powoduje wyświetlenie użytkownikowi prośby o podanie kodu PIN, wzoru lub hasła na ekranie blokady podczas następnego odblokowania. - Użytkownik odblokuje urządzenie na ekranie blokady, a urządzenie będzie gotowe , aby zastosować aktualizację.
- Klient OTA wywołuje metodę
RecoverySystem#rebootAndApply, która natychmiast uruchamia restart.
Po zakończeniu tego procesu urządzenie uruchamia się ponownie, a wskaźnik pojawiający się ponownie odblokowuje magazyn danych szyfrowanych (CE). Dla aplikacji wygląda to jak zwykłe odblokowanie przez użytkownika, więc otrzymują wszystkie sygnały, takie jak ACTION_LOCKED_BOOT_COMPLETED i ACTION_BOOT_COMPLETED, które zwykle otrzymują.
Modyfikowanie konfiguracji produktów
Produkt oznaczony jako obsługujący funkcję RoR w Androidzie 11 musi zawierać wdrożenie kodu HAL RestartEscrow HAL i dołączenie pliku XML znacznika cech. Domyślna implementacja działa dobrze na urządzeniach, które używają ciepłego restartu (gdy zasilanie DRAM pozostaje włączone podczas restartu).
Znacznik funkcji escrow do ponownego uruchamiania
Musi też występować znacznik funkcji:
PRODUCT_COPY_FILES += \
frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml
Domyślna implementacja HAL depozytu ponownego uruchomienia
Aby używać implementacji domyślnej, musisz zarezerwować 65 536 (0x10 000) bajtów. Nigdy nie zapisuj tych bajtów w pamięci trwałej, aby zapewnić trwałość właściwości zabezpieczeń.
Zmiany w drzewie urządzeń jądra systemu Linux
W drzewie urządzenia jądra Linuksa musisz zarezerwować pamięć dla regionu pmem.
W tym przykładzie rezerwujemy 0x50000000:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
Sprawdź, czy w katalogu blokowania znajduje się nowe urządzenie o nazwie /dev/block/pmem0 (np. pmem1 lub pmem2).
Zmiany w pliku Device.mk
Zakładając, że nowe urządzenie z poprzedniego kroku ma nazwę pmem0, musisz
upewnij się, że do vendor/<oem>/<product>/device.mk zostały dodane te nowe wpisy:
# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
android.hardware.rebootescrow-service.default
Reguły SELinux
Dodaj te nowe wpisy do file_contexts urządzenia:
/dev/block/pmem0 u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default u:object_r:hal_rebootescrow_default_exec:s0