Szyfrowanie całego dysku

Szyfrowanie całego dysku to proces kodowania wszystkich danych użytkownika na urządzeniu z Androidem za pomocą zaszyfrowanego klucza. Po zaszyfrowaniu urządzenia wszystkie dane utworzone przez użytkownika są automatycznie szyfrowane przed zapisaniem na dysku, a wszystkie odczyty automatycznie odszyfrowywane przed przekazaniem do procesu wywołania.

Szyfrowanie całego dysku zostało wprowadzone w Androidzie 4.4, ale w Androidzie 5.0 pojawiły się nowe funkcje:

• Utworzono szybkie szyfrowanie, które szyfruje tylko używane bloki na partycji danych, aby uniknąć długiego czasu uruchamiania po raz pierwszy. Szybkie szyfrowanie jest obecnie obsługiwane tylko w systemach plików ext4 i f2fs.
• Dodano flagę forceencrypt fstab, aby szyfrować podczas pierwszego rozruchu.
• Dodano obsługę wzorów i szyfrowania bez hasła.
• Dodano sprzętowe przechowywanie klucza szyfrowania przy użyciu funkcji podpisywania zaufanego środowiska wykonawczego (TEE) (np. w TrustZone). Więcej informacji znajdziesz w artykule Przechowywanie zaszyfrowanego klucza.

Uwaga: urządzenia z Androidem 5.0, które zostały zaszyfrowane, można odszyfrować, wykonując przywracanie danych fabrycznych. Nowe urządzenia z Androidem 5.0 zaszyfrowane podczas pierwszego uruchamiania nie mogą zostać przywrócone do stanu niezaszyfrowanego.

Jak działa pełne szyfrowanie dysku na Androidzie

Szyfrowanie całego dysku w Androidzie opiera się na dm-crypt, czyli funkcji jądra, która działa na poziomie urządzenia blokowego. Z tego powodu szyfrowanie działa z kartami Embedded MultiMediaCard (eMMC) i podobnymi urządzeniami flash, które są rozpoznawane przez jądro jako urządzenia blokowe. Szyfrowanie nie jest możliwe w przypadku YAFFS, który komunikuje się bezpośrednio z nieprzetworzonym układem flash NAND.

Algorytm szyfrowania to 128-bitowy Advanced Encryption Standard (AES) z łańcuchem szyfrowania blokowego (CBC) i ESSIV:SHA256. Klucz główny jest szyfrowany za pomocą 128-bitowego algorytmu AES za pomocą wywołań biblioteki OpenSSL. Klucz musi mieć co najmniej 128 bitów (256 bitów jest opcjonalne).

Uwaga: producenci sprzętu mogą użyć 128-bitowego lub wyższego klucza szyfrującego.

W wersji 5.0 Androida występują 4 stany szyfrowania:

• domyślnie
• Kod PIN
• hasło
• wzór

Podczas pierwszego uruchamiania urządzenie tworzy losowo wygenerowany 128-bitowy klucz główny, a następnie szyfruje go za pomocą domyślnego hasła i zapisanego elementu soli. Hasło domyślne to „default_password”. Jednak uzyskany wynik jest również podpisywany za pomocą TEE (np. TrustZone), który używa hasha podpisu do zaszyfrowania klucza głównego.

Domyślne hasło można znaleźć w pliku cryptfs.cpp projektu Android Open Source.

Gdy użytkownik ustawia na urządzeniu kod PIN lub hasło, tylko 128-bitowy klucz jest ponownie szyfrowany i przechowywany. (np. zmiany kodu PIN, hasła lub wzorca użytkownika NIE powodują ponownego zaszyfrowania danych użytkownika). Pamiętaj, że urządzenie zarządzane może być objęte ograniczeniami związanymi z kodem PIN, wzorem lub hasłem.

Szyfrowaniem zarządzają init i vold. init wywołuje vold, a vold ustawia właściwości, aby wywoływać zdarzenia w init. Inne części systemu również korzystają z właściwości, aby wykonywać takie zadania jak sprawdzanie stanu raportu, proszenie o hasło czy wyświetlanie prośby o przywrócenie ustawień fabrycznych w przypadku krytycznego błędu. Aby wywołać funkcje szyfrowania w vold, system używa poleceń cryptfs narzędzia wiersza poleceń vdc: checkpw, restart, enablecrypto, changepw, cryptocomplete, verifypw, setfield, getfield, mountdefaultencrypted, getpwtype, getpw i clearpw.

