Szyfrowanie oparte na plikach

Android 7.0 i nowsze obsługują szyfrowanie oparte na plikach (FBE). Szyfrowanie oparte na plikach umożliwia szyfrowanie różnych plików za pomocą różnych kluczy, które można odblokować niezależnie.

W tym artykule opisano, jak włączyć szyfrowanie oparte na plikach na nowych urządzeniach i jak aplikacje systemowe mogą korzystać z interfejsów API rozruchu bezpośredniego, aby zapewnić użytkownikom najlepszą możliwą i najbezpieczniejszą obsługę.

Wszystkie urządzenia uruchamiane z systemem Android 10 lub nowszym muszą korzystać z szyfrowania opartego na plikach.

Rozruch bezpośredni

Szyfrowanie oparte na plikach umożliwia nową funkcję wprowadzoną w systemie Android 7.0 o nazwie Direct Boot . Direct Boot umożliwia zaszyfrowanym urządzeniom uruchamianie bezpośrednio do ekranu blokady. Wcześniej na zaszyfrowanych urządzeniach korzystających z szyfrowania całego dysku (FDE) użytkownicy musieli podać dane uwierzytelniające przed uzyskaniem dostępu do jakichkolwiek danych, co uniemożliwiało wykonywanie przez telefon wszystkich oprócz najbardziej podstawowych operacji. Na przykład alarmy nie mogły działać, usługi ułatwień dostępu były niedostępne, a telefony nie mogły odbierać połączeń, ale były ograniczone tylko do podstawowych operacji wybierania numerów alarmowych.

Wraz z wprowadzeniem szyfrowania opartego na plikach (FBE) i nowych interfejsów API informujących aplikacje o szyfrowaniu, aplikacje te mogą działać w ograniczonym kontekście. Może się to zdarzyć, zanim użytkownicy podają swoje dane uwierzytelniające, jednocześnie chroniąc prywatne informacje użytkownika.

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

• Pamięć zaszyfrowana poświadczeniami (CE), która jest domyślną lokalizacją przechowywania i jest dostępna tylko po odblokowaniu urządzenia przez użytkownika.
• Pamięć zaszyfrowana przez urządzenie (DE), która jest miejscem przechowywania dostępnym zarówno w trybie rozruchu bezpośredniego, jak i po odblokowaniu urządzenia przez użytkownika.

Ta separacja sprawia, że ​​profile do pracy są bezpieczniejsze, ponieważ pozwala na ochronę więcej niż jednego użytkownika jednocześnie, ponieważ szyfrowanie nie jest już oparte wyłącznie na haśle startowym.

Interfejs Direct Boot API umożliwia aplikacjom obsługującym szyfrowanie dostęp do każdego z tych obszarów. Wprowadzono zmiany w cyklu życia aplikacji, aby uwzględnić potrzebę powiadamiania aplikacji, gdy pamięć CE użytkownika zostanie odblokowana w odpowiedzi na pierwsze wprowadzenie danych uwierzytelniających na ekranie blokady lub w przypadku profilu służbowego stanowiącego wyzwanie w pracy . Urządzenia z systemem Android 7.0 muszą obsługiwać te nowe interfejsy API i cykle życia, niezależnie od tego, czy implementują FBE. Chociaż bez FBE pamięć DE i CE zawsze będzie w stanie odblokowanym.

Pełna implementacja szyfrowania opartego na plikach w systemach plików Ext4 i F2FS jest dostępna w projekcie Android Open Source Project (AOSP) i musi być włączona tylko na urządzeniach spełniających wymagania. Producenci decydujący się na użycie FBE mogą chcieć zbadać sposoby optymalizacji tej funkcji w oparciu o zastosowany system na chipie (SoC).

Wszystkie niezbędne pakiety w AOSP zostały zaktualizowane, aby uwzględniały bezpośrednie uruchamianie. Jednak w przypadku, gdy producenci urządzeń używają dostosowanych wersji tych aplikacji, będą chcieli zapewnić co najmniej pakiety obsługujące bezpośrednie uruchamianie, zapewniające następujące usługi:

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

Przykłady i źródło

