Szyfrowanie metadanych

Android 7.0 i wyższe obsługuje szyfrowania oparty na plikach (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żywane do szyfrowania zarówno zawartości plików, jak i nazw plików. Podczas korzystania z FBE inne informacje, takie jak układ katalogów, rozmiary plików, uprawnienia i czasy tworzenia/modyfikacji, nie są szyfrowane. Łącznie te inne informacje są znane jako metadane systemu plików.

Android 9 wprowadził obsługę szyfrowania metadanych. Dzięki szyfrowaniu metadanych pojedynczy klucz obecny w czasie rozruchu szyfruje zawartość, która nie jest szyfrowana przez FBE. Ten klucz jest chroniony przez Keymaster, który z kolei jest chroniony przez zweryfikowany rozruch.

Metadane szyfrowania jest zawsze włączona adoptable przechowywania ilekroć FBE jest włączony. Szyfrowanie metadanych można również włączyć w pamięci wewnętrznej. Urządzenia uruchomione z systemem Android 11 lub nowszym muszą mieć włączone szyfrowanie metadanych w pamięci wewnętrznej.

Wdrożenie na pamięci wewnętrznej

Można skonfigurować szyfrowanie metadanych na wewnętrznej pamięci nowych urządzeń poprzez ustawienie w górę metadata systemu plików, zmieniając kolejność startowy oraz umożliwienie szyfrowania metadanych w pliku fstab urządzenia.

Warunki wstępne

Szyfrowanie metadanych można skonfigurować tylko podczas pierwszego sformatowania partycji danych. W rezultacie ta funkcja jest dostępna tylko dla nowych urządzeń; to nie jest coś, co OTA powinna zmienić.

Metadane szyfrowanie wymaga, aby dm-default-key module być włączony w jądrze. W Androidzie 11 i wyżej, dm-default-key jest obsługiwany przez Android typowych jąder, wersja 4.14 i wyższych. Ta wersja dm-default-key wykorzystuje sprzętową i niezależny sprzedawca ramową szyfrowania o nazwie blk-kryptograficznych.

Aby umożliwić dm-default-key , należy:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y
CONFIG_DM_DEFAULT_KEY=y

dm-default-key zastosowań inline sprzętu szyfrującego (sprzętu, który szyfruje / odszyfrowuje dane, gdy jest on w drodze do / z urządzenia pamięci masowej), kiedy będą dostępne. Jeśli nie będzie używany sprzęt szyfrujący inline, konieczne jest również, aby umożliwić przełączenie na jądra kryptograficznego API:

CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y

Gdy nie jest używany wbudowany sprzęt szyfrujący należy również włączyć dowolną dostępną przyspieszenie procesora opartego zalecany w dokumentacji FBE .

W Androidzie 10 i dolnej, dm-default-key nie był wspierany przez Android wspólnego jądra. Było zatem do sprzedawców do wdrożenia dm-default-key .

Skonfiguruj system plików metadanych

Ponieważ nic z partycji danych użytkownika nie może być odczytane, dopóki klucz szyfrowania metadanych nie jest obecny, tabela partycji musi odłożyć oddzielną partycję o nazwie „partycja metadanych” do przechowywania obiektów blob keymastera, które chronią ten klucz. Partycja metadanych powinna mieć rozmiar 16 MB.

fstab.hardware musi zawierać wpis dla systemu plików metadanych, który mieszka na tej partycji zamontowanie jej w /metadata , w tym formattable flagą celu zapewnienia, że jest sformatowany w czasie startu. System plików f2fs nie działa na mniejszych partycjach; zalecamy zamiast tego użycie ext4. Na przykład:

/dev/block/bootdevice/by-name/metadata              /metadata          ext4        noatime,nosuid,nodev,discard                          wait,check,formattable

Aby zapewnić /metadata zamontować punkt istnieje, dodaj następującą linię do BoardConfig-common.mk :

BOARD_USES_METADATA_PARTITION := true

Zmiany w sekwencji początkowej

Gdy stosuje szyfrowanie metadane, vold musi być uruchomiony przed /data jest zamontowany. Aby upewnić się, że jest uruchomiony na tyle wcześnie, dodaj następującą strofę do init.hardware.rc :

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

Keymaster musi być uruchomiony i gotowy przed próbami startowych Aby zamontować /data .

init.hardware.rc powinna już zawierać mount_all instrukcji, które antenowe /data się w tej on late-fs strofy. Przed tej linii, dodać do dyrektywy Exec z wait_for_keymaster usługę:

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 dodać keydirectory=/metadata/vold/metadata_encryption do kolumny fs_mgr_flags z fstab objęcia userdata . Na przykład pełna linia fstab może 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. To może być przesłonięta przez ustawienie metadata_encryption opcji, także w kolumnie fs_mgr_flags:

  • Na urządzeniach, które nie posiadają przyspieszenie AES, szyfrowanie Pedatum mogą być włączone przez ustawienie metadata_encryption=adiantum .
  • Na urządzeniach, które obsługują klawisze sprzętowe owinięte , klucz szyfrowania metadane mogą być wykonane sprzętem owinięty przez ustawienie metadata_encryption=aes-256-xts:wrappedkey_v0 (lub równoważnie metadata_encryption=:wrappedkey_v0 , jak aes-256-xts jest algorytm domyślny).

Ponieważ interfejs jądra do dm-default-key zmieniane w Androidzie 11, należy również upewnić się, że ustawiono prawidłową wartość dla PRODUCT_SHIPPING_API_LEVEL w device.mk . Na przykład, jeśli uruchamia urządzenie z Androidem 11 (API poziom 30), device.mk powinien zawierać:

PRODUCT_SHIPPING_API_LEVEL := 30

Można również ustawić następującą właściwość systemu, aby wymusić użycie nowego dm-default-key API niezależnie od wysyłki poziom API:

PRODUCT_PROPERTY_OVERRIDES += \
    ro.crypto.dm_default_key.options_format.version=2

Walidacja

Aby sprawdzić, czy szyfrowanie metadanych jest włączone i działa poprawnie, uruchom testy opisane poniżej. Należy także pamiętać o typowych problemów opisanych poniżej.

Testy

Zacznij od uruchomienia następującego polecenia, aby sprawdzić, czy szyfrowanie metadanych jest włączone w pamięci wewnętrznej:

adb root
adb shell dmctl table userdata

Wynik powinien być podobny do:

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 overrode domyślne ustawienia szyfrowania, ustawiając metadata_encryption opcja w urządzeniu fstab , wtedy wyjście będzie się nieznacznie różnić od powyższych. Na przykład, jeśli włączone szyfrowanie adiantum , wówczas pole trzeci będzie xchacha12,aes-adiantum-plain64 zamiast aes-xts-plain64 .

Następnie należy uruchomić vts_kernel_encryption_test celu sprawdzenia poprawności kodowania metadanych i FBE:

atest vts_kernel_encryption_test

lub:

vts-tradefed run vts -m vts_kernel_encryption_test

Powszechne problemy

Podczas rozmowy do mount_all , który montuje metadane szyfrowane /data partycji init wykonuje narzędzie VDC. Na łączy narzędzia VDC do vold nad binder skonfigurować urządzenie metadanych szyfrowane i zamontować partycję. Na czas trwania tego połączenia init jest blokowany, a próby odczytu lub zestawów init właściwości zablokuje aż mount_all wykończeń. Jeśli na tym etapie każda część vold pracy jest bezpośrednio lub pośrednio zablokowane na odczyt lub ustawienie właściwości spowoduje impas. Ważne jest, aby zapewnić, że vold może zakończyć pracę czytania klawiszy, interakcji z Keymaster i montażu katalog danych bez interakcji dalej z init .

Jeśli keymaster nie jest w pełni zaczęło się, gdy mount_all skończy, to nie będzie reagować na vold dopóki nie czytać pewne właściwości z init , w wyniku czego dokładnie opisane impasu. Umieszczenie exec_start wait_for_keymaster powyżej odpowiedniej mount_all inwokacji, jak określono, zapewnia, że jest w pełni uruchomiony keymaster z góry i tak unika tego impasu.

Konfiguracja na możliwej do przyjęcia pamięci

Od Androida 9 formą szyfrowania metadanych jest zawsze włączona adoptable przechowywania ilekroć FBE jest włączona, nawet gdy szyfrowanie metadanych nie jest włączona w pamięci wewnętrznej.

W AOSP istnieją dwie implementacje metadanych szyfrowanie adoptable przechowywania: a Nieaktualne jeden oparty na dm-crypt , a nowszy na podstawie dm-default-key . Aby upewnić się, że prawidłowa realizacja jest wybrany dla urządzenia, należy upewnić się, że ustawiono prawidłową wartość dla PRODUCT_SHIPPING_API_LEVEL w device.mk . Na przykład, jeśli uruchamia urządzenie z Androidem 11 (API poziom 30), device.mk powinien zawierać:

PRODUCT_SHIPPING_API_LEVEL := 30

Możesz również ustawić następujące właściwości systemu, aby wymusić użycie nowej metody szyfrowania metadanych woluminu (i nowej domyślnej wersji polityki FBE) niezależnie od poziomu interfejsu API wysyłki:

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 wodowania 11 lub wyższy, szyfrowanie metadane na adoptable przechowywania korzysta z dm-default-key modułu jądra, podobnie jak na pamięci wewnętrznej. Zobacz warunki powyższe, dla których opcje konfiguracyjne jądra włączyć. Zauważ, że inline sprzętu szyfrującego, który działa na pamięci wewnętrznej urządzenia mogą być niedostępne na adoptable przechowywania, a tym samym CONFIG_BLK_INLINE_ENCRYPTION_FALLBACK=y może być wymagane.

Domyślnie dm-default-key metoda szyfrowania metadanych objętość wykorzystuje AES-256-XTS algorytm szyfrowania z sektorów kryptograficznych 4096-bajtowych. Algorytm może być przesłonięta przez ustawienie ro.crypto.volume.metadata.encryption właściwości systemu. Wartość ta właściwość ma tę samą składnię jak metadata_encryption opcji fstab opisanego powyżej. Na przykład, w urządzeniach, które nie posiadają przyspieszenie AES szyfrowania Pedatum mogą być włączone przez ustawienie ro.crypto.volume.metadata.encryption=adiantum .

Wcześniejsza metoda

Na urządzeniach z Androidem wodowania 10 lub niższy, metadane szyfrowanie na adoptable przechowywania korzysta z dm-crypt moduł jądra zamiast dm-default-key :

CONFIG_DM_CRYPT=y

W przeciwieństwie do dm-default-key metodzie dm-crypt metoda powoduje zawartość pliku do zaszyfrowania dwukrotnie: raz z kluczem FBE i raz z klucza szyfrującego metadanych. To podwójne szyfrowanie zmniejsza wydajność i nie jest wymagane do osiągnięcia celów bezpieczeństwa szyfrowania metadanych, ponieważ Android zapewnia, że ​​klucze FBE są co najmniej tak samo trudne do złamania, jak klucz szyfrowania metadanych. Sprzedawcy mogą dokonać dostosowania jądra, aby uniknąć podwójnego szyfrowania, w szczególności poprzez wdrożenie allow_encrypt_override opcję, która Android przejdzie do dm-crypt , gdy właściwość systemu ro.crypto.allow_encrypt_override ustawiony jest true . Te dostosowania nie są obsługiwane przez wspólne jądro systemu Android.

Domyślnie, dm-crypt Sposób szyfrowania objętość metadanych wykorzystuje algorytm szyfrowania AES 128 CBC z ESSIV i sektorów kryptograficznych 512 bajtów. Można to zmienić, ustawiając następujące właściwości systemu (które są również używane w FDE):

  • ro.crypto.fde_algorithm wybierze algorytm szyfrowania metadanych. Do wyboru są aes-128-cbc i adiantum . Adiantum można stosować tylko wtedy, gdy urządzenie nie ma przyspieszenie AES.
  • ro.crypto.fde_sector_size Wybiera krypto rozmiar sektora. Dostępne opcje to 512, 1024, 2048 i 4096. W przypadku szyfrowania Adiantum użyj 4096.