Android 7.0 lub nowszy obsługuje szyfrowanie na podstawie plików (FBE). FBE umożliwia szyfrowanie różnych plików za pomocą różnych kluczy, które można odblokować niezależnie. Te klucze służą do szyfrowania zarówno zawartości plików, jak i ich nazw. Gdy używana jest FBE, inne informacje, takie jak układy katalogów, rozmiary plików, uprawnienia i czasy utworzenia/modyfikacji, nie są szyfrowane. W zbiorze te inne informacje są nazywane metadanymi systemu plików.
Android 9 wprowadził obsługę szyfrowania metadanych. W przypadku szyfrowania metadanych jeden klucz obecny podczas uruchamiania szyfruje wszystkie treści, które nie są szyfrowane przez FBE. Klucz jest chroniony przez Keymaster, który z kolei jest chroniony przez weryfikowany rozruch.
Szyfrowanie metadanych jest zawsze włączone w przechowywaniu dostosowywanym, gdy włączona jest funkcja FBE. Szyfrowanie metadanych można też włączyć w pamięci wewnętrznej. Na urządzeniach z Androidem 11 lub nowszym musi być włączone szyfrowanie metadanych w pamięci wewnętrznej.
Implementacja w pamięci wewnętrznej
Szyfrowanie metadanych możesz skonfigurować w pamięci wewnętrznej nowych urządzeń, konfigurując system plików metadata, zmieniając sekwencję init i włączając szyfrowanie metadanych w pliku fstab urządzenia.
Wymagania wstępne
Szyfrowanie metadanych można skonfigurować tylko podczas formatowania partycji danych. W związku z tym ta funkcja jest dostępna tylko na nowych urządzeniach. Nie można jej zmienić za pomocą aktualizacji OTA.
Szyfrowanie metadanych wymaga włączenia modułu dm-default-key w jądrze. W Androidzie 11 i nowszych dm-default-key jest obsługiwana przez wspólne jądra Androida w wersji 4.14 lub nowszej. Ta wersja dm-default-key wykorzystuje sprzęt i niezależną od dostawcy platformę szyfrowania o nazwie blk-crypto.
Aby włączyć dm-default-key, użyj:
CONFIG_BLK_INLINE_ENCRYPTION=y CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y CONFIG_DM_DEFAULT_KEY=y
dm-default-key używa sprzętowego mechanizmu szyfrowania (sprzęt, który szyfruje/odszyfrowuje dane podczas ich przesyłania do lub z urządzenia do przechowywania), gdy jest dostępny. Jeśli nie używasz sprzętu do szyfrowania wbudowanego, musisz też włączyć opcję zastępczą interfejsu API kryptograficznego jądra:
CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y
Jeśli nie używasz sprzętowego szyfrowania w przepływie danych, włącz też wszystkie dostępne przyspieszenia oparte na procesorze zgodnie z zaleceniami podanymi w dokumentacji FBE.
W Androidzie 10 i starszych wersjach system dm-default-key nie był obsługiwany przez typowe jądro systemu. W związku z tym implementacja dm-default-key zależała od dostawców.
Konfigurowanie systemu plików metadanych
Ponieważ nic na partycji userdata nie może być odczytywane, dopóki nie pojawi się klucz szyfrowania metadanych, tabela partycji musi mieć osobną partycję o nazwie „partycja metadanych” na potrzeby przechowywania blobów klucza głównego, które chronią ten klucz. Partycja metadanych powinna mieć rozmiar 16 MB.
fstab.hardware musi zawierać wpis dotyczący systemu plików metadanych, który znajduje się na tej partycji podczas podłączania do niej pod adresem /metadata, w tym flagę formattable, która zapewnia formatowanie podczas uruchamiania. System plików f2fs nie działa na mniejszych partycjach. Zalecamy użycie systemu plików ext4. Na przykład:
/dev/block/bootdevice/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard wait,check,formattable
Aby mieć pewność, że punkt podłączania /metadata istnieje, dodaj do BoardConfig-common.mk ten wiersz:
BOARD_USES_METADATA_PARTITION := true
Zmiany w sekwencji inicjalizacji
Jeśli używasz szyfrowania metadanych, vold musi być uruchomiony, zanim /data zostanie zamontowany. Aby zapewnić, że zostanie ona uruchomiona odpowiednio wcześnie, dodaj do pliku init.hardware.rc ten wers:
# We need vold early for metadata encryption
on early-fs
start vold
Keymaster musi być uruchomiony i gotowy, zanim init spróbuje zamontować /data.
Plik init.hardware.rc powinien już zawierać instrukcję mount_all, która powoduje zamontowanie pliku /data w sekcji on
late-fs. Przed tym wierszem dodaj dyrektywę do wykonania usługi wait_for_keymaster:
on late-fs
…
# Wait for keymaster
exec_start wait_for_keymaster
# Mount RW partitions which need run fsck
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Włączanie szyfrowania metadanych
Na koniec dodaj keydirectory=/metadata/vold/metadata_encryption do kolumny fs_mgr_flags w rekordzie fstab dla userdata. Pełny wiersz fstab może na przykład wyglądać tak:
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,inlinecrypt latemount,wait,check,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized,keydirectory=/metadata/vold/metadata_encryption,quota,formattable
Domyślnym algorytmem szyfrowania metadanych w pamięci wewnętrznej jest AES-256-XTS. Można to zastąpić, ustawiając opcję metadata_encryption również w kolumnie fs_mgr_flags:
- Na urządzeniach, które nie mają akceleracji AES, szyfrowanie Adiantum można włączyć, ustawiając wartość
metadata_encryption=adiantum. - Na urządzeniach, które obsługują klucze opakowane sprzętowo, klucz szyfrowania metadanych można opakować sprzętowo za pomocą ustawienia
metadata_encryption=aes-256-xts:wrappedkey_v0(lub odpowiednikametadata_encryption=:wrappedkey_v0, ponieważaes-256-xtsjest domyślnym algorytmem).
Ponieważ w Androidzie 11 interfejs jądra systemu zmienił się na dm-default-key, musisz też ustawić prawidłową wartość PRODUCT_SHIPPING_API_LEVEL w device.mk. Jeśli na przykład Twoje urządzenie ma wprowadzenie na rynek z Androidem 11 (poziom interfejsu API 30), device.mk powinien zawierać:
PRODUCT_SHIPPING_API_LEVEL := 30
Możesz też ustawić tę właściwość systemu, aby wymusić użycie nowego interfejsu dm-default-keyAPI niezależnie od poziomu interfejsu Shipping API:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.dm_default_key.options_format.version=2
Weryfikacja
Aby sprawdzić, czy szyfrowanie metadanych jest włączone i działa prawidłowo, wykonaj opisane poniżej testy. Zwróć też uwagę na częste problemy opisane poniżej.
Testy
Najpierw uruchom to polecenie, aby sprawdzić, czy szyfrowanie metadanych jest włączone w pamięci wewnętrznej:
adb rootadb shell dmctl table userdata
Dane wyjściowe powinny wyglądać tak:
Targets in the device-mapper table for userdata: 0-4194304: default-key, aes-xts-plain64 - 0 252:2 0 3 allow_discards sector_size:4096 iv_large_sectors
Jeśli domyślne ustawienia szyfrowania zostały zastąpione przez ustawienie opcji metadata_encryption w ustawieniach fstab urządzenia, dane wyjściowe będą się nieco różnić od podanych powyżej. Jeśli np. masz włączone szyfrowanie Adiantum, trzecie pole zawiera wartość xchacha12,aes-adiantum-plain64 zamiast aes-xts-plain64.
Następnie uruchom vts_kernel_encryption_test, aby sprawdzić poprawność szyfrowania metadanych i FBE:
atest vts_kernel_encryption_test
lub:
vts-tradefed run vts -m vts_kernel_encryption_test
Typowe problemy
Podczas wywoływania funkcji mount_all, która podłącza partycję /data szyfrowaną przez metadane, init wykonuje narzędzie vdc. Narzędzie vdc
łączy się z vold przez binder, aby skonfigurować urządzenie z zaszyfrowanymi metadanymi i zamontować partycję. Podczas trwania tego wywołania init jest zablokowany, a próby odczytu lub ustawienia właściwości init są blokowane, dopóki nie zakończy się mount_all.
Jeśli na tym etapie jakakolwiek część pracy vold jest bezpośrednio lub pośrednio zablokowana w czytaniu lub ustawianiu właściwości, dochodzi do blokady. vold musi mieć możliwość odczytywania kluczy, interakcji z kluczem Keymaster i podłączania katalogu danych bez konieczności dalszej interakcji z init.
Jeśli Keymaster nie jest w pełni uruchomiony, gdy mount_all jest uruchamiany, nie odpowiada na vold, dopóki nie odczyta pewnych właściwości z init, co powoduje dokładnie opisany wyżej impas. Umieszczenie funkcji exec_start wait_for_keymaster przed odpowiednim wywołaniem funkcji mount_all zapewnia, że Keymaster jest w pełni uruchomiony z wyprzedzeniem, co zapobiega blokadzie.
Konfiguracja pamięci dostosowywanej
Od Androida 9 w przypadku włączonego FBE zawsze włączana jest forma szyfrowania metadanych w adoptowalnej pamięci, nawet jeśli szyfrowanie metadanych nie jest włączone w pamięci wewnętrznej.
W AOSP istnieją 2 implementacje szyfrowania metadanych w przystosowywalnej pamięci masowej: przestarzała oparta na dm-crypt i nowsza oparta na dm-default-key. Aby mieć pewność, że dla Twojego urządzenia wybrano prawidłową implementację, sprawdź, czy w polu PRODUCT_SHIPPING_API_LEVEL ustawiona jest prawidłowa wartość device.mk. Jeśli na przykład urządzenie uruchamia się z Androidem 11 (poziom API 30), device.mk powinien zawierać:
PRODUCT_SHIPPING_API_LEVEL := 30
Możesz też ustawić te właściwości systemowe, aby wymusić użycie nowej metody szyfrowania metadanych woluminu (i nowej domyślnej wersji zasad FBE) niezależnie od poziomu interfejsu Shipping API:
PRODUCT_PROPERTY_OVERRIDES += \
ro.crypto.volume.metadata.method=dm-default-key \
ro.crypto.dm_default_key.options_format.version=2 \
ro.crypto.volume.options=::v2
Bieżąca metoda
Na urządzeniach z Androidem 11 lub nowszym szyfrowanie metadanych na adoptowanej pamięci używa modułu jądra dm-default-key, tak jak w przypadku pamięci wewnętrznej. Sprawdź powyżej wymagania wstępne, które musisz włączyć w konfiguracji jądra. Pamiętaj, że wbudowane urządzenie do szyfrowania, które działa w pamięci wewnętrznej urządzenia, może być niedostępne w pamięci adekwatnej, dlatego może być wymagane ustawienie CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y.
Domyślnie metoda szyfrowania metadanych woluminu dm-default-key używa algorytmu szyfrowania AES-256-XTS z 4096-bajtowymi sektorami szyfrowania. Algorytm można zastąpić, ustawiając właściwość systemu ro.crypto.volume.metadata.encryption. Wartość tej właściwości ma tę samą składnię co opcja metadata_encryption
fstab opisana powyżej. Na przykład na urządzeniach, które nie mają akceleracji AES, szyfrowanie Adiantum można włączyć, ustawiając wartość ro.crypto.volume.metadata.encryption=adiantum.
Starsza metoda
Na urządzeniach z Androidem 10 lub starszym szyfrowanie metadanych w pamięci adekwatnej używa modułu jądra dm-crypt zamiast dm-default-key:
CONFIG_DM_CRYPT=y
W przeciwieństwie do metody dm-default-key metoda dm-crypt powoduje, że zawartość pliku jest szyfrowana dwukrotnie: raz kluczem szyfrowania FBE i raz kluczem szyfrowania metadanych. Podwójne szyfrowanie zmniejsza wydajność i nie jest wymagane do osiągnięcia celów bezpieczeństwa związanych z szyfrowaniem metadanych, ponieważ Android zapewnia, że klucze FBE są co najmniej tak trudne do skompromitowania jak klucz szyfrujący metadane. Dostawcy mogą dostosować jądro, aby uniknąć podwójnego szyfrowania, w szczególności poprzez wdrożenie opcji allow_encrypt_override, którą Android przekazuje do dm-crypt, gdy właściwość systemowa ro.crypto.allow_encrypt_override ma wartość true.
Te elementy nie są obsługiwane przez wspólne jądro Androida.
Domyślnie metoda szyfrowania metadanych woluminu dm-crypt używa algorytmu szyfrowania AES-128-CBC z ESSIV i 512-bajtowymi sektorami szyfrowania. Można je zastąpić, ustawiając te właściwości systemu (które są też używane do szyfrowania całego dysku):
ro.crypto.fde_algorithmwybiera algorytm szyfrowania metadanych. Dostępne opcje toaes-128-cbciadiantum. Adiantum można używać tylko wtedy, gdy urządzenie nie ma akceleracji AES.ro.crypto.fde_sector_sizewybiera rozmiar sektora kryptograficznego. Dostępne opcje to 512, 1024, 2048 i 4096. W przypadku szyfrowania Adiantum użyj wartości 4096.