Aby szyfrować, odszyfrowywać lub kasować /data, /datanie może być zamontowany. Jednak aby wyświetlić dowolny interfejs użytkownika, framework musi się uruchomić, a do tego potrzebna jest biblioteka /data. Aby rozwiązać ten problem, system plików tymczasowy jest montowany w /data. Dzięki temu Android może wyświetlać prośby o hasła, pokazywać postęp lub sugerować wyczyszczenie danych w razie potrzeby. Wymusza ono jednak ograniczenie, że aby przejść z tymczasowego systemu plików do prawdziwego systemu plików /data, system musi zatrzymać wszystkie procesy z otwartymi plikami w tymczasowym systemie plików i ponownie uruchomić te procesy w rzeczywistym systemie plików /data. Aby to zrobić, wszystkie usługi muszą należeć do jednej z 3 grup: core, main i late_start.

• core: nigdy nie wyłączaj po uruchomieniu.
• main: wyłącz komputer, a następnie uruchom go ponownie po wpisaniu hasła do dysku.
• late_start: nie rozpoczyna się, dopóki /data nie zostanie odszyfrowany i zamontowany.

Aby wywołać te działania, właściwość vold.decrypt jest ustawiona na różne ciągi znaków. Aby zatrzymać i ponownie uruchomić usługi, użyj tych poleceń init:

• class_reset: zatrzymuje usługę, ale pozwala na jej ponowne uruchomienie za pomocą klasy class_start.
• class_start: uruchamia ponownie usługę.
• class_stop: zatrzymuje usługę i dodaje flagę SVC_DISABLED. Zatrzymane usługi nie odpowiadają na class_start.

Przepływy

W przypadku zaszyfrowanego urządzenia dostępne są 4 przepływy danych. Urządzenie jest szyfrowane tylko raz, a potem następuje normalny proces uruchamiania.

• Zaszyfruj wcześniej niezaszyfrowane urządzenie:
  • Szyfrowanie nowego urządzenia za pomocą forceencrypt: obowiązkowe szyfrowanie podczas pierwszego uruchamiania (od Androida L).
  • Szyfrowanie istniejącego urządzenia: szyfrowanie inicjowane przez użytkownika (Android K i starsze wersje).
• Uruchamianie zaszyfrowanego urządzenia:
  • Uruchamianie zaszyfrowanego urządzenia bez hasła: uruchamianie zaszyfrowanego urządzenia, na którym nie zostało ustawione hasło (dotyczy urządzeń z Androidem 5.0 lub nowszym).
  • Uruchamianie zaszyfrowanego urządzenia za pomocą hasła: uruchamianie zaszyfrowanego urządzenia, na którym zostało ustawione hasło.

Oprócz tych procesów urządzenie może też nie szyfrować /data. Poniżej znajdziesz szczegółowe omówienie każdego z tych procesów.

Szyfrowanie nowego urządzenia za pomocą funkcji forceencrypt

Jest to normalne pierwsze uruchomienie urządzenia z Androidem 5.0.

1. Wykrywanie niezaszyfrowanego systemu plików za pomocą flagi forceencrypt

   /data nie jest zaszyfrowany, ale musi być, ponieważ wymaga tego forceencrypt. Odmontuj /data.

2. Rozpocznij szyfrowanie /data

   vold.decrypt = "trigger_encryption" powoduje init.rc, co powoduje, że vold szyfruje /data bez hasła. (brak ustawienia, ponieważ powinno to być nowe urządzenie).

3. Montowanie tmpfs

   vold montuje tmpfs /data (korzystając z opcji tmpfs z ro.crypto.tmpfs_options) i ustawia wartość właściwości vold.encrypt_progress na 0. vold przygotowuje tmpfs /data do uruchamiania zaszyfrowanego systemu i ustawia właściwość vold.decrypt na: trigger_restart_min_framework

