Szyfrowanie oparte na plikach

Android 7.0 lub nowszy obsługuje szyfrowanie na podstawie plików (FBE). Szyfrowanie na podstawie plików umożliwia szyfrowanie różnych plików różnymi kluczami, które można odblokowywać niezależnie.

Z tego artykułu dowiesz się, jak włączyć szyfrowanie na podstawie plików na nowych urządzeniach i jak aplikacje systemowe mogą korzystać z interfejsów API bezpośredniego rozruchu, aby oferować użytkownikom zapewniają najlepsze i najbezpieczniejsze środowisko.

Wszystkie urządzenia z Androidem 10 lub nowszym wymagane do szyfrowania na podstawie plików.

Uwaga: W Androidzie 7.0–8.1 funkcja FBE nie jest zgodna z pamięcią adaptacyjną i nośników pamięci (takich jak karta SD) można używać tylko jako pamięci tradycyjnej. Android 9 FBE jest zgodna z pamięcią adaptacyjną.

Bezpośredni rozruch

Szyfrowanie na podstawie plików włącza nową funkcję wprowadzoną w Androidzie 7.0 o nazwie Bezpośrednie Rozruch. Bezpośredni rozruch umożliwia zaszyfrowanym urządzeniom uruchamianie urządzenia bezpośrednio z poziomu blokady ekranu. Wcześniej na zaszyfrowanych urządzeniach korzystających z pełnego dysku szyfrowania (FDE), użytkownicy muszą podać dane logowania, zanim jakiekolwiek dane przez co telefon nie może wykonywać wszystkich czynności poza podstawowymi operacji. Na przykład alarmy nie mogły działać, usługi ułatwień dostępu były niedostępne, telefony nie mogły odbierać połączeń, ale były ograniczone tylko do podstawowych funkcji operacji wybierania numerów alarmowych.

Wraz z wprowadzeniem szyfrowania opartego na plikach (FBE) i nowych interfejsów API ale aplikacje te mogą działać bez szyfrowania, w ograniczonym kontekście. Może się to zdarzyć, zanim użytkownicy udostępnią swoje danych logowania, a jednocześnie chronią prywatne informacje o użytkownikach.

Na urządzeniu obsługującym FBE każdy użytkownik urządzenia ma 2 lokalizacje pamięci masowej. dostępne dla aplikacji:

• Pamięć szyfrowana danych uwierzytelniających (CE), która jest domyślną lokalizacją przechowywania. i jest dostępna tylko po odblokowaniu urządzenia przez użytkownika.
• Szyfrowanie urządzenia (DE) – miejsce przechowywania dostępne zarówno w przypadku urządzeń, w trybie bezpośredniego uruchamiania i po odblokowaniu urządzenia przez użytkownika.

.

Uwaga: jeśli to możliwe, pliki powinny znajdować się w pamięci CE.

Takie rozdzielenie zwiększa bezpieczeństwo profili służbowych, ponieważ pozwala na dostęp do więcej niż jednego użytkownika, ponieważ szyfrowanie nie jest już oparte wyłącznie na hasło podczas uruchamiania.

Interfejs Direct Boot API umożliwia aplikacjom obsługującym szyfrowanie na dostęp do każdego z tych elementów nowe obszary. W cyklu życia aplikacji wprowadziliśmy zmiany, aby uwzględnić: powiadamiaj aplikacje, gdy pamięć CE użytkownika jest odblokowana w odpowiedzi na wprowadzenie danych logowania na ekranie blokady lub w profilu służbowym, dając praca . Urządzenia z Androidem 7.0 muszą obsługiwać nowe interfejsy API. niezależnie od tego, czy wdrożono FBE. Chociaż, bez Pamięć FBE, DE i CE zawsze będzie w stanie odblokowanym.

Pełna implementacja szyfrowania na podstawie plików w plikach Ext4 i F2FS są dostarczane w ramach projektu Android Open Source Project (AOSP) i wymagają włączone na urządzeniach, które spełniają wymagania. Producenci, którzy decydują się na korzystanie z FBE mogą rozważyć sposoby optymalizacji tej funkcji w oparciu o układ scalony (SOC).

Wszystkie niezbędne pakiety w AOSP zostały zaktualizowane tak, aby rozpoznawały bezpośrednie uruchamianie. Jednak jeśli producenci urządzeń używają niestandardowych wersji tych aplikacji, mogą będzie dążyć do tego, by były przynajmniej pakiety dostępne bez bezpośredniego rozruchu, tych usług:

• Usługi telefoniczne i telefon
• Metoda wprowadzania haseł na ekranie blokady