Android zapewnia referencyjną implementację szyfrowania opartego na plikach, w którym vold ( system/vold ) zapewnia funkcjonalność zarządzania urządzeniami pamięci masowej i woluminami w systemie Android. Dodanie FBE zapewnia vold kilka nowych poleceń do obsługi zarządzania kluczami dla kluczy CE i DE wielu użytkowników. Oprócz podstawowych zmian dotyczących korzystania z możliwości szyfrowania plików w jądrze , wiele pakietów systemowych, w tym ekran blokady i SystemUI, zostało zmodyfikowanych w celu obsługi funkcji FBE i Direct Boot. Obejmują one:

• AOSP Dialer (pakiety/aplikacje/Dialer)
• Zegar na biurko (pakiety/aplikacje/DeskClock)
• LatinIME (pakiety/metody wprowadzania/LatinIME)*
• Aplikacja Ustawienia (pakiety/aplikacje/Ustawienia)*
• SystemUI (frameworks/base/packages/SystemUI)*

* Aplikacje systemowe korzystające z atrybutu manifestu defaultToDeviceProtectedStorage

Więcej przykładów aplikacji i usług obsługujących szyfrowanie można znaleźć, uruchamiając polecenie mangrep directBootAware w katalogu frameworks lub packages drzewa źródłowego AOSP.

Zależności

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

• Obsługa jądra dla szyfrowania Ext4 lub szyfrowania F2FS.
• Obsługa Keymaster z HAL w wersji 1.0 lub nowszej. Nie ma wsparcia dla Keymaster 0.3, ponieważ nie zapewnia on niezbędnych możliwości ani nie zapewnia wystarczającej ochrony kluczy szyfrujących.
• Keymaster/ Keystore i Gatekeeper muszą być zaimplementowane w Trusted Execution Environment (TEE), aby zapewnić ochronę kluczy DE, tak aby nieautoryzowany system operacyjny (niestandardowy system operacyjny flashowany na urządzeniu) nie mógł po prostu zażądać kluczy DE.
• Wymagany jest sprzętowy root of Trust i Verified Boot powiązany z inicjalizacją Keymaster, aby upewnić się, że klucze DE nie są dostępne dla nieautoryzowanego systemu operacyjnego.

Realizacja

Przede wszystkim aplikacje, takie jak budziki, telefon i funkcje ułatwień dostępu, powinny mieć Android:directBootAware zgodnie z dokumentacją programisty Direct Boot .

Obsługa jądra

Obsługa jądra dla szyfrowania Ext4 i F2FS jest dostępna we wspólnych jądrach Androida w wersji 3.18 i nowszych. Aby włączyć ją w jądrze w wersji 5.1 lub nowszej, użyj:

CONFIG_FS_ENCRYPTION=y

W przypadku starszych jąder użyj CONFIG_EXT4_ENCRYPTION=y , jeśli system plików userdata twojego urządzenia to Ext4, lub użyj CONFIG_F2FS_FS_ENCRYPTION=y , jeśli system plików userdata twojego urządzenia to F2FS.

Jeśli Twoje urządzenie będzie obsługiwać adaptowalną pamięć masową lub będzie używać szyfrowania metadanych w pamięci wewnętrznej, włącz także opcje konfiguracji jądra potrzebne do szyfrowania metadanych, zgodnie z opisem w dokumentacji szyfrowania metadanych .

Oprócz funkcjonalnej obsługi szyfrowania Ext4 lub F2FS, producenci urządzeń powinni również włączyć akcelerację kryptograficzną, aby przyspieszyć szyfrowanie oparte na plikach i poprawić komfort użytkowania. Na przykład na urządzeniach opartych na architekturze ARM64 przyspieszenie ARMv8 CE (Cryptography Extensions) można włączyć, ustawiając następujące opcje konfiguracji jądra:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Aby jeszcze bardziej poprawić wydajność i zmniejszyć zużycie energii, producenci urządzeń mogą również rozważyć wdrożenie wbudowanego sprzętu szyfrującego , który szyfruje/odszyfrowuje dane w drodze do/z urządzenia pamięci masowej. Wspólne jądra Androida (wersja 4.14 i nowsze) zawierają platformę, która umożliwia użycie wbudowanego szyfrowania, gdy dostępna jest obsługa sprzętu i sterowników dostawcy. Ramę 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 masowej opartej na UFS, włącz również:

