Szyfrowanie oparte na plikach

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

Android 7.0 i nowszy obsługuje 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 oraz jak aplikacje systemowe mogą korzystać z interfejsów API Direct Boot, aby oferować użytkownikom możliwie najlepsze i najbezpieczniejsze środowisko.

Bezpośredni rozruch

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

Dzięki wprowadzeniu szyfrowania opartego na plikach (FBE) i nowych interfejsów API, które informują 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 użytkownika.

Na urządzeniu z włączoną funkcją FBE każdy użytkownik urządzenia ma dwie lokalizacje pamięci dostępne dla aplikacji:

  • Pamięć masowa zaszyfrowana poświadczeniami (CE), która jest domyślną lokalizacją przechowywania i jest dostępna tylko po odblokowaniu urządzenia przez użytkownika.
  • Pamięć masowa zaszyfrowana przez urządzenie (DE), która jest miejscem przechowywania dostępnym zarówno w trybie rozruchu bezpośredniego, jak i po odblokowaniu urządzenia przez użytkownika.

Ta separacja sprawia, że ​​profile służbowe są bezpieczniejsze, ponieważ pozwala na ochronę więcej niż jednego użytkownika naraz, ponieważ szyfrowanie nie jest już oparte wyłącznie na haśle podczas rozruchu.

Interfejs API Direct Boot umożliwia aplikacjom obsługującym szyfrowanie dostęp do każdego z tych obszarów. Wprowadzono zmiany w cyklu życia aplikacji, aby uwzględnić potrzebę powiadamiania aplikacji, gdy pamięć CE użytkownika zostanie odblokowana w odpowiedzi na pierwsze wprowadzenie poświadczeń na ekranie blokady lub w przypadku profilu do pracy zapewniającego wyzwanie . Urządzenia z systemem Android 7.0 muszą obsługiwać te nowe interfejsy API i cykle życia, niezależnie od tego, czy implementują FBE. 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 projekcie Android Open Source Project (AOSP) i wymaga włączenia tylko na urządzeniach spełniających wymagania. Producenci decydujący się na korzystanie z FBE mogą chcieć zbadać sposoby optymalizacji funkcji w oparciu o używany system na chipie (SoC).

Wszystkie niezbędne pakiety w AOSP zostały zaktualizowane do obsługi bezpośredniego rozruchu. Jednak tam, gdzie producenci urządzeń używają niestandardowych wersji tych aplikacji, będą chcieli zapewnić przynajmniej pakiety obsługujące rozruch bezpośredni, które zapewniają następujące usługi:

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

Przykłady i źródło

System Android zapewnia referencyjną implementację szyfrowania opartego na plikach, w której vold ( system/vold ) udostępnia funkcje zarządzania urządzeniami pamięci masowej i woluminami w systemie Android. Dodanie FBE zapewnia voldowi kilka nowych poleceń wspierających zarządzanie kluczami dla kluczy CE i DE wielu użytkowników. Oprócz podstawowych zmian dotyczących korzystania z funkcji szyfrowania plików w jądrze, wiele pakietów systemowych, w tym ekran blokady i SystemUI, zostało zmodyfikowanych w celu obsługi funkcji FBE i Direct Boot. Obejmują one:

  • AOSP Dialer (pakiety/aplikacje/Dialer)
  • Zegar na biurko (pakiety/aplikacje/zegar na biurko)
  • LatinIME (pakiety/metody wprowadzania/LatinIME)*
  • Aplikacja Ustawienia (pakiety/aplikacje/Ustawienia)*
  • SystemUI (frameworki/baza/pakiety/SystemUI)*

* Aplikacje systemowe, które używają atrybutu 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 frameworks lub packages drzewa źródłowego AOSP.

Zależności

