Hébergement de code sans connaissances? [fermé]

28

À la lumière des récentes révélations sur la surveillance gouvernementale généralisée des données stockées par les fournisseurs de services en ligne, les services à connaissance zéro font désormais fureur.

Un service à connaissance zéro est un service où toutes les données sont stockées cryptées avec une clé qui n'est pas stockée sur le serveur. Le chiffrement et le déchiffrement se produisent entièrement du côté client, et le serveur ne voit jamais ni les données en clair ni la clé. Par conséquent, le fournisseur de services n'est pas en mesure de déchiffrer et de fournir les données à un tiers, même s'il le voulait.

Pour donner un exemple: SpiderOak peut être considéré comme une version zéro connaissance de Dropbox.

En tant que programmeurs, nous comptons beaucoup sur nos données les plus sensibles - notre code - et les confions à une classe particulière de fournisseurs de services en ligne: les fournisseurs d'hébergement de code (comme Bitbucket, Assembla, etc.). Je parle bien sûr des référentiels privés ici - le concept de connaissance zéro n'a pas de sens pour les référentiels publics.

Mes questions sont:

  1. Existe-t-il des obstacles technologiques à la création d'un service d'hébergement de code à connaissance zéro? Par exemple, y a-t-il quelque chose dans les protocoles réseau utilisés par les systèmes de contrôle de version populaires comme SVN, Mercurial ou Git qui rendrait difficile (ou impossible) la mise en œuvre d'un schéma où les données communiquées entre le client et le serveur sont cryptées avec une clé que le serveur ne connaît pas?

  2. Existe-t-il aujourd'hui des services d'hébergement de code à connaissance zéro?

HC4 - réintégrer Monica
la source
1
Sans cryptage homomorphe , je ne vois pas comment un site d'hébergement de code à connaissance zéro pourrait fournir une sorte d'avantage par rapport à une version à connaissance nulle de drop-box. Je ne pense pas que quiconque ait encore mis au point un tel système qui soit à la fois sûr (c'est-à-dire suffisamment sécurisé pour que les experts lui fassent confiance) et suffisamment rapide pour être utilisable.
Brian
2
@AndresF. Je ne peux que supposer que SpiderOak signifie que la génération de diff se produit sur le client, le serveur stocke les diff cryptés, puis l'application diff-to-base se produit à nouveau sur le client lorsque le diff et la base sont cryptés. Je suis d'accord que leur langage n'est pas très clair.
apsillers
2
@apsillers: Ou vous pourriez délibérément insérer un tel contenu dans un fichier et l'utiliser pour identifier le fichier lui-même (par exemple, si quelqu'un essayait d'utiliser le cryptage pour cacher le piratage).
Brian
4
Ce n'est pas quelque chose dans lequel j'ai une expérience, mais je peux imaginer un obstacle technologique possible à un service d'hébergement de code à connaissance zéro: tous les utilisateurs n'auront-ils pas besoin de connaître / utiliser exactement la même clé? Et si tel est le cas, quel sera le mécanisme d'authentification qui garantira différents niveaux d'accès utilisateur?
CB
2
@gnat: Je ne demande pas de recommandation. Je demande simplement s'il existe un service du type que j'ai décrit. L'existence d'un tel service apporterait la preuve que les obstacles technologiques que je pose plus tôt dans la question sont surmontables.
HC4 - réintègre Monica

Réponses:

3

Vous pouvez crypter chaque ligne séparément. Si vous pouvez vous permettre de divulguer vos noms de fichiers et les longueurs de ligne approximatives et les numéros de ligne sur lesquels les modifications de lignes se produisent, vous pouvez utiliser quelque chose comme ceci:

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

Comme chaque ligne est chiffrée séparément (mais avec la même clé), les modifications téléchargées n'impliqueront (comme d'habitude) que les lignes pertinentes.