Przykłady i źródło

Android udostępnia referencyjną implementację szyfrowania opartego na plikach, vold (system/vold) udostępnia funkcję zarządzania urządzeniami pamięci masowej na urządzeniach z Androidem. Dodanie FBE zapewnia vold kilka nowych poleceń do zarządzania kluczami CE i DE wielu użytkowników. Dodatkowo do podstawowych zmian, aby korzystać z funkcji opartych na plikach szyfrowania w jądrze, w wielu pakietach systemowych, w tym Blokada ekranu i interfejs SystemUI zostały zmodyfikowane, aby obsługiwać FBE i Direct Funkcje uruchamiania. Należą do nich:

• AOSP Dialer (pakiety/aplikacje/telefon)
• Zegar biurkowy (pakiety/aplikacje/zegar biurkowy)
• LatinIME (pakiety/metody wejściowe/LatinIME)*
• Aplikacja Ustawienia (pakiety/aplikacje/ustawienia)*
• SystemUI (ramki/base/pakiety/SystemUI)*

* Aplikacje systemowe, które używają defaultToDeviceProtectedStorage atrybut w pliku manifestu

Więcej przykładów aplikacji i usług, które rozpoznają szyfrowanie, można znaleźć które można znaleźć, uruchamiając polecenie mangrep directBootAware w platforma lub katalog pakietów AOSP drzewo źródłowe.

Zależności

Aby bezpiecznie korzystać z implementacji FBE AOSP, urządzenie musi spełniać te zależności:

• Obsługa jądra w przypadku szyfrowania Ext4 lub F2FS.
• Mistrz kluczy obsługa protokołu HAL w wersji 1.0 lub nowszej. Brak wsparcia dla Keymaster 0.3, ponieważ nie zapewnia on niezbędnych możliwości ani nie zapewnia wystarczającą ochronę kluczy szyfrowania.
• Keymaster/Keystore oraz kontroler bramy musi być wdrożony w zaufanym działaniu Środowisko (TEE), które zapewnia ochronę kluczy DE, dzięki czemu nieautoryzowany system operacyjny (niestandardowy system operacyjny zainstalowany na urządzeniu) nie może po prostu żądać DE.
• Sprzętowe źródło zaufania i Weryfikacja podczas uruchamiania powiązane z inicjowaniem Keymaster są wymagane, aby klucze DE nie były które mogą być dostępne przez nieautoryzowany system operacyjny.

Implementacja

Po pierwsze i najważniejsze: aplikacje takie jak budziki, telefon i ułatwienia dostępu należy ustawić jako android:directBootAware według metody Direct rozruchu dla deweloperów.

Obsługa jądra systemu

Obsługa jądra systemu szyfrowania Ext4 i F2FS jest dostępna we wspólnym systemie Android jądra w wersji 3.18 lub nowszej. Aby ją włączyć w jądrze w wersji 5.1, lub wyższej, należy użyć funkcji:

CONFIG_FS_ENCRYPTION=y

W przypadku starszych jąder używaj CONFIG_EXT4_ENCRYPTION=y, jeśli System plików userdata to Ext4 lub użyj CONFIG_F2FS_FS_ENCRYPTION=y, jeśli masz urządzenie userdata System plików to F2FS.

Jeśli urządzenie obsługuje opcje administracyjne pamięci masowej lub użyj metadanych szyfrowania w pamięci wewnętrznej, włącz też opcje konfiguracji jądra systemu niezbędnych do szyfrowania metadanych, jak opisano w dokumentacji szyfrowania metadanych.

Oprócz sprawnej obsługi szyfrowania Ext4 lub F2FS producenci powinni włączyć akcelerację kryptograficzną, do szyfrowania plików i zwiększania wygody użytkowników. Na przykład na stronie Urządzenia z procesorem ARM64, akceleracja ARMv8 CE (Cryptography Extensions) może być włącza się przez ustawienie tych opcji konfiguracji jądra:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Aby jeszcze bardziej zwiększyć wydajność i ograniczyć zużycie energii, producenci urządzeń warto też rozważyć wdrożenie wbudowanego sprzętu do szyfrowania, który szyfruje/odszyfrowuje dane przesyłane do/z urządzenia pamięci masowej. Typowe jądra Androida (w wersji 4.14 i nowszej) zawierają platformę, umożliwia używanie wbudowanego szyfrowania, gdy obsługa sprzętu i sterowników dostawcy jest i dostępności informacji. platformę szyfrowania wbudowanego można włączyć, ustawiając następujące opcje konfiguracji jądra:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Jeśli Twoje urządzenie korzysta z pamięci UFS, włącz też:

