Wznów po ponownym uruchomieniu

W systemie Android 11 aktualizacje OTA można zastosować 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 Resume-on-Reboot (RoR) odblokowuje pamięć urządzenia Credential Encrypted (CE) .

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

Chociaż musisz przyznać uprawnienia urządzenia, aby funkcja android.hardware.reboot_escrow obsługiwała RoR w systemie Android 11, nie musisz tego robić, aby włączyć RoR oparty na serwerze w systemie Android 12 i nowszych wersjach, ponieważ nie używają one 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 konieczne było wprowadzenie współczynnika wiedzy o ekranie blokady (LSKF).

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

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

Możliwości

  • Może używać klucza podpisującego 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 wiąże się zarówno z co najmniej godzinnym opóźnieniem, jak i wyłączeniem 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 urządzenia na żywo.
  • Nie można odgadnąć danych uwierzytelniających użytkownika (kodu PIN, wzoru, hasła) ani w inny sposób spowodować ich wprowadzenia.

Rozwiązanie

System aktualizacji RoR do Androida 12 zapewnia ochronę przed bardzo wyrafinowanymi atakami i robi to tak długo, jak hasła i kody PIN na urządzeniu pozostają na nim – nigdy nie są wysyłane ani przechowywane na serwerach Google. Oto przegląd procesu, który zapewnia, że ​​poziomy bezpieczeństwa są podobne do systemu RoR opartego na sprzęcie i 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 ( rozruch zweryfikowany ).
  • Usługa RoR działająca na serwerach Google zabezpiecza dane CE, przechowując tajemnicę, którą 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 nośnika CE.
    • Gdy zaplanowane jest ponowne uruchomienie w ciągu nocy, system Android monituje 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. Obydwa klucze są świeżo wygenerowane i użyte tylko do jednego ponownego uruchomienia .
  • Kiedy nadejdzie 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 potwierdzenia, a następnie wysyła je do serwera w celu pobrania K_s .
    • K_k i K_s służą 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 zapewniające bezpieczeństwo Twojego telefonu mogą odbywać się w dogodnym dla Ciebie czasie: podczas snu.

Ponowne odtwarzanie PIN-u SIM

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

Karta SIM z włączonym kodem PIN musi również przejść bezproblemową weryfikację kodu PIN (powtórne odtworzenie kodu PIN karty SIM) po nienadzorowanym ponownym uruchomieniu, aby przywrócić łączność komórkową (wymaganą 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 (identyfikator ICCID i numer gniazda SIM) są bezpiecznie przechowywane razem. Zapisany kod PIN można odzyskać i wykorzystać do weryfikacji dopiero po pomyślnym, nienadzorowanym ponownym uruchomieniu. Jeśli urządzenie jest zabezpieczone, PIN karty SIM jest przechowywany z kluczami chronionymi przez LSKF. Jeśli karta SIM ma włączony 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 go włączy, zweryfikuje lub zmodyfikuje. PIN karty SIM zostanie odrzucony, jeśli wystąpi którakolwiek z poniższych sytuacji:

  • Karta SIM została wyjęta lub zresetowana.
  • Użytkownik dezaktywuje PIN.
  • Nastąpiło ponowne uruchomienie niezainicjowane przez RoR.

Zapisany PIN karty SIM może zostać 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 PIN karty SIM nigdy nie opuszcza aplikacji TelephonyManager i nie może zostać odzyskany przez moduły zewnętrzne.

Wytyczne wdrożeniowe

W systemie Android 12 funkcje RoR oparte na wielu klientach i serwerze zapewniają mniejsze obciążenie partnerom podczas przesyłania aktualizacji OTA. Niezbędne aktualizacje mogą nastąpić w dogodnych przestojach urządzenia, np. w wyznaczonych godzinach snu.

Aby mieć pewność, że aktualizacje OTA w takich okresach nie będą przeszkadzać użytkownikom, użyj trybu ciemnego, aby ograniczyć emisję światła. Aby to zrobić, poproś program ładujący urządzenia o unattended wyszukiwanie ciągu znaków. Jeśli unattended ma wartość true , przełącz urządzenie w tryb ciemny. Należy pamiętać, że obowiązkiem każdego producenta OEM jest ograniczenie emisji dźwięku i światła.

Jeśli aktualizujesz system do Androida 12 lub uruchamiasz urządzenia z Androidem 12, nie musisz nic robić, aby wdrożyć nową funkcjonalność RoR.

W przepływie wielu klientów istnieje 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ż warstwa HAL jest przestarzała od wersji Androida 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 . Interfejs API systemu TelephonyManager jest chroniony istniejącym uprawnieniem 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 API systemu TelephonyManager jest używany przez uprzywilejowane pliki APK.

Testowanie

Aby przetestować nowe 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 systemu Android 11.

Od lipca 2020 r. wdrożenia RoR HAL można podzielić 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 ( domyślny depozyt 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), musi dodatkowo wykonać następujące czynności:
    • Być w stanie wykryć ponowne uruchomienie głównego procesora.
    • Posiadaj sprzętowe źródło licznika czasu, które będzie działać 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 że nie można go odzyskać w przypadku ataków offline. Musi przechowywać klucz RoR w sposób uniemożliwiający osobom z wewnątrz 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 po ponownym uruchomieniu. Niektóre układy SoC nie są w stanie zachować zawartości pamięci RAM po ponownym uruchomieniu komputera, dlatego producentom OEM zaleca się skonsultowanie się ze swoimi partnerami w zakresie układów SoC przed włączeniem domyślnej warstwy HAL. Kanoniczne odniesienie do tego w poniższej 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ływać metody niezbędne do wdrożenia RoR. Po spełnieniu tego warunku proces aktualizacji przebiega według następujących kroków:

  1. Aplikacja kliencka OTA pobiera aktualizację.
  2. Aplikacja kliencka OTA wywołuje funkcję 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 funkcję RecoverySystem#rebootAndApply , co natychmiast powoduje ponowne uruchomienie.

Pod koniec tego przepływu urządzenie uruchamia się ponownie, a mechanizm RoR odblokowuje pamięć zaszyfrowaną poświadczeniami (CE). W przypadku aplikacji wygląda to na 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ą.

Zmodyfikuj konfiguracje produktu

Produkt oznaczony jako obsługujący funkcję RoR w systemie Android 11 musi zawierać implementację warstwy HAL RebootEscrow i plik XML znacznika funkcji. Domyślna implementacja działa dobrze na urządzeniach, które korzystają z ciepłego ponownego uruchomienia (kiedy zasilanie pamięci DRAM pozostaje włączone podczas ponownego uruchamiania).

Uruchom ponownie znacznik funkcji Escrow

Znacznik cechy musi również być 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 skorzystać z domyślnej implementacji, należy zarezerwować 65536 (0x10000) bajtów. Nigdy nie zapisuj tych bajtów w pamięci nieulotnej, aby mieć pewność, że właściwości zabezpieczeń zostaną zachowane.

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, że 0x50000000 jest zarezerwowane:

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Sprawdź, czy masz nowe urządzenie w katalogu bloków o nazwie takiej jak /dev/block/pmem0 (np. pmem1 lub pmem2 ).

Zmiany w Device.mk

Zakładając, że Twoje nowe urządzenie z poprzedniego kroku ma 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 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