4. Wyświetlanie ramy w celu pokazania postępu

   Ponieważ urządzenie nie ma praktycznie żadnych danych do zaszyfrowania, pasek postępu nie będzie się często pojawiać, ponieważ szyfrowanie odbywa się bardzo szybko. Więcej informacji o interfejsie postępu znajdziesz w artykule Szyfrowanie istniejącego urządzenia.

5. Gdy /data jest zaszyfrowany, usuń framework

   vold ustawia vold.decrypt na trigger_default_encryption, co uruchamia usługę defaultcrypto. (spowoduje to rozpoczęcie procesu zamontowania domyślnie zaszyfrowanych danych użytkownika). trigger_default_encryption sprawdza typ szyfrowania, aby sprawdzić, czy /data jest zaszyfrowany z hasłem czy bez. Ponieważ urządzenia z Androidem 5.0 są szyfrowane przy pierwszym uruchomieniu, nie powinno być ustawionego hasła. Dlatego odszyfrowujemy i montujemy /data.

6. Montowanie /data

   init montuje /data na dysku RAM tmpfs, używając parametrów pobranych z ro.crypto.tmpfs_options, który jest ustawiony w init.rc.

7. Rozpocznij framework

   vold ustawia vold.decrypt na trigger_restart_framework, co powoduje kontynuowanie normalnego procesu uruchamiania.

Szyfrowanie istniejącego urządzenia

Dzieje się tak, gdy szyfrujesz niezaszyfrowane urządzenie z Androidem K lub starszym, które zostało przeniesione na Androida L.

Ten proces jest inicjowany przez użytkownika i jest określany w kodzie jako „szyfrowanie na miejscu”. Gdy użytkownik zdecyduje się na zaszyfrowanie urządzenia, interfejs upewnia się, że bateria jest w pełni naładowana, a zasilacz jest podłączony, aby zapewnić wystarczającą moc do zakończenia procesu szyfrowania.

Ostrzeżenie: jeśli urządzenie rozładuje się i wyłącza przed zakończeniem szyfrowania, dane pliku pozostaną częściowo zaszyfrowane. Urządzenie musi zostać zresetowane do ustawień fabrycznych, a wszystkie dane zostaną usunięte.

Aby włączyć szyfrowanie na miejscu, vold uruchamia pętlę, która odczytuje każdy sektor rzeczywistego urządzenia blokowego, a następnie zapisze go na urządzeniu blokowym szyfrującym. vold sprawdza, czy sektor jest używany, zanim odczyta lub zapisze dane, co znacznie przyspiesza szyfrowanie na nowym urządzeniu, które ma niewiele danych lub nie ma ich wcale.

Stan urządzenia: ustaw ro.crypto.state = "unencrypted" i wykonaj wyzwalacz on nonencrypted init, aby kontynuować rozruch.

1. Sprawdzanie hasła

   Interfejs wywołuje funkcję vold z poleceniem cryptfs enablecrypto inplace, gdzie passwd to hasło do ekranu blokady.

2. Usuwanie platformy

   vold sprawdza błędy, zwraca -1, jeśli nie może zaszyfrować, i drukuje przyczynę w dzienniku. Jeśli może szyfrować, ustawia właściwość vold.decrypt na trigger_shutdown_framework. Spowoduje to, że usługa init.rc przestanie działać w klasach late_start i main.

3. Tworzenie stopki kryptograficznej
4. Tworzenie pliku ścieżki nawigacyjnej
5. Uruchom ponownie
6. Wykrywanie pliku ścieżki
7. Rozpocznij szyfrowanie /data

   vold konfiguruje mapowanie szyfrowania, które tworzy wirtualne urządzenie blokowe szyfrowania, które jest mapowane na rzeczywiste urządzenie blokowe, ale szyfruje każdy sektor podczas zapisu i odszyfrowuje każdy sektor podczas odczytu. voldtworzy i zapisuje metadane szyfrowania.

8. Podczas szyfrowania zamontuj tmpfs

   vold montuje tmpfs /data (korzystając z opcji tmpfs z ro.crypto.tmpfs_options) i ustawia wartość właściwości vold.encrypt_progress na 0. vold przygotowuje tmpfs /data do uruchamiania zaszyfrowanego systemu i ustawia właściwość vold.decrypt na: trigger_restart_min_framework

