Pełne szyfrowanie dysku

Szyfrowanie całego dysku to proces kodowania wszystkich danych użytkownika na urządzeniu z Androidem za pomocą klucza szyfrowania. 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 pełnego dysku zostało wprowadzone na Androidzie w wersji 4.4, ale w Androidzie 5.0 wprowadzono te nowe funkcje:

  • Szybkie szyfrowanie, które szyfruje tylko używane bloki na partycji danych, aby uniknąć długiego czasu uruchamiania. 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ę wzorcó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 przy pierwszym uruchomieniu nie mogą zostać przywrócone do stanu niezaszyfrowanego.

Jak działa szyfrowanie pełnego dysku na Androidzie

Szyfrowanie pełnego dysku Androida opiera się na dm-crypt – funkcji jądra, która działa w warstwie urządzenia blokowego. Z tego powodu szyfrowanie działa w przypadku elementów Embedded MultiMediaCard (eMMC) i podobnych urządzeniach Flash, które wyświetlają się w jądrze jako urządzenia blokowe. Szyfrowanie nie jest możliwe w przypadku formatu 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 AES przez wywołania biblioteki OpenSSL. Klucz musi mieć co najmniej 128 bitów (256 bitów jest opcjonalne).

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

W Androidzie 5.0 dostępne są 4 rodzaje stanów szyfrowania:

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

Przy pierwszym uruchomieniu urządzenie tworzy losowo wygenerowany 128-bitowy klucz główny, a następnie szyfruje go hasłem domyślnym i zapisanym ciągiem zaburzającym. Domyślne hasło to "default_password". Wynikowy hasz jest jednak również podpisywany za pomocą TEE (np. TrustZone), który do szyfrowania klucza głównego wykorzystuje hasz podpisu.

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