CONFIG_SCSI_UFS_CRYPTO=y

Jeśli Twoje urządzenie korzysta z pamięci masowej opartej na eMMC, włącz również:

CONFIG_MMC_CRYPTO=y

Włączanie szyfrowania opartego na plikach

Włączenie FBE na urządzeniu wymaga włączenia go w pamięci wewnętrznej ( userdata ). To również automatycznie włącza FBE na adaptowalną pamięć masową; jednak format szyfrowania w pamięci możliwej do adaptacji może zostać zastąpiony, jeśli to konieczne.

Pamięć wewnętrzna

FBE jest włączane przez dodanie opcji fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] do kolumny fs_mgr_flags linii fstab dla userdata . Ta opcja określa format szyfrowania w pamięci wewnętrznej. Zawiera do trzech parametrów oddzielonych dwukropkami:

• Parametr contents_encryption_mode określa, który algorytm kryptograficzny jest używany do szyfrowania zawartości pliku. Może to być aes-256-xts lub adiantum . Od Androida 11 można również pozostawić puste, aby określić domyślny algorytm, którym jest aes-256-xts .
• Parametr filenames_encryption_mode określa, który algorytm kryptograficzny jest używany do szyfrowania nazw plików. Może to być aes-256-cts , aes-256-heh , adiantum lub aes-256-hctr2 . Jeśli nie zostanie określony, domyślnie jest to aes-256-cts , jeśli contents_encryption_mode to aes-256-xts lub adiantum , jeśli contents_encryption_mode to adiantum .
• Parametr flags , nowy w Androidzie 11, to lista flag oddzielonych znakiem + . Obsługiwane są następujące flagi:
  • Flaga v1 wybiera zasady szyfrowania w wersji 1; flaga v2 wybiera zasady szyfrowania w wersji 2. Zasady szyfrowania w wersji 2 wykorzystują bezpieczniejszą i elastyczniejszą funkcję wyprowadzania klucza . Wartość domyślna to v2, jeśli urządzenie zostało uruchomione z systemem Android 11 lub nowszym (zgodnie z ro.product.first_api_level ), lub v1, jeśli urządzenie zostało uruchomione z systemem Android 10 lub niższym.
  • Flaga inlinecrypt_optimized wybiera format szyfrowania zoptymalizowany pod kątem sprzętu do szyfrowania wbudowanego, który nie obsługuje wydajnie dużej liczby kluczy. Robi to, wyprowadzając tylko jeden klucz szyfrowania zawartości pliku na klucz CE lub DE, zamiast jednego na plik. Generowanie IV (wektorów inicjalizacyjnych) jest odpowiednio dostosowywane.
  • Flaga emmc_optimized jest podobna do inlinecrypt_optimized , ale wybiera również metodę generowania IV, która ogranicza IV do 32 bitów. Ta flaga powinna być używana tylko na sprzęcie do szyfrowania wbudowanego, który jest zgodny ze specyfikacją JEDEC eMMC v5.2 i dlatego obsługuje tylko 32-bitowe IV. Na innym sprzęcie do szyfrowania wbudowanego użyj zamiast tego inlinecrypt_optimized . Ta flaga nigdy nie powinna być używana w przypadku magazynu opartego na UFS; specyfikacja UFS pozwala na użycie 64-bitowych IV.
  • Na urządzeniach obsługujących klucze opakowane sprzętowo flaga wrappedkey_v0 umożliwia korzystanie z kluczy opakowanych sprzętowo dla FBE. Można tego użyć tylko w połączeniu z opcją montowania inlinecrypt i flagą inlinecrypt_optimized lub emmc_optimized .

Jeśli nie używasz wbudowanego sprzętu do szyfrowania, zalecanym ustawieniem dla większości urządzeń jest fileencryption=aes-256-xts . Jeśli używasz wbudowanego sprzętu szyfrującego, zalecanym ustawieniem dla większości urządzeń jest fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (lub równoważnie fileencryption=::inlinecrypt_optimized ). Na urządzeniach bez jakiejkolwiek formy akceleracji AES można użyć Adiantum zamiast AES, ustawiając fileencryption=adiantum .

