Google Android

Członek  Electronic Frontier Foundation – organizacji mającej na celu walkę między innymi o prawo do anonimowości i prywatności – Micah Lee kilka dni temu na grupie dyskusyjnej projektu Android), utworzył wątek dotyczący funkcji tworzenia kopii zapasowej danych na telefonach z tym właśnie systemem.

Opcja tworzenia kopii zapasowej prezentuje się w  telefonie w ten sposób:

EFF Google privacy backup - Kopia zapasowa na Androidzie

Tym razem problemem nie jest przesyłanie danych przez nieszyfrowane połączenie jak w mobilnej aplikacji Tumblra, ale fakt że hasła i inne dane leżą niezaszyfrowane na serwerach Google.

Lee przyznaje, że funkcja backupu jest  bardzo użyteczna, ale nie chce aby hasła do sieci Wi-fi leżały na serwerach Google plain textem oraz zaznacza, że większość użytkowników synchronizuje swoje dane z kontem Google.

Na swoim blogu pisze o członkostwie Google w programie PRISM oraz o tym,  że tworząc kopię zapasową swoich danych przy użyciu powyższej funkcji podajemy na tacy swoje hasła agentom służb bezpieczeństwa, takim jak FBI czy CIA.

Gdy zdecydujemy się wyłączyć tworzenie kopii zapasowych (w urządzeniach Nexusa opcja ta jest domyślnie zaznaczona), otrzymamy taki komunikat:

Google privacy backup - wyłączenie tworzenia kopii zapasowej

Tak więc pozostaje nam ufać, że gdy zdecydujemy się odznaczyć  tę opcję Google faktycznie te dane usunie.

Rzecznik Google w rozmowie z portalem arstechnica.com powiedział, że dane backupu są szyfrowane w tranzycie. Wydał również oświadczenie dotyczące całej tej afery:

Nasza opcjonalna usługa “Tworzenia kopii zapasowej” sprawia iż zmiana urządzenia z Androidem staje się łatwiejsza, gdyż używając konta Google możesz przywrócić swoje poprzednie ustawienia.  Pomaga Ci uniknąć kłopotów wynikających z konfigurowania swojego urządzenia od podstaw. Kiedy tylko chcesz możesz wyłączyć to ułatwienie, co spowoduje usunięcie Twoich danych. Dane te są szyfrowane w tranzycie, dostępne tylko wtedy gdy użytkownik jest uwierzytelniony do Google oraz przechowywane w Google data center, które mają silne umocnienia przeciwko cyfrowemu i fizycznemu atakowi.

Niestety nie udzielił konkretnych informacji dotyczących sposobu szyfrowania danych w tranzycie.

Na grupach dyskusyjnych pojawiają się głosy twierdzące, że właśnie na tym polega idea przechowywania kopii zapasowej w chmurze, oraz powinniśmy zaufać firmie Google. Na szczęście w dyskusjach biorą udział także ludzie tacy jak Moxie Marlinspike (twórca SSLStripa), który podsuwa techniczne rozwiązanie problemu:

