Wznawianie po ponownym uruchomieniu

W Androidzie 11 aktualizacje OTA można stosować za pomocą mechanizmów aktualizacji A/B lub wirtualnej aktualizacji A/B w połączeniu z metodami klasy RecoverySystem. 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 stosuje aktualizacje, gdy w Androidzie 11 urządzenie jest bezczynne, jednak w przypadku Androida 12 partnerzy nie potrzebują dodatkowej funkcji OTA. Proces RoR zapewnia użytkownikom dodatkowe bezpieczeństwo i wygodę, ponieważ aktualizacje mogą być wprowadzane podczas bezczynności urządzenia, a funkcje aktualizacji na Androidzie 12 obejmujące multiklientów i serwery łącznie zapewniają bezpieczeństwo na poziomie sprzętowym urządzenia.

W Androidzie 11 musisz zezwolić funkcji android.hardware.reboot_escrow na obsługę RoR, ale nie musisz tego robić, aby w Androidzie 12 i nowszych wersjach używać RoR opartych na serwerach, ponieważ nie korzystają one z HAL.

Tło

Począwszy od Androida 7, obsługiwany przez Androida bezpośredni rozruch, który umożliwia uruchomienie aplikacji na urządzeniu, zanim użytkownik odblokuje pamięć CE. Wdrożenie obsługi bezpośredniego uruchamiania zapewnia użytkownikom lepsze wrażenia, ponieważ nie muszą już wpisywać kodu na ekranie blokady.

RoR umożliwia odblokowanie pamięci CE wszystkich aplikacji na urządzeniu, w tym tych, które nie obsługują bezpośredniego uruchamiania, gdy po aktualizacji OTA rozpocznie się ponowne uruchamianie. Ta funkcja umożliwia użytkownikom otrzymywanie powiadomień ze wszystkich zainstalowanych aplikacji po ponownym uruchomieniu urządzenia.

Model zagrożenia

Wdrożenie dyrektywy RoR musi zagwarantować, że w sytuacji, gdy urządzenie wpadnie w ręce atakującego, bardzo utrudnione będzie odzyskanie danych zaszyfrowanych przy użyciu systemu CE – nawet wtedy, gdy urządzenie jest włączone, pamięć CE jest odblokowana, a urządzenie zostaje odblokowane po otrzymaniu aktualizacji OTA. Odporność na atak z wykorzystaniem informacji od osób wtajemniczonych musi być skuteczna nawet wtedy, gdy atakujący uzyska dostęp do transmitowanych kryptograficznych kluczy podpisywania.

W szczególności dane z CE nie mogą być odczytywane przez osobę atakującą, która ma fizyczny dostęp do urządzenia i ma te możliwości oraz ograniczenia:

Uprawnienia

• 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 czy pamięci flash), z wyjątkiem przypadków opisanych w Ograniczeniach poniżej. (Taka modyfikacja obejmuje jednak zarówno opóźnienie o co najmniej 1 godzinę, jak i cykl zasilania, który niszczy zawartość pamięci RAM).

Ograniczenia

• nie może zmieniać działania sprzętu odpornego na manipulacje (np. Titana M),
• Nie można odczytać pamięci RAM aktywnego urządzenia.
• nie może odgadnąć danych logowania użytkownika (kodu PIN, wzoru, hasła) ani w inny sposób powodować ich wpisywania.

Rozwiązanie

System aktualizacji RoR w Androidzie 12 zapewnia ochronę przed bardzo zaawansowanymi atakującymi, a hasła i kody PIN na urządzeniu pozostają na nim – nigdy nie są wysyłane ani zapisywane na serwerach Google. Oto omówienie procesu, który zapewnia, że poziomy zabezpieczeń są podobne do systemu RoR na poziomie urządzenia opartego na sprzęcie:

• Android stosuje zabezpieczenia kryptograficzne do danych przechowywanych na urządzeniu.
• Wszystkie dane są chronione za pomocą kluczy przechowywanych w zaufanym środowisku wykonawczym (TEE).
• TEE udostępnia klucze tylko wtedy, gdy uruchomiony system operacyjny przejdzie uwierzytelnianie kryptograficzne (sprawdzony rozruch).
• 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 jest używany do odblokowywania urządzenia i odszyfrowywania pamięci CE.
  • Gdy zaplanowano ponowne uruchomienie w nocy, Android prosi użytkownika o wpisanie kodu PIN, a następnie oblicza hasło syntetyczne (SP).
  • Następnie szyfruje SP dwukrotnie: raz za pomocą klucza K_s przechowywanego w pamięci RAM, a następnie za pomocą klucza K_k przechowywanego w TEE.
  • Podwójnie zaszyfrowany SP jest przechowywany na dysku, a SP zostaje wymazany z pamięci RAM. Oba klucze są generowane na bieżąco i służą tylko do jednego restartu.
• Gdy nadszedł czas ponownego uruchomienia, Android powierza K_s serwerowi. Pokwitowanie z K_k jest szyfrowane przed zapisaniem go na dysku.
• Po ponownym uruchomieniu Android przy użyciu K_k odszyfrowuje potwierdzenie, a następnie wysyła je na serwer w celu pobrania pliku K_s.
  • K_k i K_s sł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_k i K_s są odrzucane.

Aktualizacje, które chronią telefon, mogą nastąpić w dogodnym dla Ciebie czasie: podczas snu.