Od Androida 14 (eksperymentalny AOSP) 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. W przyszłej wersji Androida planuje się, że stanie się domyślnym trybem szyfrowania nazw plików. Jeśli twoje jądro obsługuje AES-HCTR2, można włączyć szyfrowanie nazw plików, ustawiając filenames_encryption_mode na aes-256-hctr2 . W najprostszym przypadku można to zrobić za pomocą fileencryption=aes-256-xts:aes-256-hctr2 .

Na urządzeniach, które zostały uruchomione z systemem Android 10 lub starszym, fileencryption=ice jest również akceptowane, aby określić użycie trybu szyfrowania zawartości pliku FSCRYPT_MODE_PRIVATE . Ten tryb nie jest zaimplementowany przez wspólne jądra Androida, ale może być zaimplementowany przez dostawców przy użyciu niestandardowych poprawek jądra. Format na dysku utworzony w tym trybie był specyficzny dla dostawcy. Na urządzeniach uruchamianych z Androidem 11 lub nowszym ten tryb nie jest już dozwolony i zamiast tego należy użyć standardowego formatu szyfrowania.

Domyślnie szyfrowanie zawartości plików odbywa się przy użyciu kryptograficznego interfejsu API jądra Linuksa. Jeśli zamiast tego chcesz użyć sprzętu do szyfrowania wbudowanego, dodaj również opcję montowania inlinecrypt . Na przykład pełna linia fstab może wyglądać następująco:

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

Możliwość przechowywania

Od Androida 9, FBE i adaptowalna pamięć masowa mogą być używane razem.

Określenie opcji fileencryption fstab dla userdata również automatycznie włącza szyfrowanie zarówno FBE, jak i szyfrowanie metadanych w możliwej do adaptacji pamięci masowej. Można jednak zastąpić formaty szyfrowania FBE i/lub formaty szyfrowania metadanych w możliwej do przyjęcia pamięci masowej, ustawiając właściwości w PRODUCT_PROPERTY_OVERRIDES .

Na urządzeniach z systemem Android 11 lub nowszym użyj następujących właściwości:

• ro.crypto.volume.options (nowość w Androidzie 11) wybiera format szyfrowania FBE w pamięci masowej. Ma taką samą składnię jak argument opcji fileencryption fstab i używa tych samych wartości domyślnych. Zobacz zalecenia dotyczące fileencryption powyżej, aby dowiedzieć się, czego tutaj użyć.
• ro.crypto.volume.metadata.encryption wybiera format szyfrowania metadanych w możliwej do przyjęcia pamięci masowej. Zobacz dokumentację szyfrowania metadanych .

Na urządzeniach z Androidem 10 lub starszym użyj następujących właściwości:

• ro.crypto.volume.contents_mode wybiera tryb szyfrowania zawartości. Jest to równoważne z pierwszym polem ro.crypto.volume.options rozdzielonym dwukropkami.
• ro.crypto.volume.filenames_mode wybiera tryb szyfrowania nazw plików. Jest to równoważne drugiemu polu ro.crypto.volume.options rozdzielone dwukropkami , z tą różnicą, że ustawieniem domyślnym na urządzeniach z systemem Android 10 lub starszym jest aes-256-heh . Na większości urządzeń należy to jawnie zastąpić aes-256-cts .
• ro.crypto.fde_algorithm i ro.crypto.fde_sector_size wybierz format szyfrowania metadanych w możliwej do przyjęcia pamięci masowej. Zobacz dokumentację szyfrowania metadanych .

Integracja z Keymasterem

Keymaster HAL powinien być uruchamiany jako część klasy early_hal . Dzieje się tak dlatego, że FBE wymaga, aby Keymaster był gotowy do obsługi żądań post-fs-data , czyli wtedy, gdy vold ustawia początkowe klucze.

Z wyłączeniem katalogów

init stosuje systemowy klucz DE do wszystkich katalogów najwyższego poziomu /data , z wyjątkiem katalogów, które muszą być niezaszyfrowane: katalogu zawierającego sam systemowy klucz DE oraz katalogów zawierających katalogi CE lub DE użytkownika. Klucze szyfrowania są stosowane rekurencyjnie i nie mogą być zastępowane przez podkatalogi.

