Trzeba było uczyć się od Apple, czyli jak całodyskowe szyfrowanie Androida okazało się do niczego

Choć androidowe smartfony z procesorami Qualcomma należą donajwydajniejszych na rynku, to na pewno nie należą donajbezpieczniejszych – przynajmniej w porównaniu do nowychiPhone’ów, których sprzętowe zabezpieczenia czynią ukryte nanich dane nieosiągalnymi nawet dla amerykańskich organów ścigania.W minionym tygodniu zaprezentowano metody, za pomocą którychnapastnik może wydobyć klucze szyfrujące z zablokowanegosmartfonu, w praktyce czyniąc całodyskowe szyfrowanienieskutecznym. Problem tkwi przede wszystkim w niedoskonałejimplementacji technologii ARM TrustZone w procesorach Snapdragon, alenie tylko. Odkrywca twierdzi, że sam mechanizm całodyskowegoszyfrowania Androida nie jest najlepszy, i nie jest w swojej krytyce jedyny.

Na początku warto przypomnieć, jak robi to dziś Apple. Wsystemie iOS 8 wprowadzono domyślnie całodyskowe szyfrowanie, wktórym klucz szyfrujący wyprowadzany jest z hasła użytkownika.Użytkownicy mają jednak zwykle słabe hasła, szczególnie naurządzeniach mobilnych, więc siłowe złamanie hasła szybko dałobydostęp do zaszyfrowanej pamięci masowej.

By uniknąć takiej sytuacji, Apple powiązało wygenerowany kluczszyfrujący z procesorem iPhone’a, a dokładnie z osadzonym w nim256-bitowym kluczem, unikatowym dla każdego urządzenia. Jest onlosowo generowany i osadzany w procesorze podczas jego produkcji, także żadne oprogramowanie, nawet niskopoziomowe, nie ma do niegodostępu. Jest on dostępny tylko jako klucz dla silnika szyfrowaniaAES i wykorzystywany w połączeniu z hasłem użytkownika dowygenerowania bardzo silnego klucza szyfrującego dysk.

Dla napastnika to bardzo zła wiadomość – może próbowaćataku siłowego, ale nie na klastrze obliczeniowym. Musi robić to nasamym iPhonie, który aktywnie taki atak utrudnia, coraz bardziejwydłużając czas, który musi upłynąć pomiędzy kolejnymipróbami. Co więcej, ostatnio w iOS-ie pojawiła się funkcja, którasprawia, że po 10 nieudanych próbach odgadnięcia hasła, wszystkiedane z urządzenia zostają usunięte.

W Androidzie od wersji 5.0 też dysponujemy całodyskowymszyfrowaniem, zbudowanym na bazie linuksowego podsystemu dm-crypt. Itutaj głównym problemem jest funkcja wyprowadzania kluczaszyfrującego. W uproszczeniu można powiedzieć, że urządzeniegeneruje 128-bitowy klucz szyfrujący urządzenie (Device EncryptionKey – DEK) oraz 128-bitową sól. DEK zostaje zabezpieczony wschemacie wykorzystującym dane odblokowujące dostęp (hasło, PINlub wzór) do wygenerowania klucza szyfrującego DEK. ZaszyfrowanyDEK jest przechowywany w niezaszyfrowanej części pamięci. Aby więcodszyfrować dysk, należy dysponować danymi dostępowymi,przepuścić je przez funkcję wyprowadzającą klucz szyfrujący, anastępnie użyć go do odszyfrowania DEK-a. Mając DEK, możemyodczytać zaszyfrowane dane na dysku.

Tak samo jak w iOS-ie dysponujemy tutaj obroną przed siłowymiatakami – opóźnieniami między próbami wprowadzenia hasła iopcją skasowania wszystkich danych po określonej liczbie błędnychprób podania hasła. Co jednak w wypadku Androida chroni przedsiłowymi atakami przeprowadzanymi poza urządzeniem? Tu nie maprzecież identycznego hardware ani pełnej kontroli nad procesemprodukcji, jak to jest w przypadku Apple’a. Znaleziono jednaksposób na przywiązanie funkcji wyprowadzania klucza do sprzętu.Kluczową (sic!) rolę odgrywa tu moduł KeyMaster, kryptograficznykomponent oddzielony od Androida.

Jego wykorzystanie to dość skomplikowany proces. Z grubsza: wniezaszyfrowanej pamięci przechowywany jest tzw. key blob,wygenerowana przez KeyMastera binarna struktura, zawierajacazaszyfrowany przez niego prywatny klucz RSA-2048, który jestwykorzystywany do podpisania klucza DEK w dodatkowym kroku po jegowygenerowaniu. To sprawia, że ten konkretny moduł KeyMaster musibyć użyty do stworzenia pośredniczącego klucza odszyfrowującegoDEK przy każdej próbie odszyfrowania danych.

Temu towarzyszy jeszcze jedna informacja: wartość funkcjiscrypt, której argumentem jest finalny klucz pośredniczący.Wykorzystuje się go do zweryfikowania ważności hasła w razieproblemów z deszyfrowaniem, wynikających np. z uszkodzenia dysku.Dzięki temu system może odróżnić awarię od siłowego ataku.

Jak widać, schemat zabezpieczeń całodyskowego szyfrowaniaAndroida jest zmyślny, ale zarazem zależny od KeyMastera. A jakiesą zabezpieczenia KeyMastera? Tego już właściwie nie wiadomo –dla programisty to czarna skrzynka, w dokumentacji opisana jedynie marketingowym językiem. Ta czarna skrzynka, przynajmniej w wydaniu Qualcomma, może być jednak nieszczelna.

