Хостинг нульового коду знань? [зачинено]

У світлі останніх розкриттів щодо широко розповсюдженого урядом моніторингу даних, що зберігаються в Інтернеті, постачальники послуг з нульовим знанням зараз дуже люблять.

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

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

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

Мої запитання:

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

2. Чи існують сьогодні якісь сервіси розміщення кодів з нульовим знанням?

Ви можете зашифрувати кожен рядок окремо. Якщо ви можете дозволити витік назв файлів і приблизної довжини рядків та номерів рядків, у яких відбуваються зміни рядків, ви можете використовувати щось подібне:

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

Оскільки кожен рядок шифрується окремо (але з тим самим ключем), до завантажених змін (як правило) залучаються лише відповідні рядки.

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

Рядок шифрувача вище є SCM-агностиком, але може читати уніфіковані файли diff (простого тексту) та шифрувати зміни та застосовувати їх до шифротексту. Це робить його корисним для будь-якого SCM, який генеруватиме вам єдиний розріз (як Git).

Я не думаю, що немає жодних бар'єрів - врахуйте SVN, що надсилається на сервер для зберігання - це дельта між тим, що попередня та поточна версія вашого коду - так що ви змінюєте 1 рядок, саме цей рядок надсилається на сервер. Потім сервер "сліпо" зберігає його, не здійснюючи перевірки самих даних. Якщо ви зашифрували дельту і надіслали, що натомість це не вплине на сервер, насправді вам навіть не потрібно було б змінювати сервер.

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

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

Щось подібне вже існує, до певного моменту Mozy зберігає ваші дані, зашифровані вашим приватним ключем (ви можете використовувати їх власний, і вони шумуть, "якщо ви втратите власний ключ, теж погано, ми не можемо відновити ваші дані для ти ", але це більше орієнтоване на звичайного користувача). Mozy також зберігає історію ваших файлів, тому ви можете отримати попередні версії. Там, де воно падає, - це завантаження регулярно, а не перевірка, коли потрібно, і я вважаю, що він відкидає старі версії, коли у вас не вистачає місця для зберігання. Але концепція є, вони могли б модифікувати її, щоб забезпечити безпечний контроль над джерелами за допомогою своєї існуючої системи.

Я ненавиджу робити одну з таких відповідей "на це не зовсім буде відповідь на ваше запитання", але ..

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

1. Розмістіть приватний сервер Git самостійно. Потім поставте цей сервер на VPN, до якого ви надаєте членам вашої команди доступ. Вся комунікація з сервером і з нього буде зашифрована, і ви, звичайно, можете зашифрувати сервер на рівні ОС.

2. BitSync також повинен виконати трюк. Все було б зашифровано і у величезній мережі, яка була б доступна з будь-якого місця. Насправді це може бути справді гарне застосування всієї цієї технології BitCoin / BitMessage / BitSync ..

Нарешті, люди на веб- сайті /security// можуть мати трохи більше розуміння.

Як я розумію, спосіб git pullроботи полягає в тому, що сервер надсилає вам файл упаковки, який містить усі потрібні вам об'єкти, але наразі їх немає. І навпаки для git push.

Я думаю, ви не могли зробити це так прямо (адже це означає, що сервер повинен розуміти об'єкти). Натомість ви можете зробити так, щоб сервер працював лише з низкою зашифрованих файлів пакету.

Для цього pullви завантажуєте всі пакувальні файли, які були додані з останнього часу pull, розшифровуєте їх та застосовуєте до свого git repo. Для цього pushпотрібно спочатку зробити pullтак, щоб ви знали стан сервера. Якщо конфліктів немає, ви створюєте пакувальний файл зі своїми змінами, шифруєте його та завантажуєте.

При такому підході у вас з’явиться велика кількість крихітних файлів пакету, що було б досить неефективно. Щоб виправити це, ви можете завантажити серію файлів упаковки, розшифрувати, об'єднати їх в один файл пакету, зашифрувати та завантажити їх на сервер, позначаючи їх як заміну для цієї серії.