CONFIG_SCSI_UFS_CRYPTO=y

Jeśli Twoje urządzenie korzysta z pamięci eMMC, włącz też:

CONFIG_MMC_CRYPTO=y

Włączanie szyfrowania na podstawie plików

Włączenie FBE na urządzeniu wymaga włączenia tej funkcji w pamięci wewnętrznej (userdata). Spowoduje to również automatyczne włączenie FBE w przypadku pamięć masowa; Jednak format szyfrowania w pamięci adaptacyjnej może zostać zastąpiony w razie potrzeby.

Pamięć wewnętrzna

FBE można włączyć przez dodanie opcji fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] do kolumny fs_mgr_flags wiersza fstab dla userdata. Ta opcja definiuje format szyfrowania na wewnętrznym pamięci masowej. Zawiera maksymalnie 3 parametry rozdzielone dwukropkiem:

• Parametr contents_encryption_mode określa, do szyfrowania zawartości plików – algorytm kryptograficzny. Może to być aes-256-xts lub adiantum. Od Androida 11 można również pozostawić to pole puste, aby określić jest to domyślny algorytm – aes-256-xts.
• Parametr filenames_encryption_mode określa, do szyfrowania nazw plików jest używany algorytm kryptograficzny. Może to być aes-256-cts, aes-256-heh, adiantum lub aes-256-hctr2. Jeśli nie podasz żadnej wartości, domyślnie zostanie użyta wartość aes-256-cts, jeśli contents_encryption_mode to aes-256-xts lub adiantum, jeśli contents_encryption_mode – adiantum.
• Parametr flags, nowy w Androidzie 11 to lista flag rozdzielonych znakiem + znak. Obsługiwane są te flagi:
  • Flaga v1 wybiera zasady szyfrowania w wersji 1. Flaga v2 wybiera zasady szyfrowania w wersji 2. Wersja Dwie zasady szyfrowania wykorzystują bezpieczniejszą i bardziej elastyczną funkcję pobierania kluczy. Wartością domyślną jest v2, jeśli urządzenie z Androidem 11 lub nowszym; (zgodnie z założeniami ro.product.first_api_level) lub v1, jeśli urządzenia z Androidem 10 lub obniżysz się.
  • Flaga inlinecrypt_optimized wybiera szyfrowanie zoptymalizowany pod kątem sprzętu do szyfrowania wbudowanego, który nie wydajną obsługę dużej liczby kluczy. Robi to, czerpiąc tylko jeden klucz szyfrowania treści pliku na klucz CE lub DE, a nie jeden na plik. Generacja IV (wektorów inicjujących) jest odpowiednio skorygowane.
  • Flaga emmc_optimized jest podobna do inlinecrypt_optimized, ale wybiera też typ IV metoda, która ogranicza IV do 32 bitów. Ta flaga powinna mieć tylko być używany na wbudowanym sprzęcie do szyfrowania zgodnym z Specyfikacja JEDEC eMMC w wersji 5.2, dlatego obsługuje tylko pliki 32-bitowe IV. W przypadku innego wbudowanego sprzętu do szyfrowania użyj inlinecrypt_optimized. Ta flaga nigdy nie powinna być używane w pamięci UFS; specyfikacja UFS zezwala na użycie 64-bitowego pliku IV.
  • Na urządzeniach obsługujących opakowanie sprzętowe , flaga wrappedkey_v0 umożliwia użycie opakowane sprzętowo klucze do FBE. Tego pola można używać tylko w połączeniu przy użyciu opcji podłączenia inlinecrypt i inlinecrypt_optimized lub emmc_optimized flaga.
  • Flaga dusize_4k wymusza rozmiar jednostki danych szyfrowania wynosi 4096 bajtów, nawet jeśli rozmiar bloku systemu plików nie wynosi 4096 B. Rozmiar jednostki danych szyfrowania to poziom szczegółowości pliku szyfrowanie treści. Ta flaga jest dostępna od Androida 15 (eksperyment AOSP). Tej flagi należy używać tylko do włączania korzystanie ze sprzętu do szyfrowania wbudowanego, który nie obsługuje danych jednostek większych niż 4096 bajtów na urządzeniach korzystających z rozmiaru strony jest większy niż 4096 bajtów i korzysta z systemu plików f2fs.

