Szyfrujesz Androida PIN-em? To nie była najlepsza decyzja

Szyfrowanie pamięci telefonu powinno w teorii uniemożliwiać osobom postronnym dostęp do zawartych w nim danych. Nikolay Elenkov specjalizujący się w obalaniu mitów bezpieczeństwa Androida pokazał, że przełamanie tych zabezpieczeń to kwestia sekund.

Apple prekursorem

W wersji iOS 8 Apple wprowadziło pełne szyfrowanie urządzenia (ang. FDE – Full Disk Encryption), robiąc to w sposób, który budzi w pierwszej chwili podziw. Media zarówno te techniczne jak i plotkarskie zaczęły rozpływać się nad odwagą i innowacyjnością Apple. Z punktu widzenia bezpieczeństwa przyćmiło to trochę problemy z wyginającą się obudową czy aktualizacją która uniemożliwia wykorzystywanie iPhone jako telefonu. Jak więc Apple zrealizowało ten pomysł?

1. Zaczęło domyślnie szyfrować każde urządzenie którego właściciel wprowadzi kod zabezpieczający odblokowanie.
2. Powiązało klucz użytkownika z unikalnym 256 bitowym kluczem sprzętowym.
3. Zapisało klucz w „enklawie bezpieczeństwa” i uniemożliwiło odczytanie zawartości.
4. Taki zestaw przepuszczany jest przez KDF który w wykonaniu Apple używa PBKDF2-AES i umożliwia przeprowadzenie pojedynczej iteracji w około 80 ms, co daje około 12 na sekundę.
5. Ponieważ klucz nie może być przeniesiony lub odczytany z „enklawy”, każdą z prób zgadywania należy przeprowadzić bezpośrednio na telefonie (co biorąc pod uwagę, że jest on zablokowany jest zdecydowanie utrudnione).

Tworzenie klucza szyfrującego Apple iOS8

A jak to jest w Androidzie?

Pełne szyfrowanie danych w Androidzie pojawiło się w wersji Honeycomb (3.0) i nie uległo znaczącym zmianom aż do wersji 4.4. Do szyfrowania partycji podmontowanej do katalogu /data używany jest znany z Linuksa dm-crypt. Klucz główny (128 bitowy) generowany jest na podstawie hasła zabezpieczającego odblokowanie ekranu, a sam „dysk” szyfrowany przy pomocy funkcji AES-CBC.  Aby zapobiec atakom takim jak np. atak znaku wodnego zastosowano ESSIV:SHA256.

Android do przechowywania parametrów szyfrowania używa „krypto stopki” (ang. crypto footer). Jest ona podobna do nagłówka partycji stosowanego w LUKS, ale nie obsługuje np. możliwości stosowania wielu haseł odszyfrowujących, nie dzieli klucza głównego na części (funkcja LUKS zmniejszająca prawdopodobieństwo odzyskania całego klucza w przypadku jego świadomego usunięcia), a także nie przechowuje sumy kontrolnej klucza głównego, co powoduje, że weryfikacja, czy hasło jest poprawne, odbywa się poprzez próbę zamontowania partycji (jeśli się powiedzie, hasło uznawane jest za poprawne). Podczas uruchamiania urządzenia użytkownik jest więc proszony o hasło, które przepuszczane jest przez PBKDF2, rozszyfrowuje klucz główny a następnie przekazuje go do dm-crypt, który to montuje partycję z danymi.

Skoro jest jak w Linuksie to dlaczego jest źle?

Problemem tak naprawdę nie jest to, w jaki sposób szyfrowanie zostało zaimplementowane, gdyż to uznawane jest za dosyć poprawne. Problemem jest to, że przeprowadzane jest w pełni programowo i bezpieczeństwo danych zależy wyłącznie od złożoności zastosowanego hasła. Ponieważ Android pozwala użytkownikowi na zastosowanie do szyfrowania tego samego hasła czy PINu jak w przypadku odblokowywania ekranu, nie ma się co łudzić, że ktokolwiek wybierze inną opcję. Jeśli entropia przekazana do PBDKF2 będzie słaba, to nawet 2000 iteracji tego nie zmienią. To właśnie postanowił sprawdzić Nikolay i poddał FDE Androida 4.3 łamaniu siłowemu.

Szyfrowanie Androida