W systemie Android 11 i nowszych klucz, który init ma zastosowanie do katalogów, można kontrolować za pomocą argumentu encryption=<action> polecenia mkdir w skryptach inicjujących. Możliwe wartości <action> są udokumentowane w pliku README dla języka init systemu Android .

W Androidzie 10 akcje szyfrowania init zostały zakodowane na stałe w następującej lokalizacji:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

W Androidzie 9 i wcześniejszych lokalizacja była następująca:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Możliwe jest dodanie wyjątków, aby w ogóle uniemożliwić szyfrowanie niektórych katalogów. W przypadku wprowadzenia tego rodzaju modyfikacji producent urządzenia powinien uwzględnić zasady SELinux , które przyznają dostęp tylko tym aplikacjom, które muszą korzystać z niezaszyfrowanego katalogu. Powinno to wykluczyć wszystkie niezaufane aplikacje.

Jedynym znanym akceptowalnym przypadkiem użycia jest obsługa starszych funkcji OTA.

Obsługa bezpośredniego rozruchu w aplikacjach systemowych

Uświadamianie aplikacji Direct Boot

Aby ułatwić szybką migrację aplikacji systemowych, dostępne są dwa nowe atrybuty, które 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 jest skrótem oznaczającym wszystkie komponenty w aplikacji jako obsługujące szyfrowanie.

Atrybut defaultToDeviceProtectedStorage przekierowuje domyślną lokalizację magazynu aplikacji do magazynu DE zamiast do magazynu CE. Aplikacje systemowe korzystające z tej flagi muszą dokładnie sprawdzać wszystkie dane przechowywane w domyślnej lokalizacji i zmieniać ścieżki poufnych danych, aby korzystać z magazynu CE. Producenci urządzeń korzystający z tej opcji powinni dokładnie sprawdzać przechowywane przez siebie dane, aby upewnić się, że nie zawierają one danych osobowych.

Podczas pracy w tym trybie dostępne są następujące systemowe interfejsy API, które w razie potrzeby jawnie zarządzają kontekstem wspieranym przez pamięć masową CE, co odpowiada ich odpowiednikom z funkcją Device Protected.

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

Obsługa wielu użytkowników

Każdy użytkownik w środowisku wielu użytkowników otrzymuje osobny klucz szyfrowania. Każdy użytkownik otrzymuje dwa klucze: klucz DE i klucz CE. Użytkownik 0 musi najpierw zalogować się do urządzenia, ponieważ jest to użytkownik specjalny. Jest to istotne w przypadku zastosowań związanych z administrowaniem urządzeniami .

Aplikacje obsługujące kryptografię wchodzą w interakcje między użytkownikami w następujący sposób: INTERACT_ACROSS_USERS i INTERACT_ACROSS_USERS_FULL umożliwiają aplikacji działanie na wszystkich użytkownikach urządzenia. Jednak te aplikacje będą mogły uzyskać dostęp tylko do katalogów zaszyfrowanych CE dla użytkowników, którzy są już odblokowani.

Aplikacja może swobodnie wchodzić w interakcje w obszarach DE, ale jeden odblokowany użytkownik nie oznacza, że ​​wszyscy użytkownicy urządzenia są odblokowani. Aplikacja powinna sprawdzić ten stan przed próbą uzyskania dostępu do tych obszarów.

Każdy identyfikator użytkownika profilu do pracy otrzymuje również dwa klucze: DE i CE. Po spełnieniu wyzwania w pracy użytkownik profilu zostaje odblokowany, a Keymaster (w TEE) może dostarczyć klucz TEE profilu.

Obsługa aktualizacji

Partycja odzyskiwania nie może uzyskać dostępu do pamięci chronionej przez DE na partycji danych użytkownika. Urządzenia z implementacją FBE są zdecydowanie zalecane do obsługi OTA przy użyciu aktualizacji systemu A/B . Ponieważ OTA można zastosować podczas normalnej pracy, nie ma potrzeby odzyskiwania, aby uzyskać dostęp do danych na zaszyfrowanym dysku.

