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ł?
- Zaczęło domyślnie szyfrować każde urządzenie którego właściciel wprowadzi kod zabezpieczający odblokowanie.
- Powiązało klucz użytkownika z unikalnym 256 bitowym kluczem sprzętowym.
- Zapisało klucz w „enklawie bezpieczeństwa” i uniemożliwiło odczytanie zawartości.
- 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ę.
- 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).
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.
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.
Komentarze
Znam jednego z ośmio znakowym hasłem, zaczynam się zastanawiać co on trzyma na tym telefonie :]
Skoro ios szyfruje wszystko pinem to wynika z tego ze nie ma szans na ominiecie blokady ekranu?
ja stosuję 8 znakowe hasło odbezpieczające :)
właśnie sprawiłeś, że ktoś kto by chciał złamać Twoje hasło nie będzie musiał próbować możliwości od 1-7 i powyżej 8 znaków :)
A może to podpucha i ma hasło inne niż 8 znakowe.
on wiedział, ze ty to uznasz za podpuchę, i jednak używa 8 znaków. :)
Teraz odszukaj go w realu, ukradnij jego telefon i powodzenia.
bo POWINNY być dwa różne hasła – długie do dysku przy boocie i szybkie z małą ilością prób do blokady ekranu, niestety nawet w 4.4 u mnie musi być to samo…
Te hasła są różne, tylko UI zmienia oba naraz. Na szczęście there’s an app for that: https://f-droid.org/repository/browse/?fdfilter=encryption&fdid=org.nick.cryptfs.passwdmanager
powinno być raczej „starsi bracia”, bo Android L jest młodszy.
dzięki, zmienione. Idea była raczej „młodszy numerkiem”, ale masz rację.
W kultowej Nokii 3310 starczyła blokada klawiatury
to też czasem (brak zabezpieczenia) jest dobrym rozwiązaniem:
https://www.youtube.com/watch?v=Jwpg-AwJ0Jc
suchar, ale kultowy :)
Na szczescie da sie to zrobic bezpieczniej
http://niki.hammler.net/wiki/Android_Device_Encryption
Android pozwala na stosowanie pinu o długości większej niż 10 cyfr. Zapamiętanie takiego pinu sprowadza się do ułożenia go z cyfr odpowiednio powiązanych z klawiaturą. Może to być rysunek na klawiaturze. Np.:
– romb z przekątną (7 cyfr): 8426852;
– kwadrat z krzyżykiem (8 cyfr): 79314682;
– litery NA (9 cyfr): 173918346.
Można także używać liter powiązanych z cyframi klawiatury. Np. „kapelusz pełen deszczu” da 22 cyfrowy pin: 5273587907353603379298.
Jasne, że trzeba używać osobnego hasła do deszyfracji dysku i osobnego do odblokowania pulpitu.
Jak usunac „szyfrowanie danych z samsunga? Wlaczylem to, wymagal podlaczenia ladowarki, teraz nie moge zdjac, choc znam haslo. Przy kazdrj czynnosci wymaga hasla.
Nie da się niestety jedyne co możesz zrobić to zresetować telefon do stanu fabrycznego.
Mam pytanie. Jak odszyfrować androida 4.4.4?