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.
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.
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
lubadiantum
. 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
lubaes-256-hctr2
. Jeśli nie podasz żadnej wartości, domyślnie zostanie użyta wartośćaes-256-cts
, jeślicontents_encryption_mode
toaes-256-xts
lubadiantum
, jeślicontents_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. Flagav2
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żeniamiro.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 doinlinecrypt_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żyjinlinecrypt_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łączeniainlinecrypt
iinlinecrypt_optimized
lubemmc_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.
- Flaga
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.
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
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 funkcjifileencryption
. Używa tych samych ustawień domyślnych. Powyżej znajdziesz zalecenia dotyczące aplikacjifileencryption
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 dwukropkiemro.crypto.volume.options
ro.crypto.volume.filenames_mode
wybiera nazwy plików tryb szyfrowania. Jest to odpowiednik drugiego pola rozdzielanego dwukropkiem argumenturo.crypto.volume.options
, oprócz domyślnej wartości na urządzeniach na Androidzie 10 lub starszymaes-256-heh
Na większości urządzeń ta czynność musi być jawna zastąpione naaes-256-cts
.ro.crypto.fde_algorithm
iro.crypto.fde_sector_size
wybierz szyfrowanie metadanych w pamięci adaptacyjnej. Zobacz metadane, dokumentacji dotyczącej szyfrowania.
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
:
- Utwórz katalog najwyższego poziomu (na przykład
misc_ne
) w plikuuserdata
partycja. - Skonfiguruj niezaszyfrowany katalog najwyższego poziomu (patrz Wykluczanie katalogów).
- W katalogu najwyższego poziomu utwórz katalog do przechowywania pakietów OTA.
- 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 plik
- Sprawdź, czy
ro.crypto.type
istnieje- Sprawdź, czy
ro.crypto.type
ma wartośćfile
- Sprawdź, czy
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. |
|
System DE | Dane zaszyfrowane na urządzeniu niepowiązane z konkretnym użytkownikiem |
|
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 |
|
Użytkownik DE (wewnętrzny) | Szyfrowane przez urządzenie dane poszczególnych użytkowników w pamięci wewnętrznej |
|
CE na użytkownika (dostosowane) | Szyfrowane dane logowania poszczególnych użytkowników w pamięci adaptacyjnej |
|
Użytkownik DE (możliwy do wdrożenia) | Szyfrowane przez urządzenie dane poszczególnych użytkowników w pamięci masowej |
|
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.