Hosting kodu bez wiedzy? [Zamknięte]

28

W świetle ostatnich doniesień na temat szeroko zakrojonego rządowego monitorowania danych przechowywanych przez dostawców usług online, usługi o zerowej wiedzy są teraz modne.

Usługa zerowej wiedzy to usługa, w której wszystkie dane są przechowywane w postaci zaszyfrowanej kluczem, który nie jest przechowywany na serwerze. Szyfrowanie i deszyfrowanie odbywa się całkowicie po stronie klienta, a serwer nigdy nie widzi danych w postaci zwykłego tekstu ani klucza. W rezultacie dostawca usług nie jest w stanie odszyfrować i przekazać danych stronie trzeciej, nawet jeśli tego chce.

Na przykład: SpiderOak może być postrzegany jako wersja Dropbox o zerowej wiedzy.

Jako programiści polegamy w dużym stopniu i ufamy niektórym z naszych najbardziej wrażliwych danych - naszemu kodowi - konkretnej klasie dostawców usług online: dostawcom hostingu kodów (takim jak Bitbucket, Assembla i tak dalej). Mówię tu oczywiście o prywatnych repozytoriach - koncepcja zerowej wiedzy nie ma sensu w przypadku repozytoriów publicznych.

Moje pytania to:

  1. Czy istnieją jakieś bariery technologiczne w tworzeniu usługi hostingu kodu o zerowej wiedzy? Na przykład, czy jest coś w protokołach sieciowych używanych przez popularne systemy kontroli wersji, takie jak SVN, Mercurial lub Git, które utrudniłyby (lub uniemożliwiłyby) wdrożenie schematu, w którym dane przesyłane między klientem a serwerem są szyfrowane za pomocą klucz, którego serwer nie zna?

  2. Czy istnieją obecnie jakieś usługi hostingu kodu o zerowej wiedzy?

HC4 - przywróć Monikę
źródło
1
Bez homomorficznego szyfrowania nie widzę, w jaki sposób witryna hostująca kod o zerowej wiedzy mogłaby zapewnić jakąkolwiek korzyść w porównaniu z wersją drop-box o zerowej wiedzy. Nie sądzę, aby ktokolwiek wymyślił taki program, który jest zarówno bezpieczny (tj. Wystarczająco bezpieczny, aby eksperci mu ufali), jak i wystarczająco szybki, aby był użyteczny.
Brian
2
@AndresF. Mogę tylko założyć, że SpiderOak oznacza, że ​​generowanie różnic występuje na kliencie, serwer przechowuje zaszyfrowane pliki różnic, a następnie aplikacja typu różnicowanie do bazy pojawia się ponownie na kliencie, gdy pliki różnic i baza są szyfrowane. Zgadzam się, że ich język jest bardzo niejasny.
apsillers
2
@apsillers: Lub możesz celowo upchnąć taką zawartość do pliku i użyć go do zidentyfikowania samego pliku (np. jeśli ktoś próbował użyć szyfrowania w celu ukrycia piractwa).
Brian
4
To nie jest coś, w czym mam doświadczenie, ale mogę sobie wyobrazić jedną możliwą barierę technologiczną dla posiadania usługi hostingu kodu o zerowej wiedzy: czy wszyscy użytkownicy nie muszą znać / używać dokładnie tego samego klucza? A jeśli tak, to jaki będzie mechanizm uwierzytelniania zapewniający różne poziomy dostępu użytkowników?
CB
2
@gnat: Nie proszę o rekomendację. Pytam tylko, czy istnieje usługa tego rodzaju, którą opisałem. Istnienie takiej usługi stanowiłoby dowód na to, że bariery technologiczne, o które pytam wcześniej w pytaniu, są do pokonania.
HC4

Odpowiedzi:

3

Możesz zaszyfrować każdą linię osobno. Jeśli możesz sobie pozwolić na wyciek nazw plików i przybliżonych długości linii oraz numerów linii, na których występują zmiany linii, możesz użyć czegoś takiego:

https://github.com/ysangkok/line-encryptor

Ponieważ każda linia jest szyfrowana osobno (ale z tym samym kluczem), przesłane zmiany będą (jak zwykle) dotyczyły tylko odpowiednich linii.

Jeśli obecnie nie jest to wystarczająco wygodne, możesz utworzyć dwa repozytoria Git, jedno z tekstem jawnym i jedno z tekstem zaszyfrowanym. Podczas zatwierdzania w repozytorium tekstu jawnego (który jest lokalny), hook zatwierdzenia może pobrać różnicę i uruchomić go przez szyfrator linii wymieniony powyżej, który zastosuje go do repozytorium tekstu zaszyfrowanego. Zmiany w repozytorium tekstu zaszyfrowanego zostaną zatwierdzone i przesłane.

Powyższy koder linii jest niezależny od SCM, ale może odczytywać zunifikowane pliki różnic (tekstu jawnego) oraz szyfrować zmiany i stosować je do tekstu zaszyfrowanego. To sprawia, że ​​można go używać na dowolnym SCM, który wygeneruje zunifikowany plik różnicowy (np. Git).

Janus Troelsen
źródło
Czy nie możesz w tym celu użyć programu Git do usuwania rozmazywania ?
svick,
@svick: Mógłbyś, ale w ten sposób nie rozumiem, w jaki sposób pozwoliłbyś uniknąć ponownego szyfrowania całego pliku. Ale oczywiście nie ma to większego znaczenia dla kodu, ponieważ rozmiary plików są małe. Ale nie ma potrzeby korzystania z „szyfratora liniowego”, możesz po prostu użyć dowolnego narzędzia szyfrującego.
Janus Troelsen,
Czy wiele próbek tekstu (o znanej strukturze) nie byłoby czymś, co ułatwiłoby atak na klucz? Każda pusta linia szyfrowałaby to samo. Każdy początek i koniec javadoc byłby taki sam. Teraz znasz czysty tekst i tekst zaszyfrowany dla pewnego segmentu kodu, którego można użyć. Prawdopodobnie nie przydałoby się to nikomu oprócz hobbystów (każdy z wyszkolonymi typami kryptograficznymi lub wystarczającą mocą obliczeniową mógłby złamać to przy wystarczającym wysiłku).
@MichaelT: Nie, z powodu IV. Wypróbuj sam :) Za pomocą połączonej implementacji linie szyfrują się do <IV>,<ciphertext>.
Janus Troelsen,
1
@svick: Linie są szyfrowane indywidualnie. Jeśli zmienisz linię, cała linia zostanie ponownie zaszyfrowana, ale z nową IV (jak zawsze). Ale reszta pliku nie zostanie zmieniona! Szyfrowanie jest deterministyczne, ale IV również są danymi wejściowymi i są wybierane pseudolosowo.
Janus Troelsen
1

Nie sądzę, aby istniały jakiekolwiek bariery - rozważ SVN, a to, co jest wysyłane do serwera w celu przechowywania, to różnica między tym, co poprzednia i obecna wersja twojego kodu - więc zmieniasz 1 linię, tylko ta linia jest wysyłana do serwera. Serwer następnie „ślepo” przechowuje go, nie przeprowadzając żadnej kontroli samych danych. Jeśli zaszyfrowałeś deltę i wysłałeś ją zamiast tego, nie miałoby to wpływu na serwer, w rzeczywistości nawet nie musiałbyś w ogóle modyfikować serwera.

Istnieją inne bity, które mogą mieć znaczenie, takie jak właściwości metadanych, które nie są łatwe do zaszyfrowania - takie jak typ MIME - ale inne mogą zostać zaszyfrowane, np. Komentarze w dzienniku historii, o ile wiesz, że musisz je odszyfrować w klient do wyświetlenia. Nie jestem pewien, czy struktura katalogów byłaby widoczna, myślę, że nie byłaby widoczna ze względu na sposób, w jaki SVN przechowuje katalogi, ale możliwe, że się mylę. Może to jednak nie mieć znaczenia, jeśli zawartość jest bezpieczna.

Oznaczałoby to, że nie możesz mieć strony internetowej z różnymi funkcjami widoku kodu, bez przeglądarki repozytorium po stronie serwera ani przeglądarki dziennika. Bez różnic w kodzie, bez narzędzi do przeglądania kodu online.

Coś takiego już istnieje, do tego stopnia, że ​​Mozy przechowuje twoje dane zaszyfrowane twoim kluczem prywatnym (możesz użyć ich własnego, a oni wydają odgłosy na temat „jeśli zgubisz swój klucz, szkoda, nie możemy przywrócić twoich danych dla Ty ”, ale jest to bardziej ukierunkowane na zwykłego użytkownika). Mozy przechowuje również historię twoich plików, dzięki czemu możesz odzyskać poprzednie wersje. Problem polega na tym, że przesyłanie odbywa się regularnie, a nie melduje się, kiedy chcesz, i uważam, że odrzuca stare wersje, gdy zabraknie miejsca. Ale koncepcja już istnieje, mogliby ją zmodyfikować, aby zapewnić bezpieczną kontrolę źródła przy użyciu istniejącego systemu.

gbjbaanb
źródło
Re: „Oznaczałoby to, że nie możesz mieć strony internetowej z różnymi funkcjami widoku kodu, bez przeglądarki repozytorium po stronie serwera lub przeglądarki dziennika. Brak różnic w kodzie, brak narzędzi do przeglądania kodu online”. - Mógłbyś je mieć, gdyby logika aplikacji była w JS po stronie klienta i wymagała wpisania twojego hasła / klucza (ale nie wysłania go na serwer), prawda?
HC4
Tak, mógł… Wszystko by się działo, o ile wiedziałoby, że odbiera zaszyfrowane dane przez sieć. To oczywiste ograniczenie serwera, że ​​nie może on odszyfrować danych.
gbjbaanb
1

Nienawidzę robić jednej z tych odpowiedzi „to nie do końca odpowie na twoje pytanie”, ale…

Mogę wymyślić dwa gotowe rozwiązania, które powinny rozwiązać te obawy.

  1. Hostuj prywatny serwer Git na własną rękę. Następnie umieść ten serwer w sieci VPN, do której dajesz członkom swojego zespołu dostęp. Cała komunikacja do i z serwera byłaby szyfrowana i oczywiście można zaszyfrować serwer na poziomie systemu operacyjnego.

  2. BitSync również powinien załatwić sprawę. Wszystko byłoby zaszyfrowane w ogromnej sieci, która byłaby dostępna z dowolnego miejsca. To może być naprawdę dobre zastosowanie całej tej technologii BitCoin / BitMessage / BitSync.

Wreszcie, ludzie z https://security.stackexchange.com/ mogą mieć trochę więcej wglądu.

Gumowa kaczuszka
źródło
Odnośnie BitSync: czy sugerujesz, aby używać go jako zamiennika systemu kontroli wersji, czy w jakiś sposób używać razem z systemem kontroli wersji? Jeśli to pierwsze, to na pewno, ale to nie jest bardzo interesujące. Równie dobrze mógłbym udostępniać pliki za pomocą SpiderOak i byłby scentralizowany, ale wciąż nie miałby wiedzy. Jeśli to drugie, to jak?
HC4 - przywrócenie Moniki
1
@ HighCommander4 Nie próbowałem tego, ale nie powinno być żadnego powodu, aby nie działał. Czy nie możesz skonfigurować synchronizacji, aby udostępnić zainicjowany folder git, a następnie po prostu zrobić normalny 'git push ./syncedFolderActingAsServer/MyAwesomeProject/src/'? Możesz także zrobić uprawnienia na poziomie git itp. Ktoś powinien spróbować!
Rubber Duck,
1

Jak rozumiem, sposób git pulldziałania polega na tym, że serwer wysyła ci plik paczki, który zawiera wszystkie obiekty, które chcesz, ale których obecnie nie ma. I odwrotnie dla git push.

Myślę, że nie można tego zrobić bezpośrednio (ponieważ oznacza to, że serwer musi zrozumieć obiekty). Zamiast tego możesz pozwolić serwerowi pracować tylko z serią zaszyfrowanych plików paczek.

Aby to zrobić pull, pobierasz wszystkie pliki paczek, które zostały dodane od czasu ostatniej pull, odszyfrowujesz je i stosuje się do repozytorium git. Aby to zrobić push, najpierw musisz to zrobić pull, aby poznać stan serwera. Jeśli nie ma konfliktów, tworzysz plik paczki ze swoimi zmianami, szyfrujesz go i ładujesz.

Dzięki takiemu podejściu uzyskałbyś dużą liczbę małych plików paczek, co byłoby dość nieefektywne. Aby to naprawić, możesz pobrać serię plików paczek, odszyfrować, połączyć je w jeden plik paczki, zaszyfrować i przesłać je na serwer, oznaczając je jako zamienniki tej serii.

svick
źródło