Jeśli nie używasz sprzętu do szyfrowania wbudowanego, zalecamy ustawienie zalecane dla większości urządzenia to fileencryption=aes-256-xts. Jeśli używasz wbudowanego szyfrowaniem jest zalecane ustawienie dla większości urządzeń fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (lub odpowiednik fileencryption=::inlinecrypt_optimized). Wł. urządzeń bez żadnej akceleracji AES, zamiast AES można użyć Adiantum. ustawienie: fileencryption=adiantum.

Od Androida 14 AES-HCTR2 jest preferowanym trybem szyfrowania nazw plików dla urządzeń z przyspieszonymi instrukcjami kryptograficznymi. Jednak tylko nowsze jądra Androida obsługują AES-HCTR2. Planujemy wprowadzić w przyszłej wersji Androida tryb domyślny nazw plików. szyfrowaniem. Jeśli jądro obsługuje szyfrowanie AES-HCTR2, można je włączyć do szyfrowania nazw plików przez ustawiam wartość aes-256-hctr2 w polu filenames_encryption_mode. W najprostszym przypadku można to zrobić za pomocą fileencryption=aes-256-xts:aes-256-hctr2.

Na urządzeniach z Androidem 10 lub starszym fileencryption=ice może też służyć do określania sposobu korzystania z parametru Tryb szyfrowania treści pliku FSCRYPT_MODE_PRIVATE. Ten tryb jest nie zaimplementowano przez typowe jądra Androida, ale można go wdrożyć za pomocą niestandardowych poprawek jądra systemu. Format na dysku wygenerowany przez ten tryb było specyficzne dla dostawcy. Na urządzeniach z Androidem 11 lub nowszego, ten tryb nie jest już dozwolony, a musisz użyć standardowego formatu szyfrowania.

Uwaga: Opcja fileencryption definiuje format na dysku, nie może zostać zmieniona przez OTA.

Domyślnie do szyfrowania zawartości plików wykorzystuje się jądra systemu Linux kryptografii. Jeśli chcesz zamiast tego używać sprzętu do szyfrowania wbudowanego, także dodaj opcję podłączenia inlinecrypt. Na przykład pełne fstab wiersz może wyglądać tak:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Uwaga:

• Opcje inlinecrypt i fileencryption przejść do różnych kolumn, ponieważ inlinecrypt to opcja podłączenia systemu plików, a fileencryption to flaga w przestrzeni Androida.
• Jeśli sprzęt do szyfrowania wbudowanego działa prawidłowo, a moduł Flaga wrappedkey_v0 nie jest ustawiona, Opcję podłączenia inlinecrypt można dodać lub usunąć w dowolnym miejscu bez wyczyszczenia pamięci urządzenia. Innymi słowy, o ile klucze opakowane sprzętowo są włączone, inlinecrypt powinien wpływa jedynie na implementację, a nie na format na dysku. Zalecenia testowanie usuwania inlinecrypt w trakcie programowania, aby zweryfikować czy sprzęt do szyfrowania działa prawidłowo.

Pamięć elastyczna

Od Androida 9, FBE i pamięć dostosowywana, która może być używana razem.

Określanie opcji fstab fileencryption dla userdata automatycznie włącza też FBE i szyfrowanie metadanych w przypadku wdrożenia pamięci masowej. Możesz jednak zastąpić format szyfrowania FBE lub metadanych w pamięci dostosowywanej, ustawiając właściwości w PRODUCT_PROPERTY_OVERRIDES

Na urządzeniach z Androidem 11 lub nowszym użyj tych właściwości:

• ro.crypto.volume.options (nowość w Androidzie) 11) wybiera format szyfrowania FBE na pamięci uniwersalnej. Ma taką samą składnię jak argument funkcji fileencryption. Używa tych samych ustawień domyślnych. Powyżej znajdziesz zalecenia dotyczące aplikacji fileencryption użyj tutaj.
• ro.crypto.volume.metadata.encryption wybiera metadane i formatu szyfrowania w pamięci masowej. Zobacz metadane, dokumentacji dotyczącej szyfrowania.

Na urządzeniach z Androidem 10 lub starszym używaj tych właściwości:

• ro.crypto.volume.contents_mode zaznacza treść tryb szyfrowania. Jest to odpowiednik pierwszego pola rozdzielanego dwukropkiem ro.crypto.volume.options
• ro.crypto.volume.filenames_mode wybiera nazwy plików tryb szyfrowania. Jest to odpowiednik drugiego pola rozdzielanego dwukropkiem argumentu ro.crypto.volume.options, oprócz domyślnej wartości na urządzeniach na Androidzie 10 lub starszym aes-256-heh Na większości urządzeń ta czynność musi być jawna zastąpione na aes-256-cts.
• ro.crypto.fde_algorithm i ro.crypto.fde_sector_size wybierz szyfrowanie metadanych w pamięci adaptacyjnej. Zobacz metadane, dokumentacji dotyczącej szyfrowania.

