Google is committed to advancing racial equity for Black communities. See how.
This page was translated by the Cloud Translation API.
Switch to English

Szyfrowanie oparte na plikach

Android 7.0 i nowsze obsługują szyfrowanie oparte na plikach (FBE). Szyfrowanie oparte na plikach umożliwia szyfrowanie różnych plików za pomocą różnych kluczy, które można odblokować niezależnie.

W tym artykule opisano, jak włączyć szyfrowanie oparte na plikach na nowych urządzeniach i jak aplikacje systemowe mogą korzystać z interfejsów API bezpośredniego rozruchu, aby oferować użytkownikom najlepsze i najbezpieczniejsze możliwe środowisko.

Bezpośredni rozruch

Szyfrowanie oparte na plikach umożliwia nową funkcję wprowadzoną w systemie Android 7.0 o nazwie Bezpośredni rozruch . Bezpośredni rozruch umożliwia zaszyfrowanym urządzeniom uruchamianie bezpośrednio na ekranie blokady. Wcześniej na zaszyfrowanych urządzeniach korzystających z pełnego szyfrowania dysku (FDE) użytkownicy musieli podać poświadczenia przed uzyskaniem dostępu do jakichkolwiek danych, uniemożliwiając telefonowi wykonanie wszystkich, z wyjątkiem najbardziej podstawowych, operacji. Na przykład alarmy nie działały, usługi ułatwień dostępu były niedostępne, a telefony nie mogły odbierać połączeń, ale były ograniczone tylko do podstawowych funkcji dialera alarmowego.

Dzięki wprowadzeniu szyfrowania opartego na plikach (FBE) i nowych interfejsów API informujących aplikacje o szyfrowaniu, aplikacje te mogą działać w ograniczonym kontekście. Może się to zdarzyć, zanim użytkownicy podadzą swoje poświadczenia, jednocześnie chroniąc prywatne informacje o użytkowniku.

Na urządzeniu obsługującym FBE każdy użytkownik urządzenia ma dwie lokalizacje pamięci dostępne dla aplikacji:

  • Magazyn szyfrowany (CE) poświadczeń, który jest domyślną lokalizacją przechowywania i jest dostępny tylko po odblokowaniu urządzenia przez użytkownika.
  • Urządzenie szyfrowane (DE), które jest miejscem przechowywania dostępnym zarówno w trybie bezpośredniego rozruchu, jak i po odblokowaniu urządzenia przez użytkownika.

Ta separacja sprawia, że ​​profile do pracy są bezpieczniejsze, ponieważ umożliwia ochronę więcej niż jednego użytkownika w tym samym czasie, ponieważ szyfrowanie nie jest już oparte wyłącznie na haśle startowym.

Interfejs API Direct Boot umożliwia aplikacjom obsługującym szyfrowanie dostęp do każdego z tych obszarów. Istnieją zmiany w cyklu życia aplikacji, aby uwzględnić potrzebę powiadamiania aplikacji o odblokowaniu magazynu CE użytkownika w odpowiedzi na pierwsze wprowadzenie poświadczeń na ekranie blokady lub w przypadku profilu służbowego stanowiącego wyzwanie w pracy . Urządzenia z systemem Android 7.0 muszą obsługiwać te nowe interfejsy API i cykle życia, niezależnie od tego, czy implementują FBE, czy nie. Chociaż bez FBE, pamięć DE i CE zawsze będzie w stanie odblokowanym.

Pełna implementacja szyfrowania opartego na plikach w systemach plików Ext4 i F2FS jest dostępna w Android Open Source Project (AOSP) i musi być włączona tylko na urządzeniach, które spełniają wymagania. Producenci decydujący się na korzystanie z FBE mogą chcieć zbadać sposoby optymalizacji tej funkcji w oparciu o używany system na chipie (SoC).

Wszystkie niezbędne pakiety w AOSP zostały zaktualizowane, aby obsługiwały bezpośrednie uruchamianie. Jeśli jednak producenci urządzeń używają dostosowanych wersji tych aplikacji, będą chcieli upewnić się, że istnieją co najmniej pakiety obsługujące rozruch bezpośredni, zapewniające następujące usługi:

  • Usługi telefoniczne i dialer
  • Metoda wprowadzania haseł na ekranie blokady

