Wznawianie po restarcie

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. Po ponownym uruchomieniu urządzenia w celu zastosowania aktualizacji OTA funkcja wznowienia po ponownym uruchomieniu (RoR) odblokowuje zaszyfrowane dane uwierzytelniające (CE) na urządzeniu.

Partnerzy mogą połączyć ten proces z funkcją systemu OTA, która stosuje aktualizacje, gdy urządzenie jest nieaktywne (w Androidzie 11). W Androidzie 12 partnerzy nie potrzebują dodatkowej funkcji systemu OTA. 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 na serwerze w Androidzie 12 zapewniają ochronę na poziomie sprzętu.

Aby funkcja android.hardware.reboot_escrow obsługiwała RoR w Androidzie 11, musisz przyznać jej uprawnienia na urządzeniu. Nie musisz tego robić, aby włączyć RoR na podstawie serwera w Androidzie 12 lub nowszym, ponieważ te wersje nie korzystają z interfejsu 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 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 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. Odporność na ataki wewnątrz organizacji musi być skuteczna nawet wtedy, gdy atakujący uzyska dostęp do kluczy podpisywania kryptograficznego do transmisji.

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 spowodować, że urządzenie otrzyma aktualizację OTA.
  • Może modyfikować działanie dowolnego sprzętu (np. procesora aplikacji lub pamięci flash) – z wyjątkiem opisanych poniżej ograniczeń. (jednak taka modyfikacja wymaga co najmniej 1 godziny opóźnienia i cyklu zasilania, który powoduje utratę zawartości pamięci RAM).

Ograniczenia

  • Nie można modyfikować działania sprzętu chronionego przed ingerencją (np. Titan M).
  • Nie można odczytać pamięci RAM na urządzeniu.
  • nie może odgadnąć danych logowania użytkownika (kodu PIN, wzoru lub hasła) ani w inny sposób spowodować ich wpisania;

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 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_s przechowywanego w pamięci RAM, a następnie za pomocą klucza K_k przechowywanego w TEE.
    • Podwójnie zaszyfrowany klucz SP jest przechowywany na dysku, a klucz SP zostaje wymazany z pamięci RAM. Oba klucze są nowo wygenerowane i używane tylko podczas jednego ponownego uruchamiania.
  • Gdy nadszedł czas ponownego uruchomienia, Android powierza K_s serwerowi. Potwierdzenie z K_k jest szyfrowane przed zapisaniem na dysku.
  • Po ponownym uruchomieniu Android używa K_k do odszyfrowania potwierdzenia, a następnie wysyła je na serwer, aby pobrać K_s.
    • K_k i K_s służą do odszyfrowywania SP zapisanego na dysku.
    • Android używa SP do odblokowania pamięci CE i zapewnienia normalnego uruchamiania aplikacji.
    • Wartości K_k i K_s są odrzucane.

Aktualizacje, które zapewniają bezpieczeństwo telefonu, mogą być instalowane w dogodnym dla Ciebie czasie, np. gdy śpisz.

Odtwarzanie kodu PIN karty SIM

W pewnych warunkach kod PIN karty SIM jest weryfikowany z poziomu pamięci podręcznej. Proces ten nazywa się odtwarzaniem 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. Zapisany 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 karty SIM jest przechowywany z kluczami chronionymi przez klucz 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 karty SIM jest odrzucany, jeśli wystąpi jedno z tych zdarzeń:

  • Karta SIM została usunięta lub zresetowana.
  • Użytkownik wyłącza kod PIN.
  • Wystąpił restart nieinicjowany przez RoR.

Zapisany kod PIN karty SIM może zostać użyty tylko raz po ponownym uruchomieniu urządzenia w ramach funkcji przywracania do poprzedniego stanu i tylko przez bardzo krótki czas (20 sekund) – jeśli dane karty SIM są zgodne. Zapisany PIN karty SIM nigdy nie opuszcza aplikacji TelephonyManager i nie może być odebrany przez moduły zewnętrzne.

Wskazówki 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ć, sprawdź, czy program rozruchowy urządzenia wyszukuje ciąg znaków reason unattended. Jeśli unattended = true, przełącz urządzenie w tryb ciemny. Pamiętaj, że ograniczanie emisji dźwięku i światła jest obowiązkiem każdego producenta 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 wieloklientowym isPreparedForUnattendedUpdate jest 1 nowe wywołanie, jak pokazano 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ż interfejs HAL został wycofany w Androidzie 12.

TelephonyManager

Klient OTA wywołuje interfejs API systemu TelephonyManager, gdy zbliża się czas ponownego uruchamiania systemu 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 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).
  2. Jeśli sprzęt urządzenia lub układ SoC obsługuje bezpieczną enklawę sprzętową (oddzielny procesor zabezpieczeń z własną pamięcią RAM i ROM), musi dodatkowo:
    • wykryć ponowne uruchomienie głównego procesora;
    • mieć źródło zegara sprzętowego, które jest zachowane 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 klucza w escrow w pamięci RAM/ROM enklawy, tak aby nie można było go odzyskać w ramach ataków offline. Klucz RoR musi być przechowywany w taki sposób, aby uniemożliwić jego odzyskanie osobom z wewnętr firmy lub atakującym.

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ą 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 zachować zawartości pamięci RAM po ponownym uruchomieniu, dlatego przed włączeniem domyślnego interfejsu HAL OEM-y powinny skonsultować się z partnerami, którzy dostarczają układy SoC. Pełny opis znajdziesz 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:

  1. Aplikacja klienta 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. Użytkownik odblokowuje urządzenie na ekranie blokady i urządzenie jest gotowe do zainstalowania aktualizacji.
  4. Aplikacja kliencka OTA wywołuje funkcję RecoverySystem#rebootAndApply, która natychmiast powoduje ponowne uruchamianie.

Na końcu tego procesu urządzenie uruchamia się ponownie, a mechanizm RoR odblokowuje pamięć szyfrowaną (CE) z danymi logowania. 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ć implementację interfejsu HAL RebootEscrow i plik XML z oznaczeniem funkcji. 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-u dotycząca ponownego uruchamiania

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 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 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 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