Uwaga: Na urządzeniach z Androidem 10 lub starszym domyślny tryb szyfrowania nazw plików w pamięci adaptacyjnej nie był ważny w dniu większości urządzeń i różnił się od domyślnego trybu pamięci wewnętrznej. Dlatego na takich urządzeniach należy je zastąpić, zwykle aes-256-cts

Integracja z Keymasterem

HAL Keymaster należy uruchamiać jako część klasy early_hal. Dzieje się tak, ponieważ FBE wymaga, aby narzędzie Keymaster było gotowe na obsługę żądań Faza rozruchu post-fs-data, w której trwa konfigurowanie vold klawisze początkowe.

Wykluczanie katalogów

init stosuje systemowy klucz DE do wszystkich katalogów najwyższego poziomu /data, z wyjątkiem musi być niezaszyfrowany, na przykład w katalogu zawierającym systemowy klucz DE oraz katalogi zawierające katalogi CE lub DE użytkowników. Klucze szyfrowania są stosowane rekurencyjnie i nie mogą zostać zastąpione przez podkatalogi.

W Androidzie 11 i nowszych Interfejs init ma zastosowanie do katalogów, w których można kontrolować encryption=<action> argumentu funkcji mkdir w skryptach init. Możliwe wartości parametru <action> to omówione w Plik README dla języka Android init.

W Androidzie 10 działania związane z szyfrowaniem init zostały zakodowane na stałe w tej lokalizacji:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

W Androidzie 9 i starszych lokalizacji lokalizacja była:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Możesz dodać wyjątki, aby uniemożliwić określonym katalogom w ogóle nie są zaszyfrowane. W przypadku wprowadzenia tego rodzaju modyfikacji urządzenie producent powinien dodać Zasady SELinux, które przyznają dostęp tylko do które muszą korzystać z niezaszyfrowanego katalogu. Powinno to być wykluczane wszystkie niezaufanych aplikacji.

Jedynym znanym dozwolonym przypadkiem użycia jest obsługa starszej wersji OTA. funkcje zabezpieczeń.

Obsługa bezpośredniego rozruchu w aplikacjach systemowych

Wykrywanie bezpośredniego rozruchu aplikacji

Aby ułatwić szybką migrację aplikacji systemowych, wprowadziliśmy 2 nowe atrybuty, można ustawić na poziomie aplikacji. Atrybut defaultToDeviceProtectedStorage jest dostępny tylko dla: aplikacji systemowych. Atrybut directBootAware jest dostępny dla wszystkich.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

Atrybut directBootAware na poziomie aplikacji to skrócony sposób oznaczania wszystkie komponenty aplikacji podobne do szyfrowania.

Atrybut defaultToDeviceProtectedStorage przekierowuje wartość domyślną lokalizację pamięci aplikacji, aby wskazywać pamięć masową w Niemczech, zamiast wskazywać pamięć CE. Aplikacje systemowe używające tej flagi muszą dokładnie kontrolować wszystkie dane przechowywane domyślnie lokalizacji i zmieniać ścieżki danych wrażliwych w celu korzystania z pamięci CE. Urządzenie producenci korzystający z tej opcji powinni dokładnie sprawdzać dane, są przechowywane w celu zapewnienia, że nie zawierają one danych osobowych.

Podczas pracy w tym trybie następujące systemowe interfejsy API są w razie potrzeby można w razie potrzeby bezpośrednio zarządzać kontekstem opartym na pamięci CE, co pozwala ich odpowiedniki w standardzie Ochrona urządzenia.

• Context.createCredentialProtectedStorageContext()
• Context.isCredentialProtectedStorage()

Obsługa wielu użytkowników

Każdy użytkownik w środowisku wielu użytkowników otrzymuje oddzielny klucz szyfrowania. Każdy użytkownik dwa klucze: DE i CE. Użytkownik 0 musi najpierw zalogować się na urządzeniu ze specjalnym użytkownikiem. Dotyczy to Urządzeń Administracja.

Aplikacje wykrywające kryptowaluty współdziałają z użytkownikami w następujący sposób: INTERACT_ACROSS_USERS i INTERACT_ACROSS_USERS_FULL Zezwalaj aplikacji na działanie wśród wszystkich użytkowników urządzenia. Jednak te aplikacje będą mogły korzystać tylko z katalogów zaszyfrowanych przy użyciu CE dla użytkowników, Jest już odblokowany.

