Wznów przy ponownym uruchomieniu

W systemie Android 11 aktualizacje OTA można stosować za pomocą mechanizmów aktualizacji A/B lub wirtualnych aktualizacji A/B w połączeniu z metodami klasy RecoverySystem . Po ponownym uruchomieniu urządzenia w celu zastosowania aktualizacji OTA funkcja Resume-on-Reboot (RoR) odblokowuje pamięć masową z szyfrowaniem poświadczeń (CE) urządzenia .

Chociaż partnerzy mogą sparować ten proces z funkcją systemu OTA, która stosuje aktualizacje, gdy urządzenie ma być bezczynne w systemie Android 11, w systemie Android 12 partnerzy nie potrzebują dodatkowej funkcji systemu OTA. Proces RoR zapewnia użytkownikom dodatkowe bezpieczeństwo i wygodę, ponieważ aktualizacje mogą być dokonywane w czasie bezczynności urządzenia, podczas gdy funkcje aktualizacji dla wielu klientów i na serwerze Androida 12 zapewniają bezpieczeństwo na poziomie sprzętowym urządzenia.

Chociaż musisz podać uprawnienia urządzenia, aby funkcja android.hardware.reboot_escrow obsługiwała RoR w systemie Android 11, nie musisz tego robić, aby włączyć oparte na serwerze RoR w systemie Android 12 i nowszych, ponieważ nie używają one warstwy HAL.

zapewnić uprawnienia urządzenia dla funkcji android.hardware.reboot_escrow . Nie musisz nic robić, aby włączyć oparte na serwerze RoR w systemie Android 12, ponieważ Android 12 i nowsze nie używają warstwy HAL.

Tło

Począwszy od systemu Android 7, system Android obsługuje funkcję Direct Boot , która umożliwia uruchamianie aplikacji na urządzeniu przed odblokowaniem pamięci CE przez użytkownika. Wdrożenie obsługi bezpośredniego rozruchu zapewniło użytkownikom lepsze wrażenia, zanim po uruchomieniu trzeba było wprowadzić współczynnik wiedzy o zablokowanym ekranie (LSKF).

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

Model zagrożenia

Implementacja RoR musi gwarantować, że gdy urządzenie wpadnie w ręce osoby atakującej, niezwykle trudno będzie jej odzyskać dane użytkownika zaszyfrowane przez CE, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana, a urządzenie jest odblokowane przez użytkownik po otrzymaniu aktualizacji OTA. Odporność na ataki wewnętrzne musi być skuteczna, nawet jeśli atakujący uzyska dostęp do rozgłaszanych kryptograficznych kluczy podpisywania.

W szczególności pamięć CE nie może być odczytywana przez atakującego, który fizycznie posiada urządzenie i ma następujące możliwości i ograniczenia:

Możliwości

  • 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 (takiego jak procesor aplikacji lub pamięć flash) — z wyjątkiem przypadków opisanych w sekcji Ograniczenia poniżej. (Jednak taka modyfikacja obejmuje zarówno opóźnienie o co najmniej godzinę, jak i cykl zasilania, który niszczy zawartość pamięci RAM.)

Ograniczenia

  • Nie można modyfikować działania sprzętu odpornego na manipulacje (na przykład Titan M).
  • Nie można odczytać pamięci RAM urządzenia na żywo.
  • Nie można odgadnąć poświadczeń użytkownika (kodu PIN, wzoru, hasła) ani w inny sposób spowodować ich wprowadzenia.

Rozwiązanie

