W których wersjach Androida szyfrowanie dysku naprawdę działa

dodał 9 października 2014 o 07:29 w kategorii Krypto  z tagami:
W których wersjach Androida szyfrowanie dysku naprawdę działa

Kilka dni temu pokazaliśmy Wam jak wygląda bezpieczeństwo pełnego szyfrowania pamięci zarówno w przypadku iOS 8 jak i Androida w wersji 3.0-4.3 i jak bardzo Android na tym polu przegrywa. Przyszła pora na najnowsze produkty Androida 4.4 oraz L.

Szyfrowanie całego dysku starszych wersji Androida zdecydowanie nie zapewnia wystarczającego bezpieczeństwa Waszych danych. Jak wygląda ta kwestia w najnowszych wydaniach systemu?

Wind of change

Wersja 4.4 przynosi zmiany w stosunku do poprzedniego systemu szyfrowania. W „krypto stopce” (ang. crypto footer) znajduje się tym razem informacja, że PBKDF2 został zastąpiony przez scrypt. Ma to na celu wydłużenie procesu łamania hasła ze względu na skomplikowanie obliczeniowe tej funkcji hashującej, która nie tylko wymaga dużej mocy obliczeniowej ale i dużych zasobów szybkiej pamięci. Tabela poniżej, której autorem jest Colin Percivial, pokazuje, jak w 2009 roku wyglądało zestawienie kosztów niezbędnych do złamania w ciągu roku hasła hashowanego poszczególnymi algorytmami.

Koszt złamania hasła w 12 miesięcy

Koszt złamania hasła w 12 miesięcy

Co warto zauważyć, porównywany bcrypt nie nadaje się do hashowania fraz powyżej 55 znaków, gdyż bierze on pod uwagę… tylko pierwsze 55 znaków. Obecnie nie jest to może problem, ale znów przypominając o fragmentacji Androida – telefony nie przechodzą tak szybko procesu aktualizacyjnego, a producenci często pozostają przy tej samej wersji od początku do zakończenia produkcji. Scrypt wydaje się więc tutaj być słusznym wyborem. W stopce zapisano również wszystkie wartości początkowe algorytmu scrypt (N, r, p). Nie ulega również zmianie długość klucza głównego (128 bitów), oraz sposób szyfrowania dysku (aes-cbc-essiv:sha256).

Your powers combined…

Atak siłowy na szyfrowanie Androida 4.4 wygląda podobnie jak w poprzednich wersjach. Pomimo, że hashcat wspiera algorytm scrypt, nie wspiera możliwości wykorzystania go do łamania całego klucza. Stopka nie zawiera również sumy kontrolnej klucza głównego, więc do łamania niezbędny jest również kawałek dysku – podobnie jak poprzednio będzie to nagłówek ext4. Przy użyciu zmodyfikowanego pod scrypt skryptu z Santoku Linux i 3.5 GHz procesora Intel Core i7 badacz uzyskał następujące rezultaty:

$ time python bruteforce_stdcrypto.py header footer 4

Android FDE crypto footer
-------------------------
Magic          : 0xD0B5B1C4
Major Version  : 1
Minor Version  : 2
Footer Size    : 192 bytes
Flags          : 0x00000000
Key Size       : 128 bits
Failed Decrypts: 0
Crypto Type    : aes-cbc-essiv:sha256
Encrypted Key  : 0x66C446E04854202F9F43D69878929C4A
Salt           : 0x3AB4FA74A1D6E87FAFFB74D4BC2D4013
KDF            : scrypt
N_factor       : 15     (N=32768)
r_factor       : 3      (r=8)
p_factor       : 1      (p=2)
-------------------------
Trying to Bruteforce Password... please wait
Trying: 0000
Trying: 0001
Trying: 0002
Trying: 0003
...
Trying: 1230
Trying: 1231
Trying: 1232
Trying: 1233
Trying: 1234
Found PIN!: 1234

real    4m43.985s
user    4m34.156s
sys     0m9.759s

Na powyższym przykładzie widać, że sprawdzenie 1200 kombinacji zajęło niecałe 5 minut,  co daje około godzinę na złamanie 4-cyfrowego kodu PIN (po sprawdzeniu wcześniej wszystkich schematycznych PINów jak np. 1234, 2580 czy dat urodzenia). Jak widać jest to znaczący postęp jeśli chodzi o czas, ale nadal mało bezpieczny. Dlatego radzimy nie używać pinu, a jeśli już to co najmniej 6-cyfrowy.

L-L-Lick me like a lollipop

Wersja L, istniejąca dzisiaj w opcji preview, jest już dostępna na rynku od paru miesięcy (ciągle jednak niestabilna). „Krypto stopka” z pewnością uległa zmianie, nie używa już ani PBKDF2 ani scrypt, a szyfrowanie urządzenia nie wymaga obecnie nawet zabezpieczania ekranu PINem czy hasłem, co sugeruje, że klucz główny nie jest generowany przy pomocy tego hasła. Nikolay zaobserwował, że uruchomienie procesu szyfrowania wywołuje następujący efekt logcat’a:

D/QSEECOMAPI: (  178): QSEECom_start_app sb_length = 0x2000
D/QSEECOMAPI: (  178): App is already loaded QSEE and app id = 1
D/QSEECOMAPI: (  178): QSEECom_shutdown_app 
D/QSEECOMAPI: (  178): QSEECom_shutdown_app, app_id = 1
...
I/Cryptfs (  178): Using scrypt with keymaster for cryptfs KDF
D/QSEECOMAPI: (  178): QSEECom_start_app sb_length = 0x2000
D/QSEECOMAPI: (  178): App is already loaded QSEE and app id = 1
D/QSEECOMAPI: (  178): QSEECom_shutdown_app 
D/QSEECOMAPI: (  178): QSEECom_shutdown_app, app_id = 1

QSEE to Qualcomm Secure Execution Environment który to jest implementacją TEE (Trusted Execution Environment). Jest to bezpieczne i zaufane środowisko do wykonywania zadań, niezależne od standardowego systemu operacyjnego. Technologia ta zabezpiecza poufne dane poprzez uniemożliwienie bezpośredniego dostępu systemowi operacyjnemu podobnie jak ma to miejsce w „enklawie bezpieczeństwa” Apple o której pisaliśmy w pierwszej części artykułu. Poufne dane są w TEE tylko przetwarzane, a system operacyjny ma dostęp do generowanej przez TEE odpowiedzi za pomocą wtyczki programowej TEE Client. Jak wskazuje piąta linijka, do stworzenia KDF używany jest scrypt wraz z kluczem głównym, który tak przekazywany jest do TEE. Niestety brak kodu źródłowego uniemożliwia dalszą analizę czy choćby potwierdzenie tej teorii.

Domyślnie szyfrowany?

Wszystko wskazuje na to, że podobnie jak Apple, Android L również będzie miał domyślnie włączone szyfrowanie. Badacz sprawdził dodatkowo, czy ustawienie blokowania wzorem (pattern lock) przekazuje jakieś dane do modułu szyfrującego.

D/VoldCmdListener(  173): cryptfs changepw pattern {}
D/QSEECOMAPI: (  173): QSEECom_start_app sb_length = 0x2000
D/QSEECOMAPI: (  173): App is already loaded QSEE and app id = 1
...
D/QSEECOMAPI: (  173): QSEECom_shutdown_app 
D/QSEECOMAPI: (  173): QSEECom_shutdown_app, app_id = 1
I/Cryptfs (  173): Using scrypt with keymaster for cryptfs KDF
D/QSEECOMAPI: (  173): QSEECom_start_app sb_length = 0x2000
D/QSEECOMAPI: (  173): App is already loaded QSEE and app id = 1
D/QSEECOMAPI: (  173): QSEECom_shutdown_app 
D/QSEECOMAPI: (  173): QSEECom_shutdown_app, app_id = 1
E/VoldConnector(  756): NDC Command {5 cryptfs changepw pattern [scrubbed]} took too long (6210ms)

Z powyższych danych wynika, że do wygenerowania klucza szyfrującego dysk (poprzez wywołanie cryptfs changepw), wykorzystywany będzie nie tylko PIN/hasło ale również i wzór odblokowania. Dość długi czas w jakim klucz jest generowany (6 sekund) sugeruje, że do generowania wykorzystywany jest scrypt.

Ekran odblokowania zaszyfrowanego Nexusa 7 z Android L

Ekran odblokowania zaszyfrowanego Nexusa 7 z Android L

Kolejną zmianą jest konieczność pojedynczego przeciągnięcia schematu odblokowującego przy uruchamianiu urządzenia. Dotychczas wykonywane to było dwukrotnie, pierwszy raz przy uruchomieniu, drugi na ekranie blokady.

To będzie bezpiecznie czy nie?

Z badania Nikolaya wynika, że klucz szyfrujący będzie w najnowszych urządzeniach (przynajmniej w tych z górnej półki) zabezpieczony sprzętowo. Co za tym idzie, pozyskanie „krypto stopki” powinno być niemożliwe, a tym samym przekreślona zostaje możliwość łatwego łamania siłowego. Samo szyfrowanie odbywać się będzie zapewne przy wsparciu sprzętowym (wskazuje na to szybkość z jaką udało się zaszyfrować Nexusa 7 (2013) 16GB – 10 minut). Druga możliwość to taka, że szyfrowany będzie tylko faktycznie używany obszar, a nie całość pamięci. Mamy nadzieję, że krok, który uczyniło Apple w kierunku zabezpieczenia urządzeń przed dostępem nie tylko niepowołanych osób, ale i organów ścigania, szybko stanie się standardem. Kierunek, w którym idzie Android, zdaje się to potwierdzać. Tymczasem zmieńcie swoje hasła na trudniejsze, to zawsze jest dobrym pomysłem.