9. Wyświetlanie ramy w celu pokazania postępu

   trigger_restart_min_framework powoduje, że init.rc uruchamia klasę usług main. Gdy framework wykryje, że parametr vold.encrypt_progress ma wartość 0, wyświetla pasek postępu interfejsu użytkownika, który co 5 sekund wysyła zapytanie do tej usługi i aktualizuje pasek postępu. Pętla szyfrowania aktualizuje wartość vold.encrypt_progress za każdym razem, gdy szyfruje kolejny procent partycji.

10. Jeśli /data jest zaszyfrowany, zaktualizuj stopkę dotyczącą szyfrowania

    Gdy /data zostanie zaszyfrowany, vold usuwa flagę ENCRYPTION_IN_PROGRESS w metadanych.

    Gdy urządzenie zostanie odblokowane, hasło zostanie użyte do zaszyfrowania klucza głównego, a stopka kryptograficzna zostanie zaktualizowana.

    Jeśli z jakiegoś powodu nie uda się uruchomić ponownie urządzenia, vold ustawia właściwość vold.encrypt_progress na error_reboot_failed, a interfejs wyświetla komunikat z prośbą o naciśnięcie przycisku ponownego uruchamiania. Nie powinno do tego dojść.

Uruchamianie zaszyfrowanego urządzenia z domyślnym szyfrowaniem

Tak się dzieje, gdy uruchamiasz zaszyfrowane urządzenie bez hasła. Ponieważ urządzenia z Androidem 5.0 są szyfrowane przy pierwszym uruchomieniu, nie powinno być ustawionego hasła, dlatego jest to stan domyślnego szyfrowania.

1. Wykrywanie zaszyfrowanych /data bez hasła

   wykryć, że urządzenie z Androidem jest zaszyfrowane, ponieważ /data nie może być zamontowany i jeden z flag encryptable lub forceencrypt jest ustawiony.

   vold ustawia wartość vold.decrypt na trigger_default_encryption, co powoduje uruchomienie usługi defaultcrypto. trigger_default_encryptionsprawdza typ szyfrowania, aby sprawdzić, czy /data jest zaszyfrowany z hasłem czy bez.

2. Odszyfruj /data

   Tworzy urządzenie dm-crypt na urządzeniu blokowym, aby było gotowe do użycia.

3. Mount /data

   vold najpierw montuje odszyfrowaną partycję /data, a następnie przygotowuje nową partycję. Ustawia ona właściwość vold.post_fs_data_done na 0, a potem właściwość vold.decrypt na trigger_post_fs_data. Powoduje to, że init.rc będzie wykonywać polecenia post-fs-data. Tworzą niezbędne katalogi lub linki, a potem ustawiają wartość parametru vold.post_fs_data_done na 1.

   Gdy vold zobaczy 1 w tej właściwości, ustawia właściwość vold.decrypt na: trigger_restart_framework.. Spowoduje to ponowne uruchomienie usług w klasie main przez init.rc oraz uruchomienie usług w klasie late_start po raz pierwszy od momentu uruchomienia.

4. Rozpocznij framework

   Teraz framework uruchamia wszystkie swoje usługi za pomocą odszyfrowanego klucza /data, a system jest gotowy do użycia.

Uruchamianie zaszyfrowanego urządzenia bez domyślnego szyfrowania

Tak się dzieje, gdy uruchamiasz zaszyfrowane urządzenie z ustawionym hasłem. Hasło urządzenia może być kodem PIN, wzorem lub hasłem.

1. Wykrywanie zaszyfrowanego urządzenia za pomocą hasła

   wykryć, że urządzenie z Androidem jest zaszyfrowane, ponieważ ma flagę ro.crypto.state = "encrypted"

   vold ustawia wartość vold.decrypt na trigger_restart_min_framework, ponieważ /data jest zaszyfrowany za pomocą hasła.

