dodany: 25.01.2013 | tagi: , ,

Autor:

Serwis Mega nie szyfruje Twoich danych?

1

Przez ostatnie dni sporo było wiadomości o nowym tworze Kima Dotcoma – Mega (zobacz newsa: MEGA-problem nowego serwisu Kima Dotcoma). Jest to kolejny serwis cloud, którego twórca zapewnia o jego bezpieczeństwie, ale czy możemy mu zaufać?

Usługa posiada dokumentację, której kilka stron zadedykowano programistom – poświęcono je wytłumaczeniu jak działa API. Zawiera ona także kilka szczegółów o tym, gdzie i jakich metod szyfrowania używa serwis. Niektóre z zagadnień nie są tak proste (albo tak bezpieczne), jak się może wydawać na pierwszy rzut oka.

 

Block object storage

W dokumentacji Mega użyto określenia „hierarchical file/folder paradigm”, co jest wymyślnym sposobem powiedzenia, że dane są przechowywane w postaci plików i folderów tak samo, jak na lokalnym dysku. Każdy plik oraz folder posiada identyfikator nazywany node (analogia do inode z systemów plików w Uniksach) i każdy node posiada swojego rodzica. W ten sposób paradygmat pliku/folderu jest spełniony, nawet jeśli wszystkie usługi Mega widzą same zaszyfrowane bloki. Każde konto posiada trzy kontenery, które nie mają node-rodzica – jeden to podstawowy katalog na pliki, drugi to inbox i ostatni to kosz.

Każdy node zawiera blok z atrybutami – nazwa pliku/folderu danych przypisanych do node – i bloki z danymi. W dokumentacji zaznaczono, że w przyszłości w pierwszym bloku może być przechowywanych więcej informacjitakich jak wiadomości między użytkownikami. Oba rodzaje bloków są szyfrowane za pomocą AES-128 (każdy osobno).

 

Szyfrowanie

Wszystkie operacje kryptograficzne bazują na AES-128. Szyfrowanie wykonywane jest w trybie wiązania bloków zaszyfrowanych (z ang. CBC – cipher block chaining mode) dla plików i folderów (blok atrybutów) oraz w trybie licznikowym (z ang. CTR – counter mode) dla danych samych w sobie. Każdy plik i folder używa swojego, losowo generowanego 128 bitowego klucza. Pliki używają tych samych kluczy dla danych i atrybutów oraz dodatkowo 64 bitowej losowej wartości początkowej licznika, a do weryfikacji spójności 64 bitowych danych MAC.

Pliki i foldery są zaszyfrowane symetrycznie – oznacza to, że ten sam klucz jest używany do szyfrowania i deszyfrowania danych. Jest to sposób wymagający mniejszej mocy obliczeniowej i łatwiejszy w implementacji niż szyfrowanie asymetryczne – którego Mega ma zacząć używać za jakiś czas.

AES-128 jest dobrze znanym i szeroko używanym szyfrem blokowym (z ang. block cipher). Działa poprzez transformację kawałków danych w oparciu o klucz szyfrujący. Robi to kilkunastokrotnie (w zależności od wielkości klucza – w przypadku 128 bitowego: 10 razy). Aby odszyfrować, ten sam proces jest wykonywany w odwrotnej kolejności, używając tego samego klucza. W Mega klucz szyfrujący jest generowany dla Ciebie podczas rejestracji i jest dodatkowo zaszyfrowany przy użyciu Twojego hasła.

Zanim przejdziemy dalej, zatrzymajmy się przy możliwych wnioskach. Klucz używany do szyfrowania plików i folderów w Mega jest przechowywany na ich serwerach, a nie na Twoim komputerze. Wygląda też na to, że nigdzie nie ma mechanizmu przywracania hasła na stronie logowania czy też możliwości zmiany hasła w panelu użytkownika. Ponieważ główny klucz AES-128 jest zaszyfrowany Twoim hasłem – warto je zapamiętać. Zgubienie bądź zapomnienie hasła oznacza, że nie będziesz mieć możliwości logowania w serwisie – tracisz możliwość deszyfrowania Twoich plików!

 

