Wznów przy ponownym uruchomieniu

W systemie Android 11 aktualizacje OTA można nanosić za pomocą mechanizmu 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 Resume-on-Reboot (RoR) odblokowuje pamięć urządzenia z szyfrowaniem poświadczeń (CE) .

Chociaż partnerzy mogą powiązać 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 serwera w systemie Android 12 razem zapewniają bezpieczeństwo na poziomie sprzętowym urządzenia.

Chociaż musisz zapewnić uprawnienia urządzenia dla funkcji android.hardware.reboot_escrow w celu obsługi RoR w systemie Android 11, nie musisz tego robić, aby włączyć RoR oparty na serwerze w systemie Android 12 i nowszych, ponieważ 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 przed koniecznością wprowadzenia współczynnika wiedzy o ekranie blokady (LSKF) po uruchomieniu.

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 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 atakującego, będzie mu niezwykle trudno odzyskać dane użytkownika zaszyfrowane CE, nawet jeśli urządzenie jest włączone, pamięć CE jest odblokowana, a urządzenie jest odblokowane przez użytkownika po otrzymaniu aktualizacji OTA. Odporność na ataki wewnętrzne musi być skuteczna, nawet jeśli atakujący uzyska dostęp do rozsyłanych kryptograficznych kluczy podpisujących.

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 podpisu 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 Ograniczeniach poniżej. (Jednak taka modyfikacja obejmuje zarówno opóźnienie o co najmniej jedną godzinę, jak i wyłączenie zasilania, które 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 działającego urządzenia.
  • Nie można odgadnąć poświadczeń użytkownika (PIN, wzór, hasło) ani w inny sposób spowodować ich wprowadzenia.

Rozwiązanie

System aktualizacji Androida 12 RoR zapewnia ochronę przed bardzo wyrafinowanymi atakami, a hasła i kody PIN na urządzeniu pozostają na urządzeniu – nigdy nie są wysyłane ani przechowywane na serwerach Google. To jest przegląd procesu, który zapewnia, że ​​zapewniane 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 uruchomiony system operacyjny przejdzie uwierzytelnianie kryptograficzne ( zweryfikowany rozruch ).
  • Usługa RoR działająca na serwerach Google zabezpiecza dane CE, przechowując poufne dane, które 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.
    • Gdy zaplanowane jest nocne ponowne uruchomienie, system Android prosi użytkownika o wprowadzenie kodu PIN, a następnie oblicza hasło syntetyczne (SP).
    • Następnie dwukrotnie szyfruje SP: 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 generowane i używane tylko do jednego ponownego uruchomienia .
  • Kiedy nadchodzi czas ponownego uruchomienia, Android powierza K_s serwerowi. Paragon z K_k zostaje zaszyfrowany przed zapisaniem na dysku.
  • Po ponownym uruchomieniu Android używa K_k do odszyfrowania paragonu, a następnie wysyła go do serwera w celu pobrania K_s .
    • K_k i K_s służą do odszyfrowania SP przechowywanego na dysku.
    • Android używa SP, aby odblokować pamięć CE i umożliwić normalne uruchamianie aplikacji.
    • K_k i K_s są odrzucane.

Aktualizacje zapewniające bezpieczeństwo telefonu mogą być przeprowadzane w dogodnym dla Ciebie czasie: podczas snu.

Odtwarzanie kodu PIN karty SIM

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 w celu przywrócenia łączności komórkowej (wymagane do połączeń telefonicznych, wiadomości SMS i usług transmisji danych). Kod PIN karty SIM i odpowiadające mu informacje o karcie SIM (identyfikator ICCID i numer gniazda karty SIM) są bezpiecznie przechowywane razem. Zapisany kod PIN można odzyskać i użyć do weryfikacji dopiero 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 RoR opartego na serwerze, 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 włączy, zweryfikuje lub zmodyfikuje go. Kod PIN karty SIM zostanie odrzucony, jeśli wystąpi jedna z poniższych sytuacji:

  • Karta SIM została usunięta lub zresetowana.
  • Użytkownik wyłącza PIN.
  • Wystąpił restart niezainicjowany 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 dane karty SIM są zgodne. Zapisany kod 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 serwerach zapewniają partnerom mniejsze obciążenie podczas przesyłania aktualizacji OTA. Niezbędne aktualizacje mogą mieć miejsce podczas dogodnych przestojów urządzenia, na przykład w wyznaczonych godzinach snu.

Aby aktualizacje OTA w takich okresach nie przeszkadzały użytkownikom, zastosuj tryb ciemny, aby ograniczyć emisję światła. Aby to zrobić, poproś program ładujący urządzenie o wyszukanie ciągu znaków powodującego unattended . Jeśli unattended to true , przełącz urządzenie w tryb ciemny. Należy pamiętać, że każdy producent OEM jest odpowiedzialny za ograniczenie emisji dźwięku i światła.

Jeśli przeprowadzasz aktualizację do Androida 12 lub uruchamiasz urządzenia z Androidem 12, nie musisz nic robić, aby zaimplementować nową funkcjonalność RoR.

W przepływie wielu klientów jest jedno nowe wywołanie, 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ż HAL jest przestarzały od Androida 12.

Menedżer telefonii

Klient OTA wywołuje interfejs API systemu 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 . API systemu TelephonyManager jest chronione istniejącym uprawnieniem 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 podczas ponownego uruchamiania, producenci OEM mogą korzystać z domyślnej implementacji w AOSP ( domyślny depozyt pamięci RAM ).
  2. Jeśli sprzęt urządzenia lub SoC 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 zegara sprzętowego, które utrzymuje się podczas ponownego uruchamiania. Oznacza to, że enklawa musi być w stanie wykryć ponowne uruchomienie i wygasnąć czasomierz ustawiony przed ponownym uruchomieniem.
    • Obsługa przechowywania zdeponowanego klucza w pamięci RAM/ROM enklawy w taki sposób, że nie można go odzyskać za pomocą ataków offline. Musi przechowywać klucz RoR w sposób uniemożliwiający osobom poufnym lub atakującym odzyskanie go.

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 ponownego uruchamiania. Niektóre układy SoC nie są w stanie zachować zawartości pamięci RAM po ponownym uruchomieniu, dlatego producentom OEM zaleca się skonsultowanie się z partnerami w zakresie układów SoC przed włączeniem tej domyślnej warstwy HAL. Kanoniczne odniesienie do tego w następnej sekcji.

Przebieg aktualizacji OTA przy użyciu RoR

Aplikacja kliencka OTA na telefonie musi mieć uprawnienia Manifest.permission.REBOOT i Manifest.permission.RECOVERY , aby wywołać metody niezbędne do wdrożenia RoR. Po spełnieniu tego warunku wstępnego przebieg aktualizacji obejmuje następujące kroki:

  1. Aplikacja kliencka OTA pobiera aktualizację.
  2. Aplikacja kliencka OTA wywołuje RecoverySystem#prepareForUnattendedUpdate , co powoduje, że użytkownik jest proszony 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. Wywołania aplikacji klienckiej OTA do RecoverySystem#rebootAndApply , co natychmiast uruchamia ponowne uruchomienie.

Na końcu tego przepływu urządzenie uruchamia się ponownie, a mechanizm RoR odblokowuje magazyn zaszyfrowany poświadczeniami (CE). Dla aplikacji wygląda to jak zwykłe odblokowanie użytkownika, więc otrzymują one wszystkie sygnały, takie jak ACTION_LOCKED_BOOT_COMPLETED i ACTION_BOOT_COMPLETED , które zwykle wysyłają.

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 korzystających z ciepłego restartu (gdy zasilanie pamięci DRAM pozostaje włączone podczas ponownego uruchamiania).

Zrestartuj znacznik funkcji Escrow

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 HAL depozytu ponownego uruchomienia

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

Zmiany w drzewie urządzeń jądra Linuksa

W drzewie urządzeń jądra Linuksa musisz zarezerwować pamięć dla regionu pmem . Poniższy przykład pokazuje rezerwację 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 w 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
reguły SELinuksa

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