2. Montowanie tmpfs

   init ustawia 5 właściwości, aby zapisać początkowe opcje montażu podane dla /data z parametrami przekazanymi z init.rc. vold używa tych właściwości do konfigurowania mapowania kryptowalut:

   1. ro.crypto.fs_type
   2. ro.crypto.fs_real_blkdev
   3. ro.crypto.fs_mnt_point
   4. ro.crypto.fs_options
   5. ro.crypto.fs_flags (8-cyfrowy numer szesnastkowy w standardzie ASCII poprzedzony przez 0x)
3. Rozpoczynanie platformy w celu wyświetlenia prośby o hasło

   Framework uruchamia się i widzi, że vold.decrypt ma wartość trigger_restart_min_framework. Informuje ono framework, że uruchamia się na dysku tmpfs /data i musi pobrać hasło użytkownika.

   Najpierw jednak musi się upewnić, że dysk został prawidłowo zaszyfrowany. Wysyła ono polecenie cryptfs cryptocomplete do vold. vold zwraca wartość 0, jeśli szyfrowanie zostało zakończone pomyślnie, -1 w przypadku błędu wewnętrznego lub -2, jeśli szyfrowanie nie zostało zakończone pomyślnie. vold określa to, sprawdzając flagę CRYPTO_ENCRYPTION_IN_PROGRESS w metadanych szyfrowania. Jeśli jest ustawiony, oznacza, że proces szyfrowania został przerwany i na urządzeniu nie ma żadnych przydatnych danych. Jeśli funkcja vold zwróci błąd, interfejs powinien wyświetlić użytkownikowi komunikat z prośbą o ponowne uruchomienie urządzenia i przywrócenie ustawień fabrycznych oraz przycisk, który należy nacisnąć, aby to zrobić.

4. Odszyfrowywanie danych za pomocą hasła

   Gdy cryptfs cryptocomplete zakończy się powodzeniem, framework wyświetli interfejs użytkownika z prośbą o hasło dysku. Interfejs użytkownika sprawdza hasło, wysyłając polecenie cryptfs checkpw do vold. Jeśli hasło jest prawidłowe (co jest określane przez zamontowanie odszyfrowanego /data w tymczasowym miejscu, a następnie odmontowanie), vold zapisuje nazwę odszyfrowanego urządzenia blokującego w właściwości ro.crypto.fs_crypto_blkdev i zwraca stan 0 do interfejsu użytkownika. Jeśli hasło jest nieprawidłowe, zwraca -1 do interfejsu użytkownika.

5. Zatrzymanie frameworku

   W interfejsie wyświetla się grafika przedstawiająca uruchamianie szyfrowania, a następnie wywołuje się vold z poleceniem cryptfs restart. vold ustawia właściwość vold.decrypt na trigger_reset_main, co powoduje, że init.rc wykonuje działanie class_reset main. Spowoduje to zatrzymanie wszystkich usług w klasie głównej, co pozwoli na odmontowanie tmpfs /data.

6. Montowanie /data

   vold następnie montuje odszyfrowaną partycję /data i przygotowuje nową partycję (która może nigdy nie zostać przygotowana, jeśli została zaszyfrowana za pomocą opcji wymazywania, która nie jest obsługiwana w pierwszej wersji). Ustawia właściwość vold.post_fs_data_done na 0, a następnie vold.decrypt na trigger_post_fs_data. W efekcie init.rc będzie wykonywać polecenia post-fs-data. Tworzą one niezbędne katalogi lub linki, a potem ustawiają wartość parametru vold.post_fs_data_done na 1. Gdy funkcja vold zobaczy wartość 1 w tej właściwości, ustawi właściwość vold.decrypt na trigger_restart_framework. W efekcie init.rc ponownie uruchamia usługi w klasie main, a także uruchamia usługi w klasie late_start po raz pierwszy od momentu uruchomienia.

7. Rozpocznij pełny proces

   Teraz framework uruchamia wszystkie swoje usługi przy użyciu odszyfrowanego systemu plików /data, a system jest gotowy do użycia.

Błąd

Urządzenie, które nie może odszyfrować danych, może być uszkodzone z kilku powodów. Urządzenie rozpoczyna normalną procedurę uruchamiania:

1. Wykrywanie zaszyfrowanego urządzenia za pomocą hasła
2. Punkt podłączenia tmpfs
3. Uruchom framework, aby wyświetlić prompt z prośbą o hasło

