Szyfrowanie metadanych

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Obsługa Androida 7.0 i nowszych szyfrowania opartego na plikach (FBE). FBE umożliwia szyfrowanie różnych plików za pomocą różnych kluczy, które można odblokować niezależnie. Klucze te służą do szyfrowania zawartości i nazw plików. 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 pojedynczy klucz obecny podczas uruchamiania 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 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 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 włączenia modułu dm-default-key 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ć 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 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 używasz sprzętowego szyfrowania wbudowanego w urządzenie, musisz też włączyć alternatywne szyfrowanie za pomocą interfejsu 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.

W Androidzie 10 i starszych dm-default-key nie było obsługiwane przez wspólne 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 w przypadku klucza 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 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

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ę 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: Kolumna fs_mgr_flags wpisu fstab dotyczącego userdata. Pełna linia fstab może wyglądać na przykład 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żesz to zmienić, ustawiając opcję metadata_encryption w kolumnie fs_mgr_flags:

• Na urządzeniach bez akceleracji AES można szyfrować Adiantum, 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 dla dm-default-key zmienił się w Androidzie 11, musisz też ustawić prawidłową wartość dla PRODUCT_SHIPPING_API_LEVEL w device.mk. Jeśli na przykład urządzenie jest uruchamiane z Androidem 11 (poziom API 30), device.mk powinien zawierać:

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. Zwróć też uwagę na częste problemy opisane 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 różnią się nieco od tych przedstawionych powyżej. Jeśli na przykład masz włączone szyfrowanie Adiantum, trzecie pole to xchacha12,aes-adiantum-plain64, a nie 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łania mount_all, które montuje zaszyfrowany za pomocą metadanych wolumin /data, init uruchamia narzędzie vdc. Narzędzie vdc łączy się z vold przez binder, aby skonfigurować urządzenie szyfrowane metadanymi i zamontować partycję. Na okres użytkownik init jest zablokowany i próbuje odczytać lub ustawić Właściwości init są blokowane do zakończenia 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. 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 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 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 istnieją 2 implementacje szyfrowania metadanych w przystosowywalnym magazynie: przestarzały na podstawie dm-crypt i nowsza na podstawie 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. 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ć 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ć wymagane: 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ć, ustawiając właściwość systemu 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ć, ustawiając 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 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 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. 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_algorithm wybiera szyfrowanie metadanych algorytmem bezpieczeństwa. Dostępne opcje to aes-128-cbc i adiantum Adiantum można używać 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. W przypadku szyfrowania Adiantum użyj wartości 4096.