Szyfrowanie metadanych

Obsługa Androida 7.0 i nowszych szyfrowania opartego na plikach (FBE). FBE (FBE) umożliwia szyfrowanie różnych plików za pomocą różnych kluczy, które można odblokować dzięki czemu mogą pracować niezależnie. Klucze te służą do szyfrowania zawartości i nazw plików. Jeśli używasz FBE, inne informacje, takie jak układy katalogów, rozmiary plików jak i czasy utworzenia/modyfikowania, nie są zaszyfrowane. Łącznie inne informacje są nazywane metadanymi systemu plików.

W Androidzie 9 wprowadzono obsługę szyfrowania metadanych. W przypadku szyfrowania metadanych pojedynczy klucz obecny przy uruchamianiu szyfruje wszystko, treści nie są szyfrowane przez FBE. Ten klucz jest chroniony przez system Keymaster, który w w trybie zweryfikowanym podczas uruchamiania.

Szyfrowanie metadanych jest zawsze włączone w pamięci adaptacyjnej, gdy włączona jest funkcja FBE. Szyfrowanie metadanych można też włączyć w pamięci wewnętrznej. Urządzenia wprowadzone na rynek z Androidem 11 lub nowszym musi mieć szyfrowanie metadanych w pamięci wewnętrznej.

Implementacja w pamięci wewnętrznej

Możesz skonfigurować szyfrowanie metadanych w pamięci wewnętrznej nowych urządzeń przez konfigurowanie systemu plików metadata, zmiana sekwencji inicjowania włączenie szyfrowania metadanych w pliku fstab urządzenia.

Wymagania wstępne

Szyfrowanie metadanych można skonfigurować tylko wtedy, gdy partycja danych jest pierwsza . Dlatego ta funkcja jest dostępna tylko na nowych urządzeniach. to nie jest powinien zmienić się w niej.

Szyfrowanie metadanych wymaga, aby moduł dm-default-key był które są włączone w jądrze. Na Androidzie 11 i nowszych dm-default-key jest obsługiwany przez typowe jądra Androida (wersja) wersji 4.14 i nowszych. Ta wersja aplikacji dm-default-key korzysta ze sprzętu niezależną od dostawcy platformę szyfrowania blk-crypto.

Aby włączyć funkcję dm-default-key, użyj opcji: 

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_DM_DEFAULT_KEY=y

dm-default-key używa wbudowanego sprzętu do szyfrowania (sprzętu szyfruje/odszyfrowuje dane podczas ich przesyłania do/z urządzenia pamięci masowej), gdy i dostępności informacji. Jeśli nie będziesz korzystać ze wbudowanego sprzętu do szyfrowania, należy jest też konieczne, aby umożliwić działanie awaryjnego interfejsu API kryptograficznego jądra: 

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Jeśli nie używasz sprzętu do szyfrowania wbudowanego, musisz też włączyć wszystkie dostępne Akceleracja oparta na CPU zgodnie z zaleceniami w dokumentacji FBE.

Na Androidzie 10 i starszych wersjach dm-default-key nie było obsługiwane przez typowe jądro Androida. Decyzja o tym należy więc do dostawców. w celu zaimplementowania funkcji dm-default-key.

Konfigurowanie systemu plików metadanych

Ponieważ żadne elementy partycji danych użytkownika nie mogą być odczytywane, dopóki metadane klucz szyfrowania, w tabeli partycji musi znajdować się osobny „partycja metadanych”, do przechowywania obiektów blob Keymaster, do ochrony tego klucza. Partycja metadanych powinna mieć 16 MB.

fstab.hardware musi zawierać wpis dla systemu plików metadanych działający na tej partycji, który łączy ją pod adresem /metadata, w tym flagę formattable, aby mieć pewność, że podczas uruchamiania zostanie sformatowana. System plików f2fs nie działa na mniejszych partycjach. zalecamy użycie rozszerzenia 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 następujący wiersz do użytkownika BoardConfig-common.mk: 

BOARD_USES_METADATA_PARTITION := true

Zmiany w sekwencji inicjacji