Aplikacja może być w stanie swobodnie wchodzić w interakcje na obszarach w Niemczech, ale tylko jeden użytkownik Odblokowanie nie oznacza, że wszyscy użytkownicy na urządzeniu są odblokowani. aplikacja powinna sprawdzić ten stan przed próbą uzyskania dostępu do tych obszarów.

Każdy identyfikator użytkownika profilu służbowego również otrzymuje 2 klucze: DE i CE. Kiedy wyzwanie służbowe użytkownik profilu jest odblokowany, a Keymaster (w TEE) może przekazać klucz TEE profilu.

Obsługa aktualizacji

Partycja odzyskiwania nie może uzyskać dostępu do pamięci chronionej DE na partycji danych użytkownika. Zdecydowanie zalecamy obsługę urządzeń z implementacją FBE OTA przy użyciu aktualizacji systemu A/B. Jako OTA można stosować podczas normalnego działania, nie ma potrzeby dostępu do danych na zaszyfrowanym dysku.

Korzystanie ze starszego rozwiązania OTA, które wymaga odzyskiwania, aby uzyskać dostęp do pliku OTA na partycji userdata:

1. Utwórz katalog najwyższego poziomu (na przykład misc_ne) w pliku userdata partycja.
2. Skonfiguruj niezaszyfrowany katalog najwyższego poziomu (patrz Wykluczanie katalogów).
3. W katalogu najwyższego poziomu utwórz katalog do przechowywania pakietów OTA.
4. Dodaj regułę SELinux i konteksty plików, aby kontrolować dostęp do tego katalogu i jego treści. Należy przekazywać tylko proces lub aplikacje otrzymujące aktualizacje OTA odczytu i zapisu w tym katalogu. Brak innego wniosku lub innego procesu powinien mieć dostęp do tego katalogu.

Weryfikacja

Aby upewnić się, że wdrożona wersja funkcji działa zgodnie z oczekiwaniami, najpierw uruchom wiele testów szyfrowania CTS, takich jak Test DirectBootHostHost i EncryptionTest.

Jeśli na urządzeniu działa Android 11 lub nowszy, uruchom też vts_kernel_encryption_test:

atest vts_kernel_encryption_test

lub:

vts-tradefed run vts -m vts_kernel_encryption_test

Producenci urządzeń mogą też wykonywać poniższe testy ręczne. Dzień urządzenie z włączoną funkcją FBE:

• Sprawdź, czy ro.crypto.state istnieje
  • Sprawdź, czy plik ro.crypto.state jest zaszyfrowany
• Sprawdź, czy ro.crypto.type istnieje
  • Sprawdź, czy ro.crypto.type ma wartość file

Testerzy mogą też sprawdzić, czy pamięć CE jest zablokowana, zanim urządzenie został odblokowany po raz pierwszy od uruchomienia. Aby to zrobić, użyj Kompilacja userdebug lub eng, ustawienie kodu PIN, wzoru lub na głównym koncie użytkownika i zrestartuj urządzenie. Zanim odblokujesz urządzenie, uruchom to polecenie, aby sprawdzić pamięć CE głównego użytkownika. Jeśli urządzenie korzysta z systemu bez interfejsu graficznego Tryb użytkownika (większość urządzeń motoryzacyjnych), główny użytkownik to użytkownik 10, więc uruchom:

adb root; adb shell ls /data/user/10

Na innych urządzeniach (na większości urządzeń innych niż motoryzacyjne) głównym użytkownikiem jest użytkownik 0, bieg:

adb root; adb shell ls /data/user/0

Sprawdź, czy wymienione nazwy plików są zakodowane w formacie Base64, co oznacza, że nazwy plików są zaszyfrowane, a klucz do ich odszyfrowania nie jest jeszcze dostępny. Jeśli nazwy plików są wymienione w postaci zwykłego tekstu, coś jest nie tak.

Zachęcamy też producentów urządzeń do przeprowadzenia testów fscrypt na urządzeniach z systemem Linux. jądra systemu operacyjnego. Te testy należą do pakietu testów systemu plików xfstests. Pamiętaj jednak: te testy zbiorcze nie są oficjalnie obsługiwane przez Androida.

Szczegóły implementacji AOSP

Ta sekcja zawiera szczegółowy opis implementacji AOSP oparte na plikach. Nie jest on wymagany w przypadku producentów urządzeń. wprowadzić tu zmiany, aby używać FBE i bezpośredniego rozruchu na swoich urządzeniach.

szyfrowanie przy użyciu fscrypt