Aby bezpiecznie korzystać z implementacji AOSP FBE, 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 HAL w wersji 1.0 lub 2.0. Nie ma wsparcia dla Keymaster 0.3, ponieważ nie zapewnia niezbędnych możliwości ani nie zapewnia wystarczającej ochrony kluczy szyfrowania.
  • Klucze Keymaster/ Keystore i Gatekeeper muszą być zaimplementowane w środowisku 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.
  • Hardware Root of Trust i Verified Boot powiązane z inicjalizacją keymastera 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ć zawartość niezaszyfrowaną do folderu OTA i folderu zawierającego klucz odszyfrowujący system. Większość treści powinna znajdować się w pamięci zaszyfrowanej poświadczeniami, a nie w pamięci zaszyfrowanej na urządzeniu.

Realizacja

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

Wsparcie jądra

Obsługa jądra dla szyfrowania Ext4 i F2FS jest dostępna w popularnych jądrach Androida w wersji 3.18 i nowszych. Aby włączyć ją w jądrze w wersji 5.1 lub wyższej, użyj:

CONFIG_FS_ENCRYPTION=y

W przypadku starszych jąder użyj CONFIG_EXT4_ENCRYPTION=y , jeśli system plików danych użytkownika urządzenia to Ext4, lub userdata = CONFIG_F2FS_FS_ENCRYPTION=y , jeśli system plików danych użytkownika urządzenia to userdata .

Jeśli Twoje urządzenie będzie obsługiwać pamięć masową lub będzie korzystać z szyfrowania metadanych w pamięci wewnętrznej, włącz również opcje konfiguracji jądra wymagane 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ć wrażenia użytkownika. Na przykład na urządzeniach opartych na architekturze 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 wbudowanego sprzętu szyfrującego , który szyfruje/odszyfrowuje dane w drodze do/z urządzenia pamięci masowej. Wspólne jądra systemu Android (wersja 4.14 i nowsze) zawierają strukturę, która umożliwia stosowanie szyfrowania wbudowanego, gdy dostępna jest obsługa sterowników sprzętu i dostawcy. Wbudowany framework szyfrowania 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 masowej opartej na UFS, włącz również:

CONFIG_SCSI_UFS_CRYPTO=y

Jeśli Twoje urządzenie korzysta z pamięci masowej opartej na eMMC, włącz też:

CONFIG_MMC_CRYPTO=y

Włączanie szyfrowania opartego na plikach

Włączenie FBE na urządzeniu wymaga włączenia go w pamięci wewnętrznej ( userdata ). To również automatycznie włącza FBE na możliwej do przyjęcia pamięci; jednak format szyfrowania w magazynie możliwym do przyjęcia może zostać w razie potrzeby zastąpiony.

Pamięć wewnętrzna

FBE włącza się, dodając opcję fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] do kolumny fs_mgr_flags wiersza fstab dla userdata . Ta opcja określa format szyfrowania w pamięci wewnętrznej. Zawiera do trzech parametrów oddzielonych dwukropkami:

  • Parametr content_encryption_mode określa, który algorytm kryptograficzny jest używany do szyfrowania contents_encryption_mode pliku. Może to być aes-256-xts lub adiantum . Od Androida 11 można również pozostawić puste, aby określić domyślny algorytm, którym jest aes-256-xts .
  • 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 , adiantum lub aes-256-hctr2 . Jeśli nie jest określony, domyślnie jest to aes-256-cts , jeśli contents_encryption_mode to aes-256-xts , lub adiantum , jeśli contents_encryption_mode to adiantum .
  • Parametr flags , nowy 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 wersji 2 korzystają z bezpieczniejszej i bardziej elastycznej funkcji uzyskiwania klucza . Wartość domyślna to v2, jeśli urządzenie uruchomiono na Androidzie 11 lub nowszym (zgodnie z ro.product.first_api_level ) lub v1, jeśli urządzenie uruchomiono na Androidzie 10 lub starszym.
    • Flaga inlinecrypt_optimized wybiera format szyfrowania zoptymalizowany pod kątem wbudowanego sprzętu szyfrującego, który nie obsługuje wydajnie dużej liczby kluczy. Robi to, wyprowadzając tylko jeden klucz szyfrowania zawartości pliku na klucz CE lub DE, a nie jeden na plik. Generowanie IV (wektorów inicjujących) jest odpowiednio dostosowywane.
    • Flaga emmc_optimized jest podobna do inlinecrypt_optimized , ale wybiera również metodę generacji IV, która ogranicza IV do 32 bitów. Ta flaga powinna być używana tylko na sprzęcie do szyfrowania wbudowanego, 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 pamięci masowej opartej na UFS; specyfikacja UFS pozwala na użycie 64-bitowych IV.
    • Na urządzeniach, które obsługują klucze opakowane sprzętowo , flaga wrappedkey_v0 umożliwia korzystanie z kluczy opakowanych sprzętowo dla FBE. Można tego używać tylko w połączeniu z opcją montowania inlinecrypt i flagą inlinecrypt_optimized lub emmc_optimized .