Jeśli używane jest szyfrowanie metadanych, przed rozpoczęciem musi być uruchomiona funkcja vold Podłączono: /data. Aby mieć pewność, że zacznie się wystarczająco wcześnie, dodaj ta fraza do init.hardware.rc: 

# We need vold early for metadata encryption
on early-fs
    start vold

Narzędzie Keymaster musi być uruchomione i gotowe przed rozpoczęciem próby podłączenia /data

Pole init.hardware.rc powinno już zawierać mount_all instrukcja umieszczająca /data w strumieniu on late-fs. Przed tym wierszem dodaj dyrektywę wykonującą Usługa 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: Kolumna fs_mgr_flags wpisu fstab dotyczącego 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ślnie algorytm szyfrowania metadanych w pamięci wewnętrznej to AES-256-XTS. Można to zastąpić, ustawiając parametr metadata_encryption, także w Kolumna fs_mgr_flags:

  • Na urządzeniach bez akceleracji AES szyfrowanie Adiantum może być włączone przez ustawienie metadata_encryption=adiantum.
  • Na urządzeniach obsługujących klucze opakowane sprzętowo: klucz szyfrowania metadanych można opakować sprzętowo przez ustawienie metadata_encryption=aes-256-xts:wrappedkey_v0 (lub metadata_encryption=:wrappedkey_v0, jako aes-256-xts to domyślny algorytm).

Ponieważ interfejs jądra systemu dm-default-key zmienił się w Androidzie 11, musisz też upewnić się, że są ustawione prawidłowa wartość dla PRODUCT_SHIPPING_API_LEVEL w device.mk Na przykład, jeśli Twoje urządzenie ma system Android 11 (poziom interfejsu API 30), funkcja device.mk powinna zawierają: 

PRODUCT_SHIPPING_API_LEVEL := 30

Możesz też ustawić tę właściwość systemową, aby wymuszać użycie nowej funkcji Interfejs API dm-default-key niezależnie od poziomu interfejsu API dostawy: 

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, uruchom testów opisanych poniżej. Pamiętaj również o najczęściej używanych z problemami opisanymi poniżej.

Testy

Zacznij od uruchomienia poniższego polecenia, aby sprawdzić, czy szyfrowanie metadanych jest włączone w pamięci wewnętrznej: 

adb root
adb shell dmctl table userdata

Dane wyjściowe powinny wyglądać podobnie do tych:

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 metadata_encryption w urządzeniu fstab, a następnie dane wyjściowe będą nieco inne niż te powyżej. Jeśli na przykład włączone jest szyfrowanie Adiantum, będzie mieć wartość xchacha12,aes-adiantum-plain64, a nie aes-xts-plain64

Następnie uruchom vts_kernel_encryption_test. w celu zweryfikowania poprawności szyfrowania metadanych i FBE: 

atest vts_kernel_encryption_test

lub:

vts-tradefed run vts -m vts_kernel_encryption_test

Typowe problemy

Podczas wywoływania mount_all, które podłącza zaszyfrowane metadane /data, init wykonuje narzędzie vdc. vDC narzędzie łączy się z urządzeniem vold przez binder, aby skonfigurować urządzenia zaszyfrowanego przez metadane i zamontować partycję. Na okres użytkownik init jest zablokowany i próbuje odczytać lub ustawić Właściwości init będą blokowane do czasu zakończenia działania mount_all. Jeśli na tym etapie jakakolwiek część pracy użytkownika vold jest bezpośrednio lub pośrednio zablokowane podczas odczytu lub ustawienia właściwości, spowoduje to zakleszczenie. Jest jest ważne, aby użytkownik vold mógł dokończyć odczytywanie z kluczami dostępu, pracą z Keymasterem i montowaniem katalogu danych bez więcej interakcji z użytkownikiem init.

Jeśli Keymaster nie zostanie w pełni uruchomiony po uruchomieniu mount_all, nie będzie odpowiada na funkcję vold do czasu, aż odczyta określone właściwości z init, co skutkuje dokładnie opisanym zakleszczeniem. Umieszczanie exec_start wait_for_keymaster powyżej odpowiedniej wartości Wywołanie mount_all ustawione zapewnia, że Keymaster jest w pełni które działają z wyprzedzeniem i pozwalają uniknąć zakleszczeń.