Shake it baby!

Przeprowadzenie ataku wyczerpania wszystkich możliwych kombinacji z poziomu telefonu mija się z celem ze względu na ograniczenie liczby możliwych prób jak i wydłużaniu tego procesu w czasie. Dużo wygodniej jest przeprowadzać taki atak offline. Do tego trzeba jednak mieć kopię zarówno „krypto stopki” jak i partycji (a tak właściwie pierwszych 3 sektorów). Nie można tego zrobić bez przełamania zabezpieczenia bootloadera lub uruchomienia odbezpieczonego bootloadera (co jest pierwszym krokiem niezbędnym do „rootowania” urządzenia). Wiele różnych metod obejścia zabezpieczenia bootloadera zaprezentował Thomas Cannon na konferencji DEF CON 20.

Później idzie już łatwo. Krypto stopka to tak naprawdę dedykowana partycja na urządzeniu, a jej lokalizacja znajduje się w pliku fstab pod parametrem encryptable. Np. w Galaxy Nexus

/dev/block/platform/omap/omap_hsmmc.0/by-name/userdata /data ext4 \
 noatime,nosuid,nodev,nomblk_io_submit,errors=panic \
 wait,check,encryptable=/dev/block/platform/omap/omap_hsmmc.0/by-name/metadata

Gdy już poznamy lokalizacje, można dokonać zrzutu przy pomocy linuksowego narzędzia dd. Teraz pozostaje nam wybór narzędzia. Krótkie frazy takie jak 4-cyfrowe PINy można spokojnie łamać siłowo na zwykłym CPU przy pomocy skryptu zawartego w Santoku Linux. Zdecydowanie szybciej będzie użyć zapewne znanego już czytelnikom hashcata, który od wersji 1.30 wspiera łamanie FDE Androida.

Jak szybko?

Dane jakich do złamania hasła potrzebuje hashcat to: stopka, klucz szyfrujący, sól oraz kilka pierwszych sektorów partycji (które zawierają nagłówki partycji ext4, dzięki którym można potwierdzić, czy odszyfrowanie się powiodło). Tak przygotowany hash:

$fde$16$ca56e82e7b5a9c2fc1e3b5a7d671c2f9$16$7c124af19ac913be0fc137b75a34b20d$eac806ae7277c8d4...

w przypadku 6 cyfrowego PINu

$ cudaHashcat64 -m 8800 -a 3 android43fde.txt ?d?d?d?d?d?d
...
Session.Name...: cudaHashcat
Status.........: Cracked
Input.Mode.....: Mask (?d?d?d?d?d?d) [6]
Hash.Target....: $fde$16$aca5f840...
Hash.Type......: Android FDE
Time.Started...: Sun Oct 05 19:06:23 2014 (6 secs)
Speed.GPU.#1...: 20629 H/s
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 122880/1000000 (12.29%)
Skipped........: 0/122880 (0.00%)
Rejected.......: 0/122880 (0.00%)
HWMon.GPU.#1...: 0% Util, 48c Temp, N/A Fan
Started: Sun Oct 05 19:06:23 2014
Stopped: Sun Oct 05 19:06:33 2014

na laptopowej karcie NVIDIA GeForce 730M poległ po 10 sekundach (20000 hashy na sekundę), w przypadku sześcioliterowego (małe litery) hasła ta karta graficzna potrzebowałaby około 4 godzin. Pojedyncza karta ATI Radeon R9 290x osiąga jednak prędkość 365000 hashy na sekundę znacząco skracając cały proces łamania sześciocyfrowego pinu do poniżej sekundy, ośmioliterowe hasło (również małe litery) to tylko 6,5 dnia.  Wyobrażacie sobie jednak użytkownika, który odblokowuje za każdym razem swój telefon ośmioznakowym hasłem?

Fragmentacja znów daje w kość

W kolejnej części artykułu przyjrzymy się bezpieczeństwu Androida w wersji 4.4 i L, które to nieco inaczej podchodzą do kwestii pełnego szyfrowania niż jego starsi bracia. Nie zmienia to jednak faktu, że przez brak aktualizacji dla starszych telefonów (któremu głównie winni są producenci słuchawek), można się spodziewać że „fala hejtu” wyleje się na całego Androida i będzie kolejnym argumentem dla jego przeciwników.