Jeśli nie używasz wbudowanego sprzętu szyfrującego, zalecanym ustawieniem dla większości urządzeń jest fileencryption=aes-256-xts . Jeśli używasz wbudowanego sprzętu szyfrującego, zalecanym ustawieniem dla większości urządzeń jest fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (lub równoważnie fileencryption=::inlinecrypt_optimized ). Na urządzeniach bez jakiejkolwiek formy akceleracji AES, Adiantum może być używany zamiast AES, ustawiając fileencryption=adiantum .

Od Androida 14 (eksperymentalny AOSP), AES-HCTR2 jest preferowanym trybem szyfrowania nazw plików dla urządzeń z przyspieszonymi instrukcjami kryptografii. Jednak tylko nowsze jądra Androida obsługują AES-HCTR2. W przyszłej wersji Androida planuje się stać się domyślnym trybem szyfrowania nazw plików. Jeśli twoje jądro obsługuje AES-HCTR2, możesz włączyć szyfrowanie nazw plików, ustawiając filenames_encryption_mode na aes-256-hctr2 . W najprostszym przypadku można to zrobić za pomocą fileencryption=aes-256-xts:aes-256-hctr2 .

Na urządzeniach, które zostały uruchomione z systemem Android 10 lub starszym, fileencryption=ice jest również akceptowane w celu określenia użycia trybu szyfrowania zawartości pliku FSCRYPT_MODE_PRIVATE . Ten tryb nie jest zaimplementowany przez wspólne jądra Androida, ale może być zaimplementowany przez dostawców korzystających z niestandardowych poprawek jądra. Format na dysku utworzony w tym trybie był specyficzny dla dostawcy. Na urządzeniach uruchamianych 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 API jądra Linux. Jeśli zamiast tego chcesz użyć wbudowanego sprzętu szyfrującego, dodaj również opcję montowania inlinecrypt . Na przykład pełna linia fstab może wyglądać tak:

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

Przyjmowane przechowywanie

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

Określenie opcji fileencryption szyfrowania plików dla danych użytkownika również automatycznie włącza zarówno szyfrowanie userdata , jak i metadanych na możliwej do przyjęcia pamięci masowej. Możesz jednak zastąpić formaty szyfrowania FBE i/lub metadanych w możliwej do przyjęcia pamięci masowej, 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 dostępnej 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 dostępnej pamięci masowej. Zobacz dokumentację 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 ro.crypto.volume.options oddzielonego dwukropkami .
  • ro.crypto.volume.filenames_mode wybiera tryb szyfrowania nazw plików. Jest to odpowiednik drugiego pola ro.crypto.volume.options oddzielonego dwukropkami, z tą różnicą, że domyślną wartością na urządzeniach z systemem Android 10 lub niższym jest aes-256-heh . Na większości urządzeń należy to wyraźnie zastąpić aes-256-cts .
  • ro.crypto.fde_algorithm i ro.crypto.fde_sector_size wybierz format szyfrowania metadanych w przystosowanej pamięci masowej. Zobacz dokumentację szyfrowania metadanych .

Integracja z Keymaster

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

Podczas pierwszego rozruchu klucze użytkownika 0 są generowane i instalowane na wczesnym etapie procesu rozruchu. Zanim zakończy się faza init on-post-fs , Keymaster musi być gotowy do obsługi żądań. Na urządzeniach Pixel jest to obsługiwane przez blok skryptów zapewniający, że Keymaster jest uruchamiany przed zamontowaniem /data .

