Czy pełne szyfrowanie urządzenia chroni moje dane przed Google i rządem?


13

Apple ostatnio falowało w społeczności technologicznej, odmawiając przestrzegania prawa w zakresie dostępu do zaszyfrowanych danych użytkownika. Stwierdzili, że nie mają technicznej możliwości odszyfrowania tych danych.

Czy jako użytkownik Androida istnieje jakakolwiek podobna możliwość (najlepiej wbudowana w system operacyjny zamiast strony trzeciej), której mogę użyć, aby uzyskać podobną ochronę nawet od Google i producenta mojego urządzenia? Wiem, że w moich ustawieniach jest „Pełne szyfrowanie urządzenia”, ale czy to uniemożliwia Google itp. Dostęp do niego?

Dla porównania, moje urządzenie działa z Androidem Lollipop i jest OnePlus Two. Jeśli inne wersje, takie jak Marshmallow, pozwolą mi to zrobić, to dobrze.

Odpowiedzi:


10

Google nie ma pojęcia, jaki jest klucz szyfrowania twojego urządzenia. Cały proces odbywa się na twoim urządzeniu, a klucz nigdy nie jest nigdzie przesyłany. Sam klucz nie jest również przechowywany w postaci zwykłego tekstu na urządzeniu :

Przechowywanie zaszyfrowanego klucza

Zaszyfrowany klucz jest przechowywany w metadanych kryptograficznych. Tworzenie kopii zapasowych sprzętu jest realizowane za pomocą funkcji podpisywania w środowisku Trusted Execution Environment (TEE). Wcześniej szyfrowaliśmy klucz główny za pomocą klucza generowanego przez zastosowanie scrypt do hasła użytkownika i przechowywanej soli. Aby uczynić klucz odpornym na ataki z pudełka, rozszerzamy ten algorytm, podpisując wynikowy klucz przechowywanym kluczem TEE. Powstały podpis jest następnie zamieniany na klucz o odpowiedniej długości przez jeszcze jedną aplikację scrypt. Ten klucz jest następnie używany do szyfrowania i deszyfrowania klucza głównego.

Więc nawet jeśli ktoś miał kopię zaszyfrowanego klucza głównego, nie mógł go odszyfrować bez klucza TEE z karty SoC urządzenia.

Dlatego, poza wadą implementacji, pełne szyfrowanie urządzenia uniemożliwi każdemu dostęp do twoich danych, chyba że znają / uzyskują twoje hasło LUB mogą odgadnąć twoje hasło (np. Poprzez brutalne wymuszenie lub jakieś techniki inżynierii społecznej). Na urządzeniach, które nie są wyposażone w niezbędne wsparcie sprzętowe, FDE podejmie próbę zaszyfrowania klucza przy użyciu metody tylko programowej.


@beeshyams Jest to funkcja procesora. Implementacja ARM nazywa się „TrustZone”, ale inne architektury również zapewniają podobne mechanizmy. Chodzi o to, że możesz wygenerować klucz urządzenia, przechowywać go w miejscu dostępnym tylko dla TEE, a następnie nigdy nie ujawniać go zewnętrznemu światu. Gdy musisz coś zaszyfrować / odszyfrować, poprosisz o uruchomienie kodu w TEE, aby klucz był bezpieczny. Wikipedia ma przyzwoity (-ish) artykuł .
eldarerathis

1
@eldarerathis Słyszałem, że iPhone 6 i nowsze są bezpieczne nawet przed aktualizacjami OEM, ponieważ weryfikacja hasła (w tym opóźnienie / blokada czasowa) są realizowane całkowicie sprzętowo. Pytam o to, czy Android robi coś podobnego, czy też jest to wyłącznie blokada oprogramowania - co oczywiście można ominąć dzięki aktualizacji oprogramowania układowego. Pytam również, czy istnieją telefony z systemem Android z programami ładującymi, które odmawiają aktualizacji bez podania hasła określonego przez użytkownika - co ułatwiłoby omijanie okresów blokowania oprogramowania.
Bob

1
Jeszcze innym sposobem przeformułowania jest to, czy istnieje sposób, aby wymagać odszyfrowania (z hasłem użytkownika) przed zezwoleniem na aktualizacje. Innymi słowy, czy aktualizacje (OEM, podpisane) można zainstalować bez klucza deszyfrującego (bez obowiązkowego czyszczenia danych użytkownika)?
Bob

1
@Bob Według mojej wiedzy, system Android nie wymaga hasła deszyfrującego do przeprowadzenia procesu aktualizacji, ponieważ szyfruje tylko /userdatapartycję, a nie partycje, które aktualizacja mogłaby faktycznie zmodyfikować ( /systemi /bootogólnie). Jest prawie w tej samej łodzi, co iPhone 5 (i niższe).
eldarerathis

1
Dodam, że nie jestem pewien, czy ogólne opóźnienie przy każdej próbie może być „wyłączone” przez aktualizację, czy też Android sztucznie skaluje to. Android używa rund scrypt podczas procesu generowania klucza, więc musiałby zostać użyty również podczas odszyfrowywania klucza, a scrypt został zaprojektowany specjalnie z myślą o przyspieszeniu, jako środek zapobiegający brutalnemu forsowaniu. Tyle pozostanie spójne. Blokada po X liczbie nieudanych prób (lub skalowana blokada, jeśli taka istnieje) zostanie zaimplementowana w oprogramowaniu, AFAIK.
eldarerathis

-1

Pełne szyfrowanie urządzenia ochroni twoje urządzenie, jeśli użyjesz klucza zbyt długiego, aby użyć siły, nawet jeśli atakujący są w stanie zastosować techniki brutalnej siły - zakładając, że istnieją na to sposoby. Snowden twierdzi, że 64 znaki są wystarczająco długie, aby zapewnić naprawdę niezniszczalne szyfrowanie. Można więc uzyskać pełne bezpieczeństwo - jeśli nie masz nic przeciwko wpisywaniu hasła złożonego z 64 znaków za każdym razem, gdy budzisz telefon.


Czy zdajesz sobie sprawę z ograniczenia długości kodu PIN blokady ekranu? Zastanów się nad ponownym uruchomieniem odpowiedzi
beeshyams,

Tak, 16 znaków jest ograniczeniem, jeśli sprawdzisz kod źródłowy .
Firelord
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.