Przykłady i źródło

Android zapewnia referencyjną implementację szyfrowania opartego na plikach, w której vold ( system / vold ) zapewnia funkcjonalność zarządzania urządzeniami magazynującymi i woluminami w systemie Android. Dodanie FBE zapewnia voldowi kilka nowych poleceń do obsługi zarządzania kluczami dla kluczy CE i DE wielu użytkowników. Oprócz podstawowych zmian w zakresie korzystania z funkcji szyfrowania opartego na plikach w jądrze, wiele pakietów systemowych, w tym lockscreen i SystemUI, zostało zmodyfikowanych w celu obsługi funkcji FBE i Direct Boot. Obejmują one:

  • AOSP Dialer (pakiety / aplikacje / Dialer)
  • Desk Clock (pakiety / aplikacje / DeskClock)
  • LatinIME (pakiety / metody wprowadzania / LatinIME) *
  • Aplikacja ustawień (pakiety / aplikacje / ustawienia) *
  • SystemUI (frameworki / baza / pakiety / SystemUI) *

* Aplikacje systemowe korzystające z defaultToDeviceProtectedStorage manifestu defaultToDeviceProtectedStorage

Więcej przykładów aplikacji i usług obsługujących szyfrowanie można znaleźć, uruchamiając polecenie mangrep directBootAware w katalogu frameworków lub pakietów drzewa źródłowego AOSP.

Zależności

Aby bezpiecznie korzystać z implementacji FBE AOSP, urządzenie musi spełniać następujące zależności:

  • Obsługa jądra dla szyfrowania Ext4 lub szyfrowania F2FS.
  • Obsługa Keymaster z warstwą HAL w wersji 1.0 lub 2.0. Nie ma wsparcia dla Keymaster 0.3, ponieważ nie zapewnia to niezbędnych możliwości ani nie zapewnia wystarczającej ochrony kluczy szyfrujących.
  • Keymaster / Keystore i Gatekeeper muszą być zaimplementowane w Trusted Execution Environment (TEE), aby zapewnić ochronę kluczy DE, tak aby nieautoryzowany system operacyjny (niestandardowy system operacyjny flashowany na urządzeniu) nie mógł po prostu zażądać kluczy DE.
  • Sprzętowe rootowanie zaufania i zweryfikowany rozruch powiązany z inicjalizacją mistrza kluczy są wymagane, aby zapewnić, że poświadczenia szyfrowania urządzenia nie są dostępne dla nieautoryzowanego systemu operacyjnego.

Uwaga : zasady przechowywania są stosowane do folderu i wszystkich jego podfolderów. Producenci powinni ograniczyć niezaszyfrowaną zawartość do folderu OTA i folderu zawierającego klucz odszyfrowywania systemu. Większość zawartości powinna znajdować się w magazynie zaszyfrowanym poświadczeniami, a nie w magazynie zaszyfrowanym przez urządzenie.

Realizacja

Przede wszystkim aplikacje takie jak budziki, telefon, funkcje ułatwień dostępu powinny być wykonane na androida: directBootAware zgodnie z dokumentacją dewelopera Direct Boot .

Wsparcie jądra

Obsługa jądra dla szyfrowania Ext4 i F2FS jest dostępna we wspólnych jądrach Androida w wersji 3.18 i nowszych. Aby włączyć to w jądrze w wersji 5.1 lub nowszej, użyj:

CONFIG_FS_ENCRYPTION=y

Dla starszych jąder, użytkowania CONFIG_EXT4_ENCRYPTION=y , jeśli urządzenie jest userdata systemu plików Ext4 jest lub wykorzystanie CONFIG_F2FS_FS_ENCRYPTION=y , jeśli urządzenie użytkownika userdata plików jest f2fs.

