Szyfrowanie w Androidzie L: napastnikom nie będzie już tak łatwo, jak teraz

Wzmocnieniu przez Apple mechanizmu szyfrowania danych użytkownikaw systemie iOS 8 towarzyszyła niemal natychmiastowa reakcja Google,zdradzająca kompleks „me too”. Firma z Mountain Viewprzypomniała, że szyfrowanie w Androidzie możliwe jest od wielulat, a w najnowszej wersji systemu, znanej roboczo jako „L”,będzie ono domyślnie włączane. Reakcja była na tyle szybka, żeGoogle zdołało załapać się na krytykę ze strony przedstawicieliorganów ścigania ze Stanów Zjednoczonych i Europolu,niezadowolonych, że nie będą w stanie zmusić producentów doodszyfrowania dla nich danych z telefonów aresztowanych osób. O ilejednak przedstawiona w iOS Security Guide implementacja zabezpieczeńspotkałasię z pochwałami kryptografów, to w wypadku Androida sytuacjawygląda bardziej skomplikowanie. Wiele osób pamięta wciąż, jakmierne były zabezpieczenia w poprzednich wersjach tego systemu –czemu więc mielibyśmy sądzić, że z Androidem L sytuacja będziewyglądała inaczej?

Tej kwestii przyjrzałsię bliżej Nikołaj Elenkow, jeden z najbardziej znanychekspertów od bezpieczeństwa Androida, autor książki AndroidSecurity Internals. Na swoim blogu analizuje rozwiązaniaszyfrowania pamięci masowej wprowadzane w kolejnych wersjachgoogle'owego systemu, by finalnie przyjrzeć się zmianom, jakiezaszły w wersji 4.4 – i tego, co możemy spodziewać się wAndroidzie L.

Po raz pierwszy pełne szyfrowanie danych zawitało wprzeznaczonym tylko dla tabletów Androidzie 3.0 – i jak zobaczymy,nie było zbyt udane, a mimo to Google korzystało z niego bez zmianw kolejnych wydaniach, aż do Androida 4.4. Doprowadziło to dosytuacji, w której zabezpieczenia większości używanych dziśurządzeń z „robocikiem” są mało warte.

Samemu kryptosystemowi Androida 3.0-4.3 nic zarzucić nie można.To dobrze znany z Linuksa dm-crypt, który pozwala na szyfrowanie wtle wszystkiego, co zapisywanie jest w partycji użytkownika /data iautomatyczne deszyfrowanie danych stamtąd odczytywanych. 128-bitowyklucz szyfrujący jest generowany losowo i chroniony hasłemwpisywanym na ekranie blokady. Same sektory pamięci masowej sąszyfrowane za pomocą wspomnianego klucza szyfrem AES, w trybie CBC.Wektory inicjalizacyjne wyprowadzane są bezpieczną metodą ESSIV,wykorzystującą solone funkcje skrótu.

Parametry szyfrowania są jednak w Androidzie przechowywane wprostszy sposób niż normalnie w linuksowym LUKS. Jest tu miejscetylko na jedną kopię klucza, a co za tym idzie na tylko jednąfrazę deszyfrującą. Nie ma tu też mechanizmu rozdzielania klucza,zmniejszającego prawdopodobieństwo jego odzyskania po skasowaniu zdysku, ani też testu sumy kontrolnej klucza głównego, pozwalającejna sprawdzenie poprawności frazy odblokowującej bez deszyfrowaniadanych na dysku. Android po prostu próbuje podłączyć zaszyfrowanąpartycję. Jeśli mu się to uda, to frazę szyfrującą uznaje sięza poprawną. I co najciekawsze – klucz główny jest szyfrowanyz wykorzystaniem 128-bitowego klucza AES, wyprowadzonego z frazyszyfrującej użytkownika via 2 tys. iteracji funkcji wyprowadzeniaklucza PBKDF2. Uruchomiając zaszyfrowane urządzenie, Androidprzyjmuje frazę szyfrującą, przepuszcza ją przez PBKDF2,odszyfrowuje klucz główny i oddaje go dm-cryptowi, by podłączyćpartycję użytkownika.

