Szyfrowanie oparte na plikach

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

Android 7.0 i nowsze wersje 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.

Z tego artykułu dowiesz się, jak włączyć szyfrowanie plików na nowych urządzeniach oraz jak aplikacje systemowe mogą korzystać z interfejsów Direct Boot API, aby zapewnić użytkownikom jak najlepszą ochronę.

Wszystkie urządzenia z Androidem 10 lub nowszym muszą używać szyfrowania opartego na plikach.

Bezpośredni rozruch

Szyfrowanie plików umożliwia korzystanie z nowej funkcji wprowadzonej w Androidzie 7.0, zwanej Direct Boot. Bezpośrednie uruchamianie umożliwia szyfrowanym urządzeniom uruchamianie się bezpośrednio na ekranie blokady. Wcześniej na zaszyfrowanych urządzeniach korzystających z szyfrowania całego dysku (FDE) użytkownicy musieli podać dane logowania, aby uzyskać dostęp do danych. W efekcie telefon nie mógł wykonywać żadnych operacji oprócz najbardziej podstawowych. Na przykład nie działały alarmy, usługi ułatwień dostępu były niedostępne, a telefony nie mogły odbierać połączeń. Mogły wykonywać tylko podstawowe operacje w dialerze alarmowym.

Wprowadzenie szyfrowania na poziomie plików (FBE) i nowych interfejsów API, które informują aplikacje o szyfrowaniu, umożliwia działanie tych aplikacji w ograniczonym kontekście. Może się to zdarzyć, zanim użytkownicy podadzą swoje dane logowania, a prywatne informacje o użytkownikach pozostają chronione.

Na urządzeniu z funkcją FBE każdy użytkownik ma 2 miejsca na dane dostępne dla aplikacji:

• Pamięć zaszyfrowana (CE) to domyślna lokalizacja pamięci, która jest dostępna dopiero po odblokowaniu urządzenia przez użytkownika.
• Zaszyfrowana pamięć urządzenia (DE) to lokalizacja pamięci dostępna zarówno w trybie bezpośredniego uruchamiania, jak i po odblokowaniu urządzenia przez użytkownika.

Dzięki temu profile służbowe są bezpieczniejsze, ponieważ można chronić więcej niż 1 użytkownika naraz, ponieważ szyfrowanie nie opiera się już tylko na haśle podczas uruchamiania.

Interfejs Direct Boot API umożliwia aplikacjom obsługującym szyfrowanie dostęp do tych obszarów. Wprowadziliśmy zmiany w cyklu życia aplikacji, aby umożliwić im powiadamianie o odblokowaniu pamięci CE użytkownika w odpowiedzi na wprowadzenie przez niego po raz pierwszy danych logowania na ekranie blokady lub, w przypadku profilu służbowego, wyzwanie wyzwania służbowego. Urządzenia z Androidem 7.0 muszą obsługiwać te nowe interfejsy API i cykle życia niezależnie od tego, czy implementują FBE. Bez FBE pamięć DE i CE jest zawsze odblokowana.

Pełne szyfrowanie plików w systemach plików Ext4 i F2FS jest dostępne w ramach Projektu Android Open Source (AOSP) i musi być włączone tylko na urządzeniach spełniających wymagania. Producenci, którzy zdecydują się na korzystanie z FBE, mogą szukać sposobów optymalizacji tej funkcji w zależności od używanego układu 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ą niestandardowych wersji tych aplikacji, muszą zadbać o to, aby w ramach uruchamiania bezpośredniego były dostępne co najmniej te pakiety:

• Dialer i usługi telefoniczne
• Metoda wprowadzania haseł na ekranie blokady

Przykłady i źródło

Android udostępnia referencyjne szyfrowanie oparte na plikach, w którym vold (system/vold) zapewnia funkcje do zarządzania urządzeniami i woluminami pamięci masowej na Androidzie. Dodanie FBE zapewnia vold kilka nowych poleceń do obsługi zarządzania kluczami w przypadku kluczy CE i DE wielu użytkowników. Oprócz zmian w jądrze, które umożliwiają korzystanie z funkcji szyfrowania plików w jądrze, wiele pakietów systemowych, w tym ekran blokady i interfejs SystemUI, zostało zmodyfikowanych, aby obsługiwały funkcje FBE i Direct Boot. Należą do nich:

• Dialer AOSP (pakiety/aplikacje/Dialer)
• Zegar (pakiety/aplikacje/DeskClock)
• LatinIME (packages/inputmethods/LatinIME)*
• Aplikacja Ustawienia (pakiety/aplikacje/Ustawienia)*
• SystemUI (frameworks/base/packages/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 frameworków lub pakietów w drzewie źródeł AOSP.

Zależności

Aby można było bezpiecznie korzystać z implementacji FBE w AOSP, urządzenie musi spełniać te zależności:

• Obsługa jądra w przypadku szyfrowania Ext4 lub F2FS.
• Obsługa Keymastera w przypadku HAL w wersji 1.0 lub nowszej. Nie obsługujemy wersji Keymaster 0.3, ponieważ nie zapewnia ona niezbędnych funkcji ani wystarczającej ochrony kluczy szyfrowania.
• Keymaster/Keystore i Gatekeeper muszą być wdrażane w zaufanym środowisku wykonawczym (TEE), aby zapewnić ochronę kluczy DE. Dzięki temu nieautoryzowany system operacyjny (niestandardowy system operacyjny wgrany na urządzenie) nie może po prostu poprosić o klucze DE.
• Główny element zaufania w sprzęcie i weryfikacja podczas uruchamiania związane z inicjalizacją Keymastera są wymagane, aby zapewnić, że klucze DE nie będą dostępne dla nieautoryzowanego systemu operacyjnego.

Implementacja

Przede wszystkim aplikacje takie jak budziki, telefon i funkcje ułatwień dostępu powinny być zgodne z android:directBootAware zgodnie z dokumentacją dla deweloperów dotyczącą DirectBoot.

Obsługa jądra

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

CONFIG_FS_ENCRYPTION=y

W przypadku starszych jąder użyj opcji CONFIG_EXT4_ENCRYPTION=y, jeśli userdatasystem plików urządzenia to Ext4, lub CONFIG_F2FS_FS_ENCRYPTION=y, jeśli userdatasystem plików urządzenia to F2FS.

Jeśli Twoje urządzenie obsługuje adoptable storage lub używa szyfrowania metadanych w pamięci wewnętrznej, włącz też opcje konfiguracji jądra potrzebne do szyfrowania metadanych zgodnie z opisem w dokumentacji szyfrowania metadanych.

Oprócz funkcjonalnego wsparcia szyfrowania Ext4 lub F2FS producenci urządzeń powinni również włączyć przyspieszenie kryptograficzne, aby przyspieszyć szyfrowanie plików i poprawić komfort użytkownika. Na przykład na urządzeniach z procesorem ARM64 można włączyć akcelerację ARMv8 CE (Cryptography Extensions), ustawiając te opcje konfiguracji jądra:

CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y

Aby jeszcze bardziej zwiększyć wydajność i zredukować zużycie energii, producenci urządzeń mogą rozważyć wdrożenie sprzętu do szyfrowania w transmisji, który szyfruje i odszyfrowuje dane w drodze do lub z urządzenia do przechowywania. Wspólne jądra Androida (w wersji 4.14 lub nowszej) zawierają środowisko, które umożliwia stosowanie szyfrowania w linii, gdy dostępne jest wsparcie dla sterownika sprzętu i producenta. Ramę szyfrowania w postaci kodu wbudowanego można włączyć, ustawiając te opcje konfiguracji jądra:

CONFIG_BLK_INLINE_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION_INLINE_CRYPT=y

Jeśli urządzenie korzysta z pamięci UFS, włącz też:

CONFIG_SCSI_UFS_CRYPTO=y

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

CONFIG_MMC_CRYPTO=y

Włączanie szyfrowania opartego na plikach

Włączenie FBE na urządzeniu wymaga włączenia go na pamięci wewnętrznej (userdata). W ten sposób automatycznie włączysz FBE na pamięci adoptowanej. W razie potrzeby format szyfrowania na pamięci adoptowanej można jednak zastąpić.

Pamięć wewnętrzna

FBE jest włączane przez dodanie opcji fileencryption=contents_encryption_mode[:filenames_encryption_mode[:flags]] do kolumny fs_mgr_flags w wierszu fstab w pliku userdata. Ta opcja określa format szyfrowania w pamięci wewnętrznej. Zawiera maksymalnie 3 parametry rozdzielone dwukropkiem:

• Parametr contents_encryption_mode określa, który algorytm kryptograficzny jest używany do szyfrowania zawartości pliku. Może to być aes-256-xts lub adiantum. Od Androida 11 można go też pozostawić pusty, aby użyć domyślnego algorytmu (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 podasz żadnej wartości, zostanie użyta wartość domyślna 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 rozdzielana znakiem +. Obsługiwane są te flagi:
  • Flaga v1 wybiera zasady szyfrowania w wersji 1, a flaga v2 – zasady szyfrowania w wersji 2. Wersja 2 zasad szyfrowania korzysta z bezpieczniejszej i bardziej elastycznej funkcji derywacji klucza. Domyślnie jest to wersja 2, jeśli urządzenie zostało uruchomione na Androidzie 11 lub nowszym (jak określa parametr ro.product.first_api_level), lub wersja 1, jeśli urządzenie zostało uruchomione na Androidzie 10 lub starszym.
  • Flaga inlinecrypt_optimized wybiera format szyfrowania zoptymalizowany pod kątem sprzętu do szyfrowania w strumieniu, który nie obsługuje efektywnie dużej liczby kluczy. Dokonuje tego, wyprowadzając klucz szyfrowania zawartości tylko jednego pliku na klucz CE lub DE, a nie jeden na plik. Generowanie wektorów inicjalizacji (IV) jest odpowiednio dostosowywane.
  • Flaga emmc_optimized jest podobna do flagi inlinecrypt_optimized, ale wybiera też metodę generowania IV, która ogranicza IV do 32 bitów. Tej flagi należy używać tylko w przypadku sprzętu do szyfrowania w transmisji zgodnego ze specyfikacją JEDEC eMMC v5.2, który obsługuje tylko 32-bitowe tablice IV. W przypadku innego sprzętowego szyfrowania w strumieniu danych użyj inlinecrypt_optimized. Tego parametru nie należy używać w przypadku pamięci na podstawie UFS. Specyfikacja UFS zezwala na używanie 64-bitowych IV.
  • Na urządzeniach, które obsługują klucze zaszyfrowane sprzętowo, flaga wrappedkey_v0 umożliwia korzystanie z kluczy zaszyfrowanych sprzętowo w ramach FBE. Można go używać tylko w połączeniu z opcją inlinecrypt i flagą inlinecrypt_optimized lub emmc_optimized.
  • Flaga dusize_4k wymusza, aby rozmiar jednostki danych szyfrowania wynosił 4096 bajtów, nawet jeśli rozmiar bloku w systemie plików nie wynosi 4096 bajtów. Rozmiar jednostki danych szyfrowania to poziom szczegółowości szyfrowania treści pliku. Ta flaga jest dostępna od Androida 15. Tego parametru należy używać tylko do włączania korzystania z hardware'owego szyfrowania w przesyłaniu, które nie obsługuje jednostek danych większych niż 4096 bajtów, na urządzeniu z rozmiarem strony większym niż 4096 bajtów i systemem plików f2fs.

Jeśli nie używasz sprzętowego szyfrowania w strumieniu danych, zalecane ustawienie dla większości urządzeń to fileencryption=aes-256-xts. Jeśli używasz sprzętowego szyfrowania w ramach, zalecane ustawienie dla większości urządzeń to fileencryption=aes-256-xts:aes-256-cts:inlinecrypt_optimized (lub równoważne fileencryption=::inlinecrypt_optimized). Na urządzeniach bez żadnej formy przyspieszenia AES zamiast AES można użyć Adiantum, ustawiając fileencryption=adiantum.

Od Androida 14 AES-HCTR2 jest preferowanym trybem szyfrowania nazw plików na urządzeniach z przyspieszonymi instrukcjami szyfrowania. Jednak tylko nowsze jądra Androida obsługują AES-HCTR2. W przyszłej wersji Androida ma to być domyślny tryb szyfrowania nazw plików. Jeśli jądro obsługuje AES-HCTR2, można włączyć szyfrowanie nazw plików, ustawiając wartość filenames_encryption_mode na aes-256-hctr2. W najprostszym przypadku można to zrobić za pomocą funkcji fileencryption=aes-256-xts:aes-256-hctr2.

Na urządzeniach z Androidem 10 lub starszym można też użyć wartości fileencryption=ice, aby określić użycie trybu szyfrowania zawartości pliku FSCRYPT_MODE_PRIVATE. Ten tryb nie jest obsługiwany przez wspólne jądra Androida, ale może być implementowany przez dostawców za pomocą niestandardowych poprawek jądra. Format na dysku wygenerowany przez ten tryb był specyficzny dla dostawcy. Na urządzeniach z Androidem 11 lub nowszym ten tryb nie jest już dozwolony i zamiast niego należy użyć standardowego formatu szyfrowania.

Domyślnie szyfrowanie zawartości plików odbywa się za pomocą interfejsu szyfrowania jądra Linuksa. Jeśli chcesz użyć sprzętowego szyfrowania w strumieniu, dodaj opcję inlinecrypt. 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

Pamięć dostosowywana

Od Androida 9 można używać razem FBE i adoptable storage.

Wskazanie opcji fileencryption w pliku fstab w przypadku userdata powoduje automatyczne włączanie FBE i szyfrowania metadanych w przystosowywanym magazynie. Możesz jednak zastąpić formaty szyfrowania FBE lub metadanych w przypadku adoptowanego miejsca na dane, ustawiając właściwości w PRODUCT_PROPERTY_OVERRIDES.

Na urządzeniach z Androidem 11 lub nowszym użyj tych właściwości:

• ro.crypto.volume.options (nowy w Androidzie 11) wybiera format szyfrowania FBE w pamięci wewnętrznej. Ma tę samą składnię co argument opcji fileencryption fstab i korzysta z tych samych wartości domyślnych. Aby dowiedzieć się, jakie wartości należy tu użyć, zapoznaj się z zaleceniami dotyczącymi fileencryption powyżej.
• ro.crypto.volume.metadata.encryption wybiera format szyfrowania metadanych w pamięci adoptowanej. Zapoznaj się z dokumentacją dotyczącą szyfrowania metadanych.

Na urządzeniach z Androidem 10 lub starszym używaj tych właściwości:

• ro.crypto.volume.contents_mode wybiera tryb szyfrowania treści. Jest to pole odpowiadające pierwszemu polu w elementotypie ro.crypto.volume.options, które jest oddzielone dwukropkiem.
• ro.crypto.volume.filenames_mode wybiera tryb szyfrowania nazw plików. Jest to pole odpowiadające drugiemu polu w ro.crypto.volume.options, z tym, że domyślnie na urządzeniach z Androidem 10 lub starszym jest to pole aes-256-heh. Na większości urządzeń należy wyraźnie ustawić wartość aes-256-cts.
• ro.crypto.fde_algorithm i ro.crypto.fde_sector_size wybierz format szyfrowania metadanych w pamięci wewnętrznej. Zapoznaj się z dokumentacją dotyczącą szyfrowania metadanych.

Integracja z Keymasterem

Interfejs HAL Keymaster powinien być uruchamiany w ramach klasy early_hal. Wynika to z tego, że FBE wymaga, aby Keymaster był gotowy do obsługi żądań na etapie uruchamiania post-fs-data, czyli wtedy, gdy vold konfiguruje klucze początkowe.

Wykluczanie katalogów

init stosuje systemowy klucz DE do wszystkich katalogów najwyższego poziomu w /data, z wyjątkiem katalogów, które muszą być niezaszyfrowane, takich jak katalog zawierający sam klucz systemowy DE oraz katalogi zawierające katalogi użytkownika CE lub DE. Klucze szyfrowania są stosowane rekurencyjnie i nie można ich zastąpić podkatalogami.

W Androidzie 11 i nowszych klucz, który init stosuje do katalogów, można kontrolować za pomocą argumentu encryption=<action> w komendach mkdir w skryptach init. Możliwe wartości <action> są opisane w README dla języka inicjalizacji Androida.

W Androidzie 10 działania szyfrowania init zostały zakodowane na stałe w tym miejscu:

/system/extras/libfscrypt/fscrypt_init_extensions.cpp

Na Androidzie 9 i starszych lokalizacja była:

/system/extras/ext4_utils/ext4_crypt_init_extensions.cpp

Możesz dodać wyjątki, aby uniemożliwić szyfrowanie niektórych katalogów. Jeśli takie modyfikacje zostaną wprowadzone, producent urządzenia powinien uwzględnić zasady SELinux, które przyznają dostęp tylko aplikacjom, które muszą korzystać z niezaszyfrowanego katalogu. Powinny być wykluczone wszystkie niesprawdzone aplikacje.

Jedynym znanym dopuszczalnym przypadkiem użycia jest obsługa starszych funkcji OTA.

Obsługa bezpośredniego rozruchu w aplikacji systemowej

Ustawienie aplikacji na potrzeby funkcji Direct Boot

Aby ułatwić szybkie przenoszenie aplikacji systemowych, dodaliśmy 2 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 to skrót oznaczający, że wszystkie komponenty w aplikacji są szyfrowane.

Atrybut defaultToDeviceProtectedStorage przekierowuje domyślną lokalizację pamięci aplikacji na pamięć DE zamiast na pamięć CE. Aplikacje systemowe korzystające z tego flagi muszą dokładnie sprawdzić wszystkie dane przechowywane w domyślnej lokalizacji i zmienić ścieżki danych wrażliwych, aby używać 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 danych osobowych.

W tym trybie dostępne są te interfejsy System API, które umożliwiają w razie potrzeby jawne zarządzanie kontekstem obsługiwanym przez pamięć CE. Są one odpowiednikami interfejsów Device Protected.

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

Obsługa wielu użytkowników

Każdy użytkownik w środowisku wieloużytkownika otrzymuje osobny klucz szyfrowania. Każdy użytkownik otrzymuje 2 klucze: DE i CE. Użytkownik 0 musi najpierw zalogować się na urządzeniu, ponieważ jest to użytkownik specjalny. Dotyczy to zarządzania urządzeniami.

Aplikacje obsługujące kryptowaluty w ten sposób nawiązują interakcje z użytkownikami: INTERACT_ACROSS_USERS i INTERACT_ACROSS_USERS_FULL pozwalają aplikacji działać na wszystkich użytkownikach urządzenia. Te aplikacje mają jednak dostęp tylko do katalogów zaszyfrowanych za pomocą CE w przypadku użytkowników, którzy są już odblokowani.

Aplikacja może swobodnie działać w obszarach DE, ale odblokowanie dostępu dla jednego użytkownika nie oznacza, że wszyscy użytkownicy na urządzeniu mają dostęp. Aplikacja powinna sprawdzić ten stan przed próbą uzyskania dostępu do tych obszarów.

Każdy identyfikator użytkownika profilu służbowego otrzymuje też 2 klucze: DE i CE. Gdy użytkownik spełni wymagania wyzwania służbowego, jego profil zostanie odblokowany, a administrator kluczy (w ramach TEE) będzie mógł udostępnić klucz TEE profilu.

Obsługa aktualizacji

Partycja odzyskiwania nie ma dostępu do miejsca na dane chronionego przez DE na partycji userdata. Zalecamy, aby urządzenia z FBE obsługiwały OTA za pomocą aktualizacji systemu A/B. Ponieważ aktualizację OTA można zastosować podczas normalnej pracy, nie trzeba przywracać danych, aby uzyskać dostęp do zaszyfrowanego dysku.

Jeśli używasz starszego rozwiązania OTA, które wymaga przywrócenia, aby uzyskać dostęp do pliku OTA na partycji userdata:

1. Utwórz katalog najwyższego poziomu (na przykład misc_ne) na partycji userdata.
2. Skonfiguruj ten katalog najwyższego poziomu tak, aby nie był szyfrowany (patrz Wykluczanie katalogów).
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 katalogu i jego zawartości. Tylko proces lub aplikacje otrzymujące aktualizacje OTA powinny mieć możliwość odczytu i zapisu w tym katalogu. Żadna inna aplikacja ani proces nie powinny mieć dostępu do tego katalogu.

Weryfikacja

Aby mieć pewność, że zaimplementowana wersja funkcji działa zgodnie z oczekiwaniami, najpierw uruchom wiele testów szyfrowania CTS, takich jak DirectBootHostTest i EncryptionTest.

Jeśli urządzenie ma Androida 11 lub nowszego, uruchom też 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ć te testy ręcznie. Na urządzeniu z włączonym FBE:

• Sprawdź, czy istnieje zmienna ro.crypto.state.
  • Upewnij się, że ro.crypto.state jest zaszyfrowane
• Sprawdź, czy istnieje zmienna ro.crypto.type.
  • Upewnij się, że ro.crypto.type ma wartość file.

Testerzy mogą też sprawdzić, czy pamięć CE jest zablokowana, zanim urządzenie zostanie odblokowane po raz pierwszy od uruchomienia. Aby to zrobić, użyj wersji userdebug lub eng, ustaw kod PIN, wzór lub hasło dla głównego użytkownika i ponownym uruchom urządzenie. Przed odblokowaniem urządzenia uruchom to polecenie, aby sprawdzić pamięć CE użytkownika głównego. Jeśli urządzenie korzysta z trybu bezprzewodowego systemu sterowania samochodem (większość urządzeń Automotive), głównym użytkownikiem jest użytkownik 10, więc uruchom:

adb root; adb shell ls /data/user/10

Na innych urządzeniach (w większości przypadków nie są to urządzenia motoryzacyjne) głównym użytkownikiem jest użytkownik 0, a zatem:

adb root; adb shell ls /data/user/0

Sprawdź, czy wymienione nazwy plików są zakodowane w formacie Base64, co oznacza, że pliki są zaszyfrowane, a klucz do ich odszyfrowania nie jest jeszcze dostępny. Jeśli nazwy plików są wyświetlane w postaci zwykłego tekstu, coś jest nie tak.

Producentów urządzeń zachęcamy też do przetestowania upstreamowych testów Linuksa dla fscrypt na swoich urządzeniach lub jądrach. Te testy są częścią zestawu testów xfstests dotyczących systemu plików. Te testy upstream nie są jednak oficjalnie obsługiwane przez Androida.

Szczegóły implementacji AOSP

W tej sekcji znajdziesz szczegółowe informacje o implementacji AOSP oraz opis działania szyfrowania plików. Producenci urządzeń nie powinni wprowadzać żadnych zmian, aby korzystać z FBE i Direct Boot na swoich urządzeniach.

szyfrowanie fscrypt

Implementacja AOSP korzysta z szyfrowania „fscrypt” (obsługiwanego przez ext4 i f2fs) w jądrze i zazwyczaj jest skonfigurowana tak, aby:

• Szyfrowanie zawartości pliku za pomocą AES-256 w trybie XTS
• Szyfrowanie nazw plików za pomocą AES-256 w trybie CBC-CTS

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

fscrypt obsługuje 2 wersje zasad szyfrowania: 1 i 2. Wersja 1 została wycofana, a wymagania dotyczące zgodności urządzeń z Androidem 11 lub nowszym są zgodne tylko z wersją 2. Zasady szyfrowania w wersji 2 używają funkcji HKDF-SHA512 do wyprowadzania rzeczywistych kluczy szyfrowania z kluczy dostarczonych w przestrzeni użytkownika.

Więcej informacji o fscrypt znajdziesz w dokumentacji jądra.

Klasy pamięci

W tabeli poniżej znajdziesz więcej informacji o kluczach FBE i katalogach, które chronią:

Przechowywanie i ochrona kluczy

Wszystkie klucze FBE są zarządzane przez vold i są przechowywane w zaszyfrowanej formie na dysku, z wyjątkiem klucza uruchamiania, który nie jest wcale przechowywany. W tabeli poniżej wymieniono lokalizacje, w których przechowywane są różne klucze FBE:

Jak widać w poprzedniej tabeli, większość kluczy FBE jest przechowywana w katalogach zaszyfrowanych za pomocą innego klucza FBE. Kluczy nie można odblokować, dopóki nie odblokuje się klasa pamięci, która je zawiera.

vold stosuje też warstwę szyfrowania do wszystkich kluczy FBE. Każdy klucz (oprócz kluczy CE do pamięci wewnętrznej) jest szyfrowany za pomocą algorytmu AES-256-GCM przy użyciu własnego klucza Keystore, który nie jest dostępny poza TEE. Dzięki temu kluczy FBE nie można odblokować, dopóki nie uruchomi się nieznany system operacyjny, co jest wymuszane przez weryfikację podczas uruchamiania. Odzyskiwanie danych jest również wymagane w przypadku klucza Keystore, co umożliwia bezpieczne usunięcie kluczy FBE na urządzeniach, na których Keymaster obsługuje odzyskiwanie danych. W razie braku możliwości odwrócenia zmian jako Tag::APPLICATION_ID klucza Keystore używany jest hasz SHA-512 o długości 16 384 losowych bajtach, który jest przechowywany w pliku secdiscardable obok klucza. Aby odzyskać klucz FBE, trzeba odzyskać wszystkie te bajty.

Klucze CE do pamięci wewnętrznej są chronione na wyższym poziomie, co oznacza, że nie można ich odblokować bez znajomości czynnika wiedzy blokady ekranu (LSKF) (kod PIN, wzór lub hasło), zabezpieczonego tokena resetowania kodu dostępu lub kluczy po stronie klienta i serwera w ramach operacji Resume-on-Reboot. Tokeny resetowania hasła można tworzyć tylko w przypadku profili służbowych i w pełni zarządzanych urządzeń.

W tym celu vold szyfruje każdy klucz CE na potrzeby pamięci wewnętrznej przy użyciu klucza AES-256-GCM wygenerowanego na podstawie hasła syntetycznego użytkownika. Hasło syntetyczne to niezmienne, szyfrowane hasło o wysokiej entropii, które jest generowane losowo dla każdego użytkownika. LockSettingsService w system_server zarządza hasłem syntetycznym i sposobami jego ochrony.

Aby chronić syntetyczne hasło za pomocą klucza LSKF,LockSettingsService najpierw rozciągasz ten klucz, przekazując go przez scrypt, aby uzyskać czas około 25 ms i wykorzystanie pamięci około 2 MiB. Ponieważ klucze LSKF są zwykle krótkie, ten krok zwykle nie zapewnia większego bezpieczeństwa. Główna warstwa zabezpieczeń to Secure Element (SE) lub ograniczanie szybkości na poziomie TEE, jak opisano poniżej.

Jeśli urządzenie ma element zabezpieczeń (SE), LockSettingsService przekształca rozciągnięty klucz LSKF w losowy klucz o wysokiej entropii przechowywany w SE za pomocą Weaver HAL. LockSettingsService następnie dwukrotnie szyfruje hasło syntetyczne: najpierw za pomocą klucza oprogramowania wygenerowanego na podstawie rozciągniętego klucza LSKF i tajemnicy Weavera, a potem za pomocą klucza Keystore bez uwierzytelniania. Umożliwia to ograniczenie liczby prób LSKF narzucone przez SE.

Jeśli na urządzeniu nie ma SE, LockSettingsService używa rozciągniętego LSKF jako hasła Gatekeeper. LockSettingsService następnie szyfruje syntetyczne hasło dwa razy: najpierw za pomocą klucza oprogramowania wygenerowanego na podstawie rozciągniętego klucza LSKF i ciągu znaków skrótu pliku, a potem za pomocą klucza Keystore, który jest powiązany z autoryzacją w rejestrze Gatekeeper. Umożliwia to ograniczenie szybkości prób LSKF narzucone przez TEE.

Gdy zmienisz klucz LSKF, LockSettingsService usunie wszystkie informacje powiązane z połączeniem hasła syntetycznego ze starym kluczem LSKF. Na urządzeniach, które obsługują klucze Keystore z obsługą Weaver lub przywracania, gwarantuje to bezpieczne usunięcie starego powiązania. Z tego powodu zabezpieczenia opisane w tym artykule są stosowane nawet wtedy, gdy użytkownik nie ma LSKF.