Jeśli Twoje urządzenie będzie obsługiwać przystosowalną pamięć masową lub będzie używać szyfrowania metadanych w pamięci wewnętrznej, włącz także opcje konfiguracji jądra potrzebne do szyfrowania metadanych, zgodnie z opisem w dokumentacji szyfrowania metadanych .

Oprócz funkcjonalnej obsługi szyfrowania Ext4 lub F2FS, producenci urządzeń powinni również włączyć akcelerację kryptograficzną, aby przyspieszyć szyfrowanie oparte na plikach i poprawić komfort użytkowania. Na przykład na urządzeniach opartych na ARM64 akcelerację ARMv8 CE (Cryptography Extensions) można włączyć, ustawiając następujące opcje konfiguracji jądra:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Aby jeszcze bardziej poprawić wydajność i zmniejszyć zużycie energii, producenci urządzeń mogą również rozważyć wdrożenie sprzętu szyfrującego w linii , który szyfruje / odszyfrowuje dane w drodze do / z urządzenia magazynującego. Wspólne jądra systemu Android (wersja 4.14 i nowsze) zawierają strukturę, która umożliwia szyfrowanie wbudowane, gdy dostępna jest obsługa sprzętu i sterowników dostawcy. Strukturę 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 opartej na systemie UFS, włącz również:

CONFIG_SCSI_UFS_CRYPTO=y

Jeśli Twoje urządzenie korzysta z pamięci eMMC, włącz także:

CONFIG_MMC_CRYPTO=y

Włączanie szyfrowania opartego na plikach

Włączanie FBE na urządzeniu wymaga umożliwiając jej na pamięci wewnętrznej ( userdata ). To również automatycznie włącza FBE w adaptowalnej pamięci masowej; jednak w razie potrzeby format szyfrowania w przystosowanej pamięci masowej może zostać zastąpiony.

Pamięć wewnętrzna

FBE jest włączona przez dodanie funkcji fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] na kolumnę fs_mgr_flags na fstab line userdata . Ta opcja określa format szyfrowania w pamięci wewnętrznej. Zawiera do trzech parametrów oddzielonych dwukropkiem:

  • W contents_encryption_mode definiuje parametr, który algorytm kryptograficzny jest używany do szyfrowania zawartości plików. Może to być aes-256-xts lub adiantum .
  • Parametr filenames_encryption_mode określa, który algorytm kryptograficzny jest używany do szyfrowania nazw plików. Może to być aes-256-cts , aes-256-heh lub adiantum . Jeśli nie podano, to domyślnie aes-256-cts jeśli contents_encryption_mode jest aes-256-xts lub adiantum jeśli contents_encryption_mode jest adiantum .
  • Parametr flags , nowość w Androidzie 11, to lista flag oddzielonych znakiem + . Obsługiwane są następujące flagi:
    • Flaga v1 wybiera zasady szyfrowania w wersji 1; flaga v2 wybiera zasady szyfrowania w wersji 2. Zasady szyfrowania w wersji 2 wykorzystują bezpieczniejszą i bardziej elastyczną funkcję pozyskiwania klucza . Wartość domyślna to v2, jeśli urządzenie zostało uruchomione w systemie Android 11 lub nowszym (zgodnie z określeniem ro.product.first_api_level ), lub v1, jeśli urządzenie zostało uruchomione w systemie Android 10 lub ro.product.first_api_level .
    • Flaga inlinecrypt_optimized wybiera format szyfrowania, który jest zoptymalizowany pod kątem sprzętu do szyfrowania wbudowanego, który nie obsługuje wydajnie dużej liczby kluczy. Robi to poprzez wyprowadzenie tylko jednego klucza szyfrowania zawartości pliku na klucz CE lub DE, a nie jednego na plik. Generowanie IV (wektorów inicjalizacyjnych) jest odpowiednio dostosowywane.
    • Flaga emmc_optimized jest podobna do inlinecrypt_optimized , ale wybiera również metodę IV generacji, która ogranicza IV do 32 bitów. Ta flaga powinna być używana tylko na sprzęcie szyfrującym w linii, który jest zgodny ze specyfikacją JEDEC eMMC v5.2 i dlatego obsługuje tylko 32-bitowe IV. Na innym sprzęcie do szyfrowania wbudowanego użyj zamiast tego inlinecrypt_optimized . Ta flaga nigdy nie powinna być używana w przypadku pamięci masowej opartej na systemie UFS; specyfikacja UFS pozwala na użycie 64-bitowych IV.
    • Flaga wrappedkey_v0 umożliwia użycie kluczy opakowanych sprzętowo. Po włączeniu klucze FBE nie są generowane przez oprogramowanie, ale raczej są generowane przez Keymaster przy użyciu tagu STORAGE_KEY . Następnie każdy klucz FBE faktycznie dostarczony do jądra jest kluczem STORAGE_KEY wyeksportowanym z Keymaster, co powoduje, że jest on opakowany efemerycznym kluczem dla każdego rozruchu. Następnie jądro dostarcza opakowane klucze bezpośrednio do wbudowanego sprzętu szyfrującego. Po prawidłowym wdrożeniu niezapakowane klucze nigdy nie są obecne w pamięci systemowej, a po ponownym uruchomieniu nie można użyć uszkodzonego, opakowanego klucza. Flaga ta wymaga wsparcia sprzętowego, wsparcie keymaster dla STORAGE_KEY , wsparcie sterowników jądra, inlinecrypt opcji montażu, i albo inlinecrypt_optimized lub emmc_optimized flagi.

Jeśli nie używasz sprzętu do szyfrowania wbudowanego, zalecane ustawienie dla większości urządzeń to fileencryption=aes-256-xts . Jeśli używasz sprzętu do szyfrowania wbudowanego, zalecanym ustawieniem dla większości urządzeń jest fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized . Na urządzeniach bez żadnej formy akceleracji AES można użyć Adiantum zamiast AES, ustawiając fileencryption=adiantum .

Na urządzeniach z systemem Android 10 lub fileencryption=ice akceptuje się również fileencryption=ice celu określenia użycia trybu szyfrowania zawartości plików FSCRYPT_MODE_PRIVATE . Ten tryb nie jest zaimplementowany przez wspólne jądra Androida, ale może być zaimplementowany przez dostawców przy użyciu niestandardowych poprawek do jądra. Format na dysku utworzony w tym trybie był specyficzny dla dostawcy. Na urządzeniach z systemem Android 11 lub nowszym ten tryb nie jest już dozwolony i zamiast tego należy użyć standardowego formatu szyfrowania.

Domyślnie szyfrowanie zawartości plików odbywa się za pomocą kryptograficznego interfejsu API jądra systemu Linux. Jeśli zamiast tego chcesz użyć sprzętu do szyfrowania inline, dodaj również opcję montowania inlinecrypt . Na przykład pełna linia fstab może wyglądać następująco:

/dev/block/by-name/userdata /data f2fs nodev,noatime,nosuid,errors=panic,inlinecrypt wait,fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized

Adoptable storage

Od Androida 9 FBE i adaptowalna pamięć masowa mogą być używane razem.

Określanie fileencryption opcję fstab dla userdata również automatycznie umożliwia zarówno FBE i metadanych szyfrowanie na adoptable przechowywania. Możesz jednak przesłonić formaty szyfrowania FBE i / lub metadanych w adaptowalnej pamięci, ustawiając właściwości w PRODUCT_PROPERTY_OVERRIDES .

Na urządzeniach z systemem Android 11 lub nowszym użyj następujących właściwości:

  • ro.crypto.volume.options (nowość w Androidzie 11) wybiera format szyfrowania FBE w przystosowanej pamięci masowej. Ma taką samą składnię jak argument opcji fileencryption fstab i używa tych samych wartości domyślnych. Zobacz zalecenia dotyczące fileencryption powyżej, aby dowiedzieć się, czego tutaj użyć.
  • ro.crypto.volume.metadata.encryption wybiera format szyfrowania metadanych w przystosowanej pamięci masowej. Zobacz dokumentację dotyczącą szyfrowania metadanych .

