Question:
Motif permettant à plusieurs personnes de décrypter un document, sans partager la clé de cryptage?
Monika
2014-10-29 20:31:12 UTC
view on stackexchange narkive permalink

Configuration actuelle

Nous avons un service qui permet aux utilisateurs de télécharger des documents via un site Web et de stocker les documents téléchargés chiffrés sur disque.

Les documents sur le disque sont chiffré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 crypté 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écrypter la clé de document qui se trouve dans tour utilisé pour déchiffrer le document.

Nous avons choisi ce modèle pour éviter le besoin de rechiffrer tous les documents chiffrés lorsque l'utilisateur choisit de changer son mot de passe: il suffit de rechiffrer la clé du document.

Cette configuration fonctionne correctement (et nous pensons que c'est un modèle sécurisé 1 ).


Modifications requises

Malheureusement, nous avons deux nouvelles exigences à mettre en œuvre.

  1. Selon la loi, nous sommes tenus d'être en mesure de décrypter tous les documents que nous avons sur le disque, à la demande du gouvernement;
  2. 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.

Ma question est donc:

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és lors du chiffrement du document?



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 ne pas transmettre la clé aux données chiffrées dont vous disposez 2 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 à la demande. Cependant, à l'exception de certains autres pays, nous sommes libres de communiquer le fait que nous avons reçu un ordre de déchiffrement de documents. Ces lois ne sont malheureusement pas rares.

Informer nos clients et le public:
Comme je l’ai indiqué dans un commentaire avant, j'ai bien l'intention de mettre tout mon poids pour que cette politique soit clairement communiquée à nos clients. Les déclarations de confidentialité doivent être modifiées et les conditions d'utilisation doivent être mises à jour.
La sensibilisation du public d'une part et s'assurer 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 messagerie et leur boîte de réception pour stocker et partager des documents. Donc, 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 avocat, c'est donc ma traduction profane de ce qu'ils ont conclu).
3. Oui, pas un bureau de sécurité sophistiqué, mais la police. Il existe certaines garanties pour 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 incombait au propriétaire de ces données cryptées de les supprimer ensuite. Mais aucune affaire de ce genre n'a encore (à ma connaissance) été jugée par un tribunal.