Okazuje się, że atak na ten system wcale nie jest skomplikowanyi na pewno leży w zasięgu czy to organów ścigania czyzorganizowanych grup przestępczych. Jeśli urządzenie jestzrootowane, wystarczy uruchomić na nim specjalny obraz recovery.Jeśli nie jest – praktycznie każdy producent dysponujepodpisanymi przez siebie obrazami, które pozwalają na zrobieniezrzutu partycji i zbioru parametrów szyfrowania. W ostatecznościmożna skorzystać z błędów w bootloaderze, które pozwalają nauruchomienie niepodpisanych obrazów systemowych. Po uzyskaniuzrzutów, sforsowanie zabezpieczeń jest sprawą trywialną. Frazyszyfrujące to zazwyczaj zwykłe PIN-y używane do odblokowaniaekranu, ich entropia jest bardzo niska, nie stanowią żadnegowyzwania dla współczesnego sprzętu.

Nie trzeba tu żadnego superkomputera – wystarczy zwykły laptopz dyskretnym GPU, na którym uruchomimy np. Kali Linuksa z narzędziemhashcat, które od jakiegoś czasu zawiera gotowy moduł do łamaniaandroidowego szyfrowania dysków. Jak wyjaśnia Elenkow, na laptopiez GeForce 730M złamanie 6-cyfrowego PIN-u zajmuje niecałe 10sekund. Złamanie 6-znakowego ciągu liter to około czterech godzin.Można sobie wyobrazić, że zainteresowany zawartością telefonunapastnik będzie dysponował czymś więcej niż niedrogim laptopemdo gier – niewykluczone, że będzie miał do dyspozycji całyklaster obliczeniowy z najpotężniejszymi Titanami.

W Androidzie 4.4 Google wprowadziło kilka istotnych ulepszeń docałego tego procesu. Przede wszystkim funkcję wyprowadzania kluczaPBKDF2 zastąpiono funkcją scrypt, znaną z tego, że jest trudnadla GPU, gdyż wymaga bardzo dużej ilości pamięci operacyjnej –której zwykle GPU brakuje. Po zaktualizowaniu urządzenia doAndroida 4.4, zbiór parametrów szyfrowania i sam klucz głównyzostaje zabezpieczony właśnie scryptem. Hashcat, mimo że obsługujełamanie tej funkcji, nie radzi sobie z tym zbyt efektywnie, niepotrafi też (jeszcze) automatycznie odzyskać frazy szyfrującej. Odziwo bardziej efektywnie jest skorzystać z działających naszybkim CPU łamaczy, choć oczywiście nie można się nastawiać natak szybki sukces, jak w wypadku starszych wersji Androida.

Wypróbowanie 1200 kombinacji czterocyfrowego PIN-u to niemal pięćminut na Core i7. Względne bezpieczeństwo może więc zagwarantowaćtylko odpowiednio długa fraza (przynajmniej 12+ znaków, najlepiejoprócz liter i cyfr także znaki niealfanumeryczne). Trudno jednaksądzić, by ktoś w telefonie stosował takie rozwiązanie, zakażdym razem odblokowując ekran w tak niewygodny sposób.

Przeprowadzona przez Elenkowa analiza Androida L pokazuje, żeGoogle wreszcie poszło po rozum do głowy. W zbiorze parametrówszyfrowania pojawiły się odniesienia do jakiejś nowej, nieznanejfunkcji wyprowadzania skrótu. Szyfrowanie urządzenia nie jest teżjuż powiązane z ustawieniem PIN-u blokady ekranu, co wskazuje nato, że klucz szyfrujący klucz główny nie jest bezpośredniowyprowadzany z tej formy hasła. W kodzie pojawiają się teżodniesienia do sprzętowego kryptosystemu ARM TrustZone (aprzynajmniej jego implementacji w procesorach Qualcomma).

Wygląda więc na to, że deklaracje Google'a o ulepszeniuszyfrowania w nowych Androidach nie są zmyślone. WykorzystanieTrustZone to spory krok naprzód w porównaniu do czystosoftware'owych rozwiązań z poprzednich wersji systemu. Nawetpozyskanie zrzutu pamięci masowej nie wystarczy teraz napastnikowido odszyfrowania zawartości, gdyż klucz szyfrujący klucz znajdujesię w mikroprocesorze. Możliwe też, że najlepszy sprzęt zAndroidem otrzyma specjalizowane procesory kryptograficzne,dorównujące temu, co oferuje Apple ze swoją Secure Enclave – aleo tym przekonamy się dopiero po premierze pierwszych smartfonów itabletów z Androidem L.

Wtedy też zobaczymy, czy sięgając po taki sprzęt, nie zostaniemy automatycznie uznany przez władze za islamskiego terrorystę czy miłośnika nieletnich. W końcu, jak powszechnie wiadomo, osoby z czystym sumieniem nie mają niczego do ukrycia.