Na urządzeniach z systemem Android 10 lub starszym użyj następujących właściwości:

  • ro.crypto.volume.contents_mode wybiera tryb szyfrowania zawartości. Jest to odpowiednik pierwszego pola rozdzielanego dwukropkami w ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode wybiera tryb szyfrowania nazw plików. Jest to odpowiednik drugiego pola rozdzielanego dwukropkami w ro.crypto.volume.options , z tą różnicą, że domyślną wartością na urządzeniach z Androidem 10 lub ro.crypto.volume.options jest aes-256-heh . Na większości urządzeń należy to jawnie zastąpić aes-256-cts .
  • ro.crypto.fde_algorithm i ro.crypto.fde_sector_size wybierają format szyfrowania metadanych na przystosowanej pamięci. Zobacz dokumentację dotyczącą szyfrowania metadanych .

Integracja z Keymaster

Generowanie kluczy i zarządzanie zestawem kluczy jądra jest obsługiwane przez vold . Implementacja FBE AOSP wymaga, aby urządzenie obsługiwało Keymaster HAL w wersji 1.0 lub nowszej. Nie ma wsparcia dla wcześniejszych wersji Keymaster HAL.

Przy pierwszym uruchomieniu klucze użytkownika 0 są generowane i instalowane na wczesnym etapie procesu uruchamiania. Do czasu zakończenia fazy on-post-fs init , Keymaster musi być gotowy do obsługi żądań. Na urządzeniach Pixel jest to obsługiwane przez blok skryptu, zapewniający uruchomienie Keymastera przed zamontowaniem /data .

Polityka szyfrowania

Szyfrowanie oparte na plikach stosuje zasady szyfrowania na poziomie katalogu. Gdy urządzenie jest userdata partycja jest stworzony, podstawowe konstrukcje i zasady są stosowane przez init skryptów. Skrypty te spowodują utworzenie kluczy CE i DE pierwszego użytkownika (użytkownika 0), a także zdefiniują, które katalogi mają być zaszyfrowane tymi kluczami. Podczas tworzenia dodatkowych użytkowników i profili niezbędne dodatkowe klucze są generowane i przechowywane w magazynie kluczy; tworzone są ich dane uwierzytelniające i lokalizacje pamięci urządzeń, a zasady szyfrowania łączą te klucze z tymi katalogami.

W systemie Android 11 i nowszych, zasady szyfrowania nie są już zakodowane na stałe w scentralizowanej lokalizacji, ale raczej są definiowane przez argumenty poleceń mkdir w skryptach inicjalizacyjnych. Katalogi zaszyfrowane za pomocą systemowego klucza DE używają encryption=Require , podczas gdy niezaszyfrowane katalogi (lub katalogi, których podkatalogi są zaszyfrowane kluczami na użytkownika) używają encryption=None .

W systemie Android 10 zasady szyfrowania zostały zakodowane na stałe w tej lokalizacji:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

W systemie Android 9 i wcześniejszych lokalizacja:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Możliwe jest dodanie wyjątków, aby w ogóle uniemożliwić szyfrowanie niektórych katalogów. Jeśli tego rodzaju modyfikacje zostaną wprowadzone, producent urządzenia powinien uwzględnić zasady SELinux, które zapewniają dostęp tylko do aplikacji, które muszą korzystać z niezaszyfrowanego katalogu. Powinno to wykluczyć wszystkie niezaufane aplikacje.

Jedynym znanym dopuszczalnym przypadkiem użycia w tym przypadku jest wsparcie starszych funkcji OTA.

Obsługa bezpośredniego rozruchu w aplikacjach systemowych

Uwzględnianie bezpośredniego rozruchu aplikacji

Aby ułatwić szybką migrację aplikacji systemowych, istnieją dwa nowe atrybuty, które 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 jest skrótem służącym do oznaczania wszystkich składników aplikacji jako obsługujących szyfrowanie.

