Wznawianie po ponownym uruchomieniu

W Androidzie 11 aktualizacje OTA można stosować przy użyciu aktualizacji A/B. lub wirtualnej aktualizacji A/B w połączeniu z przy użyciu systemu RecoverySystem i metod klas. Po ponownym uruchomieniu urządzenia w celu zastosowania aktualizacji OTA funkcja wznowienia po ponownym uruchomieniu (Resume-on-Reboot, RoR) odblokowuje zaszyfrowane dane uwierzytelniające (CE).

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

chociaż musisz udzielić zgody na korzystanie z urządzenia android.hardware.reboot_escrow obsługuje RoR w Androidzie 11, nie musisz tego robić, oparte na serwerach RoR w Androidzie 12 i nowszych, ponieważ nie używaj 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 funkcji bezpośredniego rozruchu zapewniło użytkownikom przed podaniem współczynnika wiedzy na ekranie blokady (LSKF). po rozruchu.

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. Funkcja ta umożliwia użytkownikom otrzymywanie powiadomień ze wszystkich swoich zainstalowane aplikacje, po ponownym uruchomieniu.

Model zagrożeń

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. Zespół wewnętrzny odporność na atak musi być skuteczna, nawet jeśli atakujący uzyska dostęp do przesyłanie kryptograficznych kluczy podpisywania.

W szczególności pamięć CE nie może być odczytywana przez osobę przeprowadzającą atak, która fizycznie oraz ma te możliwości i ograniczenia:

Potencjał

  • Może używać klucza podpisywania dowolnego dostawcy lub firmy do podpisywania dowolnych wiadomości.
  • Może powodować otrzymywanie aktualizacji 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 opóźnienia o co najmniej godzinę 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 aktywnego urządzenia.
  • 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 Androida 12 RoR zapewnia bezpieczeństwo przed bardzo zaawansowanymi atakami. Czyli tylko hasła na urządzeniu Kody PIN pozostają na urządzeniu – nigdy nie są wysyłane na serwery Google ani na nich przechowywane. Ten Omówienie procesu, który zapewnia poziom zabezpieczeń podobny do sprzętowego systemu RoR na poziomie urządzenia:

  • Android stosuje zabezpieczenia kryptograficzne do danych przechowywanych na urządzeniu.
  • Wszystkie dane są chronione przez klucze przechowywane 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.
  • Do odblokowywania urządzenia używany jest klucz kryptograficzny chroniony kodem PIN użytkownika i odszyfrować pamięć CE.
    • Gdy zaplanowano ponowne uruchomienie w nocy, Android prosi użytkownika o wprowadzenie dla kodu PIN, a następnie oblicza hasło syntetyczne (SP).
    • Następnie szyfruje dostawcę usług dwa razy: raz za pomocą klucza K_s zapisanego w pamięci RAM i ponownie za pomocą klucza K_s z kluczem K_k zapisanym w TEE.
    • Podwójnie szyfrowany dostawca usług jest przechowywany na dysku, który jest usuwany z pamięci RAM. Oba klucze są nowo wygenerowane i używane tylko podczas jednego ponownego uruchamiania.
  • Przy ponownym uruchomieniu Android powierza K_s serwerowi. Potwierdzenie z K_k jest szyfrowane przed zapisaniem na dysku.
  • Po ponownym uruchomieniu Android odszyfrowuje potwierdzenie za pomocą K_k, a następnie wysyła je na serwer, który będzie pobierać K_s.
    • K_k i K_s służą do odszyfrowywania SP 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 czasie dla Ciebie: podczas snu.

Odtwarzanie kodu PIN karty SIM

W pewnych warunkach kod PIN karty SIM jest weryfikowany z pamięci podręcznej, To proces nazywany ponownym odtwarzaniem karty SIM z kodem PIN.

Karta SIM z włączonym kodem PIN również musi przejść kod PIN bez zakłóceń. weryfikacja (ponowne odtworzenie kodu SIM i kodu PIN) po ponownym uruchomieniu bez nadzoru w celu przywrócenia sieci komórkowej; połączenia (wymagane do połączeń telefonicznych, SMS-ów i usług transmisji danych); kod PIN do karty SIM i odpowiednie informacje o karcie SIM (identyfikator ICCID oraz gniazdo karty SIM); są bezpiecznie przechowywane razem. Zdjęty 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 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 do karty SIM zostanie odrzucony, jeśli wystąpi jedna z tych sytuacji następuje:

  • 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. tylko przez bardzo krótki czas (20 sekund) – jeśli dane karty SIM są szczegółowe. są takie same. Zapisana karta SIM nigdy nie opuszcza aplikacji TelephonyManager i nie może być odzyskiwana przez moduły zewnętrzne.