Gdy użytkownik ustawi kod PIN, hasło lub hasło na urządzeniu, tylko 128-bitowy klucz zostanie ponownie zaszyfrowany i zapisany. (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 podlegać ograniczeniom związanym z kodem PIN, wzorem lub hasłem.

Szyfrowaniem zarządza init i vold. init wywołuje vold, a vold ustawia właściwości, aby wywoływać zdarzenia w init. Inne części systemu analizują też właściwości, aby wykonywać takie zadania jak zgłaszanie stanu, pytanie o hasło czy prośbę o przywrócenie do ustawień fabrycznych w przypadku błędu krytycznego. Aby wywołać funkcje szyfrowania w vold, system używa poleceń cryptfs w narzędziu wiersza poleceń: checkpw, restart, enablecrypto, changepw, cryptocomplete, verifypw, setfield, getfield, mountdefaultencrypted, getpwtype, getpw i clearpw.vdc

Aby można było zaszyfrować, odszyfrować lub wyczyścić pamięć /data, nie można podłączyć urządzenia /data. Jednak aby wyświetlić interfejs użytkownika, platforma musi się uruchomić, a platforma wymaga uruchomienia /data. Aby rozwiązać ten problem, w: /data podłącza się tymczasowy system plików. 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, mainlate_start.

  • core: nigdy nie wyłączaj się po uruchomieniu.
  • main: wyłącz komputer, a następnie uruchom go ponownie po wpisaniu hasła do dysku.
  • late_start: rozpoczyna się dopiero po odszyfrowaniu i podłączeniu urządzenia /data.

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 zezwala na jej ponowne uruchomienie z użyciem atrybutu 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 przechodzi przez normalny proces uruchamiania.

  • Zaszyfruj 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 bez ustawionego hasła (dotyczy urządzeń z Androidem 5.0 lub nowszym).
    • Uruchamianie zaszyfrowanego urządzenia przy użyciu 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 szczegółowo opisujemy każdy 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

    Plik /data nie jest zaszyfrowany, ale musi być, ponieważ wymaga tego forceencrypt. Odłącz urządzenie /data.

  2. Rozpocznij szyfrowanie /data

    vold.decrypt = "trigger_encryption" powoduje init.rc, co powoduje, że vold szyfruje /data bez hasła. Nie ustawiono żadnej wartości, ponieważ powinno to być nowe urządzenie.

  3. Montaż tmpfs

    vold podłącza tmpfs /data (przy użyciu opcji tmpfs z ro.crypto.tmpfs_options) i ustawia właściwość vold.encrypt_progress na 0. vold przygotowuje /data tmpfs do uruchomienia zaszyfrowanego systemu i ustawia właściwość vold.decrypt na: trigger_restart_min_framework

  4. Otwórz schemat, aby wyświetlić postępy.

    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 UI postępu znajdziesz w sekcji Szyfrowanie istniejącego urządzenia.

  5. Kiedy /data jest zaszyfrowany, usuń tę platformę

    vold ustawia vold.decrypt na trigger_default_encryption, co uruchamia usługę defaultcrypto. (Rozpocznie się poniższa procedura podłączania domyślnie zaszyfrowanych danych użytkownika). trigger_default_encryption sprawdza typ szyfrowania, aby zobaczyć, czy metoda /data jest szyfrowana 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

    Następnie init podłącza /data na tmpfs RAMDisk, używając parametrów pobieranych z ro.crypto.tmpfs_options, która jest ustawiona w init.rc.

  7. Rozpocznij framework

    vold ustawia vold.decrypt na trigger_restart_framework, co jest kontynuacją zwykłego 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 w kodzie określany jest jako „szyfrowanie lokalne”. Gdy użytkownik wybierze opcję zaszyfrowania urządzenia, interfejs dba o to, aby bateria była w pełni naładowana, a zasilacz był podłączona do zasilania, dzięki czemu udało się zakończyć szyfrowanie.

Ostrzeżenie: jeśli w urządzeniu zostanie rozładowane i wyłączy się przed zakończeniem szyfrowania, dane plików 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. Przed odczytaniem i zapisaniem danych vold sprawdza, czy sektor jest używany. Na nowym urządzeniu, na którym jest mało danych lub nie ma ich wcale, szyfrowanie jest znacznie szybsze.

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

  1. Sprawdzanie hasła

    Interfejs wywołuje vold za pomocą polecenia cryptfs enablecrypto inplace, gdzie passwd to hasło do ekranu blokady użytkownika.

  2. Wyłączenie zasad

    vold sprawdza błędy, zwraca -1, jeśli nie może zaszyfrować, i drukuje przyczynę w dzienniku. Jeśli może zaszyfrować, 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 krypto
  4. Tworzenie pliku ścieżki nawigacyjnej
  5. Uruchom ponownie
  6. Wykrywanie pliku ścieżki
  7. Rozpocznij szyfrowanie /data

    vold konfiguruje mapowanie kryptograficzne, co powoduje utworzenie wirtualnego urządzenia blokującego kryptowaluty, które jest mapowane na rzeczywiste urządzenie blokowe, ale szyfruje każdy zapisywany sektor i odszyfrowuje każdy odczytywany sektor. Następnie vold tworzy i zapisuje metadane kryptograficzne.

  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 uruchomienia zaszyfrowanego systemu i ustawia właściwość vold.decrypt na: trigger_restart_min_framework

  9. Otwórz schemat, aby wyświetlić postępy.

    trigger_restart_min_framework powoduje, że init.rc uruchamia klasę usług main. Gdy platforma wykryje, że vold.encrypt_progress ma wartość 0, wyświetla interfejs na pasku postępu, w którym co 5 sekund wysyła zapytania do tej właściwości i aktualizuje pasek postępu. Pętla szyfrowania aktualizuje wartość vold.encrypt_progress za każdym razem, gdy szyfruje kolejny procent partycji.

  10. Gdy kod /data jest zaszyfrowany, zaktualizuj stopkę kryptograficzną

    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 restart się nie uda, vold ustawia właściwość vold.encrypt_progress na error_reboot_failed, a w interfejsie powinien wyświetlić się komunikat z prośbą o naciśnięcie przycisku w celu zrestartowania urządzenia. Nie powinno do tego dojść.

Uruchamianie zaszyfrowanego urządzenia z domyślnym szyfrowaniem

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

  1. Wykrywanie zaszyfrowanych /data bez hasła

    Wykrywa, że urządzenie z Androidem jest zaszyfrowane, ponieważ nie można podłączyć /data i ustawiona jest jedna z flag encryptable lub forceencrypt.

    vold ustawia vold.decrypt na trigger_default_encryption, co uruchamia usługę 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 ono gotowe do użycia.

  3. Podłączanie /dane

    vold podłącza odszyfrowaną prawdziwą partycję /data i przygotowuje nową. Ustawia ona właściwość vold.post_fs_data_done na 0, a następnie właściwość vold.decrypt na trigger_post_fs_data. Powoduje to, że init.rc będzie wykonywać polecenia post-fs-data. Tworzy potrzebne katalogi lub linki, a potem ustawia vold.post_fs_data_done na 1.

    Gdy vold wykryje w tej usłudze 1, ustawia właściwość vold.decrypt na: trigger_restart_framework.. Powoduje to, że init.rc ponownie uruchamia usługi w klasie main, a także po raz pierwszy od uruchomienia usługi w klasie late_start.

  4. Rozpocznij framework

    Teraz platforma uruchamia wszystkie usługi przy użyciu odszyfrowanego /data i 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 vold.decrypt na trigger_restart_min_framework, ponieważ /data jest zaszyfrowany hasłem.

  2. Montaż tmpfs

    init ustawia 5 właściwości pozwalających zapisać początkowe opcje podłączenia podane dla elementu /data z parametrami przekazywanymi 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. Uruchomienie frameworku, aby wyświetlić prośbę o hasło

    Platforma uruchamia się i widzi, że vold.decrypt ma wartość trigger_restart_min_framework. Informuje on platformę, że uruchamia się na dysku /data tmpfs i musi uzyskać hasło użytkownika.

    Najpierw jednak musi się upewnić, że dysk został prawidłowo zaszyfrowany. Następnie wysyła 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. Określa to, sprawdzając metadane kryptograficzne w flagi CRYPTO_ENCRYPTION_IN_PROGRESS (vold). Jeśli jest ustawiona, szyfrowanie zostało przerwane i na urządzeniu nie ma danych, których można by użyć. 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 się powiedzie, platforma wyświetli interfejs z prośbą o podanie hasła do 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 podłączenie odszyfrowanego /data w tymczasowej lokalizacji, a następnie odłączenie go), vold zapisuje nazwę odszyfrowanego urządzenia blokującego we właściwości ro.crypto.fs_crypto_blkdev i zwraca stan 0 w interfejsie użytkownika. Jeśli hasło jest nieprawidłowe, w interfejsie użytkownika zwraca wartość -1.

  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 ustawia vold.decrypt na trigger_post_fs_data. W efekcie init.rc będzie wykonywać polecenia post-fs-data. Tworzy potrzebne katalogi lub linki, a potem ustawia 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. Spowoduje to, że init.rc ponownie uruchomi usługi w klasie main, a także uruchomi usługi w klasie late_start po raz pierwszy od uruchomienia.

  7. Rozpocznij pełny proces

    Teraz platforma uruchamia wszystkie usługi przy użyciu odszyfrowanego systemu plików /data i 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 uruchamia się w zwykły sposób:

  1. Wykrywanie zaszyfrowanego urządzenia za pomocą hasła
  2. Punkt podłączenia tmpfs
  3. Uruchom platformę do wyświetlania prośby 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 wpisał 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 użytkownika, vold ponownie uruchomi system. Jeśli restart się nie powiedzie, ustawia vold.encrypt_progress na error_shutting_down i zwraca -1, ale nie ma niczego, co mogłoby wychwytywać błąd. To nie powinno się zdarzyć.