Implementacja AOSP używa „fscrypt” szyfrowanie (obsługiwane przez ext4 i f2fs) w jądrze i zwykle jest skonfigurowana w taki sposób, aby:

• Szyfruj zawartość pliku za pomocą AES-256 w trybie XTS
• Szyfruj nazwy plików za pomocą AES-256 w trybie CBC-CTS

Szyfrowanie Adiantum też jest obsługiwane. Gdy włączone jest szyfrowanie Adiantum, zarówno zawartość, jak i nazwy plików są szyfrowane za pomocą Adiantum.

fscrypt obsługuje 2 wersje zasad szyfrowania: wersję 1 i 2. Wersja 1 została wycofana, a wymagania CDD dotyczące urządzeń wprowadzonych na rynek Android 11 i nowsze wersje są zgodne tylko z wersją 2. Zasady szyfrowania w wersji 2 używają HKDF-SHA512 w celu uzyskania rzeczywistych kluczy szyfrowania z kluczy podanych w przestrzeni użytkownika.

Więcej informacji o szyfrowaniu fscrypt znajdziesz w dokumentacji nadrzędnego jądra.

Klasy pamięci

Tabela poniżej zawiera listę kluczy FBE i katalogów, które są przez nie chronione szczegóły:

Klasa pamięci masowej	Opis	Katalogi
Niezaszyfrowane	Katalogi w usłudze /data, które nie mogą lub nie muszą być chronione przez FBE. Na urządzeniach korzystających z metadanych szyfrowania, katalogi te nie są w rzeczywistości niezaszyfrowane, ale są chronione kluczem szyfrowania metadanych, który jest odpowiednikiem System DE.	/data/apex, z wyłączeniem /data/apex/decompressed i /data/apex/ota_reserved w systemie DE /data/lost+found /data/preloads /data/unencrypted Wszystkie katalogi, których podkatalogi używają różnych kluczy FBE. Dla: bo każdy katalog /data/user/${user_id} korzysta z klucza poszczególnych użytkowników, /data/user nie używa żadnego klucza
System DE	Dane zaszyfrowane na urządzeniu niepowiązane z konkretnym użytkownikiem	/data/apex/decompressed /data/apex/ota_reserved /data/app /data/misc /data/system /data/vendor Wszystkie inne podkatalogi /data, że ta tabela nie wspomina o innej klasie
Zależnie od rozruchu	Efemeryczne pliki systemowe, które nie muszą przetrwać restartu	/data/per_boot
Użytkownik CE (wewnętrzny)	Szyfrowane dane logowania poszczególnych użytkowników w pamięci wewnętrznej	/data/data (alias /data/user/0) /data/media/${user_id} /data/misc_ce/${user_id} /data/system_ce/${user_id} /data/user/${user_id} /data/vendor_ce/${user_id}
Użytkownik DE (wewnętrzny)	Szyfrowane przez urządzenie dane poszczególnych użytkowników w pamięci wewnętrznej	/data/misc_de/${user_id} /data/system_de/${user_id} /data/user_de/${user_id} /data/vendor_de/${user_id}
CE na użytkownika (dostosowane)	Szyfrowane dane logowania poszczególnych użytkowników w pamięci adaptacyjnej	/mnt/expand/${volume_uuid}/media/${user_id} /mnt/expand/${volume_uuid}/misc_ce/${user_id} /mnt/expand/${volume_uuid}/user/${user_id}
Użytkownik DE (możliwy do wdrożenia)	Szyfrowane przez urządzenie dane poszczególnych użytkowników w pamięci masowej	/mnt/expand/${volume_uuid}/misc_de/${user_id} /mnt/expand/${volume_uuid}/user_de/${user_id}

Przechowywanie kluczy i ich ochrona

Wszystkimi kluczami FBE zarządza vold i są przechowywane w postaci zaszyfrowanej na dysku, z wyjątkiem klucza uruchamiania, który nie jest przechowywany. Tabela poniżej zawiera listę lokalizacji, w których są przechowywane różne klucze FBE:

Typ klucza	Lokalizacja klucza	Klasa pamięci lokalizacji klucza
Systemowy klucz DE	/data/unencrypted	Niezaszyfrowane
Klucze CE (wewnętrzne) użytkownika	/data/misc/vold/user_keys/ce/${user_id}	System DE
Klucze wewnętrzne (wewnętrzne) użytkownika	/data/misc/vold/user_keys/de/${user_id}	System DE
Klucze CE (adaptacyjne) użytkownika	/data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid}	Użytkownik CE (wewnętrzny)
Klucze DE (dostępne) użytkownika	/data/misc_de/${user_id}/vold/volume_keys/${volume_uuid}	Użytkownik DE (wewnętrzny)

