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 użytkownikom dodatkowe bezpieczeństwo i wygodę, ponieważ aktualizacje można wprowadzać w czasie bezczynności urządzenia, a Android 12 funkcje aktualizacji bazujące na serwerze i multiklientach pozwalają na poziomie sprzętowym.
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, bezpośredni rozruch obsługiwany przez Androida, który umożliwia uruchamianie aplikacji na urządzeniu przed odblokowaniem pamięci CE 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ń
Implementacja RoR musi zagwarantować, że w razie ataku urządzenia będzie bardzo trudno odzyskać kod CE. zaszyfrowanych danych, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana; urządzenie jest 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 podpisywać dowolne wiadomości kluczem podpisywania dowolnego dostawcy lub firmy.
- Może powodować otrzymywanie aktualizacji OTA.
- Mogą modyfikować działanie dowolnego sprzętu (takiego jak procesor aplikacji, lub pamięci flash) z wyjątkiem przypadków opisanych w Ograniczenia poniżej. (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 aktywnego urządzenia.
- nie są 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 zabezpiecza dane CE przez przechowywanie obiektu tajnego które można pobrać tylko przez ograniczony czas. Działa to w całym ekosystemie Androida.
- Do odblokowywania urządzenia używany jest klucz kryptograficzny chroniony kodem PIN użytkownika
i odszyfrować pamięć CE.
- Gdy zaplanowano ponowne uruchomienie w nocy, Android prosi użytkownika o wprowadzenie dla kodu PIN, a następnie oblicza hasło syntetyczne (SP).
- Następnie dwa razy szyfruje dostawcę usług: raz za pomocą klucza
K_szapisanego w pamięci RAM i ponownie za pomocą kluczaK_sz kluczemK_kzapisanym 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 odszyfrowuje potwierdzenie za pomocą
K_k, a następnie wysyła je na serwer, który będzie pobieraćK_s.K_kiK_ssą używane do odszyfrowywania dostawcy usług zapisanego na dysku.- Android korzysta z dostawcy usług, aby odblokować pamięć CE i umożliwić normalne uruchamianie aplikacji.
K_kiK_szostały odrzucone.
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 do karty SIM i odpowiednie informacje o karcie SIM (identyfikator ICCID oraz gniazdo karty SIM); są bezpiecznie przechowywane razem. Zapisany kod PIN można pobrać i użyć do weryfikacji tylko po udanym ponownym uruchomieniu bez nadzoru. 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 zapisywany za każdym razem, gdy użytkownik włączy usługę. zweryfikować lub zmodyfikować. Kod PIN do karty SIM zostanie odrzucony w następujących przypadkach: następuje:
- Karta SIM została wyjęta lub zresetowana.
- użytkownik wyłączy kod PIN;
- Ponowne uruchomienie nie zostało zainicjowane 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ć, musisz mieć urządzenie
program rozruchowy wyszuka hasło dla przyczyny 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ądzeń z Androidem 12, nie trzeba nic robić, wdrożyć nową funkcję RoR.
W ramach procesu multikonta klientów pojawiło się jedno nowe wywołanie: isPreparedForUnattendedUpdate,
poniżej:
@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)
Nie musisz tego stosować, ponieważ HAL jest wycofywany Android 12.
Menedżer telefonii
Klient OTA wywołuje systemowy interfejs API TelephonyManager, gdy zbliża się ponowne uruchomienie
na Androidzie 12. Ten interfejs API przenosi wszystkie kody PIN zapisane w pamięci podręcznej z
stan AVAILABLE na REBOOT_READY. System TelephonyManager
Interfejs API jest chroniony przez dotychczasowy interfejs REBOOT
Uprawnienia do pliku manifestu.
/**
* 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()
Systemowy interfejs API TelephonyManager jest używany przez pliki APK z podwyższonymi uprawnieniami.
Testowanie
Aby przetestować nowy interfejs API, uruchom to polecenie:
adb shell cmd phone unattended-reboot
To 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.
Od lipca 2020 r. implementacje RoR HAL dzielą się na 2 kategorie:
- Jeśli układ SoC obsługuje trwałość pamięci RAM po ponownym uruchomieniu, OEM może używać funkcji domyślna implementacja w AOSP (Default RAM Escrow).
- Jeśli sprzęt 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ć
:
- Mieć możliwość wykrycia ponownego uruchomienia 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ć go 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ą dbać o to, aby ich układy SOC obsługiwały trwałość pamięci RAM podczas ponownego uruchamiania. 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. W poniższej sekcji znajdziesz odpowiednie materiały kanoniczne na ten temat.
Proces aktualizacji OTA za pomocą RoR
Aplikacja kliencka OTA na telefonie musi mieć
Manifest.permission.REBOOT
i Manifest.permission.RECOVERY do wywoływania niezbędnych metod
i wdrożyć funkcję RoR. Po spełnieniu tego warunku wstępnego proces
wykonaj te czynności:
- Aplikacja kliencka OTA pobiera aktualizację.
- Wywołania aplikacji klienta OTA pod adresem
RecoverySystem#prepareForUnattendedUpdate, które powoduje wyświetlenie prośby o podanie kodu PIN, wzoru lub hasła na blokady ekranu 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). W przypadku aplikacji będzie widoczny jako odblokowany przez normalnego użytkownika, dzięki czemu będzie otrzymywać wszystkie sygnały, takie jak ACTION_LOCKED_BOOT_UKOŃCZONO oraz ACTION_BOOT_COMPLETED co zwykle.
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 korzystają z ponownego uruchamiania (gdy zasilanie DRAM pozostaje włączone podczas ponownego uruchamiania).
Ponowne uruchomienie znacznika funkcji depozytu
Musi być też dostępny znacznik cech:
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 zapisywać te bajty w pamięci nieulotnej, aby zapewnić, że właściwości zabezpieczeń i utrwalać się.
Zmiany drzewa urządzeń z jądrem Linuksa
W drzewie urządzenia jądra Linuksa musisz zarezerwować pamięć dla regionu pmem.
Ten przykład pokazuje zarezerwowanie zasobu 0x50000000:
reserved-memory {
my_reservation@0x50000000 {
no-map;
reg = <0x50000000 0x10000>;
}
}
reboot_escrow@0 {
compatible = "pmem-region";
reg = <0x50000000 0x10000>;
};
Sprawdź, czy w katalogu bloków znajduje się nowe urządzenie o nazwie takiej jak
/dev/block/pmem0 (np. pmem1 lub pmem2).
Zmiany na urządzeniu 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 nowe wpisy do sekcji 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