[Chmura] Deduplikacja a Wuala
Na początku bieżącego roku (lub jeszcze w poprzednim) na blogu DP pojawił się wpis poddający w wątpliwość bezpieczeństwo plików przechowywanych w chmurze Wuala - a jest to usługa, która z założenia jest bezpieczna, bo pliki opuszczają komputer właściciela w postaci zaszyfrowanej jego hasłem. Sprawa mnie zaintrygowała. W wolnej chwili zacząłem dociekać co i jak z tym bezpieczeństwem w Wuala. Poniżej rezultaty.
Deduplikacja
Na wstępie definicja, na wszelki wypadek: funkcją skrótu nazywamy funkcję, która dowolnie dużemu plikowi przyporządkowuje, na podstawie jego zawartości, relatywnie krótki ciąg znaków (długość jest taka sama dla wszystkich plików). W idealnym przypadku każde dwa pliki mają różne skróty, jak również dwa podobne pliki mają zupełnie niepodobne skróty. Ze skrótu nie można (łatwo) odtworzyć skracanego pliku. Znany, niedoskonały przykład to sumy MD5. Lepszy przykład to SHA‑3.
Deduplikacja jest metodą oszczędzania miejsca na serwerach usługodawców chmurowych.
A z chmurami to jest różnie z bezpieczeństwem. Są chmury, które nie są bezpieczne z założenia - są to prawie wszystkie tego typu usługi. Bezpieczne jest albo tylko połączenie, czyli osoba trzecia plików nie podejrzy, ale usługodawca już może do nich zajrzeć, albo bezpieczne nie jest nawet połączenie, co twórcy Wuala porównują do nadania pocztówki - każdy może przeczytać. Pliki na serwerach mogą (powinny) leżeć na szyfrowanych dyskach, aby w razie fizycznej kradzieży dysku dane były bezpieczne, ale w gruncie rzeczy, niewiele to zmienia. Mogą też leżeć w postaci zaszyfrowanej, ale kluczem znanym usługodawcy - to też wiele nie zmienia. Co prawda gdy osoba trzecia nie zna klucza, to treści pliku nie pozna, ale usługodawca dalej może pliki podglądać. I pokazywać np. amerykańskiej NSA.
W chmurze niezabezpieczonej deduplikacja działa jak następuje: użytkownik A chce wysłać plik "b.cde" na pusty serwer. Przed wysłaniem tego pliku, program-klient chmury oblicza skrót tegoż pliku - powiedzmy, że skrótem tym jest "w45cf6". Skrót ten jest wysyłany do chmury i porównywany z bazą danych o już przesłanych plikach - bazą pustą, bo tak założyliśmy. Klient wysyła plik "b.cde" do chmury, a w bazie danych pojawia się wpis (pierwszy) o treści typu:
id właściciel nazwa_pliku skrót_pliku ścieżka_pliku 1 A b.cde w45cf6 /chmura/00000001
Niech teraz użytkownik F zechce wysłać dwa pliki na serwer. Pierwszy z nich - "g.hij" - będzie nowym plikiem, a drugi z nich - "k.lmn" - będzie tym samym, co wysłany przez użytkownika A (nazwa inna, zawartość ta sama). Klient liczy skróty. Dla "g.hij" skrótem niech będzie "876trd", a dla "k.lmn" znane nam już "w45cf6". Klient wysyła pierwszy skrót do bazy danych. Baza danych nie zna tego skrótu. Plik "g.hij" zostaje wysłany na serwer, a baza danych wygląda teraz tak:
id właściciel nazwa_pliku skrót_pliku ścieżka_pliku 1 A b.cde w45cf6 /chmura/00000001 2 F g.hij 876trd /chmura/00000002
Klient wysyła teraz skrót ostatniego pliku, czyli "w45cf6" dla "k.lmn". Baza danych stwierdza, że taki skrót już zna. Plik "k.lmn" nie zostaje wysłany na serwer, ale zawartość bazy danych się zmienia, o tak:
id właściciel nazwa_pliku skrót_pliku ścieżka_pliku 1 A b.cde w45cf6 /chmura/00000001 2 F g.hij 876trd /chmura/00000002 3 F k.lmn w45cf6 /chmura/00000001
Czyli użytkownicy A i F mają w sumie trzy pliki, w bazie danych są dla nich trzy wpisy, ale na serwerze leżą dwa pliki, bo jeden z tamtych trzech się powtarza, czyli jest zduplikowany. Chmura zapobiegła trzymaniu dwa razy tego samego pliku, czyli nastąpiła deduplikacja.
Wyobraźmy sobie teraz, że ktoś wypuszcza do sieci plik ze spiraconym filmem. Plik taki swoje waży. Powiedzmy, że 4 GB. Do chmury chce go wrzucić nie dwóch, a stu użytkowników. Dzięki deduplikacji serwer trzyma jedną jego kopię zamiast stu, czyli oszczędza 99*4 GB = 396 GB danych. A jeszcze do tego wypadałoby mieć kopie zapasowe tego, co użytkownicy w chmurze trzymają. Czyli np. drugi serwer z tą samą zawartością. A więc oszczędność to już 2*396 GB = 792 GB. 792 GB oszczędności na jednym pliku 4 GB. Jest się o co bić. A to, że liczby są z sufitu, nic nie zmienia.
Kontynuujmy opowieść. Plik był piracki, właściciel praw do filmu dowiedział się, że plik wisi w sieci. Pobrał go sobie i wysyła po kolei do wszystkich chmur. Przy każdym wysyłaniu sprawdza obciążenie swojego łącza - sprawdza, czy plik rzeczywiście wyszedł przez łącze, czy nie. Jeśli wyszedł, nikt tego pliku w tej chmurze jeszcze nie trzymał. Jeśli nie wyszedł, to znaczy, że deduplikacja zadziałała i ktoś w chmurze trzyma sobie ten spiracony plik. Właściciel dzwoni do właściciela chmury i... No, tu już może być różnie. Teoretycznie, właściciel praw do filmu, właściciel chmury i policja dobierają się do skóry pirata i musi on zapłacić karę, oraz jego konto w chmurze zostaje usunięte.
Jest jeszcze inny aspekt deduplikacji - ktoś może generować wszelkie pliki, jakie tylko mu do łba strzelą, i patrzeć, co robi deduplikacja. I w ten sposób poznać wszystkie pliki, jakie w danej chmurze istnieją. Nasuwają się tylko dwa pytania: 1. Po co? 2. Kiedy? Na pierwsze pytanie możemy odpowiedzieć: jak nie wiadomo o co chodzi, to wiadomo o co chodzi. Czyli można połasić się na zapisane jawnie hasła do kont bankowych itp. Na drugie pytanie odpowiedź brzmi: nie prędko. Jak myślicie, ile trwa wygenerowanie wszystkich plików o rozmiarze nie większym, niż ustalony, np. niż 1 MB? Wszystkich, tzn. wszystkich możliwych ciągów bitów. Bez wdawania się w dywagacje - dużo. I jeszcze trzeba by było to wszystko zweryfikować.
Także zagrożenie jest, ale raczej teoretyczne.
Bezpieczeństwo Wuala
We wspomnianym na początku wpisie jego autor twierdził (w skrócie), że skoro w Wuala jest deduplikacja, to pliki nie są tak na prawdę szyfrowane. Czy tak jest w istocie?
Sprawa bezpieczeństwa w Wuala (i paru innych podobnych usługach) jest długa, nudna i trudna. W skrócie więc: z nazwy i hasła użytkownika generowany jest klucz szyfrujący, którym są szyfrowane podstawowe informacje na temat naszego konta, w tym katalog główny i klucze szyfrujące jego plików i folderów w nim zawartych. I tak samo niżej. Wuala określa to mianem drzewa, ale ja bym powiedział, że robi się taki stosik: żeby otworzyć coś, co jest niżej, trzeba otworzyć coś, co jest wyżej. A na samym wierzchu jest katalog główny obłożony kluczem z hasła użytkownika. Wszystko więc jest "przygniecione" hasłem użytkownika. Kluczem z hasła otwieramy katalog główny, z niego wyjmujemy klucz do podfolderu, z niego wyjmujemy klucz do podfolderu podfolderu, z niego (...) wyjmujemy klucz do pliku. I każdy kolejny klucz Wuala przechowuje u siebie w postaci zaszyfrowanej, tak, jak pliki. "Gołe" hasło użytkownika nigdy nie opuszcza komputera użytkownika. Przechowywana jest jego zaszyfrowana postać, aby sprawdzić, czy przy kolejnym logowaniu użytkownik podał dobre hasło. To, co znajduje się na serwerach w chmurze, to są folderu użytkownika, pliki użytkownika, metadane nt. tych plików i folderów i klucze do tego całego bałaganu. Wszystko to (nawet klucze) jest zawsze zaszyfrowane jakimś kluczem - albo losowym, albo zrobionym z funkcji skrótu, albo wygenerowanym z hasła użytkownika - zależnie od poziomu.
Deduplikacja w Wuala
Pozornie wygląda ona jak w przypadku niezabezpieczonym. Klient wysyła skrót pliku do chmury z pytaniem czy chmura zna już ten plik. I chmura odpowiada czy zna, czy trzeba przesłać. Ale! Używamy dwóch funkcji skrótu. Chmurze pokazujemy skrót zrobiony pierwszą funkcją, ale wysyłamy plik zaszyfrowany kluczem, którym jest skrót z drugiej funkcji. Chmura (Wuala) zna zaszyfrowany plik i jego pierwszy skrót (do deduplikacji). Ale nie potrafi go odszyfrować. Do jego odszyfrowania potrzebny jest drugi skrót oryginalnego, niezaszyfrowanego pliku, a ten jest... wysyłany jako zaszyfrowany, wedle wcześniejszego opisu. Dla użytkowników A i F z wcześniejszego przykładu, plik jest ten sam, pierwszy skrót jest ten sam, plik zaszyfrowany drugim skrótem jest ten sam, drugi skrót jest ten sam, ale drugi skrót każdy z nich trzyma zaszyfrowany innym kluczem losowym (lub wygenerowanym z własnego hasła). I inne mogą być metadane. Innymi słowy, Wuala ma pierwszy klucz, "bezużyteczny", a obaj użytkownicy mają swoje egzemplarze drugiego klucza w swoich własnych sejfach. Każdy z nich może tego klucza użyć bez udziału drugiego z nich, a chmura nie może nic zrobić.
Tak więc pliki wysyłane do Wuala są szyfrowane i nikt poza właścicielem ich nie może otworzyć. Pojawia się tylko potencjalne zagrożenie ze strony deduplikacji: drugi właściciel takiego samego pliku. Ja się tego nie boję.
Udostępnianie
A co się dzieje, gdy właściciel pliku (a właściwie katalogu) chce go udostępnić? Klucz jest ujawniany osobom, z którymi katalog jest dzielony (dzielenie się w obrębie przyjaciół w Wuala) albo wszem i wobec (w przypadku dzielenia się przez podanie linku do pliku).
Kto nie czuje się jeszcze dość zamotany tymi kluczami, skrótami, szyfrowaniami i innymi cudami, może sobie poczytać poniższe mądre teksty, na których bazowałem. I zapraszam do skorzystania z mojego zaproszenia do Wuala.
- http://www.wuala.com/en/learn/technology
- http://www.wuala.com/blog/2011/04/wualas-encryption-for-dummies.html
- https://forum.wuala.com/viewtopic.php?f=11&t=7892
- http://dcg.ethz.ch/publications/srds06.pdf
- https://plus.google.com/116211747541130660089/posts/f7kUWiAMzxj
- http://thesimplecomputer.info/behind-the-curtain-of-encrypted-cloud-storage-page2/#wuala