Po otwarciu frameworku na urządzeniu mogą wystąpić błędy:

• Hasło pasuje, ale nie można odszyfrować danych
• Użytkownik 30 razy wpisze nieprawidłowe hasło

Jeśli te błędy nie zostaną usunięte, poproś użytkownika o przywrócenie ustawień fabrycznych:

Jeśli vold wykryje błąd podczas procesu szyfrowania, a żadne dane nie zostały jeszcze zniszczone i ramka jest aktywna, vold ustawia właściwość vold.encrypt_progress na error_not_encrypted. Interfejs prosi użytkownika o uruchomienie ponownie i ostrzega, że proces szyfrowania nigdy nie został uruchomiony. Jeśli błąd wystąpi po usunięciu frameworka, ale przed wyświetleniem paska postępu w interfejsie, vold ponownie uruchomi system. Jeśli ponowne uruchomienie się nie powiedzie, funkcja ustawi vold.encrypt_progress na error_shutting_down i zwróci -1, ale nie będzie nic, co pozwoliłoby złapać błąd. Nie powinno tak się zdarzyć.

Jeśli vold wykryje błąd podczas procesu szyfrowania, ustawi vold.encrypt_progress na error_partially_encrypted i zwróci -1. W interfejsie powinien się wtedy wyświetlić komunikat o nieudanym szyfrowaniu i przycisk umożliwiający przywrócenie urządzenia do ustawień fabrycznych.

Przechowywanie zaszyfrowanego klucza

Zaszyfrowany klucz jest przechowywany w metadanych szyfrowania. Obsługa sprzętowa jest implementowana za pomocą funkcji podpisywania w zaufanym środowisku wykonawczym (TEE). Wcześniej klucz główny był szyfrowany za pomocą klucza wygenerowanego przez scrypt na podstawie hasła użytkownika i zmagazynowanego parametru soli. Aby klucz był odporny na ataki zewnętrzne, rozszerzyliśmy ten algorytm, podpisując uzyskany klucz za pomocą przechowywanego klucza TEE. Uzyskany podpis jest następnie zamieniany na klucz o odpowiedniej długości przez ponowne zastosowanie scrypt. Następnie klucz ten służy do szyfrowania i odszyfrowywania klucza głównego. Aby zapisać ten klucz:

1. Wygeneruj losowy 16-bajtowy klucz szyfrowania dysku (DEK) i 16-bajtową sól.
2. Zastosuj scrypt do hasła użytkownika i soli, aby wygenerować 32-bajtowy klucz pośredni 1 (IK1).
3. Wypełnij IK1 zerami, aby uzyskać rozmiar klucza prywatnego powiązanego z sprzętem (HBK). W szczególności wypełniamy: 00 || IK1 || 00..00; 1 bajt równy 0, 32 bajty IK1, 223 bajty równe 0.
4. Podpisz wypełniony IK1 za pomocą HBK, aby uzyskać IK2 o długości 256 bajtów.
5. Zastosuj scrypt do IK2 i soli (ta sama sól co w kroku 2), aby uzyskać 32-bajtowy IK3.
6. Jako KEK użyj pierwszych 16 bajtów IK3, a jako IV – ostatnich 16 bajtów.
7. Szyfruj DEK za pomocą AES_CBC, klucza KEK i wektora inicjującego IV.

Zmień hasło

Gdy użytkownik zdecyduje się zmienić lub usunąć hasło w ustawieniach, interfejs wyśle polecenie cryptfs changepw do vold, a vold ponownie zaszyfruje klucz główny dysku za pomocą nowego hasła.

Właściwości szyfrowania

vold i init komunikują się ze sobą, ustawiając właściwości. Oto lista dostępnych właściwości szyfrowania.

Właściwości Vold

Właściwości init

działania inicjowania,

on post-fs-data
on nonencrypted
on property:vold.decrypt=trigger_reset_main
on property:vold.decrypt=trigger_post_fs_data
on property:vold.decrypt=trigger_restart_min_framework
on property:vold.decrypt=trigger_restart_framework
on property:vold.decrypt=trigger_shutdown_framework
on property:vold.decrypt=trigger_encryption
on property:vold.decrypt=trigger_default_encryption