Gal Beniamini, niezależny izraelski haker, który badałdziałanie całodyskowego szyfrowania w Androidzie, przeniknąłdziałanie tego mechanizmu. Mamy otóż w procesorach Qualcommabezpieczne środowisko uruchomieniowe QSEE, w którym możnauruchamiać programiki zwane „trustletami”. Działają one nawydzielonym procesorze bezpiecznego świata TrustZone. Okazuje się, że na procesorach Qualcomma KeyMaster jest po prostu jednym z takich trustletów. Stosując opracowane wcześniej techniki odwrotnej inżynierii, izraelski haker zdołał wejrzeć w to, co się dzieje w środku. Zainteresowani szczegółami powinni dokładnie przyjrzeć się wykorzystaniu klucza HMAC. Tutaj powiemy tyle, że zamiast korzystać z podobnego do iOS-a schematu szyfrowania, w którym oprogramowanie nigdzie nie dotyka sprzętowego klucza, KeyMaster Qualcomma przeprowadza sobie operacje szyfrowania i uwierzytelnienia blobów za pomocą kluczy bezpośrednio dostępnych oprogramowaniu, z wykorzystaniem w tym procesie sprzętowego klucza (SHK). Wnioski wyciągnięte przez Gala Beniaminiego są bardzo interesujące:

• wyprowadzanie klucza nie jest zależne od sprzętu, klucz ten jest bezpośrednio dostępny oprogramowaniu działającemu w TrustZone,
• producenci sprzętu mogą łatwo spełnić nakaz organów ścigania i złamać szyfrowanie, po prostu tworząc obraz TrustZone, który pobiera klucze KeyMastera i flashuje je na docelowym urządzeniu. Potem zostaje już tylko siłowy atak offline z wykorzystaniem zdobytych kluczy.
• łatanie podatności TrustZone nie chroni przed tym problemem. Nawet jeśli TrustZone zostałoby jakoś zabezpieczone, napastnik może pozyskać zaszyfrowany obraz systemowy, obniżyć wersję systemu do podatnej na atak wersji, wydobyć klucz i przejść do siłowego ataku. W ten sposób można załatwić każde androidowe urządzenie na procesorach Qualcommach, w którym można cofnąć się z wersją firmware.
• wartość całodyskowego szyfrowania na Androidzie zależy wyłącznie od bezpieczeństwa kernela TrustZone czy modułu KeyMaster. Każda podatność w nich prowadzi do ujawnienia kluczy, pozwalając na ataki siłowe offline na zaszyfrowane dane użytkownika.

Izraelski haker nie zadowolił się samymi wnioskami, lecz zakasał rękawy i napisał kod wykradający klucze z KeyMastera, z wykorzystaniem dwóch znanych podatności w TrustZone. Google i Qualcomm, powiadomione o odkryciu, sprawę zbagatelizowały. Dały do zrozumienia że nie ma się czym przejmować, ponieważ podatności te zostały już załatane, jedna w styczniu, druga w maju (i odkrywcy luk dostali za to nagrodę)… ale ciężko takie tłumaczenie wziąć za dobrą monetę. Otóż z badań niezależnej firmy Duo Security wynika, że obecnie około 37% smartfonów korzystających z jej aplikacji jest wciąż podatnych na atak, ponieważ jak to z Androidem bywa, od wydania łatek do ich dostarczenia końcowym użytkownikom droga daleka.

Nawet jeśli jednak smartfon zostałby zabezpieczony, to dla instytucji takich jak NSA nie byłoby to żadną przeszkodą. Jeśli urządzenie ma odblokowany bootloader (co dziś nie jest rzadkie), to można przywrócić na nim starszą, podatną na atak wersję oprogramowania. Tak jest w wypadku np. smartfonów Nexus 5 i Nexus 6.

Zdaniem ekspertów Google popełniło poważny błąd, stawiając na TrustZone. Nagle okazało się, że cały ten skomplikowany proces generowania i szyfrowania kluczy jedynie powiększa powierzchnię ataku, a użytkownika skazuje na konieczność ufania stronom trzecim – producentom urządzeń mobilnych. Oni mogą zaś w TrustZone uruchomić co im się żywnie podoba – i ani Google, ani Qualcomm ich przed tym nie powstrzymają. Niezwykle proste rozwiązanie zastosowane w iOS-ie jest tymczasem nie do złamania, bo nie ma tam miejsca na błędy w implementacji. W czipie z bezpieczną enklawą jest klucz, niedostępny jakiemukolwiek oprogramowaniu, do odczytania tylko przez sprzętowy akcelerator kryptograficzny, jak ktoś chce to złamać, musi łamać całą matematykę, albo znaleźć sposób, jak odczytać klucz za pomocą mikroskopu elektronowego (przypominamy jednak, że życie to nie serial CSI).

Najgorsze w tym wszystkim jest to, że wcale nie trzeba było tak kombinować – czipy Qualcomma też mają osadzony w krzemie klucz SHK. Gdyby został on wykorzystany bezpośrednio do całodyskowego szyfrowania, problemu by nie było. Problem za chwilę zaś będzie, i to poważny, gdyż już twórcy popularnego łamacza haseł Hashcat zapowiedzieli, że pracują nad wykorzystaniem wydobytych z KeyMastera kluczy w swoim programie.

Czy sprzęt z procesorem innym niż produkcji Qualcomma jest wolny od tych wad? Nie wiadomo. Beniamini uważa, że nie zdziwiłoby go, gdyby implementacje TrustZone u innych producentów cierpiały na podobne podatności. Możemy więc założyć, że zawartość przynajmniej jednej trzeciej smartfonów na rynku może zostać odszyfrowana za pomocą publicznie dostępnych exploitów, zaś co do reszty – zapewne wystarczy grzecznie poprosić producenta.