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

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

Strona główna AktualnościBEZPIECZEŃSTWO

Choć androidowe smartfony z procesorami Qualcomma należą do najwydajniejszych na rynku, to na pewno nie należą do najbezpieczniejszych – przynajmniej w porównaniu do nowych iPhone’ów, których sprzętowe zabezpieczenia czynią ukryte na nich dane nieosiągalnymi nawet dla amerykańskich organów ścigania. W minionym tygodniu zaprezentowano metody, za pomocą których napastnik może wydobyć klucze szyfrujące z zablokowanego smartfonu, w praktyce czyniąc całodyskowe szyfrowanie nieskutecznym. Problem tkwi przede wszystkim w niedoskonałej implementacji technologii ARM TrustZone w procesorach Snapdragon, ale nie tylko. Odkrywca twierdzi, że sam mechanizm całodyskowego szyfrowania Androida nie jest najlepszy, i nie jest w swojej krytyce jedyny.

KISS, czyli Keep it simple, stupid

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

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

r   e   k   l   a   m   a

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

W Androidzie od wersji 5.0 też dysponujemy całodyskowym szyfrowaniem, zbudowanym na bazie linuksowego podsystemu dm-crypt. I tutaj głównym problemem jest funkcja wyprowadzania klucza szyfrującego. W uproszczeniu można powiedzieć, że urządzenie generuje 128-bitowy klucz szyfrujący urządzenie (Device Encryption Key – DEK) oraz 128-bitową sól. DEK zostaje zabezpieczony w schemacie wykorzystującym dane odblokowujące dostęp (hasło, PIN lub wzór) do wygenerowania klucza szyfrującego DEK. Zaszyfrowany DEK jest przechowywany w niezaszyfrowanej części pamięci. Aby więc odszyfrować dysk, należy dysponować danymi dostępowymi, przepuścić je przez funkcję wyprowadzającą klucz szyfrujący, a następnie użyć go do odszyfrowania DEK-a. Mając DEK, możemy odczytać zaszyfrowane dane na dysku.

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

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

Temu towarzyszy jeszcze jedna informacja: wartość funkcji scrypt, której argumentem jest finalny klucz pośredniczący. Wykorzystuje się go do zweryfikowania ważności hasła w razie problemó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 szyfrowania Androida jest zmyślny, ale zarazem zależny od KeyMastera. A jakie są 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.

Dziurawe kieszenie klucznika

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 Qualcomma bezpieczne środowisko uruchomieniowe QSEE, w którym można uruchamiać programiki zwane „trustletami”. Działają one na wydzielonym 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.

Stary exploit a może

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.

© dobreprogramy
r   e   k   l   a   m   a
r   e   k   l   a   m   a

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.