r   e   k   l   a   m   a
r   e   k   l   a   m   a

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

Strona główna AktualnościOPROGRAMOWANIE

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

Tej kwestii przyjrzał się bliżej Nikołaj Elenkow, jeden z najbardziej znanych ekspertów od bezpieczeństwa Androida, autor książki Android Security Internals. Na swoim blogu analizuje rozwiązania szyfrowania pamięci masowej wprowadzane w kolejnych wersjach google'owego systemu, by finalnie przyjrzeć się zmianom, jakie zaszły w wersji 4.4 – i tego, co możemy spodziewać się w Androidzie L.

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

r   e   k   l   a   m   a

Stare Androidy łatwo „pękają”

Samemu kryptosystemowi Androida 3.0-4.3 nic zarzucić nie można. To dobrze znany z Linuksa dm-crypt, który pozwala na szyfrowanie w tle wszystkiego, co zapisywanie jest w partycji użytkownika /data i automatyczne deszyfrowanie danych stamtąd odczytywanych. 128-bitowy klucz szyfrujący jest generowany losowo i chroniony hasłem wpisywanym 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 w prostszy sposób niż normalnie w linuksowym LUKS. Jest tu miejsce tylko 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 z dysku, ani też testu sumy kontrolnej klucza głównego, pozwalającej na sprawdzenie poprawności frazy odblokowującej bez deszyfrowania danych 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 szyfrowany z wykorzystaniem 128-bitowego klucza AES, wyprowadzonego z frazy szyfrującej użytkownika via 2 tys. iteracji funkcji wyprowadzenia klucza PBKDF2. Uruchomiając zaszyfrowane urządzenie, Android przyjmuje 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 skomplikowany i na pewno leży w zasięgu czy to organów ścigania czy zorganizowanych grup przestępczych. Jeśli urządzenie jest zrootowane, wystarczy uruchomić na nim specjalny obraz recovery. Jeśli nie jest – praktycznie każdy producent dysponuje podpisanymi przez siebie obrazami, które pozwalają na zrobienie zrzutu partycji i zbioru parametrów szyfrowania. W ostateczności można skorzystać z błędów w bootloaderze, które pozwalają na uruchomienie niepodpisanych obrazów systemowych. Po uzyskaniu zrzutów, sforsowanie zabezpieczeń jest sprawą trywialną. Frazy szyfrujące to zazwyczaj zwykłe PIN-y używane do odblokowania ekranu, ich entropia jest bardzo niska, nie stanowią żadnego wyzwania dla współczesnego sprzętu.

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

Scrypt metodą na procesory graficzne

W Androidzie 4.4 Google wprowadziło kilka istotnych ulepszeń do całego tego procesu. Przede wszystkim funkcję wyprowadzania klucza PBKDF2 zastąpiono funkcją scrypt, znaną z tego, że jest trudna dla GPU, gdyż wymaga bardzo dużej ilości pamięci operacyjnej – której zwykle GPU brakuje. Po zaktualizowaniu urządzenia do Androida 4.4, zbiór parametrów szyfrowania i sam klucz główny zostaje zabezpieczony właśnie scryptem. Hashcat, mimo że obsługuje łamanie tej funkcji, nie radzi sobie z tym zbyt efektywnie, nie potrafi też (jeszcze) automatycznie odzyskać frazy szyfrującej. O dziwo bardziej efektywnie jest skorzystać z działających na szybkim CPU łamaczy, choć oczywiście nie można się nastawiać na tak 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, najlepiej oprócz liter i cyfr także znaki niealfanumeryczne). Trudno jednak sądzić, by ktoś w telefonie stosował takie rozwiązanie, za każdym razem odblokowując ekran w tak niewygodny sposób.

Android L: wciąż sporo niewiadomych

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

Wygląda więc na to, że deklaracje Google'a o ulepszeniu szyfrowania w nowych Androidach nie są zmyślone. Wykorzystanie TrustZone to spory krok naprzód w porównaniu do czysto software'owych rozwiązań z poprzednich wersji systemu. Nawet pozyskanie zrzutu pamięci masowej nie wystarczy teraz napastnikowi do odszyfrowania zawartości, gdyż klucz szyfrujący klucz znajduje się w mikroprocesorze. Możliwe też, że najlepszy sprzęt z Androidem otrzyma specjalizowane procesory kryptograficzne, dorównujące temu, co oferuje Apple ze swoją Secure Enclave – ale o tym przekonamy się dopiero po premierze pierwszych smartfonów i tabletó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.

© dobreprogramy

Komentarze

r   e   k   l   a   m   a
r   e   k   l   a   m   a
Czy wiesz, że używamy cookies (ciasteczek)? Dowiedz się więcej o celu ich używania i zmianach ustawień.
Korzystając ze strony i asystenta pobierania wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.