Ważne: funkcja RoR oparta na serwerze działa tak, że serwer nigdy nie zapamiętuje kodu PIN użytkownika: klucz K_s to jedyny tajny klucz powierzony serwerowi i jest generowany losowo za każdym razem. Hasła i kod PIN pozostają na urządzeniu – nigdy nie są wysyłane na serwery ani przechowywane na nich.

Ponowne odtwarzanie kodu PIN z karty SIM

W pewnych warunkach kod PIN karty SIM jest weryfikowany z pamięci podręcznej. Jest to tzw. ponowne odtwarzanie kodu PIN karty SIM.

Karta SIM z włączonym kodem PIN musi też przejść płynną weryfikację kodu PIN (powtórzenie kodu PIN karty SIM) po automatycznym ponownym uruchomieniu, aby przywrócić łączność komórkową (wymagane do nawiązywania połączeń telefonicznych, wysyłania SMS-ów i korzystania z 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 zabezpieczone, kod PIN do karty SIM jest przechowywany wraz z kluczami chronionymi przez LSKF. Jeśli karta SIM ma włączony kod PIN, interakcja z serwerem RoR wymaga połączenia Wi-Fi w przypadku aktualizacji OTA i RoR na serwerze, co zapewnia podstawowe funkcje (z możliwością łączenia się z siecią komórkową) po ponownym uruchomieniu.

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 do karty SIM zostanie odrzucony w tych sytuacjach:

• 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 tylko raz po ponownym uruchomieniu urządzenia w ramach funkcji RoR i tylko przez bardzo krótki czas (20 sekund) – jeśli dane karty SIM są zgodne. Zapisany kod PIN do karty SIM nigdy nie opuszcza aplikacji TelephonyManager i nie można go pobrać przez moduły zewnętrzne.

Wytyczne dotyczące implementacji

W Androidzie 12 funkcje RoR dla wielu klientów i na serwerze zmniejszają obciążenie partnerów podczas przesyłania aktualizacji OTA. Niezbędne aktualizacje mogą odbywać się w dogodnych momentach, gdy urządzenie jest nieużywane, np. w godzinach snu.

Aby aktualizacje OTA w takich okresach nie zakłócały użytkowników, stosuj tryb ciemny, aby ograniczyć emisję światła. Aby to zrobić, program rozruchowy urządzenia wyszuka ciąg unattended. Jeśli unattended = true, włącz tryb ciemny na urządzeniu. Pamiętaj, że za złagodzenie emisji dźwięku i światła odpowiada każdy OEM.

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 multikonta klientów pojawiło się jedno nowe wywołanie – isPreparedForUnattendedUpdate, jak widać poniżej:

@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 interfejs API systemu TelephonyManager, gdy zbliża się czas ponownego uruchamiania urządzenia w 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-reboot

To polecenie działa tylko wtedy, gdy powłoka działa jako 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:

1. Jeśli układ SoC obsługuje trwałość pamięci RAM po ponownym uruchomieniu, OEM może użyć domyślnej implementacji w AOSP (Default RAM Escrow).
2. Jeśli urządzenie lub układ SOC obsługuje bezpieczną enklawę sprzętową (oddzielny współprocesor zabezpieczający z własną pamięcią RAM i ROM), musi dodatkowo wykonać te czynności:
   • 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 być w stanie wykryć ponowne uruchomienie i zakończyć działanie zegara ustawionego przed ponownym uruchomieniem.
   • Obsługa przechowywania zdekodowanego klucza w pamięci RAM/ROM enklawy, aby nie dało się go odzyskać za pomocą ataków offline. Musi przechowywać klucz RoR w sposób uniemożliwiający osobom wtajemniczonym lub przeprowadzającym atak.

Domyślne zabezpieczenie RAM

AOSP zawiera implementację interfejsu RoR HAL, która korzysta z 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 po ponownym uruchomieniu. Niektóre układy SOC nie są w stanie utrwalać zawartości pamięci RAM podczas ponownego uruchamiania, dlatego zalecamy skonsultowanie się ze swoimi partnerami SoC przed włączeniem tego domyślnego 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 tych wymagań wstępnych proces aktualizacji przebiega w następujący sposób:

1. Aplikacja kliencka OTA pobiera aktualizację.
2. 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.
3. Gdy użytkownik odblokuje urządzenie na ekranie blokady, będzie gotowe do zastosowania aktualizacji.
4. Klient OTA wywołuje metodę RecoverySystem#rebootAndApply, co natychmiast powoduje ponowne uruchomienie.

Po zakończeniu tego procesu urządzenie uruchamia się ponownie, a mechanizm RoR odblokowuje szyfrowaną dane logowania (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

Usługa oznaczona jako obsługująca funkcję RoR w Androidzie 11 musi zawierać implementację kodu HAL RestartEscrow HAL i zawierać plik XML znacznika cech. Domyślna implementacja działa dobrze na urządzeniach, które korzystają z ponownego uruchomienia urządzenia z pamięcią (gdy zasilanie DRAM jest włączone podczas ponownego uruchamiania).

Ponowne uruchomienie znacznika funkcji depozytu

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-u dotycząca restartu

Aby użyć implementacji domyślnej, musisz zarezerwować 65 536 (0x10000) bajtów. Nigdy nie zapisuj tych bajtów w pamięci trwałej, aby zachować właściwości zabezpieczeń.

Zmiany drzewa urządzeń z jądra systemu Linux

W drzewie urządzenia jądra Linuksa musisz zarezerwować pamięć dla regionu pmem. Ten przykład pokazuje zarezerwowanie obiektu 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 dodać do vendor/<oem>/<product>/device.mk 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