Android o całe lata za iOS‑em pod względem zabezpieczeń – nawet Nougat nie pomógł

Podstawowym problemem urządzeń z Androidem jest, zdaniemGreena, potraktowanie ich jak pecetów, mimo że pecetami nie są.Od Androida 4.4 KitKat mobilny system Google’a stosuje szyfrowaniepraktycznie takie samo, jak desktopowe systemy linuksowe. Bazuje onona podsystemie szyfrowania kernela dm-crypt. To rozwiązanie świetne,ale czy właściwe dla smartfonów? Problem tkwi w tym, żecałodyskowe szyfrowanie chroni dane na smartfonie… gdy jest onwyłączony. Gdy urządzenie jest włączone, a klucze deszyfrująceznajdują się w pamięci operacyjnej, to tego szyfrowania jakby niebyło.

Większość użytkowników urządzeń mobilnych praktyczniejednak ich nie wyłącza. Pomyślano o płynnym przechodzeniumiędzy stanami energooszczędnego czuwania i skoków aktywności, wimię wydłużenia czasu pracy na baterii. Dziś dobre smartfony mogąw ten sposób pracować po kilka dni, a gdy poziomnaładowania robi się niski, użytkownicy po prostu podłączają jedo ładowarek. Uptime smartfonów może więc sięgać całychmiesięcy.

Czy dla tak działających urządzeń całodyskowe szyfrowaniejest dobre? Green odpowiada „nie” – i trudno się z nim niezgodzić. Dbający o swoją prywatność użytkownicy komputerówosobistych nie usypiają ich, tylko wyłączają, mając pewność,że całodyskowe szyfrowanie czyni ich dane niedostępnymi dla osóbtrzecich. Smartfony nosimy jednak ze sobą cały czas, niewyłączone.Gdy smartfon zgubimy, lub zostanie nam przemocą odebrany, napastnikwciąż dostaje urządzenie z kluczami w RAM, z pełnym dostępem dodanych użytkownika. dm-crypt w tym wypadku nic nie daje.

Apple poszło zupełnie inną drogą. Od iOS-a 4 w mobilnymsystemie z Cupertino mamy do czynienia z mechanizmem ochrony danych,pozwalającym zaszyfrować dane przechowywane na urządzeniu.Rozumiejąc jednak specyfikę wykorzystania urządzeń mobilnych,Apple postawiło na szyfrowanie plików – każdego z osobna. W tymsystemie zawartość każdego pliku jest szyfrowana za pomocąunikatowego klucza (metadane plików są szyfrowane osobno),unikatowe klucze są zaś szyfrowane za pomocą jednego z kluczy klasbezpieczeństwa, wyprowadzonych z hasła użytkownika i danychprzechowywanych sprzętowo w procesorze urządzenia.

W ten sposób Apple oferuje precyzyjną kontrolę dostępu doplików iOS-a. Programiści mają dostęp do interfejsuprogramowania, który pozwala określić, który z kluczy klasbezpieczeństwa ma zostać wykorzystany do zabezpieczenia danegopliku. W ten sposób możemy tworzyć pliki, które są dostępne dlakażdego, nawet po restarcie urządzenia przed zalogowaniem sięużytkownika, pliki zabezpieczone do momentu pierwszego zalogowaniaużytkownika, oraz co najważniejsze, pliki, które sązabezpieczone cały czas: są odszyfrowywane tylko na chwilę, gdyurządzenie zostało odblokowane. Po ponownym zablokowaniu, kluczjest usuwany z pamięci urządzenia.

W Androidzie 7 Google ulepszyło swoją strategię. Nowy model,Direct Boot, oferuje dwa konteksty szyfrowania. Pierwszy to sprzętowozaszyfrowana pamięć (te pliki nie są szyfrowane hasłemużytkownika, co najwyżej są szyfrowane za pomocą danychsprzętowych, a więc są dostępne zaraz po rozruchu, a przedlogowaniem), drugi to pamięć szyfrowana poprzez uwierzytelnianie –takie pliki dostępne są tylko po podaniu przez użytkownika swojegohasła. Atutem DirectBoota ma być to, że można skorzystać zróżnych kontekstów szyfrowania dla różnych użytkownikówsmartfonu, choć do końca nie wiadomo, po co to komu – smartfonyto jednak raczej jednoosobowe urządzenia.

Pomimo tych zmian, widać, że Android 7 nie oferuje takiegozabezpieczenia jak iOS 10 z usuwaniem kluczy z pamięci dla plików wpełni chronionych. W teorii można by było to wymusić na poziomieaplikacji, tyle że jak zauważa Green, nie ma jasnej metodypowiedzenia aplikacjom, kiedy to Android został ponowniezablokowany. Nawet aplikacje systemowe tego nie wiedzą – gdyodetniesz im nagle dostęp do plików, sypią błędami. Co więcej,Android 7 nawet nie próbuje tak naprawdę usunąć kluczy z pamięcipo zablokowaniu urządzenia. W kodzie systemu plików ext4 widać,że funkcja mająca zapewnić ich usunięcie z pęku kluczy kernelanie została jeszcze napisana!

Matthew Green zauważa więc na koniec, że ta słabość Androidawłaściwie nie wiąże się z kryptografią. To problem zarównoarchitektury systemu, jak i braku należytych wytycznych dlaprogramistów. Podążając w tym kierunku, Google skazuje Androidana całe lata bycia niebezpiecznym. Świetny ruch – szczególniedziś, gdy władze wielu państw tylko szukają rozwiązań prawnych,które pozwolą im się bez ograniczeń włamywać do urządzeńobywateli. Być może pan Adrian Ludwig nie uważa tego jednak zaistotne zagrożenie?