Atrybut defaultToDeviceProtectedStorage przekierowuje domyślną lokalizację magazynu aplikacji, aby wskazywała na magazyn DE zamiast wskazywać na magazyn CE. Aplikacje systemowe używające tej flagi muszą dokładnie kontrolować wszystkie dane przechowywane w domyślnej lokalizacji i zmieniać ścieżki danych wrażliwych, aby korzystały z pamięci CE. Producenci urządzeń korzystający z tej opcji powinni dokładnie sprawdzić przechowywane przez siebie dane, aby upewnić się, że nie zawierają one danych osobowych.

Podczas pracy w tym trybie następujące systemowe interfejsy API są dostępne do jawnego zarządzania kontekstem obsługiwanym przez magazyn CE w razie potrzeby, co jest równoważne ich odpowiednikom chronionym przez 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 otrzymuje dwa klucze: DE i CE. Użytkownik 0 musi najpierw zalogować się do urządzenia, ponieważ jest to użytkownik specjalny. Jest to istotne w przypadku zastosowań związanych z administrowaniem urządzeniem .

Aplikacje obsługujące szyfrowanie współdziałają z użytkownikami w ten sposób: INTERACT_ACROSS_USERS i INTERACT_ACROSS_USERS_FULL pozwalają aplikacji działać na wszystkich użytkownikach urządzenia. Jednak te aplikacje będą miały dostęp tylko do katalogów zaszyfrowanych CE dla użytkowników, którzy są już odblokowani.

Aplikacja może mieć możliwość swobodnej interakcji w obszarach DE, ale odblokowanie jednego użytkownika nie oznacza, że ​​wszyscy użytkownicy urządzenia są odblokowani. Aplikacja powinna sprawdzić ten stan przed próbą uzyskania dostępu do tych obszarów.

Każdy identyfikator użytkownika profilu do pracy otrzymuje również dwa klucze: DE i CE. Gdy wyzwanie robocze zostanie spełnione, użytkownik profilu zostaje odblokowany, a Keymaster (w TEE) może dostarczyć klucz TEE profilu.

Obsługa aktualizacji

Partycja odzyskiwania nie może uzyskać dostępu do magazynu chronionego przez DE na partycji danych użytkownika. Urządzenia implementujące FBE są zdecydowanie zalecane do obsługi OTA przy użyciu aktualizacji systemu A / B. Ponieważ OTA można zastosować podczas normalnej pracy, nie ma potrzeby odzyskiwania dostępu do danych na zaszyfrowanym dysku.

W przypadku używania starszego rozwiązanie OTA, który wymaga odzyskania dostępu do pliku OTA na userdata partycji:

  1. Utwórz katalog najwyższego poziomu (na przykład misc_ne ) w userdata partycji.
  2. Dodaj ten katalog najwyższego poziomu do wyjątku zasad szyfrowania (zobacz powyżej zasady szyfrowania ).
  3. Utwórz katalog w katalogu najwyższego poziomu do przechowywania pakietów OTA.
  4. Dodaj regułę SELinux i konteksty plików, aby kontrolować dostęp do tego folderu i jego zawartości. Tylko proces lub aplikacje otrzymujące aktualizacje OTA powinny mieć możliwość odczytu i zapisu w tym folderze. Żadna inna aplikacja ani proces nie powinien mieć dostępu do tego folderu.

Uprawomocnienie

Aby upewnić się, że zaimplementowana wersja funkcji działa zgodnie z przeznaczeniem, najpierw uruchom wiele testów szyfrowania CTS, takich jak DirectBootHostTest i EncryptionTest .

Jeśli urządzenie działa pod kontrolą Androida 11 lub nowszego, uruchom również vts_kernel_encryption_test :

atest vts_kernel_encryption_test

lub:

vts-tradefed run vts -m vts_kernel_encryption_test

Ponadto producenci urządzeń mogą przeprowadzić następujące testy ręczne. Na urządzeniu z włączonym FBE:

  • Sprawdź, ro.crypto.state istnieje ro.crypto.state
    • Upewnij się, że ro.crypto.state jest zaszyfrowany
  • Sprawdź, ro.crypto.type istnieje ro.crypto.type
    • Upewnij się, że ro.crypto.type jest ustawiony na file