Jeśli vold wykryje błąd podczas szyfrowania, ustawia vold.encrypt_progress na error_partially_encrypted i zwraca -1. W interfejsie powinien się wtedy wyświetlić komunikat o nieudanym szyfrowaniu i przycisk umożliwiający użytkownikowi zresetowanie 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 przekształcany w klucz o odpowiedniej długości przez zastosowanie jeszcze raz 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 sól, aby utworzyć 32-bajtowy klucz pośredni 1 (IK1).
  3. Uzupełnij kod IK1 o 0 bajtów w zakresie rozmiaru powiązanego sprzętowo klucza prywatnego (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.

Zmiana hasła

Gdy użytkownik zmieni lub usunie hasło w ustawieniach, interfejs wysyła polecenie cryptfs changepw do usługi vold, a vold ponownie zaszyfruje główny klucz dysku nowym hasłem.

Właściwości szyfrowania

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

Właściwości Vold

Właściwość Opis
vold.decrypt trigger_encryption Zaszyfruj dysk bez hasła.
vold.decrypt trigger_default_encryption Sprawdź, czy dysk jest zaszyfrowany bez hasła. Jeśli tak, odszyfruj i podłącz go, w przeciwnym razie ustaw vold.decrypt na aktywator_restart_min_framework.
vold.decrypt trigger_reset_main Ustawiona przez vold, aby wyłączyć interfejs użytkownika z prośbą o hasło do dysku.
vold.decrypt trigger_post_fs_data Ustawione przez vold, aby przygotować dla /data potrzebne katalogi itp.
vold.decrypt trigger_restart_framework Ustaw przez vold, aby uruchomić prawdziwy framework i wszystkie usługi.
vold.decrypt trigger_shutdown_framework Ustaw przez vold, aby wyłączyć cały framework i rozpocząć szyfrowanie.
vold.decrypt trigger_restart_min_framework Ustaw przez vold, aby uruchomić interfejs paska postępu szyfrowania lub wyświetlić prośbę o hasło, w zależności od wartości ro.crypto.state.
vold.encrypt_progress Jeśli ta właściwość jest skonfigurowana, po uruchomieniu platformy włącz tryb interfejsu paska postępu.
vold.encrypt_progress 0 to 100 Pasek postępu powinien wyświetlać ustawioną wartość procentową.
vold.encrypt_progress error_partially_encrypted W interfejsie paska postępu powinien wyświetlać się komunikat o nieudanym szyfrowaniu i opcja zresetowania urządzenia do ustawień fabrycznych.
vold.encrypt_progress error_reboot_failed Interfejs paska postępu powinien wyświetlać komunikat informujący o zakończeniu szyfrowania oraz udostępnić użytkownikowi przycisk ponownego uruchomienia urządzenia. Ten błąd nie powinien wystąpić.
vold.encrypt_progress error_not_encrypted Interfejs paska postępu powinien wyświetlać komunikat o wystąpieniu błędu, informować, że żadne dane nie zostały zaszyfrowane ani utracone, oraz zawierać przycisk umożliwiający ponowne uruchomienie systemu.
vold.encrypt_progress error_shutting_down Interfejs paska postępu nie działa, więc nie wiadomo, kto reaguje na ten błąd. A to nigdy nie powinno się wydarzyć.
vold.post_fs_data_done 0 Ustawiono przez vold tuż przed ustawieniem vold.decrypt na trigger_post_fs_data.
vold.post_fs_data_done 1 Wyznaczony przez użytkownika init.rc lub init.rc zaraz po ukończeniu zadania post-fs-data.

właściwości init

Właściwość Opis
ro.crypto.fs_crypto_blkdev Ustawiany przez polecenie vold checkpw do późniejszego użycia w poleceniu vold restart.
ro.crypto.state unencrypted Ustawione przez init, aby wskazać, że system działa z niezaszyfrowanym /data ro.crypto.state encrypted. Ustawione przez init informujące, że w tym systemie używany jest zaszyfrowany plik /data.

ro.crypto.fs_type
ro.crypto.fs_real_blkdev
ro.crypto.fs_mnt_point
ro.crypto.fs_options
ro.crypto.fs_flags

Te 5 właściwości są ustawiane przez init, gdy próbuje zamontować /data z parametrami przekazanymi przez init.rc. vold używa ich do konfigurowania mapowania kryptowalut.
ro.crypto.tmpfs_options Ustawione przez init.rc z opcjami, których init powinien używać podczas montowania systemu plików tmpfs /data.

inicjowanie działań

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