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
lubadiantum
. Od Androida 11 można również pozostawić puste, aby określić domyślny algorytm, którym jestaes-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
lubaes-256-hctr2
. Jeśli nie zostanie określony, domyślnie jest toaes-256-cts
, jeślicontents_encryption_mode
toaes-256-xts
lubadiantum
, jeślicontents_encryption_mode
toadiantum
. - 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; flagav2
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 zro.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 doinlinecrypt_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 tegoinlinecrypt_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ą montowaniainlinecrypt
i flagąinlinecrypt_optimized
lubemmc_optimized
.
- Flaga
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 opcjifileencryption
fstab i używa tych samych wartości domyślnych. Zobacz zalecenia dotyczącefileencryption
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 polemro.crypto.volume.options
rozdzielonym dwukropkami. -
ro.crypto.volume.filenames_mode
wybiera tryb szyfrowania nazw plików. Jest to równoważne drugiemu poluro.crypto.volume.options
rozdzielone dwukropkami , z tą różnicą, że ustawieniem domyślnym na urządzeniach z systemem Android 10 lub starszym jestaes-256-heh
. Na większości urządzeń należy to jawnie zastąpićaes-256-cts
. -
ro.crypto.fde_algorithm
iro.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
:
- Utwórz katalog najwyższego poziomu (na przykład
misc_ne
) w partycjiuserdata
. - Skonfiguruj ten katalog najwyższego poziomu tak, aby był niezaszyfrowany (zobacz Wykluczanie katalogów ).
- Utwórz katalog w katalogu najwyższego poziomu do przechowywania pakietów OTA.
- 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
- Upewnij się, że
- Sprawdź, czy
ro.crypto.type
istnieje- Upewnij się,
ro.crypto.type
jest ustawiony nafile
- Upewnij się,
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ą:
Klasa przechowywania | Opis | Katalogi |
---|---|---|
System DE | Dane zaszyfrowane na urządzeniu niepowiązane z konkretnym użytkownikiem | /data/system , /data/app i różne inne podkatalogi /data |
Na rozruch | Efemeryczne pliki systemowe, które nie muszą przetrwać ponownego uruchomienia | /data/per_boot |
Użytkownik CE (wewnętrzny) | Dane zaszyfrowane poświadczeniami poszczególnych użytkowników w pamięci wewnętrznej |
|
Użytkownik DE (wewnętrzny) | Dane zaszyfrowane na urządzeniu użytkownika w pamięci wewnętrznej |
|
Użytkownik CE (do przyjęcia) | Dane zaszyfrowane poświadczeniami poszczególnych użytkowników w możliwej do adaptacji pamięci masowej |
|
Użytkownik DE (do przyjęcia) | Dane zaszyfrowane na urządzeniu każdego użytkownika w możliwej do adaptacji pamięci masowej |
|
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:
Typ klucza | Kluczowa lokalizacja | Klasa przechowywania lokalizacji klucza |
---|---|---|
Systemowy klucz DE | /data/unencrypted | Nieszyfrowane |
Klucze użytkownika CE (wewnętrzne). | /data/misc/vold/user_keys/ce/${user_id} | System DE |
Klawisze DE użytkownika (wewnętrzne). | /data/misc/vold/user_keys/de/${user_id} | System DE |
Klucze użytkownika CE (do przyjęcia). | /data/misc_ce/${user_id}/vold/volume_keys/${volume_uuid} | Użytkownik CE (wewnętrzny) |
Klucze użytkownika DE (do przyjęcia). | /data/misc_de/${user_id}/vold/volume_keys/${volume_uuid} | Użytkownik DE (wewnętrzny) |
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.