Szyfrowanie oparte na plikach

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 plików w oparciu umożliwia to nowa funkcja wprowadzona w systemie Android 7.0 o nazwie bezpośrednie Boot . Bezpośredni rozruch umożliwia zaszyfrowanym urządzeniom uruchamianie się bezpośrednio na ekranie blokady. Wcześniej na zaszyfrowanych urządzeń wykorzystujących szyfrowanie całego dysku (FDE) użytkownik konieczne w celu zapewnienia poświadczenia przed jakichkolwiek danych można uzyskać dostępu, zapobiegając telefon przed wykonaniem wszystkich, ale najbardziej podstawowe operacje. 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. Są zmiany w cyklu życia aplikacji, aby pomieścić potrzebę zgłaszania aplikacji podczas przechowywania CE użytkownika zostanie odblokowane w odpowiedzi na pierwsze mandatów wjeżdżających na ekranie blokady, lub w przypadku profilu pracy stanowiącego wyzwanie 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. 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, które spełniają 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

Android dostarcza implementację referencyjną szyfrowania plików opartych, w którym vold ( System / vold ) zapewnia funkcjonalność do zarządzania urządzeniami pamięci masowej i woluminów na Androida. Dodanie FBE zapewnia voldowi kilka nowych poleceń wspierających zarządzanie kluczami dla kluczy CE i DE wielu użytkowników. Oprócz rdzenia zmienia korzystać z szyfrowania plików na bazie możliwości w jądrze, wiele pakietów systemowych, w tym lockscreen i SystemUI zostały zmodyfikowane w celu wspierania FBE i Direct Boot możliwości. 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ą defaultToDeviceProtectedStorage oczywisty atrybut

Więcej przykładów zastosowań i usług, które są świadome szyfrowania można znaleźć uruchamiając polecenie mangrep directBootAware w ramach lub pakiety katalogu 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:

  • Kernel Wsparcie dla szyfrowania ext4 lub szyfrowania f2fs.
  • Keymaster Pomoc z HAL 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.
  • Keymaster / kluczy i Gatekeeper musi być realizowane w Trusted Execution Environment (TEE), aby zapewnić ochronę kluczy DE tak że nieuprawniona OS (custom OS błysnął na urządzenie) nie można po prostu poprosić o klucze DE.
  • Korzeń jest wymagane części składowe zaufania i zweryfikowane Boot związana z inicjalizacją keymaster celu zapewnienia, że poświadczenia Encryption Device nie są dostępne przez nieautoryzowanego systemu operacyjnego.

Uwaga: polityka magazynowe 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 android: directBootAware według bezpośrednie Boot dokumentacji dla programistów.

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

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 urządzenie będzie wspierać adoptable przechowywania lub użyje szyfrowanie metadanych w pamięci wewnętrznej, a także włączyć opcje konfiguracyjne jądra potrzebne do szyfrowania metadanych, jak opisano 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 dodatkowo zwiększyć wydajność i zmniejszyć zużycie energii, producenci urządzeń mogą również rozważyć wdrożenie sprzętu szyfrowania inline, który szyfruje / odszyfrowuje dane, gdy jest on 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łączanie FBE na urządzeniu wymaga umożliwiając jej na 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 jest włączona przez dodanie funkcji fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] do kolumny fs_mgr_flags z fstab line userdata . Ta opcja określa format szyfrowania w pamięci wewnętrznej. Zawiera do trzech parametrów oddzielonych dwukropkami:

  • 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 . Od Androida 11 może też być pozostawione puste, aby określić domyślny algorytm, który jest aes-256-xts .
  • W filenames_encryption_mode definiuje parametr, który algorytm kryptograficzny jest używany do szyfrowania nazwy 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 .
  • flags parametrem nowego w Androidzie 11, znajduje się lista flag oddzielonych + charakteru. Obsługiwane są następujące flagi:
    • W v1 polityka wersja 1 szyfrowania Oznacz wybiera; w v2 Oznacz wybiera wersja 2 polityk szyfrowania. Wersja 2 polityk szyfrowania użyć bardziej bezpieczny i elastyczny funkcji uzyskiwania klucza . Domyślnie jest V2, jeżeli urządzenie uruchomiono na Androidzie 11 lub wyższym (jak określono ro.product.first_api_level ) lub V1 Gdy urządzenie uruchomiono na Androidzie 10 lub mniej.
    • inlinecrypt_optimized flag wybiera format szyfrowania, który jest zoptymalizowany dla inline sprzętu szyfrującego, który nie efektywnie obsługiwać dużą liczbę 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.
    • emmc_optimized flaga jest podobny do inlinecrypt_optimized , ale również zaznacza się sposób generowania IV, który ogranicza kroplówki 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 szyfrowania inline, użyj inlinecrypt_optimized zamiast. Ta flaga nigdy nie powinna być używana w pamięci masowej opartej na UFS; specyfikacja UFS pozwala na użycie 64-bitowych IV.
    • W urządzeniach obsługujących kluczy sprzętowych owinięte The wrappedkey_v0 flaga umożliwia użycie klawiszy sprzętowych zawinięte dla FBE. To może być używany tylko w połączeniu z inlinecrypt opcji montażu, i albo inlinecrypt_optimized lub emmc_optimized flagę.