Ponadto testerzy mogą uruchamiać instancję userdebug z userdebug ustawioną na głównym użytkowniku. Następnie adb shell do urządzenia i użyj su aby zostać rootem. Upewnij się, że /data/data zawiera zaszyfrowane nazwy plików; jeśli nie, coś jest nie tak.

Producentów urządzeń zachęca się również do zbadania możliwości uruchamiania zewnętrznych testów Linuksa dla fscrypt na ich urządzeniach lub jądrach. Te testy są częścią zestawu testów systemu plików xfstests. Jednak te testy upstream nie są oficjalnie obsługiwane przez Androida.

Szczegóły implementacji AOSP

Ta sekcja zawiera szczegółowe informacje na temat implementacji AOSP i opisuje sposób działania szyfrowania opartego na plikach. Producenci urządzeń nie powinni wprowadzać żadnych zmian w tym miejscu, aby używać FBE i bezpośredniego rozruchu na swoich urządzeniach.

szyfrowanie fscrypt

Implementacja AOSP wykorzystuje w jądrze szyfrowanie „fscrypt” (obsługiwane przez ext4 i f2fs) i zwykle jest skonfigurowana tak, aby:

  • Szyfruj zawartość pliku za pomocą AES-256 w trybie XTS
  • Szyfruj nazwy plików za pomocą AES-256 w trybie CBC-CTS

Obsługiwane jest również szyfrowanie Adiantum . Gdy szyfrowanie Adiantum jest włączone, zarówno zawartość plików, jak i nazwy plików są szyfrowane za pomocą Adiantum.

Aby uzyskać więcej informacji o fscrypt, zobacz dokumentację jądra źródłowego.

Wyprowadzenie klucza

Klucze szyfrowania oparte na plikach, które są kluczami 512-bitowymi, są przechowywane w postaci zaszyfrowanej innym kluczem (256-bitowym kluczem AES-GCM) przechowywanym w TEE. Aby użyć tego klucza TEE, muszą być spełnione trzy wymagania:

  • Token autoryzacji
  • Rozciągnięte referencje
  • „Secdiscardable hash”

Token uwierzytelniania to token uwierzytelniany kryptograficznie, generowany przez Gatekeepera, gdy użytkownik loguje się pomyślnie. TEE odmówi użycia klucza, chyba że zostanie dostarczony poprawny token uwierzytelniania. Jeśli użytkownik nie ma poświadczeń, nie jest używany ani potrzebny token uwierzytelniania.

Rozciągnięte poświadczenie to poświadczenie użytkownika po soleniu i rozciągnięciu za pomocą algorytmu scrypt . Poświadczenie jest faktycznie szyfrowane raz w usłudze ustawień blokady, zanim zostanie przekazane do vold celu przekazania do scrypt . Jest to kryptograficznie powiązane z kluczem w TEE ze wszystkimi gwarancjami, które mają zastosowanie do KM_TAG_APPLICATION_ID . Jeśli użytkownik nie ma poświadczeń, nie jest używane ani potrzebne żadne rozciągnięte poświadczenie.

secdiscardable hash to 512-bitowy skrót losowego pliku o rozmiarze 16 KB przechowywany wraz z innymi informacjami używanymi do rekonstrukcji klucza, takimi jak ziarno. Ten plik jest bezpiecznie usuwany po usunięciu klucza lub jest szyfrowany w nowy sposób; ta dodatkowa ochrona gwarantuje, że osoba atakująca musi odzyskać każdy bit tego bezpiecznie usuniętego pliku, aby odzyskać klucz. Jest to kryptograficznie powiązane z kluczem w TEE ze wszystkimi gwarancjami, które mają zastosowanie do KM_TAG_APPLICATION_ID .

W większości przypadków klucze FBE są również poddawane dodatkowemu etapowi wyprowadzania klucza w jądrze, aby wygenerować podklucze faktycznie używane do szyfrowania, na przykład klucze dla pliku lub dla trybu. W przypadku zasad szyfrowania w wersji 2 używany jest do tego HKDF-SHA512.