Modèle permettant à plusieurs personnes de déchiffrer un document, sans partager la clé de chiffrement?
Configuration actuelle
Nous avons un service qui permet aux utilisateurs de télécharger des documents via un site Web et stocke les documents téléchargés cryptés sur le disque.
Les documents sur disque sont cryptés avec une clé par utilisateur, qui est générée aléatoirement lors de la création du compte. Cette clé de document est stockée dans un champ de base de données qui est chiffré avec le mot de passe de l'utilisateur comme clé. Lorsque l'utilisateur (propriétaire) souhaite télécharger un document, il doit fournir son mot de passe, qui est utilisé pour déchiffrer la clé du document qui est à son tour utilisée pour déchiffrer le document.
Nous avons choisi ce modèle pour supprimer la nécessité de rechiffrer tous les documents cryptés lorsque l'utilisateur choisit de changer son mot de passe: nous avons seulement besoin de recrypter la clé du document.
Cette configuration fonctionne bien (et nous pensons que c'est un modèle sécurisé1).
Modifications requises
Malheureusement, nous avons deux nouvelles exigences à implémenter.
- Selon la loi, nous sommes tenus de pouvoir décrypter tous les documents que nous avons sur disque, à la demande du gouvernement;
- Quelqu'un a décidé que le propriétaire d'un document devrait pouvoir partager le document téléchargé avec d'autres utilisateurs.
Je ne sais pas comment mettre en œuvre ces exigences tout en conservant les documents stockés avec un cryptage par utilisateur.
Donc, ma question est:
Existe-t-il un modèle connu qui permet de chiffrer les documents afin qu'ils puissent être déchiffrés par une ou plusieurs parties, où les parties en question doivent être déterminées lors du chiffrement des documents?
Mise à jour :
Quelques informations générales sur la loi mentionnée ci-dessus:
En fait, la loi ne stipule pas que nous sommes tenus de construire une porte dérobée. La loi érige en infraction pénale le fait de pas remettre la clé de toutes les données cryptées dont vous disposez2 si la police demande la clé3. En conséquence, nous qui hébergeons les données devons avoir une porte dérobée ou faire face à des poursuites au cas où nous ne pourrions pas décrypter les données sur demande. Cependant, sauf dans certains autres pays, nous sommes libres de communiquer le fait que nous avons reçu une commande de décryptage de documents. Ces lois sont malheureusement pas rares .
Informer nos clients et le public:
Comme je l'ai indiqué dans n commentaire avant, j'ai bien l'intention de faire tout mon possible pour m'assurer que cette politique est clairement communiquée à nos clients. Les déclarations de confidentialité doivent être modifiées et les CGU doivent être mises à jour.
La sensibilisation du public d'une part et la garantie que les "mauvaises lois coûtent de l'argent" d'autre part sont la meilleure méthode dont je dispose pour protester contre de telles lois.
Cependant, en même temps, je suis un peu sceptique quant à l'impact d'une telle déclaration. La plupart des gens s'en moquent. Dans le même temps, de nombreuses personnes utilisent leur courrier électronique et leur boîte de réception pour stocker et partager des documents. De ce point de vue, notre service est (encore) une énorme amélioration (et c'est la raison pour laquelle certains de nos clients exigent que leurs employés l'utilisent).
1. S'il y a un trou flagrant dans cette méthode, n'hésitez pas à le commenter.
2. Les avocats ont pensé que les "données dont vous disposez" sont censées inclure toutes les données stockées sur les appareils physiques que vous possédez (je ne suis pas un avocat, donc ce sont mes profanes qui traduisent ce qu'ils ont conclu).
3. Oui, pas un bureau de sécurité sophistiqué, mais la police. Il y a certains garanties quand ils peuvent demander un mot de passe, mais cela ne change pas les implications de cette loi. La grande question est de savoir ce qui se passe lorsque vous avez vraiment oublié le mot de passe de certaines données. Le ministre a indiqué qu'il incombe au propriétaire de ces données chiffrées de les supprimer. Mais aucune affaire de ce type n'a (à ma connaissance) encore été jugée par un tribunal.
Vous avez besoin d'une clé par document, pas d'une clé par utilisateur. Eh bien, vous avez également besoin de clés par utilisateur, mais c'est une autre question.
A savoir, chaque document [~ # ~] d [~ # ~] est crypté avec une clé KRé. Cette clé est générée de manière aléatoire la première fois que le document est importé dans le système. Chaque document a sa propre clé. La clé d'un document ne peut pas être déduite de la clé d'un autre document.
Chaque utilisateur [~ # ~] u [~ # ~] possède également une clé KU. Par conséquent, si vous avez besoin que le document [~ # ~] d [~ # ~] soit accessible aux utilisateurs [ ~ # ~] u [~ # ~] , [~ # ~] v [~ # ~] et [~ # ~] w [~ # ~] , puis vous enregistrez EKRé(D) (cryptage de [~ # ~] d [~ # ~] avec la clé de document), avec EKU(KRé) , EKV(KRé) et EKW(KRé) (cryptage de la clé KRé avec les clés de l'utilisateur [~ # ~] u [~ # ~] , [~ # ~] v [~ # ~] et [~ # ~] w [~ # ~] ). Ces "clés cryptées" ont une petite taille (quelques dizaines d'octets, quelle que soit la taille du document), donc cela évolue.
Pour rendre les choses plus pratiques, vous devrez peut-être utiliser cryptage asymétrique pour les clés utilisateur: cryptage de [~ # ~] d [~ # ~] utilise un système symétrique pratique (disons AES), mais les "clés utilisateur" seront de type RSA (ou un autre algorithme similaire comme ElGamal). De cette façon, si l'utilisateur [~ # ~] u [~ # ~] souhaite partager le document [~ # ~] d [~ # ~] avec l'utilisateur [~ # ~] v [~ # ~] , Puis il:
- récupère EKU(KRé) du serveur;
- utilise sa propre clé privée pour déchiffrer cela et récupérer KRé;
- chiffre KRé avec [~ # ~] v [~ # ~] clé publique , donnant EKV(KRé) .
La beauté de ce schéma est que [~ # ~] v [~ # ~] n'a pas besoin d'être présent pour cette procédure, car seulement La clé publique de [~ # ~] v [~ # ~] est utilisée.
À ce stade, ce que vous avez vraiment est OpenPGP , un format destiné principalement aux e-mails sécurisés. Les e-mails ont cette "propriété de partage" (un e-mail peut être envoyé à plusieurs destinataires) et sont asynchrones (lorsque vous envoyez l'e-mail, le destinataire n'est pas nécessairement disponible immédiatement). Il serait judicieux de réutiliser OpenPGP, un format qui a été examiné par de nombreux cryptographes et pour lequel des implémentations existent déjà.
Lorsque vous avez un mécanisme de partage, vous pouvez simplement vous mettre comme destinataire implicite pour chaque document, et vous pouvez tout lire. Indépendamment des exigences de la loi, assurez-vous d'informer les utilisateurs à travers les "conditions d'utilisation" que vous pouvez tout lire techniquement; sinon, ils pourraient vous poursuivre pour manque d'avertissement.
MAIS, nous avons deux nouvelles exigences à mettre en œuvre:
Selon la loi, nous sommes tenus de pouvoir décrypter tous les documents que nous avons sur disque, à la demande du gouvernement;
Sensationnel. J'vraiment j'espère que vous prévoyez d'informer vos utilisateurs que vous allez faire du backdooring à votre service pour l'application de la loi afin qu'ils aient suffisamment de temps pour supprimer leurs données de votre service avant que cela ne se produise. Ce serait la chose éthique et honorable à faire.
Si vous êtes obligé de le faire, par exemple par lettre de sécurité nationale et vous n'êtes pas autorisé à en parler en raison d'un ordre de bâillon, alors vos options sont limitées:
- Demandez à quelqu'un dans l'entreprise de divulguer anonymement ces informations à la presse gratuite (à l'avenir, votre service sera détourné).
- Arrêtez le service pour des raisons non spécifiées. Donnez à vos utilisateurs quelques semaines pour télécharger leurs données avant de les supprimer définitivement.
- Déménagez votre entreprise, votre service en ligne et votre personnel dans un pays où il n'y a pas de lois draconiennes en matière de surveillance.
Il semble que vous disposiez déjà d'un service sécurisé et que vous ayez attiré des utilisateurs soucieux de la confidentialité. N'importe quoi serait mieux que d'installer volontairement une porte dérobée pour l'application de la loi et de visser vos utilisateurs. Pour tout ce que vous savez, dès que votre système proposé est en place pour l'application de la loi, ils vous enverront un mandat pour tous les données des utilisateurs.
Vous feriez mieux de fermer l'entreprise, de prendre votre argent et de démarrer une nouvelle entreprise, mais cette fois en le faisant correctement. Voici mes suggestions:
- Démarrez votre entreprise dans un pays sans ces lois. Hébergez également vos serveurs et vos données utilisateur.
- Utilisez un client open source pour que les utilisateurs aient confiance dans le logiciel qui s'exécute sur leur ordinateur/appareil. Il sera très difficile de cacher une porte dérobée à l'avenir si les autorités vous y obligent, car quelqu'un le remarquera.
- Toutes les clés de chiffrement des données privées sont stockées client côté, jamais sur le serveur. Seules les données chiffrées sont stockées sur le serveur. Tout le cryptage et le décryptage sont effectués sur le client. Le serveur ne contient que des données cryptées. Les utilisateurs ont la responsabilité de sauvegarder leurs propres clés privées. Ensuite, votre entreprise est littéralement incapable de répondre aux futures demandes NSL car vous n'avez pas les clés.
- Pour l'authentification auprès du serveur et pour permettre à l'utilisateur de stocker et de télécharger des données chiffrées à partir de son compte, configurez une sorte de protocole d'authentification par clé publique par utilisateur. Le serveur détient peut-être la clé publique de chaque utilisateur. L'utilisateur détient la clé privée, puis signe chaque téléchargement de données et demande au serveur. Chaque client peut intégrer la clé publique du serveur (épinglée) pour vérifier les réponses et les données chiffrées téléchargées à partir du serveur.
- Pour partager des fichiers avec d'autres utilisateurs, l'utilisateur peut rechiffrer son fichier avec une nouvelle clé symétrique et partager cette clé en utilisant l'échange de clés publiques avec d'autres utilisateurs du système. Votre service pourrait gérer le partage de la clé publique pour eux. Cependant, cela est dangereux si les utilisateurs ne peuvent pas faire entièrement confiance au serveur et si le serveur se trouve dans un pays aux lois de surveillance hostiles. Les utilisateurs ne savent pas si le serveur leur donne une fausse ou réelle clé publique pour l'autre utilisateur, ils seraient donc vulnérables aux attaques MITM. Ce serait une façon dont les forces de l'ordre pourraient utiliser pour accéder aux données non cryptées des fichiers partagés entre d'autres utilisateurs. Dans ce scénario, il serait plus sûr que les utilisateurs connaissent leurs propres clés publiques et puissent les partager en privé avec d'autres utilisateurs lorsqu'ils souhaitent partager des données avec eux.
- Utilisez des algorithmes de clé publique plus récents qui ne sont pas vulnérables aux ordinateurs quantiques. Pas de courbes RSA, DSA ou elliptiques.
- Utilisez des algorithmes de hachage et de clé symétriques plus récents d'auteurs soucieux de la confidentialité et n'aimant pas la surveillance de masse. Par exemple, Bruce Schneier et Daniel J. Bernstein.
La solution décrite par Tom Leek ci-dessus a été mise en œuvre par le magasin de documents cloud open source ownCloud . Le modèle de cryptage est décrit ici .
Comme indiqué dans d'autres réponses, vous pouvez faire la même chose avec OpenPGP/GPG que j'ai décrit dans une réponse à une question connexe . Pour répéter brièvement l'approche standard:
- Chaque utilisateur a une paire de clés publique/privée
- Chaque document reçoit une clé symétrique unique avec laquelle le document est chiffré et téléchargé dans le conteneur de stockage de sauvegarde. C'est ce qu'on appelle la clé de fichier
- Chaque fois qu'un utilisateur est autorisé à accéder au fichier, la clé de fichier est chiffrée avec la clé publique de l'utilisateur
Plus précisément, vous voulez être en mesure de fournir la clé de fichier lorsque contraint par la loi. C'est une fonctionnalité opt-in de ownCloud où chaque clé de fichier est également cryptée avec la clé publique de l'administrateur système. Avec ownCloud, l'intention de la fonctionnalité est que l'utilisateur peut avoir oublié la phrase secrète de sa clé privée et peut demander à l'administration de lui accorder à nouveau l'accès au fichier.
Une chose à noter est que ownCloud utilise une base de données régulière pour les données utilisateur/groupe et les métadonnées du fichier. Les objets blob de fichiers réels peuvent être stockés localement ou sur un fournisseur externe tel qu'Amazon S3 ou Google Drive. Vous pouvez adopter la même approche; demandez au client de chiffrer et d'écrire d'abord dans un magasin d'objets blob externes hors de la juridiction chiffré avec ses propres clés, puis d'écrire uniquement l'URL (généralement un GUID 128 bits) dans votre système. Bien que cela soit loin d'être idéal en termes de complexité du système, cela pourrait bien vous libérer de l'obligation de vous conformer à une loi dangereuse et oppressive; car vous ne pouvez transférer que des pointeurs vers les données.
Je pense qu'au moins un pays qui applique de telles lois totalitaires oblige tous les fournisseurs de cloud offshore à déplacer leurs serveurs dans le pays pour les utilisateurs domiciliés dans ce pays. Dans ce cas, votre dernier recours consiste à laisser les utilisateurs du système chiffrer et écrire sur leurs propres lecteurs réseau locaux et stocker un chemin de fichier dans votre système. Il appartient ensuite au client d'effectuer des sauvegardes hors site de ces données.
En réponse directe à votre question, la réponse de Tom Leek est parfaite.
Cependant, je vous recommande d'adopter une approche différente: abandonner le chiffrement par utilisateur.
Vous utiliserez toujours le cryptage réseau (HTTPS), le hachage de mot de passe et, si vous le souhaitez, le cryptage complet du disque sur le serveur. Cependant, n'utilisez aucun cryptage au-delà de cela. Votre application décide toujours qui peut consulter un document particulier: l'utilisateur qui a téléchargé le premier, votre administrateur à des fins juridiques et tous les utilisateurs qui ont partagé le document avec eux. Dans cet arrangement, il est assez facile de répondre à toutes vos exigences.
Alors pourquoi est-ce que je suggère d'abandonner le chiffrement par utilisateur? Parce que c'est complexe et difficile à mettre en œuvre, et cela n'ajoute en fait pas beaucoup de sécurité. Vous n'avez pas vraiment expliqué quel avantage vous vouliez pour le cryptage par utilisateur, mais je suppose que c'est pour protéger les documents au cas où le serveur serait compromis électroniquement ou physiquement. Ces deux événements doivent être extrêmes: vous devez prendre des précautions standard comme le pare-feu pour éviter que cela ne se produise. Mais si un événement aussi extrême se produit, un attaquant avancé peut tout de même obtenir les documents de vos utilisateurs. Ils attendent tranquillement, attendant que vos utilisateurs se connectent, puis capturent le mot de passe et décryptent les documents.
Je sais que cela a déjà été répondu, mais ...
Je dois faire quelque chose de très similaire sur mon site Web.
Les documents sont cryptés mais peuvent être partagés avec d'autres utilisateurs.
Étant au Royaume-Uni, je suis tenu de partager les détails de sécurité avec les services de sécurité si nécessaire, mais uniquement si je les ai. Je n'y ai pas accès donc ce n'est pas un problème. (Je ne suis pas non plus autorisé à informer les utilisateurs que des détails ont été demandés - le prix de la liberté!)
Chaque utilisateur dispose d'une paire de clés asymétriques qui est utilisée pour sécuriser ses documents. Les clés publiques sont stockées en texte brut mais les clés privées sont cryptées à l'aide de Blowfish, avec une clé de 128 bits dérivée du mot de passe des utilisateurs.
Lorsqu'un utilisateur souhaite partager un document, celui-ci est déchiffré et une copie est effectuée et chiffrée à l'aide de la clé publique de l'utilisateur cible, ce qui est facile à faire en texte brut. Lorsque l'utilisateur cible se connecte, il peut déchiffrer le document à l'aide de sa clé privée sécurisée.
Évidemment, s'il est partagé avec plusieurs utilisateurs, il doit y avoir une copie pour chacun.
Étant donné que les exigences énoncées forcent le cryptage à être essentiellement destiné à la protection contre le "show" (théâtre de sécurité?) Et au vol de base, et non à une protection sécurisée au niveau du document, je recommanderais le cryptage de base du disque complet à l'aide de LUKS ou similaire. De cette façon, vous disposez de la clé principale de l'archive entière et pouvez utiliser des schémas non basés sur le chiffrement pour contrôler l'accès par utilisateur aux différents documents. Le chiffrement par document ne vous apporte vraiment rien, sauf les tracas à la lumière de l'exigence n ° 1.
Aussi, je voudrais seconder la réponse d'antispy ci-dessus. Au minimum, le service proposé est hautement contraire à l'éthique et, dans certaines juridictions, serait même considéré comme une fraude en fonction des conditions de service/de ce que vous avez divulgué à vos utilisateurs.