Wytyczne dotyczące implementacji

Na Androidzie 12 multiklient i serwerowy wskaźnik RoR zmniejsza obciążenie partnerom podczas przekazywania aktualizacji OTA. Niezbędne aktualizacje mogą wystąpić podczas dogodnych przerw w działaniu urządzenia, np. w określonych godzinach snu.

Aby mieć pewność, że aktualizacje OTA w takich okresach nie będą przeszkadzać użytkownikom, wdrożyliśmy tryb ciemny w celu ograniczenia emisji światła. Aby to zrobić, sprawdź, czy program rozruchowy urządzenia wyszukuje ciąg znaków reason unattended. Jeśli unattended = true, włącz tryb ciemny na urządzeniu. 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:

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

Nie musisz tego wdrażać, ponieważ HAL został wycofany w Androidzie 12.

TelephonyManager

Klient OTA wywołuje interfejs API systemu TelephonyManager, gdy zbliża się czas ponownego uruchamiania urządzenia w Androidzie 12. Ten interfejs API przenosi wszystkie kody PIN zapisane w pamięci podręcznej z stan AVAILABLE na 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()

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 działa jako 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żywać funkcji domyślna implementacja w AOSP (Default RAM Escrow).
  2. Jeśli urządzenie lub układ SOC obsługuje bezpieczną enklawę sprzętową (oddzielną przez współprocesora zabezpieczeń z własną pamięcią RAM i ROM), dodatkowo musi wykonać :
    • 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 wygaśnięcia licznika czasu ustawionego przed i uruchomić ponownie.
    • Obsługa przechowywania zdekodowanego klucza w pamięci RAM/ROM enklawy, tak aby nie można było z niego korzystać które można odzyskać za pomocą ataków offline. Klucz RoR musi być przechowywany w taki sposób, aby uniemożliwić jego odzyskanie osobom z wewnętrznego zespołu 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 powinni skonsultować się z partnerami, którzy dostarczają układy SoC. Pełna informacja na ten temat znajduje się w następnej sekcji.

Proces aktualizacji OTA za pomocą 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 kliencka OTA pobiera aktualizację.
  2. Wywołania aplikacji klienta OTA pod adresem RecoverySystem#prepareForUnattendedUpdate, które powoduje wyświetlenie prośby o podanie kodu PIN, wzoru lub hasła na blokady ekranu podczas następnego odblokowania.
  3. Użytkownik odblokowuje urządzenie na ekranie blokady i urządzenie jest gotowe do zainstalowania aktualizacji.
  4. Klient OTA wywołuje metodę RecoverySystem#rebootAndApply, która natychmiast uruchamia restart.

Na końcu tego procesu urządzenie uruchamia się ponownie, a mechanizm RoR odblokowuje pamięć szyfrowaną (CE) z danymi logowania. W przypadku aplikacji będzie widoczny jako odblokowany przez normalnego użytkownika, dzięki czemu będzie otrzymywać wszystkie sygnały, takie jak ACTION_LOCKED_BOOT_UKOŃCZONO oraz ACTION_BOOT_COMPLETED co zwykle.

Modyfikowanie konfiguracji produktów

Produkt oznaczony jako obsługujący funkcję RoR w Androidzie 11 musi zawierać wdrożenie kodu HAL RestartEscrow HAL i dołączenie pliku XML znacznika cech. Domyślna implementacja działa dobrze na urządzeniach, które korzystają z ponownego uruchamiania (gdy zasilanie DRAM pozostaje włączone podczas ponownego uruchamiania).

Ponowne uruchomienie znacznika funkcji depozytu

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 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 trwałej, aby zapewnić trwałość 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 bloków znajduje się nowe urządzenie o nazwie takiej jak /dev/block/pmem0 (np. pmem1 lub pmem2).

Zmiany na urządzeniu Device.mk

Zakładając, że nowe urządzenie z poprzedniego kroku ma nazwę pmem0, musisz upewnij się, że do vendor/<oem>/<product>/device.mk zostały dodane 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