W przypadku korzystania ze starszego rozwiązania OTA, które wymaga odzyskania w celu uzyskania dostępu do pliku OTA na partycji userdata :

1. Utwórz katalog najwyższego poziomu (na przykład misc_ne ) w partycji userdata .
2. Skonfiguruj ten katalog najwyższego poziomu tak, aby był niezaszyfrowany (zobacz Wykluczanie katalogów ).
3. Utwórz katalog w katalogu najwyższego poziomu do przechowywania pakietów OTA.
4. Dodaj regułę SELinux i konteksty plików, aby kontrolować dostęp do tego katalogu i jego zawartości. Tylko proces lub aplikacje otrzymujące aktualizacje OTA powinny mieć możliwość odczytu i zapisu w tym katalogu. Żadna inna aplikacja ani proces nie powinien mieć dostępu do tego katalogu.

Walidacja

Aby upewnić się, że zaimplementowana wersja funkcji działa zgodnie z przeznaczeniem, najpierw uruchom wiele testów szyfrowania CTS, takich jak DirectBootHostTest i EncryptionTest .

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

atest vts_kernel_encryption_test

Lub:

vts-tradefed run vts -m vts_kernel_encryption_test

Ponadto producenci urządzeń mogą przeprowadzać następujące testy ręczne. Na urządzeniu z włączonym FBE:

• Sprawdź, czy ro.crypto.state istnieje
  • Upewnij się, że ro.crypto.state jest zaszyfrowany
• Sprawdź, czy ro.crypto.type istnieje
  • Upewnij się, ro.crypto.type jest ustawiony na file

Ponadto testerzy mogą uruchomić instancję userdebug z ekranem blokady ustawionym na głównym użytkowniku. Następnie adb shell do urządzenia i użyj su , aby zostać rootem. Upewnij się /data/data zawiera zaszyfrowane nazwy plików; jeśli tak nie jest, coś jest nie tak.

Producentów urządzeń zachęca się również do zbadania uruchamiania testów Linuksa pod kątem fscrypt na ich urządzeniach lub jądrach. Te testy są częścią zestawu testów systemu plików xfstests. Jednak te wstępne testy nie są oficjalnie obsługiwane przez system Android.

Szczegóły implementacji AOSP

Ta sekcja zawiera szczegółowe informacje na temat implementacji AOSP i opisuje sposób działania szyfrowania opartego na plikach. Nie powinno być konieczne, aby producenci urządzeń wprowadzali tutaj jakiekolwiek zmiany, aby używać FBE i Direct Boot na swoich urządzeniach.

szyfrowanie fscrypt

Implementacja AOSP wykorzystuje szyfrowanie „fscrypt” (obsługiwane przez ext4 i f2fs) w jądrze i zwykle jest skonfigurowana do:

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

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

fscrypt obsługuje dwie wersje zasad szyfrowania: wersję 1 i wersję 2. Wersja 1 jest przestarzała, a wymagania dotyczące CDD dla urządzeń uruchamianych z systemem Android 11 i nowszym są zgodne tylko z wersją 2. Zasady szyfrowania w wersji 2 wykorzystują HKDF-SHA512 do uzyskiwania rzeczywistych klucze szyfrujące z kluczy dostarczonych w przestrzeni użytkownika.

Aby uzyskać więcej informacji na temat fscrypt, zobacz dokumentację nadrzędną jądra .

Klasy przechowywania

W poniższej tabeli przedstawiono bardziej szczegółowo klucze FBE i katalogi, które chronią:

Przechowywanie i ochrona kluczy

Wszystkie klucze FBE są zarządzane przez vold i są przechowywane w postaci zaszyfrowanej na dysku, z wyjątkiem klucza na rozruch, który w ogóle nie jest przechowywany. W poniższej tabeli wymieniono lokalizacje, w których przechowywane są różne klucze FBE:

Jak pokazano w powyższej tabeli, większość kluczy FBE jest przechowywana w katalogach zaszyfrowanych innym kluczem FBE. Kluczy nie można odblokować, dopóki klasa pamięci, która je zawiera, nie zostanie odblokowana.