Jak pokazano w poprzedniej tabeli, większość kluczy FBE jest przechowywana w katalogach, które są szyfrowane przez inny klucz FBE. Kluczy nie można odblokować, dopóki nie skończy się pamięć klasa, która je zawiera, została odblokowana.

vold stosuje również warstwę szyfrowania do wszystkich kluczy FBE. Każdy klucz oprócz kluczy CE do pamięci wewnętrznej są szyfrowane przy użyciu własnego algorytmu AES-256-GCM Klucz Keystore, który nie jest poza TEE. Dzięki temu nie będzie można odblokować kluczy FBE, chyba że zaufany system operacyjny został uruchomiony zgodnie z wymuszaniem weryfikacji podczas uruchamiania. Przywrócenie oporność jest także żądana dla klucza magazynu kluczy, co umożliwia kluczom FBE są bezpiecznie usuwane na urządzeniach, na których Keymaster obsługuje opór procesu wycofywania. Jako SHA-512, czyli najlepiej działającą opcję zastępczą, gdy opór wycofania jest niedostępny. hasz 16 384 losowych bajtów przechowywanych w zapisanym pliku secdiscardable jest używany razem z kluczem jako identyfikator aplikacji. klucza magazynu kluczy. Wszystkie te bajty trzeba przywrócić, aby przywrócić Klucz FBE.

Klucze CE do pamięci wewnętrznej mają silniejszy poziom ochrony, który zapewnia nie można ich odblokować bez znajomości ekranu blokady użytkownika Knowledge Factor (LSKF) (kod PIN, wzór lub hasło), zabezpieczony token resetowania hasła lub oba te klucze Wznowienie przy ponownym uruchomieniu. Tokeny resetowania kodu dostępu można tworzyć tylko dla profili służbowych. całkowicie zarządzanych urządzeniach.

W tym celu vold szyfruje każdy klucz CE w pamięci wewnętrznej przy użyciu klucza AES-256-GCM pobranego z hasła syntetycznego użytkownika. Hasło syntetyczne to stały sekret kryptograficzny o wysokiej entropii, który generowanych losowo dla każdego użytkownika. LockSettingsService in system_server zarządza hasłem syntetycznym i sposobem, w jaki i jest chronione.

Aby chronić hasło syntetyczne za pomocą funkcji LSKF, LockSettingsService najpierw rozciąga wskaźnik LSKF, przechodząc przez niego scrypt, czas kierowania wynoszący około 25 ms i wykorzystanie pamięci około 2 MiB. Filmy LSKF są zwykle krótkie, więc ten krok zwykle nie zapewnia dobrego bezpieczeństwa. Główną warstwą zabezpieczeń jest bezpieczny Element (SE) lub ograniczenie szybkości wymuszone przez TEE opisane poniżej.

Jeśli urządzenie jest wyposażone w bezpieczny element, LockSettingsService mapuje rozciągnięty LSKF na losowy obiekt tajny o wysokiej entropii przechowywanym w SE za pomocą HAL Weaver. LockSettingsService, a następnie zaszyfruje 2-krotnie: za pomocą klucza programowego pobranego z rozciągnięto LSKF i obiekt tajny Weaver, a po drugie z magazynem kluczy niepowiązanym z uwierzytelnianiem . Zapewnia to wymuszone przez SE ograniczenie liczby przypuszczalnych operacji LSKF.

Jeśli urządzenie nie ma SE, zamiast tego użyj LockSettingsService używa rozciągniętego LSKF jako bramki dostępu hasła. LockSettingsService następnie zaszyfruje hasło syntetyczne dwukrotnie: najpierw za pomocą klucza oprogramowania pozyskanego z rozciągniętego LSKF i skrótu funkcji z plikiem secdiscard, a drugi z kluczem magazynu kluczy powiązanym z uwierzytelnianiem Rejestracja strażnika. Powoduje to wymuszone przez TEE ograniczenie liczby przypuszczalnych operacji LSKF.

Po zmianie LSKF LockSettingsService usuwa wszystkie informacje związane z powiązaniem hasła syntetycznego ze starym NSKF. Na urządzeniach, które obsługują odporne na wycofanie klucze Weaver lub wycofywanie kluczy magazynu kluczy, gwarantuje bezpieczne usunięcie starego powiązania. Z tego powodu zabezpieczenia opisane tu są stosowane nawet wtedy, gdy użytkownik nie ma klucza LSKF.