Si cela ne vous convient pas actuellement, vous pouvez créer deux référentiels Git, un avec du texte en clair et un avec du texte chiffré. Lorsque vous effectuez une validation dans le référentiel en texte brut (qui est local), un hook de validation peut prendre le diff et l'exécuter via le chiffreur de ligne référencé ci-dessus, qui l'appliquerait au référentiel de texte chiffré. Les modifications du référentiel de texte chiffré seraient validées et téléchargées.

Le chiffreur de ligne ci-dessus est agnostique SCM, mais peut lire les fichiers diff unifiés (de texte en clair) et chiffrer les modifications et les appliquer au texte chiffré. Cela le rend utilisable sur n'importe quel SCM qui vous générera un diff unifié (comme Git).

Janus Troelsen
la source
Ne pourriez-vous pas utiliser git's smudge-clean pour cela?
svick
@svick: Vous pourriez, mais de cette façon, je ne vois pas comment vous permettriez bien d'éviter de rechiffrer le fichier entier. Mais bien sûr, cela n'aurait pas beaucoup d'importance pour le code car les tailles de fichier sont petites. Mais il n'est pas nécessaire d'avoir un "chiffreur de ligne", vous pouvez simplement utiliser n'importe quel outil de chiffrement.
Janus Troelsen
De nombreux échantillons de texte (avec une structure connue) ne seraient-ils pas quelque chose qui faciliterait l' attaque de la clé? Chaque ligne vierge crypterait la même chose. Chaque début et fin d'un javadoc serait le même. Vous connaissez maintenant le texte clair et le texte chiffré pour un segment du code qui peut être utilisé. Cela ne serait probablement pas utile contre tout le monde, mais les amateurs (toute personne ayant des types de crypto formés ou une puissance de calcul suffisante pourrait le casser avec suffisamment d'effort).
@MichaelT: Non, à cause des IV. Essayez-le vous-même :) En utilisant l'implémentation liée, les lignes sont cryptées <IV>,<ciphertext>.
Janus Troelsen
1
@svick: les lignes sont chiffrées individuellement. Si vous changez une ligne, la ligne entière serait rechiffrée, mais avec un nouveau IV (comme toujours). Mais le reste du fichier ne sera pas touché! Le cryptage est déterministe, mais les IV sont également des entrées, et ils sont choisis de manière pseudo-aléatoire.
Janus Troelsen
1

Je ne pense pas qu'il y ait d'obstacles - considérez SVN, ce qui est envoyé au serveur pour le stockage est le delta entre ce que la version précédente et actuelle de votre code - donc vous changez 1 ligne, juste cette ligne est envoyée au serveur. Le serveur le stocke alors «à l'aveugle» sans effectuer aucune inspection des données lui-même. Si vous chiffriez le delta et l'envoyiez à la place, cela n'aurait aucun impact sur le serveur, en fait, vous n'auriez même pas besoin de modifier le serveur.

Il y a d'autres bits qui peuvent être importants, tels que les propriétés des métadonnées qui ne sont pas facilement chiffrables - comme le type MIME - mais d'autres peuvent être chiffrés, par exemple des commentaires dans le journal d'historique, tant que vous savez que vous devez les déchiffrer sur le client à afficher. Je ne sais pas si la structure des répertoires serait visible, je pense qu'elle ne serait pas visible en raison de la façon dont SVN stocke les répertoires, mais c'est possible, je me trompe. Cela peut cependant ne pas vous concerner si le contenu est sécurisé.

Cela signifierait que vous ne pourriez pas avoir un site Web avec les diverses fonctionnalités d'affichage de code, pas de navigateur de référentiel côté serveur ou de visionneuse de journaux. Pas de différences de code, pas d'outils de révision de code en ligne.

Quelque chose comme ça existe déjà, à un point, Mozy stocke vos données cryptées avec votre clé privée (vous pouvez utiliser la leur, et ils font du bruit "si vous perdez votre propre clé, dommage, nous ne pouvons pas restaurer vos données pour vous ", mais c'est plus ciblé sur l'utilisateur ordinaire). Mozy stocke également un historique de vos fichiers, vous pouvez donc récupérer les versions précédentes. Là où ça tombe, c'est que le téléchargement se fait régulièrement, pas de check-in quand vous le souhaitez, et je pense qu'il rejette les anciennes versions lorsque vous manquez d'espace de stockage. Mais le concept est là, ils pourraient le modifier pour fournir un contrôle de source sécurisé en utilisant leur système existant.

gbjbaanb
la source
Re: "Cela signifierait que vous ne pourriez pas avoir un site Web avec les différentes fonctionnalités d'affichage de code, pas de navigateur de référentiel côté serveur ou de visionneuse de journaux. Pas de différences de code, pas d'outils de révision de code en ligne." - Vous pourriez toujours les avoir si la logique de l'application était en JS côté client et qu'elle vous faisait entrer votre mot de passe / clé (mais pas l'envoyer au serveur), non?
HC4 - réintègre Monica
Oui, cela pourrait ... Tout serait possible tant qu'il savait qu'il recevait des données chiffrées sur le réseau. C'est juste une limitation évidente du serveur qu'il ne peut pas décrypter les données.
gbjbaanb
1

Je déteste faire une de ces réponses "ça ne va pas vraiment répondre à votre question" .. mais ..

Je peux penser à deux solutions prêtes à répondre à ces inquiétudes.

  1. Hébergez vous-même un serveur Git privé. Ensuite, placez ce serveur sur un VPN auquel vous donnez accès aux membres de votre équipe. Toutes les communications vers et depuis le serveur seraient cryptées, et vous pourriez bien sûr crypter le serveur au niveau du système d'exploitation.

  2. BitSync devrait également faire l'affaire. Tout serait crypté, et dans un immense réseau qui serait disponible de n'importe où. Cela pourrait en fait être une très bonne application de toute cette technologie BitCoin / BitMessage / BitSync.

Enfin, les gens sur /security// pourraient avoir plus d'informations.

Canard en caoutchouc
la source
Concernant BitSync: proposez-vous qu'il soit utilisé en remplacement d'un système de contrôle de version, ou d'une manière ou d'une autre utilisé avec un système de contrôle de version? Si le premier, alors bien sûr, mais ce n'est pas très intéressant. Je pourrais tout aussi bien partager les fichiers sur SpiderOak et ce serait centralisé, mais toujours sans connaissance. Si ce dernier, alors comment?
HC4 - réintègre Monica
1
@ HighCommander4 Je ne l'ai pas essayé, mais cela ne devrait pas être une raison pour que cela ne fonctionne pas. Ne pourriez-vous pas configurer la synchronisation pour partager votre dossier git initialisé, alors faites simplement une opération normale 'git push ./syncedFolderActingAsServer/MyAwesomeProject/src/'? Vous pouvez également faire des permissions au niveau git, etc. quelqu'un devrait essayer ça!
Rubber Duck
1

Si je comprends bien, la façon dont git pullfonctionne est que le serveur vous envoie un fichier pack qui contient tous les objets que vous voulez, mais que vous n'avez pas actuellement. Et vice versa pour git push.

Je pense que vous ne pouvez pas le faire directement comme ça (car cela signifie que le serveur doit comprendre les objets). Ce que vous pourriez faire à la place, c'est de laisser le serveur fonctionner uniquement avec une série de fichiers pack chiffrés.

Pour ce faire pull, vous téléchargez tous les fichiers pack qui ont été ajoutés depuis votre dernier pull, les déchiffrez et appliquez à votre git repo. Pour ce faire push, vous devez d'abord le faire pull, afin de connaître l'état du serveur. S'il n'y a pas de conflits, vous créez un fichier pack avec vos modifications, le cryptez et le téléchargez.

Avec cette approche, vous vous retrouveriez avec un grand nombre de petits fichiers pack, ce qui serait assez inefficace. Pour résoudre ce problème, vous pouvez télécharger une série de fichiers pack, les décrypter, les combiner en un seul fichier pack, les crypter et les télécharger sur le serveur, en les marquant en remplacement de cette série.

svick
la source