Jednym ze sposobów na szyfrowanie tych danych jest:

  1. Twoje hasło zostaje użyte to wygenerowania dwóch tokenów. Jeden do uwierzytelniania użytkownika w usłudze Google i drugi do szyfrowania danych. Tokenem uwierzytelniania jest PBKDF2 (N, hasło) a tokenem szyfrowania jest PBKDF2 (N-1, hasło). Token uwierzytelniania dajesz Google przy logowaniu. Google nie jest w stanie wyprowadzić tokenu szyfrowania z tokenu uwierzytelniania, ale użytkownik ma możliwość wygenerowania obu tokenów ze swojego hasła.
  2. Dla procesu tworzenia kopii zapasowej, prosisz użytkownika o jego hasło, obliczasz token szyfrowania, generujesz parę kluczy ECC, szyfrujesz prywatny klucz ECC za pomocą tokenu szyfrowania i wysyłasz zaszyfrowany klucz prywatny na serwer Google. To jest ostatni moment kiedy użytkownik jest proszony o swoje hasło, aż do procesu przywracania danych.
  3. Za każdym razem kiedy zechcesz wysłać aktualizację swoich danych na serwerze kopii zapasowych, generujesz symetryczny klucz, który szyfrujesz kluczem publicznym użytkownika, szyfrujesz dane kluczem symetrycznym i wysyłasz zaszyfrowane dane wraz z zaszyfrowanym kluczem symetrycznym na serwer Google. Ten proces nie wymaga proszenia użytkownika o jego hasło czy przechowywania go na telefonie.
  4. Przy przywracaniu danych, prosisz użytkownika o jego hasło, używasz go do zdeszyfrowania klucza prywatnego pobranego z serwera backupu, którym możesz deszyfrować już dane użytkownika.

Ktoś mógłby w tym momencie powiedzieć – No, ale przecież hasło do konta Google, na które trzeba się zalogować by wysłać backup, może służyć do szyfrowania danych. Przy ściąganiu backupu, znowu logujesz się na swoje konto Google i ściągasz dane rozszyfrowując je kluczem wygenerowanym z hasła do konta Google.

Otóż już wyjaśniam dlaczego nie. Co by się stało gdyby użytkownik w międzyczasie zmienił hasło? Wtedy cała powyższa teoria bierze w łeb ze względów technicznych, ponieważ proces wyglądałby mniej więcej tak:

  1. Dane szyfrowane są Kluczem1 wygenerowanym z Hasła1.
  2. Zaszyfrowane dane zostają wysłane na serwer.
  3. Użytkownik zapomina hasła do konta Google i tworzy nowe hasło – Hasło2.
  4. Użytkownik postanawia ściągnąć backup, więc musi go rozszyfrować. Hasłem, którym uwierzytelnia się do usługi Google jest teraz Hasło2  i z niego generuje Klucz2.
  5. Dane zaszyfrowane Kluczem1 nie mogą zostać rozszyfrowane, gdyż teraz posiadamy jedynie Klucz2. Klucza1 nie możemy odzyskać, bo zmieniliśmy telefon i nie możemy go wygenerować, ze względu na zmianę Hasła, z którego Klucz jest tworzony.

Ciągle jednak pozostaje jeszcze problem użyteczności, gdyż użytkownik będzie musiał zapamiętać dodatkowe hasło (potrzebne do szyfrowania danych).

Ładne podsumowanie wystosował Paul Ducklin na blogu nakedsecurity:

Czy jesteś przygotowany na zatrzaśnięcie kluczy w swoim samochodzie na zawsze, czy może wolisz mieć tylne wejście, lecz dostępne także dla innych osób?

Zdjęcie: eleZeta

Jak oceniasz artykuł?

1 Star2 Stars3 Stars4 Stars5 Stars (1 ocena, średnio: 5,00 na 5)
Loading...

brak komentarzy
Dodaj swoją opinie

Kompetencje

Certyfikat Cisco Certified Network Associate (CCNA) Routing and Switching

Polecamy

VirtualStudy.pl - technologia w zasięgu Internetu

Zasubskrybuj Newsletter

Wyrażam zgodę na otrzymywanie informacji handlowych za pomocą środków komunikacji elektronicznej (zgodnie z Ustawą z dnia 18 lipca 2002 r. o świadczeniu usług drogą elektroniczną - Dz. U. Nr 144 poz. 1204.).

autoresponder system powered by FreshMail
 
Przeczytaj poprzedni wpis:
Zbiory danych osobowych. Czyli o rejestracji i konsekwencjach jej braku

Dwa miliony przedsiębiorstw funkcjonuje w naszym kraju, a zdecydowana większość posiada zbiory danych osobowych podlegające rejestracji. Jednak tylko 100 tysięcy...

Zamknij