Quel est l'avantage du chiffrement par utilisateur? On dirait que vous pourriez aussi bien utiliser le cryptage complet du disque et demander à l'application de vérifier les mots de passe pour les téléchargements.
L'avantage du chiffrement par utilisateur est que toutes les séquences de déchiffrement nécessitent un mot de passe. En d'autres termes, il n'y a aucune clé de déchiffrement stockée n'importe où sur le disque (sous forme non chiffrée).
Alors, l'utilisateur doit entrer son mot de passe pour déchiffrer? Cela est incompatible avec votre obligation légale de déchiffrer sur demande.
@paj28, exactement. C'est pourquoi j'ai posé la question. Notez que bien que la loi nous oblige à être en mesure de décrypter n'importe quel document, elle n'exige pas qu'il s'agisse d'un processus automatisé. Ainsi, nous pouvons toujours garder secret notre «mot de passe principal».
@Monika: si vous stockez votre "mot de passe principal" dans une machine hors ligne ou dans un morceau de papier, il y a en effet une sécurité supplémentaire dans le cryptage par utilisateur.
Est-ce que la personne qui a voté contre le fait d'expliquer pourquoi?
Je considérerais qu'il est malhonnête d'offrir ce service, car votre obligation légale de pouvoir décrypter et documenter n'est pas compactable avec ce à quoi vos clients peuvent raisonnablement s'attendre.
@IanRingrose, Le service offre aux utilisateurs la possibilité de stocker des documents afin qu'ils puissent y accéder quand ils en ont besoin. Nous chiffrons les documents parce que nous respectons l'idée de confidentialité, pas parce que le contrat avec le client l'exige. En deuxième lieu, le service est utilisé exclusivement par les clients professionnels, qui utiliseraient normalement (ou simultanément) leur boîte de réception de courrier électronique dans le même sens.
La loi ne vous oblige certainement à déchiffrer que si vous êtes physiquement capable de le faire. Si vous empêchez le déchiffrement des données utilisateur, il n'y a pas de problème, n'est-ce pas?
@JMK, Si vous ne pouvez pas fournir le mot de passe, la loi suppose que vous travaillez contre la demande. La loi essaie d'empêcher les gens de prétendre avoir «oublié» leur mot de passe et est formulée comme telle. L'effet secondaire de cette formulation de la loi (le cas dans cette question) ne leur dérange pas.
@Monika, Je ne crois pas que la loi nous incombe, vous l’affirmez, car tout service de sauvegarde qui sauvegarde un fichier de ma machine que j’ai déjà chiffré serait nécessaire pour pouvoir remettre la clé. De même si l'un de vos clients crypte un fichier lui-même avant d'utiliser votre système pour le partager.
@IanRingrose, Je ne suis pas avocat et je ne pense pas que ce soit le lieu de discuter de la question de savoir si cette loi doit être interprétée comme elle l'a fait. En attendant, je dois * faire * trouver une solution qui satisfait aux deux exigences décrites dans ma question.
Une question strictement pratique: bien que vous puissiez modifier le stockage des clés comme suggéré ci-dessous pour les nouveaux documents, comment avez-vous l'intention de gérer tout ce qui a été téléchargé avant que le changement ne soit effectué lorsque seul l'utilisateur dispose d'une copie de la clé de déchiffrement ...
@DanNeely, que l'on me dérange aussi. Le tout avec ce problème est que la loi a été conçue par des personnes qui, apparemment, n'y ont pas réfléchi ou, plus probablement, n'ont pas le «savoir-faire» technique pour voir toutes les implications et impossibilités qu'elle crée. Pour l'instant, je pense que je devrais a) l'ignorer ou b) me trouver un autre travail ou quelque chose.
Attendez, ce ne sont pas VOS données et clés cryptées - ce sont celles de l'UTILISATEUR. Pourquoi avez-VOUS exigé de donner les clés à n'importe quel cabinet juridique? Vous ne stockez que des données aléatoires pour les utilisateurs, alors envoyez-les pour récupérer les clés des utilisateurs.
@Monika Si le manque de capacité de déchiffrement peut être retenu contre vous, cela vous expose à une sorte de chantage: imaginez qu'un utilisateur télécharge une séquence de bits aléatoire et trompe le gouvernement en vous demandant un "déchiffrement"
Dans quel pays est-ce, si cela ne vous dérange pas de me demander
Éventuellement lié: [SuperUser: Crypter un document avec plusieurs clés et rendre les gens responsables de ces clés] (http://superuser.com/q/638358/53590)
@Monika de quel pays s'agit-il?
Six réponses:
Tom Leek
2014-10-29 20:48:44 UTC
view on stackexchange narkive permalink

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.

À savoir, chaque document D est chiffré avec une clé K D sous> . Cette clé est générée aléatoirement 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 être déduite de la clé d'aucun autre document.

Chaque utilisateur U possède également une clé K U . Par conséquent, si vous avez besoin que le document D soit accessible aux utilisateurs U , V et W , alors vous stockez E K D (D) (cryptage de D avec la clé de document), avec E K U (K D ) , E K V sub > (K D ) et EKW (K D ) (chiffrement de la clé KD avec les clés de l'utilisateur U , V et W ). Ces "clés chiffrées" ont une petite taille (quelques dizaines d'octets, quelle que soit la taille du document), donc cela augmente.

Pour rendre les choses plus pratiques, vous devrez peut-être utiliser un chiffrement asymétrique pour les clés utilisateur: le chiffrement de D utilise un système symétrique pratique (par exemple, 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 , alors il:

  1. récupère EKU (K D ) du serveur;
  2. utilise le sien clé privée pour décrypter cela et récupérer KD;
  3. crypte K D sub > avec la clé publique de V , donnant EKV (K D ) .

La beauté de ce schéma est que V n'a pas besoin d'être présent pour cette procédure, puisque seulement V est utilisée.

À ce stade, vous avez vraiment 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 forcément disponible tout de suite). Vous feriez bien de réutiliser OpenPGP, un format qui a été révisé par de nombreux cryptographes, et pour lequel des implémentations existent déjà.


Lorsque vous avez un mécanisme de partage, vous pouvez simplement destinataire implicite pour chaque document, et vous pouvez tout lire. Indépendamment des exigences de la loi, assurez-vous d'informer les utilisateurs via les «conditions d'utilisation» que vous pouvez techniquement tout lire; sinon, ils pourraient vous poursuivre pour manque d'avertissement.

J'espérais un cryptage élégant à plusieurs clés publiques avec un schéma de décryptage à clé privée associé, mais c'est probablement plus simple (donc mieux). [et ne vous inquiétez pas, je veillerai à ce que la déclaration de confidentialité et les conditions d'utilisation soient modifiées; la sensibilisation du public d'une part et s'assurer que les «mauvaises lois coûtent de l'argent» d'autre part, sont la meilleure méthode de protestation dont je dispose, contre de telles lois.]
Existe-t-il un schéma de «cryptage à clé publique multiple, décrypter avec la clé privée associée»? ou quelqu'un n'a pas encore compris celui-ci?
Le schéma OpenPGP en est un exemple; mais vous obtenez toujours des frais généraux par destinataire. Il existe des schémas de «cryptage de diffusion» qui tentent de réduire cette surcharge; mais vous ne pouvez pas le supprimer complètement.
Je devrais me réinscrire à l'université :-)
Et une implémentation PGP fait déjà le point 1 (requête du gouvernement) ou du moins l'a fait. La version "commerciale" de PGP Inc, vers 2000 lorsque le gouvernement américain poussait Clipper, etc., a ajouté une alternative plus douce appelée ADK Additional Decryption Key qui permet au propriétaire de déchiffrer si nécessaire, dans ce cas, la demande du gouvernement. Je n'ai pas suivi, mais certaines recherches sur Google suggèrent que le nouveau propriétaire Symantec maintient cette capacité. Vous devez certainement configurer les contrôles afin qu'ils ne soient utilisés que lorsqu'ils sont légalement appropriés, quel que soit le domaine de votre juridiction.
La clé de déchiffrement supplémentaire (ADK) @dave_thompson_085, est intéressante. Pourriez-vous peut-être développer votre commentaire en une réponse?
Notez que la configuration proposée ne remplit pas l'exigence de la question selon laquelle les documents peuvent être partagés "sans partager la clé de chiffrement". Vous le partagez sous une forme cryptée, mais vous le partagez toujours. Cela signifie que si vous souhaitez révoquer l'accès de quelqu'un, vous devrez toujours rechiffrer le document avec un nouveau K_D et le partager (sous forme cryptée ou non) avec tous les utilisateurs restants qui devraient y avoir accès.
On peut soutenir que si la clé K_D est spécifique au document, le partage de la clé et du document est la même chose. On pourrait dire que vous ne pouvez pas forcer quelqu'un à oublier un document, pas plus que vous ne pouvez le forcer à oublier une clé. En ce sens, «révoquer» un accès n'est pas bien défini.
@Chris Je pense que le meilleur compromis ici serait s'il y avait une nouvelle clé générée chaque fois que le document était édité. Une partie du processus de téléchargement serait alors de crypter la nouvelle clé pour chaque personne qui devrait être autorisée à écrire dans le document.
antispy
2014-10-30 05:44:43 UTC
view on stackexchange narkive permalink

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 le disque, à la demande du gouvernement;

Wow. J'espère vraiment que vous prévoyez d'informer vos utilisateurs que vous allez détourner votre service pour les forces de l'ordre 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:

  1. Demandez à quelqu'un de l'entreprise de divulguer anonymement ces informations à la presse libre (qu'à l'avenir votre service sera détourné).
  2. Arrêtez le service pour des raisons non spécifiées. Donnez à vos utilisateurs quelques semaines pour télécharger leurs données avant qu'elles ne soient définitivement supprimées.
  3. Transférez votre entreprise, vos services en ligne et votre personnel dans un pays où il n'y a pas de lois de surveillance draconiennes.
  4. ol >

    Il semble que vous ayez déjà 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 autant que vous le sachiez, dès que votre système proposé sera en place pour l'application de la loi, ils vous enverront un mandat pour toutes les données des utilisateurs.

    Vous feriez mieux de fermer l'entreprise vers le bas, en prenant votre argent et en démarrant une nouvelle entreprise, mais cette fois-ci, le faire correctement. Voici mes suggestions:

  • Créez 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 parce que quelqu'un le remarquera.
  • Toutes les clés de chiffrement de données privées sont stockées côté client , jamais sur le serveur. Seules les données crypté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 chiffré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 permettre à l'utilisateur de stocker et de télécharger des données chiffrées à partir de son compte, configurez une sorte de par protocole d'authentification par clé publique 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 (épingler) la clé publique du serveur pour vérifier les réponses et les données chiffrées téléchargées depuis le serveur.
  • Pour partager des fichiers avec d'autres utilisateurs, l'utilisateur peut rechiffrer son fichier avec un nouveau clé symétrique et partagez cette clé à l'aide d'un échange de clé publique avec d'autres utilisateurs du système. Votre service peut 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 avec des 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 chiffré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 au quantum des ordinateurs. Pas de RSA, DSA ou courbes elliptiques.
  • Utilisez de nouveaux algorithmes de clé symétrique et de hachage d'auteurs qui se soucient de la confidentialité et n'aiment pas la surveillance de masse. Par exemple, Bruce Schneier & Daniel J. Bernstein.
8. Installez un canari de mandat avant d'obtenir une assignation secrète du gouvernement.
Les nouveaux algorithmes à clé publique ont un bilan beaucoup plus court que RSA, DSA et EC. Étant donné que les progrès de l'informatique quantique ont été lents et que les progrès dans la rupture des nouveaux algorithmes ont souvent été étonnamment rapides, il semble raisonnablement probable que les services de sécurité aient attaqué certains de ces algorithmes.
Je ne suis pas non plus satisfait de l'aspect éthique de toute la question, en fait, j'essaie de voir comment nous pouvons minimiser les dommages. Veuillez également consulter le paragraphe * mise à jour * dans la question.
C'était une assez bonne réponse jusqu'aux deux derniers points. Utiliser des algorithmes non testés en faveur d'algorithmes bien connus et examinés de manière approfondie qui se sont révélés assez sûrs dans la pratique est une mauvaise idée, pour des raisons qui ont été discutées à maintes reprises. Edward Snowden était confiant dans l'utilisation de GnuPG pour communiquer en toute sécurité et [a déclaré] (http://www.theguardian.com/world/2013/jun/17/edward-snowden-nsa-files-whistleblower) que «le cryptage fonctionne. ** Les systèmes de cryptographie forts correctement mis en œuvre sont l'une des rares choses sur lesquelles vous pouvez compter. ** ", avec une forte mise en garde concernant la sécurité des terminaux.
L'attaque semi-pratique la plus connue du public contre AES-256 semble être une attaque par clé connexe d'une complexité d'environ 2 ^ 99,5. L'attaque de récupération de clé complète la plus connue à nouveau sur AES-256 est de complexité 2 ^ 254,4. Le premier peut probablement être évité dans la sélection des clés, et le second est plus une curiosité académique qu'autre chose, étant donné que nous [ne pouvons même pas de façon réaliste * compter * jusqu'à un trivial 2 ^ 192] (http: // security. stackexchange.com/a/6149/2138) et sont pressés pour 2 ^ 128. Wikipédia: [attaques AES connues du public] (https://en.wikipedia.org/wiki/Advanced_Encryption_Standard#Known_attacks).
"Utiliser des algorithmes non testés en faveur d'algorithmes bien connus, examinés de manière approfondie et qui se sont avérés assez sûrs dans la pratique est une mauvaise idée" - En général, je suis d'accord, mais dans le cas des ordinateurs quantiques, tous les algorithmes à clé publique sécurisés actuellement (contreordinateurs classiques) seront rendus obsolètes et non sécurisés.Il existe également des algorithmes post-quantiques testés et examinés dans le temps qui sont toujours considérés comme sécurisés aujourd'hui (si des clés de grande taille sont utilisées), par exemple.McEliece.Il y a maintenant un concours d'algorithmes post-quantiques pour trouver des options sûres pour l'avenir.Combiner deux finalistes serait robuste.
"Edward Snowden était confiant dans l'utilisation de GnuPG pour communiquer en toute sécurité et a déclaré que" le cryptage fonctionne.Les systèmes de cryptographie forts correctement mis en œuvre sont l'une des rares choses sur lesquelles vous pouvez compter. "- Les marionnettes de chaussettes du gouvernement * adorent * répéter cela. Snowden n'est * pas * qualifié pour dire * quels * systèmes de cryptographie peuvent être fiables. Après tout,Il a eu accès à des * rien * détaillés sur les techniques de cryptanalyse. En fait, la seule information que nous ayons sur BULLRUN était une diapositive disant "ne pas poser de questions". Vous savez pourquoi? Ce sont des informations ECI SCI Top Secret. Seulement quelques-unes desles cryptanalystes de la NSA le savent.
"Wikipédia: attaques AES connues du public" - C'est juste ça.* Attaques connues du public *.Qu'est-ce que la NSA sait briser?Il y avait une autre diapositive NSA divulguée disant qu'ils avaient classé les techniques * en interne * contre des chiffrements par blocs comme AES.Faites confiance à AES à vos risques et périls.Le chiffrement avec deux algorithmes est une idée beaucoup plus sûre, par ex.AES-CTR avec une clé, puis ChaCha20 avec une autre clé.
simbo1905
2015-01-11 19:21:36 UTC
view on stackexchange narkive permalink

La solution décrite par Tom Leek ci-dessus a été mise en œuvre par le magasin de documents en nuage OpenSource ownCloud. Le modèle de chiffrement est décrit ici.

Comme indiqué dans d'autres réponses, vous pouvez faire la même chose avec OpenPGP / GPG, ce que j'ai décrit dans une réponse à une question relative. Pour répéter brièvement l'approche standard:

  1. Chaque utilisateur dispose d'une paire de clés publique / privée
  2. 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 support. C'est ce qu'on appelle la clé de fichier
  3. Chaque fois qu'un utilisateur a accès au fichier, la clé de fichier est chiffrée avec la clé publique de l'utilisateur

Plus précisément, vous voulez être capable de fournir la clé de fichier lorsque la loi l'exige. C'est une fonctionnalité opt-in d'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 de passe de sa clé privée et peut demander à l'administration de lui accorder à nouveau l'accès au fichier.

Une chose à noter est qu'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 externe hors juridiction chiffré avec ses propres clés, puis d'écrire uniquement l'URL (généralement un GUID de 128 bits) dans votre système. Bien que cela soit loin d'être idéal en termes de complexité du système, cela peut vous éviter d'avoir à vous conformer à une loi dangereuse et oppressive; car vous ne pouvez transmettre que des pointeurs vers les données.

Je pense qu'au moins un pays qui met en œuvre 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 est de laisser les utilisateurs du système crypter et écrire sur leurs propres lecteurs de réseau local 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.

Je suis très mécontent d'apprendre que je vis dans un pays avec une telle loi http://goo.gl/NdC2T2
Cette réponse ne fonctionne malheureusement pas pour nous car il y a suffisamment d'informations stockées sur le serveur pour pouvoir décrypter les documents stockés.Par conséquent, il est possible pour les autorités d'obtenir le document clair.
J'ai répondu au corps de la question où l'auteur est tenu par les autorités de pouvoir décrypter le document.si votre situation ne ressemble pas à la leur, la réponse à leur situation ne vous aidera pas.il est possible de faire un chiffrement et un déchiffrement au niveau du client de sorte que le serveur ne puisse déchiffrer aucun contenu.utilisez des vérificateurs de mot de passe SRP (et non des mots de passe salés) afin que vous ne puissiez même pas vous authentifier en tant que client (par exemple, thinbus-npm).permettre aux clients d'échanger des clés publiques et des clés de fichier cryptées avec des clés privées.utilisez le partage de secret de shamir pour la récupération de mot de passe peer-2-peer.
faire tout le cryptage sur le client (navigateur / téléphone).crypter les clés privées avec un mot de passe et les stocker sur le serveur (srp signifie que vous ne connaissez pas le mot de passe).s'ils perdent leur téléphone, ils peuvent télécharger la clé privée et l'utiliser.utilisez le partage secret shamir sur le téléphone pour sauvegarder le mot de passe à vos amis.le mot de passe ne peut être récupéré que sur leur téléphone.tout ce que vous devez vous assurer, c'est qu'ils utilisent un mot de passe très fort.Vérifiez le hachage par rapport à la base de données Pwned Passwords et utilisez un vérificateur de mot de passe fort sur le client.Q.E.D.
paj28
2014-10-30 13:50:24 UTC
view on stackexchange narkive permalink

En tant que 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 allez utilisez 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 afficher 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 que cela n'ajoute pas beaucoup de sécurité. Vous n'avez pas vraiment expliqué quel avantage vous souhaitiez pour le chiffrement par utilisateur, mais je suppose que c'est pour protéger les documents au cas où le serveur serait électroniquement ou physiquement compromis. Ces deux événements doivent être des événements extrêmes: vous devez prendre des précautions standard telles que le pare-feu pour éviter que cela ne se produise. Mais si un événement aussi extrême se produit, un attaquant avancé peut quand 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écrypter les documents.

Merci. L'objectif est en effet de protéger l'utilisateur des documents téléchargés contre le vol par un tiers malveillant. La question est formulée dans la perspective de notre implémentation actuelle et de la manière de la changer. Pourtant, le chiffrement du disque entier peut être une meilleure solution.
Je suis d'accord avec la plupart de ce que vous avez dit, mais le dernier point.Le fait est que les documents existants ne peuvent être décodés que si la clé privée est compromise et non les informations de connexion.
CompanyDroneFromSector7G
2014-10-31 16:09:20 UTC
view on stackexchange narkive permalink

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 a une paire de clés asymétrique qui est utilisé pour sécuriser leurs documents. Les clés publiques sont stockées en texte brut, mais les clés privées sont chiffré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, il est déchiffré et une copie est créé et chiffré à 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 en utilisant sa clé privée sécurisée.

Évidemment, s'il est partagé avec plusieurs utilisateurs, il doit y avoir une copie pour chacun.

"Le prix de la liberté" ... en fait, cela me semble l'opposé de la liberté, mais ok
@iCodeSometime Oui, c'était de l'ironie.
madscientist159
2014-10-30 07:25:55 UTC
view on stackexchange narkive permalink

Étant donné que les exigences énoncées obligent le chiffrement à être essentiellement destiné au «spectacle» (théâtre de sécurité?) et à la protection de base contre le vol, et non à une protection sécurisée au niveau du document, je recommanderais un chiffrement de base du disque complet à l'aide de LUKS ou similaire. De cette façon, vous disposez de la clé principale de l'ensemble de l'archive et pouvez utiliser des schémas non cryptés pour contrôler l'accès par utilisateur aux différents documents. Le cryptage par document ne vous achète vraiment rien sauf des tracas à la lumière de l'exigence n ° 1.

Aussi, j'aimerais appuyer la réponse 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.

Je ne suis pas non plus satisfait de l'aspect éthique de toute la question, en fait, j'essaie de voir comment nous pouvons minimiser les dommages. Veuillez également consulter le paragraphe * mise à jour * dans la question.
Compris. En reculant la question technique et en supposant que vous et le gouvernement avez des droits d'accès identiques (par la loi), comme indiqué, je ne vois aucun avantage au cryptage par document. En d'autres termes, vous et le gouvernement partagez les privilèges root sur un système multi-utilisateur; pour vous conformer à cette loi, vous pouvez tous les deux lire n'importe quel document à tout moment. Le simple fait d'avoir un compte root ne rend pas un système multi-utilisateur non sécurisé; cela revient à savoir qui utilisera ce pouvoir et dans quel but. J'aurais aimé savoir de quel pays il s'agissait pour qu'il puisse figurer sur une liste d'endroits où vivre ...


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...