Jeśli nie używasz inline sprzęt szyfrujący zalecane ustawienie dla większości urządzeń jest fileencryption=aes-256-xts . Jeśli używasz inline sprzęt szyfrujący zalecane ustawienie dla większości urządzeń jest fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (lub równoważnie fileencryption=::inlinecrypt_optimized ). W urządzeniach bez jakiejkolwiek formie przyspieszania AES Pedatum mogą być stosowane zamiast AES ustawiając fileencryption=adiantum .

Na urządzeniach z Androidem rozpoczętych 10 lub niższy, fileencryption=ice jest również przyjęta do określenia wykorzystania FSCRYPT_MODE_PRIVATE trybie szyfrowania zawartości plików. 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 chcesz użyć zamiast inline sprzęt szyfrujący, również dodać inlinecrypt opcję zamontowania. Na przykład, pełne fstab linia 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

Przyjmowane przechowywanie

Od Androida 9 FBE i adoptable przechowywania mogą być wykorzystywane razem.

Określanie fileencryption opcję fstab dla userdata również automatycznie umożliwia zarówno FBE i metadanych szyfrowanie na adoptable przechowywania. Można jednak przesłonić FBE i / lub metadanych formatach szyfrowania na adoptable przechowywania poprzez ustawienie 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 na adoptable przechowywania. Ma taką samą składnię jako argument do fileencryption opcji fstab i wykorzystuje te same ustawienia domyślne. Patrz zalecenia dotyczące fileencryption powyżej co do wykorzystania tutaj.
  • ro.crypto.volume.metadata.encryption wybiera format kodowania metadanych adoptable przechowywania. 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 równoważne pierwszej okrężnicy oddzielone dziedzinie ro.crypto.volume.options .
  • ro.crypto.volume.filenames_mode wybiera tryb szyfrowania nazwy plików. Jest to równoważne z drugim okrężnicy oddzielone dziedzinie ro.crypto.volume.options tym wyjątkiem, że domyślna dla urządzenia, które rozpoczęto Android 10 lub mniejsza jest aes-256-heh . Na większości urządzeń, musi to być wyraźnie przeważa na aes-256-cts .
  • ro.crypto.fde_algorithm i ro.crypto.fde_sector_size wybrać metadanych formatu szyfrowania na adoptable przechowywania. Zobacz dokumentację szyfrowania metadanych .

Integracja z Keymaster