Konfiguracja pamięci dostosowywanej

Od Androida 9 formą szyfrowania metadanych jest zawsze włączona w pamięci adaptacyjnej gdy włączone jest FBE, nawet jeśli szyfrowanie metadanych jest wyłączone pamięci wewnętrznej.

W AOSP dostępne są 2 implementacje szyfrowania metadanych miejsce na dane: wycofana (w oparciu o dm-crypt) i nowsza w dniu dm-default-key. Aby mieć pewność, że implementacja jest prawidłowa, dla Twojego urządzenia, upewnij się, że ustawiono prawidłową wartość PRODUCT_SHIPPING_API_LEVEL w device.mk. Przykład: jeśli Twoje urządzenie ma premierę z Androidem 11 (poziom interfejsu API 30): Pole device.mk powinno zawierać: 

PRODUCT_SHIPPING_API_LEVEL := 30

Możesz też ustawić poniższe właściwości systemowe, aby wymuszać stosowanie nowych metoda szyfrowania metadanych woluminu (i nowa domyślna wersja zasad FBE) niezależnie od poziomu interfejsu API dostawy: 

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

Obecna metoda

Na urządzeniach z Androidem 11 lub nowszym Szyfrowanie metadanych w pamięci możliwej korzysta z protokołu dm-default-key jądra systemu operacyjnego, tak samo jak w pamięci wewnętrznej. Zobacz powyższe wymagania wstępne dotyczące konfiguracji jądra systemu aby ją włączyć. Pamiętaj, że sprzęt do szyfrowania wbudowanego, który działa na pamięć wewnętrzna urządzenia może być niedostępna w pamięci adaptacyjnej, Może być wymagana CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y.

Domyślnie metoda szyfrowania metadanych woluminu dm-default-key korzysta z algorytmu szyfrowania AES-256-XTS z 4096-bajtowymi sektorami kryptograficznymi. algorytm można zastąpić przez ustawienie Właściwość systemowa ro.crypto.volume.metadata.encryption. Ten ma taką samą składnię jak metadata_encryption opisanej powyżej opcji fstab. Na przykład na urządzeniach bez AES. acceleration, szyfrowanie Adiantum można włączyć przez ustawienie ro.crypto.volume.metadata.encryption=adiantum

Starsza metoda

Na urządzeniach z Androidem 10 lub starszym szyfrowanie w pamięci adaptacyjnej korzysta z modułu jądra dm-crypt. a nie 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 za pomocą klucza FBE i raz za pomocą klucza klucz szyfrowania metadanych. Podwójne szyfrowanie zmniejsza wydajność. nie jest wymagana do osiągnięcia celów w zakresie bezpieczeństwa w zakresie szyfrowania metadanych, ponieważ Android zapewnia, że klucze FBE są co najmniej tak trudne do podważenia jak metadane. klucz szyfrowania. Dostawcy mogą modyfikować jądro, aby uniknąć podwójnego zwłaszcza przez wdrożenie Opcja allow_encrypt_override, do której Android będzie przekazywać dm-crypt, gdy właściwość systemowa Ustawienie ro.crypto.allow_encrypt_override ma wartość true. Te dostosowania nie są obsługiwane przez popularne jądro Androida.

Domyślnie metoda szyfrowania metadanych woluminu dm-crypt używa Algorytm szyfrowania AES-128-CBC z sektorami ESSIV i 512-bajtowymi kryptowalutami. Ten można zastąpić, ustawiając następujące właściwości systemowe (które są również używany w przypadku FDE):

  • ro.crypto.fde_algorithm wybiera szyfrowanie metadanych algorytmem bezpieczeństwa. Dostępne opcje to aes-128-cbc i adiantum Parametr Adiantum może być używany tylko wtedy, gdy urządzenie nie ma przyspieszenia AES.
  • ro.crypto.fde_sector_size wybiera rozmiar sektora kryptograficznego. Dostępne opcje to 512, 1024, 2048 i 4096. Do szyfrowania Adiantum użyj 4096).