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

28

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

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

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

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

Мои вопросы:

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

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

version-control encryption project-hosting privacy HC4 - восстановить монику
источник
1
Без гомоморфного шифрования я не вижу, как сайт, размещающий код с нулевым знанием, мог бы дать какую-либо выгоду по сравнению с версией с нулевым знанием. Я не верю, что кто-то еще придумал такую ​​схему, которая является одновременно безопасной (то есть достаточно безопасной, чтобы эксперты ей доверяли) и достаточно быстрой, чтобы ее можно было использовать.
Брайан
2
@AndresF. Я могу только предположить, что SpiderOak означает, что diff-генерация происходит на клиенте, сервер сохраняет зашифрованные diff-файлы, и затем приложение diff-to-base снова появляется на клиенте, когда diff и base зашифрованы. Я согласен, что их язык очень неясен.
Апсиллеры
2
@apsillers: или вы можете сознательно поместить такой контент в файл и использовать его для идентификации самого файла (например, если кто-то пытается использовать шифрование, чтобы скрыть пиратство).
Брайан
4
У меня нет такого опыта, но я могу представить один возможный технологический барьер для службы хостинга кода с нулевым знанием: не нужно ли всем пользователям знать / использовать один и тот же ключ? И если это так, каким будет механизм аутентификации, обеспечивающий разные уровни доступа пользователей?
CB
2
@gnat: я не прошу рекомендации. Я просто спрашиваю, существует ли услуга того типа, который я описал. Существование такой службы может служить доказательством того, что технологические барьеры, о которых я спрашиваю ранее в этом вопросе, являются слишком сложными.
HC4 - восстановить Монику

Ответы:

3

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

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

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

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

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

Янус Троелсен
источник
Не могли бы вы использовать Git's smudge-clean для этого?
svick
@svick: Вы могли бы, но таким образом, я не понимаю, как бы вы позволили избежать повторного шифрования всего файла. Но, конечно, это не будет иметь большого значения для кода, так как размеры файлов невелики. Но тогда нет необходимости в «линейном шифраторе», вы можете просто использовать любой инструмент шифрования.
Янус Троелсен
Разве множество текстовых примеров (с известной структурой) не облегчили бы атаку ключа? Каждая пустая строка будет шифроваться одинаково. Каждое начало и конец Javadoc будет одинаковым. Теперь вы знаете открытый текст и зашифрованный текст для некоторого сегмента кода, который можно использовать. Это, вероятно, не было бы полезно ни для кого, кроме любителей (любой, у кого есть обученные крипто-типы или достаточная вычислительная мощность, может сломать его с достаточным усилием)
@MichaelT: нет, из-за IV. Попробуйте сами :) Используя связанную реализацию, строки шифруются <IV>,<ciphertext>.
Янус Троелсен
1
@svick: строки шифруются индивидуально. Если вы измените строку, вся строка будет перешифрована, но с новым IV (как всегда). Но остальная часть файла не будет затронута! Шифрование является детерминированным, но IV также являются входными данными, и они выбираются псевдослучайно.
Янус Троелсен
1

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

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

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

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

gbjbaanb
источник
Re: «Это означало бы, что у вас не может быть веб-сайта с различными функциями просмотра кода, нет обозревателя хранилища на стороне сервера или средства просмотра журналов. Нет различий в кодах, нет инструментов для онлайн-проверки кода». - Вы могли бы иметь их, если бы логика приложения была на стороне клиента JS, и это заставило вас ввести свой пароль / ключ (но не отправлять его на сервер), верно?
HC4 - восстановить Монику
Да, это могло бы быть ... Все что угодно, если бы оно знало, что получает зашифрованные данные по сети. Это просто очевидное ограничение сервера - он не может расшифровать данные.
gbjbaanb
1

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

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

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

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

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

Резиновая утка
источник
Что касается BitSync: вы предлагаете использовать его как замену для системы контроля версий или как-то использовать вместе с системой контроля версий? Если первое, то конечно, но это не очень интересно. Я мог бы также поделиться файлами через SpiderOak, и они были бы централизованы, но с нулевым знанием. Если последнее, то как?
HC4 - восстановить Монику
1
@ HighCommander4 Не пробовал, но не должно быть никаких причин, чтобы он не работал. Не могли бы вы настроить синхронизацию для общего доступа к вашей инициализированной папке git, а затем просто сделать нормальный 'git push ./syncedFolderActingAsServer/MyAwesomeProject/src/'? Вы могли бы также сделать разрешения уровня git, и т.д .. кто-то должен попробовать это!
Резиновая утка
1

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

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

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

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

svick
источник