System aktualizacji Androida 12 RoR zapewnia ochronę przed bardzo wyrafinowanymi hakerami i robi to, gdy hasła i kody PIN pozostają na urządzeniu — nigdy nie są wysyłane ani przechowywane na serwerach Google. Oto przegląd procesu, który zapewnia, że ​​podane poziomy bezpieczeństwa są podobne do sprzętowego systemu RoR na poziomie urządzenia:

  • Android stosuje zabezpieczenia kryptograficzne do danych przechowywanych na urządzeniu.
  • Wszystkie dane są chronione kluczami przechowywanymi w zaufanym środowisku wykonawczym (TEE).
  • TEE zwalnia klucze tylko wtedy, gdy działający system operacyjny przejdzie uwierzytelnianie kryptograficzne ( zweryfikowany rozruch ).
  • Usługa RoR działająca na serwerach Google zabezpiecza dane CE, przechowując sekret, który można odzyskać tylko przez ograniczony czas . Działa to w całym ekosystemie Androida.
  • Klucz kryptograficzny, chroniony kodem PIN użytkownika, służy do odblokowania urządzenia i odszyfrowania pamięci CE.
    • Po zaplanowaniu nocnego ponownego uruchomienia system Android prosi użytkownika o wprowadzenie kodu PIN, a następnie oblicza hasło syntetyczne (SP).
    • Następnie szyfruje SP dwukrotnie: raz kluczem K_s przechowywanym w pamięci RAM i ponownie kluczem K_k przechowywanym w TEE.
    • Podwójnie zaszyfrowany SP jest przechowywany na dysku, a SP jest usuwany z pamięci RAM. Oba klucze są świeżo wygenerowane i używane tylko do jednego ponownego uruchomienia .
  • Kiedy nadejdzie czas na ponowne uruchomienie, Android powierza K_s serwerowi. Pokwitowanie z K_k jest szyfrowane przed zapisaniem na dysku.
  • Po ponownym uruchomieniu system Android używa K_k do odszyfrowania potwierdzenia, a następnie wysyła go na serwer w celu pobrania K_s .
    • K_k i K_s są używane do odszyfrowania SP przechowywanego na dysku.
    • Android używa SP do odblokowania pamięci CE i umożliwienia normalnego uruchamiania aplikacji.
    • K_k i K_s są odrzucane.

Aktualizacje, które zapewniają bezpieczeństwo telefonu, mogą się pojawić w dogodnym dla Ciebie czasie: podczas snu.

Powtórka SIM-PIN

W pewnych warunkach kod PIN karty SIM jest weryfikowany z pamięci podręcznej w procesie zwanym odtwarzaniem SIM-PIN.

Karta SIM z włączonym kodem PIN musi również przejść bezproblemową weryfikację kodu PIN (powtórka SIM-PIN) po nienadzorowanym ponownym uruchomieniu, aby przywrócić łączność komórkową (wymagane w przypadku połączeń telefonicznych, wiadomości SMS i usług transmisji danych). Kod PIN karty SIM i odpowiadające mu informacje o karcie SIM (numer ICCID i gniazdo karty SIM) są bezpiecznie przechowywane razem. Zapisany kod PIN można odzyskać i użyć do weryfikacji tylko po pomyślnym nienadzorowanym ponownym uruchomieniu. Jeśli urządzenie jest zabezpieczone, kod PIN 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 celu aktualizacji OTA i opartego na serwerze RoR, co zapewnia podstawową funkcjonalność (z łącznością komórkową) po ponownym uruchomieniu.

Kod PIN karty SIM jest ponownie szyfrowany i przechowywany za każdym razem, gdy użytkownik pomyślnie go włączy, zweryfikuje lub zmodyfikuje. Kod PIN karty SIM jest odrzucany, jeśli wystąpi jedna z następujących sytuacji:

  • Karta SIM została usunięta lub zresetowana.
  • Użytkownik wyłącza PIN.
  • Wystąpiło ponowne uruchomienie nie zainicjowane przez RoR.

Zapisany kod PIN karty SIM może być użyty tylko raz po ponownym uruchomieniu zainicjowanym przez RoR i tylko przez bardzo krótki czas (20 sekund) – jeśli szczegóły karty SIM są zgodne. Zapisany PIN karty SIM nigdy nie opuszcza aplikacji TelephonyManager i nie może zostać odzyskany przez zewnętrzne moduły.

Wytyczne wdrożeniowe

W systemie Android 12 funkcje RoR oparte na wielu klientach i serwerze zapewniają mniejsze obciążenie partnerów, gdy wysyłają aktualizacje OTA. Niezbędne aktualizacje mogą wystąpić podczas dogodnych przestojów urządzenia, na przykład w wyznaczonych godzinach snu.

Aby upewnić się, że aktualizacje OTA w takich okresach czasu nie przeszkadzają użytkownikom, zastosuj tryb ciemny, aby złagodzić emisje światła. Aby to zrobić, niech bootloader urządzenia wyszuka ciąg znaków unattended . Jeśli unattended jest true , przełącz urządzenie w tryb ciemny. Należy pamiętać, że każdy producent OEM odpowiada za ograniczenie emisji dźwięku i światła.

Jeśli przeprowadzasz aktualizację do systemu Android 12 lub uruchamiasz urządzenia z systemem Android 12, nie musisz nic robić, aby wdrożyć nową funkcję RoR.

Istnieje jedno nowe wywołanie w przepływie wielu klientów, isPreparedForUnattendedUpdate , pokazane poniżej:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

Nie musisz tego implementować, ponieważ warstwa HAL jest przestarzała w systemie Android 12.

