Hosting kodu bez wiedzy? [Zamknięte]

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?

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).

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.

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.

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.