vold stosuje również warstwę szyfrowania do wszystkich kluczy FBE. Każdy klucz oprócz kluczy CE do pamięci wewnętrznej jest szyfrowany za pomocą AES-256-GCM przy użyciu własnego klucza magazynu kluczy, który nie jest ujawniany poza TEE. Gwarantuje to, że klucze FBE nie będą mogły zostać odblokowane, dopóki zaufany system operacyjny nie zostanie uruchomiony, zgodnie z wymuszonym przez Verified Boot . Odporność na przywracanie jest również wymagana w kluczu magazynu kluczy, który umożliwia bezpieczne usuwanie kluczy FBE na urządzeniach, na których Keymaster obsługuje odporność na przywracanie. W ramach najlepszego działania awaryjnego, gdy odporność na wycofywanie jest niedostępna, skrót SHA-512 składający się z 16384 losowych bajtów przechowywanych w pliku secdiscardable przechowywanym obok klucza jest używany jako znacznik identyfikatora aplikacji klucza magazynu kluczy. Wszystkie te bajty muszą zostać odzyskane, aby odzyskać klucz FBE.

Klucze CE do pamięci wewnętrznej otrzymują wyższy poziom ochrony, który gwarantuje, że nie można ich odblokować bez znajomości współczynnika wiedzy o ekranie blokady (LSKF) użytkownika (PIN, wzór lub hasło), bezpiecznego tokena resetowania hasła lub obu tych elementów po stronie klienta oraz klucze po stronie serwera dla operacji Resume-on-Reboot . Tokeny resetowania kodu dostępu można tworzyć tylko dla profili służbowych i w pełni zarządzanych urządzeń .

Aby to osiągnąć, vold szyfruje każdy klucz CE do przechowywania wewnętrznego za pomocą klucza AES-256-GCM pochodzącego z syntetycznego hasła użytkownika. Hasło syntetyczne to niezmienny sekret kryptograficzny o wysokiej entropii, który jest generowany losowo dla każdego użytkownika. LockSettingsService w system_server zarządza syntetycznym hasłem i sposobami jego ochrony.

Aby zabezpieczyć syntetyczne hasło za pomocą LSKF, LockSettingsService najpierw rozciąga LSKF, przepuszczając je przez scrypt , celując w czas około 25 ms i zużycie pamięci około 2 MiB. Ponieważ LSKF są zwykle krótkie, ten krok zwykle nie zapewnia dużego bezpieczeństwa. Główną warstwą bezpieczeństwa jest opisany poniżej sposób ograniczania szybkości wymuszony przez bezpieczny element (SE) lub TEE.

Jeśli urządzenie ma bezpieczny element (SE), LockSettingsService odwzorowuje rozciągnięty LSKF na losowy sekret o wysokiej entropii przechowywany w SE przy użyciu warstwy Weaver HAL . Następnie LockSettingsService dwukrotnie szyfruje syntetyczne hasło: najpierw za pomocą klucza programowego pochodzącego z rozciągniętego klucza LSKF i tajnego klucza Weaver, a następnie za pomocą klucza magazynu kluczy niezwiązanego z uwierzytelnianiem. Zapewnia to wymuszone przez SE ograniczanie szybkości domysłów LSKF.

Jeśli urządzenie nie ma SE, LockSettingsService zamiast tego używa rozciągniętego LSKF jako hasła strażnika . Następnie LockSettingsService dwukrotnie szyfruje hasło syntetyczne: najpierw za pomocą klucza programowego pochodzącego z rozciągniętego LSKF i skrótu pliku, który można odrzucić, a następnie za pomocą klucza magazynu kluczy, który jest powiązany z rejestracją Gatekeepera. Zapewnia to wymuszone przez TEE ograniczanie szybkości domysłów LSKF.

Gdy LSKF zostanie zmieniony, LockSettingsService usuwa wszystkie informacje związane z powiązaniem hasła syntetycznego ze starym LSKF. Na urządzeniach, które obsługują Weaver lub klucze Keystore odporne na wycofanie, gwarantuje to bezpieczne usunięcie starego powiązania. Z tego powodu opisane tutaj zabezpieczenia są stosowane nawet wtedy, gdy użytkownik nie posiada LSKF.