Хостинг с нулевым знанием? [закрыто]

В свете недавних откровений о широкомасштабном государственном мониторинге данных, хранимых провайдерами онлайн-услуг, услуги с нулевым знанием сейчас в моде.

Служба с нулевым знанием - это служба, в которой все данные хранятся в зашифрованном виде с ключом, который не хранится на сервере. Шифрование и дешифрование происходит полностью на стороне клиента, и сервер никогда не видит ни текстовых данных, ни ключа. В результате поставщик услуг не может расшифровать и предоставить данные третьей стороне, даже если он этого хочет.

Для примера: SpiderOak можно рассматривать как версию Dropbox с нулевым уровнем знаний.

Как программисты, мы в значительной степени полагаемся и доверяем некоторые из наших наиболее важных данных - наш код - определенному классу поставщиков онлайн-услуг: поставщикам хостинга кода (таким как Bitbucket, Assembla и т. Д.). Я, конечно, говорю здесь о частных репозиториях - концепция нулевого знания не имеет смысла для публичных репозиториев.

Мои вопросы:

1. Существуют ли какие-либо технологические барьеры для создания услуги хостинга кода с нулевым знанием? Например, есть ли что-то в сетевых протоколах, используемых в популярных системах контроля версий, таких как SVN, Mercurial или Git, которые затрудняют (или делают невозможным) реализацию схемы, в которой данные, передаваемые между клиентом и сервером, шифруются с помощью ключ сервер не знает?

2. Существуют ли сегодня какие-либо услуги хостинга с нулевым знанием?

Вы можете зашифровать каждую строку отдельно. Если вы можете позволить себе указывать имена файлов и приблизительные длины строк и номера строк, в которых происходят изменения строк, вы можете использовать что-то вроде этого:

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

Поскольку каждая строка шифруется отдельно (но с одним и тем же ключом), загруженные изменения (как обычно) будут включать только соответствующие строки.

Если это в настоящее время недостаточно удобно, вы можете создать два репозитория Git, один с открытым текстом и один с зашифрованным текстом. Когда вы фиксируете в репозитории открытого текста (который является локальным), ловушка фиксации может взять diff и запустить его через строковый шифратор, упомянутый выше, который применил бы его к репозиторию зашифрованного текста. Изменения в хранилище зашифрованного текста будут зафиксированы и загружены.

Вышеупомянутый линейный шифратор не зависит от SCM, но может читать унифицированные файлы различий (открытого текста), шифровать изменения и применять их к зашифрованному тексту. Это делает его пригодным для использования на любом SCM, который сгенерирует вам унифицированный diff (например, Git).

Я не думаю, что есть какие-то барьеры - рассмотрим SVN, то, что отправляется на сервер для хранения, является разницей между предыдущей и текущей версиями вашего кода - поэтому вы меняете 1 строку, только эта строка отправляется на сервер. Затем сервер «вслепую» сохраняет его без какой-либо проверки самих данных. Если вы зашифруете дельту и отправите ее вместо этого, это не окажет влияния на сервер, фактически вам даже не потребуется изменять сервер вообще.

Существуют и другие биты, которые могут иметь значение, такие как свойства метаданных, которые нелегко зашифровать - например, mime-тип - но другие могут быть зашифрованы, например, комментарии в журнале истории, если вы знаете, что их нужно дешифровать на клиент для просмотра. Я не уверен, что структура каталогов будет видна, я думаю, что она не будет видна из-за того, как SVN хранит каталоги, но возможно, я ошибаюсь. Это может не иметь значения для вас, если содержание в безопасности, однако.

Это означало бы, что у вас не может быть веб-сайта с различными функциями просмотра кода, без обозревателя хранилища на стороне сервера или средства просмотра журналов. Нет различий в кодах, нет онлайн-инструментов для проверки кода

Нечто подобное уже существует, в какой-то момент Mozy хранит ваши данные в зашифрованном виде с помощью вашего закрытого ключа (вы можете использовать их собственные, и они шутят о том, «если вы потеряете свой собственный ключ, слишком плохо, мы не можем восстановить ваши данные для вы ", но это больше нацелено на обычного пользователя). Mozy также хранит историю ваших файлов, так что вы можете получить предыдущие версии. Ситуация сводится к тому, что загрузка происходит регулярно, а не возвращается, когда вы хотите, и я считаю, что она удаляет старые версии, когда у вас заканчивается свободное место. Но концепция существует, они могут изменить ее, чтобы обеспечить безопасный контроль над источниками, используя свою существующую систему.

Я ненавижу делать один из тех ответов "это не совсем ответит на ваш вопрос" .. но ..

Я могу придумать два готовых решения, которые должны решить эти проблемы.

1. Разместите собственный Git-сервер самостоятельно. Затем поместите этот сервер в VPN, к которому вы предоставляете доступ членам вашей команды. Вся связь с сервером будет зашифрована, и вы, конечно, сможете зашифровать сервер на уровне ОС.

2. BitSync должен сделать то же самое. Все будет зашифровано, и в огромной сети, которая будет доступна из любой точки мира. Может быть действительно хорошим приложением всей этой технологии BitCoin / BitMessage / BitSync.

Наконец, ребята по адресу /security// могут иметь более глубокое понимание.

Насколько я понимаю, способ git pullработает так, что сервер отправляет вам файл пакета, который содержит все объекты, которые вы хотите, но не имеете в настоящее время. И наоборот для git push.

Я думаю, что вы не можете сделать это напрямую (потому что это означает, что сервер должен понимать объекты). Вместо этого вы можете позволить серверу работать только с серией зашифрованных файлов пакетов.

Для этого pullвы скачиваете все файлы пакета, которые были добавлены с момента вашего последнего использования pull, расшифровываете их и применяете к своему git-репо. Чтобы сделать push, вы должны сначала сделать pull, чтобы вы знали состояние сервера. Если нет конфликтов, вы создаете файл пакета со своими изменениями, шифруете его и загружаете его.

При таком подходе вы получите большое количество крошечных упаковочных файлов, что будет весьма неэффективно. Чтобы это исправить, вы можете загрузить серию файлов пакета, расшифровать, объединить их в один файл пакета, зашифровать и загрузить их на сервер, пометив их как замену этой серии.