Poking holes

Z pozoru wszystko wygląda całkiem bezpiecznie – dane są szyfrowane za pomocą AES-128, jest osobna metoda szyfrowania wiadomości między użytkownikami. Jednak tutaj wszystko zaczyna się psuć…

Największym problemem metod Mega jest niewystarczająca ilość entropii zebranej przy generacji pary kluczy RSA. Klucze szyfrowania muszą być trudne do odgadnięcia i z reguły tworzy się je losowo poprzez odpowiedni algorytm. Komputery notorycznie są pseudolosowe i te wygenerowane przez nie „losowe” liczby, np. przez /dev/random, muszą być wspomagane przez czynnik zwany entropią. Jest to „prawdziwa” losowość zdobywana przez komputer z różnych źródeł – wciśnięcia klawiszy, ruchów myszką, dźwięków odbieranych z mikrofonu i tak dalej. Niektóre nowoczesne procesory zawierają nawet „prawdziwe generatory liczb losowych”, które jako entropii używają wibracji na poziomie atomowym w CPU.

Zasada jest prosta – im większa entropia – tym bardziej losowy klucz, a więc będzie on możliwie „niezgadywalny”. Jeżeli generujesz parę kluczy RSA w linii poleceń używając narzędzia jak openssl – masz wszystko podane na tacy, narzędzie się martwi entropią za Ciebie. Niestety dla Mega klucz RSA generowany jest za pomocą Javascript i odpowiednie ilości entropii nie zostają zbierane. Nadim Kobeissi, twórca Cryptocat, całkiem dużo tweetował na ten temat w sobotę (19 stycznia). Zaznaczył, że Mega używa math.random, jako podstawy generowania losowych liczb. Dodatkowo na wzmocnienie – pobiera trochę danych z klawiatury i myszki. Jednak wiadomość podczas generowania klucza jest myląca:

 

Zaznaczenie_002

Aby wzmocnić klucz zebraliśmy entropię z ruchów Twojej myszki i naciśnięć klawiatury.

 

Powinniśmy ruszać teraz myszką czy już jest po wszystkim? Bez dodatkowej entropii „losowe” liczby pierwsze podane przez math.random do użycia, jako klucze RSA są tylko pseudolosowe i mogą zostać odgadnięte. Koniec końców jest łatwiej niż być powinno (nie łatwo, a łatwiej) poprzez inżynierię wsteczną (z ang. reverse-engineering) poznać prywatny klucz RSA użytkownika Mega. To znaczy, że łatwiej jest poznać tożsamość użytkownika podczas wysyłania wiadomości lub plików.

 

Deduplikacja

Warto zwrócić uwagę na jeszcze jedną, niebezpieczną sprawę. Regulamin usługi zawiera następujący punkt:

Nasza usługa może automatycznie skasować część danych, którą wgrywasz (upload) albo dać komuś innemu dostęp do danych, które są dokładną kopią oryginalnych danych już dostępnych w naszej usłudze. W tym przypadku – dostaniesz dostęp do oryginalnych danych.

Brzmi to jak deduplikacja – przechowywanie każdego unikatowego kawałka danych tylko jeden raz na dysku w celu zaoszczędzenia miejsca. Wykorzystanie szyfrowania AES-128 dla bloków z danymi powinno zapewnić, że każdy zaszyfrowany blok jest inny, nawet jeśli są to te same pliki. Jeśli Mega widzi tylko zaszyfrowane dane, które z definicji są całkowicie unikatowe, w jaki sposób chce je „deduplikować”? Czy coś tu dzieje się nie tak?