Polityka szyfrowania

Szyfrowanie oparte na plikach stosuje zasady szyfrowania na poziomie katalogu. Kiedy partycja danych użytkownika urządzenia jest userdata po raz pierwszy, podstawowe struktury i zasady są stosowane przez init . Skrypty te spowodują utworzenie kluczy CE i DE pierwszego użytkownika (użytkownika 0) oraz zdefiniują, które katalogi mają być zaszyfrowane tymi kluczami. Po utworzeniu dodatkowych użytkowników i profili niezbędne dodatkowe klucze są generowane i przechowywane w magazynie kluczy; tworzone są ich lokalizacje przechowywania poświadczeń i urządzeń, a zasady szyfrowania łączą te klucze z tymi katalogami.

W systemie Android 11 i nowszych polityka szyfrowania nie jest już zakodowana w scentralizowanej lokalizacji, ale jest definiowana przez argumenty poleceń mkdir w skryptach init. Katalogi zaszyfrowane kluczem DE systemu używają encryption=Require , podczas gdy katalogi niezaszyfrowane (lub katalogi, których podkatalogi są zaszyfrowane kluczami użytkownika) używają encryption=None .

W Androidzie 10 polityka szyfrowania została zakodowana w tej lokalizacji:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

W systemie Android 9 i wcześniejszych lokalizacja była:

/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. W przypadku dokonania tego rodzaju modyfikacji, producent urządzenia powinien dołączyć zasady SELinux, które przyznają dostęp tylko tym aplikacjom, które muszą korzystać z niezaszyfrowanego katalogu. Powinno to wykluczyć wszystkie niezaufane aplikacje.

Jedynym znanym dopuszczalnym przypadkiem użycia tego jest wsparcie starszych funkcji OTA.

Obsługa bezpośredniego rozruchu w aplikacjach systemowych

Uwrażliwianie aplikacji na Direct Boot

Aby ułatwić szybką migrację aplikacji systemowych, wprowadzono 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 do oznaczania wszystkich składników w aplikacji jako świadomych szyfrowania.

Atrybut defaultToDeviceProtectedStorage przekierowuje domyślną lokalizację magazynu aplikacji do magazynu DE zamiast wskazywania magazynu CE. Aplikacje systemowe korzystające z tej flagi muszą dokładnie kontrolować wszystkie dane przechowywane w domyślnej lokalizacji i zmieniać ścieżki danych wrażliwych, aby korzystać z pamięci CE. Producenci urządzeń korzystający z tej opcji powinni dokładnie sprawdzić dane, które przechowują, aby upewnić się, że nie zawierają one żadnych danych osobowych.

Podczas pracy w tym trybie dostępne są następujące systemowe interfejsy API do jawnego zarządzania kontekstem wspieranym przez magazyn CE w razie potrzeby, które są równoważne z ich odpowiednikami chronionymi przez urządzenie.

  • Context.createCredentialProtectedStorageContext()
  • Context.isCredentialProtectedStorage()

Wspieranie wielu użytkowników

Każdy użytkownik w środowisku wielu użytkowników otrzymuje osobny klucz szyfrowania. Każdy użytkownik otrzymuje dwa klucze: klucz DE i klucz CE. Użytkownik 0 musi najpierw zalogować się do urządzenia, ponieważ jest to użytkownik specjalny. Jest to istotne dla zastosowań Administracji Urządzeniami .

Aplikacje obsługujące technologię kryptograficzną wchodzą w interakcję między użytkownikami w następujący sposób: INTERACT_ACROSS_USERS i INTERACT_ACROSS_USERS_FULL umożliwiają aplikacji działanie 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 swobodnie komunikować się w obszarach DE, ale odblokowanie jednego użytkownika nie oznacza, że ​​wszyscy użytkownicy na urządzeniu 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. Zdecydowanie zaleca się, aby urządzenia z implementacją FBE obsługiwały OTA przy użyciu aktualizacji systemu A/B . Ponieważ OTA można stosować podczas normalnej pracy, nie ma potrzeby odzyskiwania danych w celu uzyskania dostępu do danych na zaszyfrowanym dysku.

W przypadku korzystania ze starszego rozwiązania OTA, które wymaga odzyskania dostępu do pliku userdata na partycji danych użytkownika:

  1. Utwórz katalog najwyższego poziomu (na przykład misc_ne ) userdata partycji danych użytkownika.
  2. Dodaj ten katalog najwyższego poziomu do wyjątku zasad szyfrowania (zobacz Zasady szyfrowania powyżej).
  3. Utwórz katalog w katalogu najwyższego poziomu, aby przechowywać pakiety 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.

Walidacja

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 na urządzeniu działa system Android 11 lub nowszy, 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ą przeprowadzać następujące testy ręczne. Na urządzeniu z włączoną funkcją FBE:

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

Dodatkowo testerzy mogą uruchomić instancję userdebug z ustawionym ekranem blokady dla głównego użytkownika. Następnie adb shell do urządzenia i użyj su , aby stać się rootem. Upewnij się, że /data/data zawiera zaszyfrowane nazwy plików; jeśli nie, coś jest nie tak.

Zachęca się również producentów urządzeń do zbadania możliwości uruchomienia zewnętrznych testów Linuksa pod kątem fscrypt na swoich urządzeniach lub jądrach. Testy te są częścią zestawu testów systemu plików xfstests. Jednak te testy zewnętrzne nie są oficjalnie obsługiwane przez system Android.

Szczegóły wdrożenia AOSP

Ta sekcja zawiera szczegółowe informacje na temat implementacji AOSP i opisuje, jak działa szyfrowanie oparte na plikach. Producenci urządzeń nie powinni tutaj wprowadzać żadnych zmian, aby używać FBE i Direct Boot na swoich urządzeniach.

szyfrowanie fscrypt

Implementacja AOSP wykorzystuje szyfrowanie "fscrypt" (obsługiwane przez ext4 i f2fs) w jądrze i zwykle jest skonfigurowana do:

  • 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ść pliku, jak i nazwy plików są szyfrowane za pomocą Adiantum.

Aby uzyskać więcej informacji o fscrypt, zobacz dokumentację jądra autora .

Pochodzenie klucza

Klucze szyfrowania oparte na plikach, które są kluczami 512-bitowymi, są przechowywane w postaci zaszyfrowanej przez inny klucz (klucz 256-bitowy AES-GCM) przechowywany w TEE. Aby użyć tego klucza TEE, należy spełnić trzy wymagania:

  • Token uwierzytelniania
  • Rozciągnięte poświadczenie
  • „Secdiscardable hash”

Token uwierzytelniania to kryptograficznie uwierzytelniony token generowany przez Gatekeeper po pomyślnym zalogowaniu użytkownika. TEE odmówi użycia klucza, jeśli nie zostanie dostarczony prawidłowy token uwierzytelniania. Jeśli użytkownik nie ma poświadczeń, token uwierzytelniania nie jest używany ani potrzebny.

Rozciągnięte dane uwierzytelniające to dane uwierzytelniające użytkownika po rozszerzeniu i rozciągnięciu za pomocą algorytmu scrypt . Poświadczenie jest w rzeczywistości zahaszowane raz w usłudze ustawień blokady, zanim zostanie przekazane do vold w 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 wielkości 16 KB, który jest przechowywany wraz z innymi informacjami używanymi do rekonstrukcji klucza, takimi jak nasiona. Ten plik jest bezpiecznie usuwany, gdy klucz jest usuwany lub jest zaszyfrowany w nowy sposób; ta dodatkowa ochrona zapewnia, że ​​atakujący musi odzyskać każdy fragment 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 przechodzą również dodatkowy etap wyprowadzania klucza w jądrze w celu wygenerowania podkluczy faktycznie używanych do szyfrowania, na przykład kluczy na plik lub na tryb. W przypadku zasad szyfrowania w wersji 2 używany jest do tego HKDF-SHA512.