Menedżer telefonii

Klient OTA wywołuje systemowy interfejs API TelephonyManager , gdy zbliża się ponowne uruchomienie systemu Android 12. Ten interfejs API przenosi wszystkie buforowane kody PIN ze stanu AVAILABLE do stanu REBOOT_READY . System API TelephonyManager jest chroniony przez istniejące uprawnienie REBOOT Manifest.

 /**
    * 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 API systemu TelephonyManager jest używany przez uprzywilejowane pakiety APK.

Testowanie

Aby przetestować nowy interfejs API, wykonaj 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.

Od lipca 2020 r. wdrożenia RoR HAL dzielą się na dwie kategorie:

  1. Jeśli sprzęt SoC obsługuje trwałość pamięci RAM po ponownym uruchomieniu, producenci OEM mogą użyć domyślnej implementacji w AOSP ( Default RAM Escrow ).
  2. Jeśli sprzęt lub SoC urządzenia obsługuje bezpieczną enklawę sprzętową (dyskretny koprocesor bezpieczeństwa z własną pamięcią RAM i ROM), dodatkowo musi wykonać następujące czynności:
    • Być w stanie wykryć ponowne uruchomienie głównego procesora.
    • Mieć źródło czasomierza sprzętowego, które utrzymuje się po ponownym uruchomieniu. Oznacza to, że enklawa musi być w stanie wykryć ponowne uruchomienie i wygasnąć czas ustawiony przed ponownym uruchomieniem.
    • Obsługa przechowywania zdeponowanego klucza w enklawie RAM/ROM, tak aby nie można go było odzyskać za pomocą ataków offline. Musi przechowywać klucz RoR w sposób uniemożliwiający osobom postronnym lub atakującym jego odzyskanie.

Domyślny depozyt pamięci RAM

AOSP ma implementację RoR HAL wykorzystującą trwałość pamięci RAM. Aby to zadziałało, producenci OEM muszą upewnić się, że ich SoC obsługują trwałość pamięci RAM podczas ponownych uruchomień. Niektóre SoC nie są w stanie zachować zawartości pamięci RAM po ponownym uruchomieniu, dlatego zaleca się producentom OEM skonsultowanie się z partnerami SoC przed włączeniem domyślnej warstwy HAL. Odniesienie kanoniczne do tego w następnej sekcji.

Przepływ aktualizacji OTA za pomocą RoR

Aplikacja kliencka OTA na telefonie musi mieć uprawnienia Manifest.permission.REBOOT i Manifest.permission.RECOVERY , aby wywoływać metody niezbędne do wdrożenia RoR. Po spełnieniu tego wymagania wstępnego przepływ aktualizacji przebiega zgodnie z następującymi krokami:

  1. Aplikacja kliencka OTA pobiera aktualizację.
  2. Aplikacja kliencka OTA wywołuje RecoverySystem#prepareForUnattendedUpdate , co powoduje wyświetlenie monitu o podanie kodu PIN, wzoru lub hasła na ekranie blokady podczas następnego odblokowania.
  3. Użytkownik odblokowuje urządzenie na ekranie blokady, a urządzenie jest gotowe do zastosowania aktualizacji.
  4. Aplikacja kliencka OTA wywołuje RecoverySystem#rebootAndApply , co natychmiast wyzwala ponowne uruchomienie.

Pod koniec tego przepływu urządzenie uruchamia się ponownie, a mechanizm RoR odblokowuje magazyn zaszyfrowany poświadczeniami (CE). Dla aplikacji wygląda to jako normalne odblokowanie użytkownika, więc odbierają wszystkie sygnały, takie jak ACTION_LOCKED_BOOT_COMPLETED i ACTION_BOOT_COMPLETED , które zwykle robią.

Modyfikowanie konfiguracji produktów

Produkt oznaczony jako obsługujący funkcję RoR w systemie Android 11 musi zawierać implementację RebootEscrow HAL i zawierać plik XML znacznika 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).

Zrestartuj znacznik funkcji depozytu

Znacznik funkcji musi być również obecny:

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 warstwy HAL usługi depozytu ponownego uruchomienia

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

Zmiany w drzewie urządzeń jądra Linux

W drzewie urządzeń jądra Linux musisz zarezerwować pamięć dla regionu pmem . Poniższy przykład pokazuje zarezerwowanie 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 Device.mk

Zakładając, że nowe urządzenie z poprzedniego kroku nosi nazwę pmem0 , musisz upewnić się, że następujące nowe wpisy zostaną dodane do vendor/<oem>/<product>/device.mk :

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default
Zasady 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