Generowanie kluczy i zarządzanie kluczy jądra są 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. Przez czas on-post-fs faza init zakończeniem, keymaster musi być gotowy do obsługi żądań. Na urządzeniach pikseli, to jest obsługiwane przez blok mający zapewnić keymaster skrypt jest uruchomiony przed /data jest zamontowany.

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) 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 Androidzie 11 i wyższe, polityka szyfrowania nie jest już ustalony w centralnej lokalizacji, ale raczej jest zdefiniowany przez argumenty do mkdir poleceń w skryptach startowych. Katalogi kodowane w systemie DE użycie klucz encryption=Require , gdy niekodowane katalogi (lub katalogi, których podkatalogów są szyfrowane za pomocą klawiszy per-użytkownik) stosowanie 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. Jeśli modyfikacje tego rodzaju są wówczas producent urządzenie powinno zawierać polityki SELinux , że tylko przyznać dostęp do aplikacji, które trzeba użyć katalogu niezaszyfrowane. Powinno to wykluczyć wszystkie niezaufane aplikacje.

Jedynym znanym akceptowalnym 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. defaultToDeviceProtectedStorage atrybut jest dostępny tylko dla aplikacji systemowych. directBootAware atrybut jest dostępny dla wszystkich.

<application
    android:directBootAware="true"
    android:defaultToDeviceProtectedStorage="true">

directBootAware atrybut na poziomie aplikacji jest skrótem dla oznaczenia wszystkich elementów w aplikacji jako szyfrowanie świadomy.

defaultToDeviceProtectedStorage atrybut przekierowuje miejsce przechowywania domyślnej aplikacji do momentu, w DE przechowywania zamiast wskazując na przechowywanie 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 administracji Urządzenie zastosowań.

Crypto-aware aplikacje interakcje między użytkownikami w ten sposób: INTERACT_ACROSS_USERS i INTERACT_ACROSS_USERS_FULL pozwalają aplikacja działa we wszystkich użytkowników 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. Urządzenia wykonawcze FBE są zalecane do wsparcia OTA za pomocą 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 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 z wyjątkiem polityki szyfrowania (patrz polityki 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 zapewnić realizowany wersję dzieła m.in. zgodnie z przeznaczeniem, najpierw uruchomić wiele testów szyfrowania CTS, takie jak DirectBootHostTest i EncryptionTest .

Jeśli urządzenie z Androidem 11 lub wyższy, również uruchomić 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ź, ro.crypto.state istnieje
    • Zapewnić ro.crypto.state jest szyfrowana
  • Sprawdź, ro.crypto.type istnieje
    • Zapewnić ro.crypto.type jest ustawiony na file

Dodatkowo testerzy może uruchomić userdebug wystąpienie z zestawem lockscreen na głównego użytkownika. Następnie adb shell do urządzenia i korzystanie z su do roota. Upewnij się /data/data zawiera zaszyfrowane nazwy plików; jeśli nie, coś jest nie tak.

Producenci urządzeń są również zachęcani do odkrywania uruchamiając upstream testy Linux dla fscrypt na swoich urządzeniach lub jąder. 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

Szyfrowanie adiantum jest również wspierany. 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 na temat fscrypt, zobacz upstream dokumentacji jądra .

Pochodzenie 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, należy spełnić trzy wymagania:

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

Auth token to kryptograficznego tokena przysięgłe generowane przez Gatekeeper , gdy użytkownik loguje się powodzeniem. TEE odmówi użyć klawisza chyba że dostarczany jest prawidłowe auth żeton. Jeśli użytkownik nie ma poświadczeń, token uwierzytelniania nie jest używany ani potrzebny.

Rozciągnięty poświadczenia jest poświadczenia użytkownika po soleniu rozciągania z scrypt algorytmu. Poświadczenia rzeczywiście zakodowane raz w służbie Blokada ustawień przed przekazywane vold do przejścia do scrypt . To jest kryptograficznym związany z kluczem w TEE z 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 jest 512-bitowy skrót losowego pliku 16 KB przechowywanej obok innych informacji wykorzystywanych do rekonstrukcji klucz, takich 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. To jest kryptograficznym związany z kluczem w TEE z 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.