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 odblokowuje pamięć CE (z szyfrowaniem danych uwierzytelniających).

Partnerzy mogą połączyć ten proces z funkcją systemu OTA, która stosuje aktualizacje, gdy Android 11 jest bezczynny, 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ć, żeby 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. Implementacja funkcji bezpośredniego rozruchu zapewniła użytkownikom większą wygodę, zanim po uruchomieniu konieczne było wprowadzenie współczynnika wiedzy na 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żeń

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 odblokowane przez użytkownika 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.

Dane pamięci CE nie mogą być odczytywane przez osobę przeprowadzającą atak, która fizycznie ma dane urządzenie, z tymi możliwościami i ograniczeniami:

Potencjał

  • Może podpisywać dowolne wiadomości kluczem podpisywania dowolnego dostawcy lub firmy.
  • 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 Androida 12 RoR zapewnia ochronę przed bardzo zaawansowanymi atakami. W ten sposób działa, gdy hasła i kody PIN na urządzeniu pozostają na urządzeniu – nigdy nie są wysyłane na serwery Google ani na nich przechowywane. Poniżej znajduje się omówienie procesu, który ma na celu zapewnienie, że dostarczane poziomy zabezpieczeń 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 obiekt tajny, który 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.
    • Następnie szyfruje dostawcę usług dwa razy: raz z użyciem klucza K_s zapisanego w pamięci RAM i ponownie za pomocą klucza K_k zapisanego w TEE.
    • Podwójnie szyfrowany dostawca usług jest przechowywany na dysku, który jest usuwany z pamięci RAM. Oba klucze są generowane na bieżąco i służą tylko do jednego restartu.
  • Przy ponownym uruchomieniu Android powierza K_s serwerowi. Pokwitowanie z K_k jest szyfrowane przed zapisaniem go na dysku.
  • Po ponownym uruchomieniu Android za pomocą 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żywane do odszyfrowywania dostawcy usług zapisanego na dysku.
    • Android korzysta z dostawcy usług, aby odblokować pamięć CE i umożliwić normalne uruchamianie aplikacji.
    • K_k i K_s zostały odrzucone.

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

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 również przejść bezproblemową weryfikację kodu PIN (ponowne odtworzenie z kodem SIM/PIN) po nienadzorowanym ponownym uruchomieniu, aby przywrócić połączenie komórkowe (niezbędne dla połączeń telefonicznych, SMS-ów i usług transmisji danych). Kod PIN do karty SIM i pasujące do niego informacje o karcie SIM (numer ICCID oraz numer gniazda karty SIM) są bezpiecznie przechowywane razem. Zapisany kod PIN można pobrać i użyć do weryfikacji tylko po udanym ponownym uruchomieniu bez nadzoru. Jeśli urządzenie jest zabezpieczone, kod PIN do karty SIM jest przechowywany wraz z kluczami chronionymi przez LSKF. Jeśli kod PIN na karcie SIM ma włączony kod PIN, do aktualizacji OTA wymaga połączenia Wi-Fi, które po ponownym uruchomieniu zapewnia podstawowe działanie (z połączeniami komórkowymi).

Kod PIN do karty SIM jest ponownie szyfrowany i zapisywany za każdym razem, gdy użytkownik go włączy, zweryfikuje lub zmieni. 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 raz po zrestartowaniu zainicjowanym przez 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 działające w multiklientach i na serwerze zmniejszają obciążenie partnerów, gdy przesyłają aktualizacje OTA. Niezbędne aktualizacje mogą być wykonywane w dogodnych czasie przestoju, 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 zniwelować emisję światła. Aby to zrobić, program rozruchowy urządzenia wyszuka ciąg unattended. Jeśli unattended ma wartość true, włącz tryb ciemny na urządzeniu. Pamiętaj, że to każdy OEM jest odpowiedzialny za ograniczanie emisji dźwięku i światła.

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 stosować, ponieważ w Androidzie 12 protokół HAL został wycofany.

Menedżer telefonii

Klient OTA wywołuje systemowy interfejs API TelephonyManager po ponownym uruchomieniu Androida 12. Ten interfejs API przenosi wszystkie kody PIN zapisane w pamięci podręcznej ze stanu AVAILABLE do stanu REBOOT_READY. Systemowy interfejs API TelephonyManager jest chroniony przez istniejące uprawnienia w 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()

Systemowy interfejs API TelephonyManager jest używany przez pliki APK z podwyższonymi uprawnieniami.

Testowanie

Aby przetestować nowy interfejs API, uruchom to polecenie:

    adb shell cmd phone unattended-reboot

To polecenie działa tylko wtedy, gdy powłoka jest uruchomiona jako użytkownik root (adb root).

Tylko Android 11

Pozostała część tej strony dotyczy Androida 11.

Od lipca 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:
    • Mieć możliwość wykrycia ponownego uruchomienia procesora.
    • Mieć sprzętowe źródło licznika czasu, które pozostaje ustawione po ponownym uruchomieniu. Oznacza to, że enklawa musi mieć możliwość wykrycia ponownego uruchomienia i upływu czasu ustawionego przed ponownym uruchomieniem.
    • Obsługa przechowywania zdekodowanego klucza w pamięci RAM/ROM enklawy, aby nie można było go odzyskać za pomocą ataków offline. Musi przechowywać klucz RoR w sposób uniemożliwiający osobom wtajemniczonym lub przeprowadzającym atak.

Domyślny depozyt pamięci RAM

AOSP ma wdrożenie algorytmu RoR HAL na podstawie trwałości 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. W poniższej sekcji znajdziesz odpowiednie materiały kanoniczne na ten temat.

Proces aktualizacji OTA za pomocą RoR

Aplikacja kliencka OTA na telefonie musi mieć uprawnienia Manifest.permission.REBOOT i Manifest.permission.RECOVERY do wywoływania metod niezbędnych do wdrożenia RoR. Po spełnieniu tych wymagań wstępnych proces aktualizacji przebiega w następujący sposób:

  1. Aplikacja kliencka OTA pobiera aktualizację.
  2. Klient OTA wywołuje RecoverySystem#prepareForUnattendedUpdate, co powoduje, że podczas następnego odblokowania użytkownik zobaczy prośbę o wpisanie kodu PIN, wzoru lub hasła na ekranie blokady.
  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 uruchomi się ponownie, a mechanizm RoR odblokowuje szyfrowaną dane logowania (CE). W aplikacjach jest to widoczne jako odblokowanie przez użytkownika, a więc otrzymuje wszystkie sygnały, takie jak ACTION_LOCKED_BOOT_COMPLETED i ACTION_BOOT_COMPLETED, które zwykle otrzymujesz.

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 być też dostępny znacznik cech:

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żywać implementacji domyślnej, musisz zarezerwować 65 536 (0x10 000) bajtów. Nigdy nie zapisuj tych bajtów w pamięci nieulotnej, aby zapewnić utrzymanie właściwości zabezpieczeń.

Zmiany drzewa urządzeń z jądrem Linuksa

W drzewie urządzenia jądra Linuksa musisz zarezerwować pamięć dla regionu pmem. Ten przykład pokazuje zarezerwowanie zasobu 0x50000000:

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

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

Sprawdź, czy w katalogu blokad znajduje się nowe urządzenie o nazwie takiej jak /dev/block/pmem0 (np. pmem1 lub pmem2).

Zmiany na urządzeniu Device.mk

Przy założeniu, ż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