Na Hacker News powstało wiele teorii, będących próbą wyjaśnienia, w jaki sposób może działać Mega – np. poprzez używanie szyfrowania zbieżnego (z ang. convergent encryption) do rozpoznawania nieunikatowych bloków. Jakikolwiek sposób by to nie był – faktem jest, że deduplikacja jest używana i pozostaje ona przeciwko postawie „see no evil” przybranej przez Mega. Globalna metoda rozpoznawania specyficznych danych niekoniecznie musi coś znaczyć. W pewien sposób obciąża to Mega – może właściciele serwisu nie mogą powiedzieć, co użytkownicy Jan czy Jaś mają na swoich kontach, jednak istnieje możliwość powiedzenia czy Jan i Jaś mają ten sam plik. Jeśli np. MPAA (z ang. Motion Picture Association of America) dowie się, że Jan ma ich film „Hobbit: Niespodziewanie długi film” i przypadkiem Jaś też go posiada – udowodnienie użytkownikom np. korzystania z nielegalnej kopii pozostaje banalnie prostym przedsięwzięciem.

 

Czym to grozi?

Wygląda na to, że wiele problemów z implementacją kryptografii w usługach Mega wynika z chęci zrobienia serwisu najlżejszego jak się da, wymagającego tylko przeglądarki obsługującej Javascript (Chrome jest preferowane, przynajmniej tak piszą na stronie). Z jednej strony oznacza to, że żadna zewnętrzna aplikacja „klient” nie jest wymagana i przeglądarka sama w sobie pełni funkcję platformy – to ułatwia testowanie i wdrażanie nowych funkcjonalności do usługi, począwszy od aktualizacji plików Javascript). Dodatkowo nie ma problemów z kompatybilnością między platformami – wszystko działa na każdym komputerze i (prawie) każdej przeglądarce. Z drugiej strony – dokumentacja i implementacja posiada niemałą liczbę słabości i potencjalnych exploitów. Generator pary kluczy RSA powinien byś ulepszony oraz powinna istnieć jakaś możliwość kopii i zmiany klucza szyfrowania.

Fakt, że zaszyfrowane dane nie są całkowitą tajemnicą dla Mega, jest największym problemem. Z jednej strony – stosowanie deduplikacji danych na poziomie bloków jest oczywiste – przestrzeń dyskowa jest tania, ale nie aż tak. Do tego zamiast trzymać tysiące kopii „Hobbita” – przechowywana będzie tylko jedna, zwalniając tym samym terabajty miejsca (ze względu na brak wiedzy o skali i zasięgu deduplikacji wyliczenia te mogą być optymistyczne). Z drugiej strony – nawet jeśli Mega nie wie, że te bloki danych to akurat „Hobbit”, Mega wciąż ma wiedzę, do kogo one należą.

Mathias Ortman, CTO Mega, podczas konferencji startowej powiedział:

Szyfrowanie jest open source. Spodziewamy się, że społeczność od bezpieczeństwa dokładnie spojrzy i skomentuje możliwe słabości.

avatar
WebSecurity.pl to największy w Polsce portal o bezpieczeństwie sieciowym.
WebSecurity.pl to codziennie aktualizowane źródło najnowszych informacji i interesujących artykułów z zakresu bezpieczeństwa IT. Na WebSecurity.pl dzielimy się z Wami wiedzą (know-how) i umiejętnościami (how-to), publikując pomocne wskazówki, porady, kursy i tutoriale. Na portalu znajdziecie także prezentacje sprzętu oraz recenzje oprogramowania. WebSecurity.pl to również baza najciekawszych i najważniejszych wydarzeń branżowych w Polsce i na świecie.

Jedna odpowiedź do “Serwis Mega nie szyfruje Twoich danych?”

  1. avatar Sources napisał(a):

    Now i am now not guaranteed what your location is having your information, nevertheless terrific subject. My spouse and i should invest some time mastering additional as well as understanding extra. Many thanks for outstanding data I used to be on the lookout for this data for my objective. Now i am now not guaranteed what your location is having your information, nevertheless terrific subject. My spouse and i should invest some time mastering additional as well as understanding extra. Many thanks for outstanding data I used to be on the lookout for this data for my objective.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *