Sauvegarde en ligne: comment le chiffrement et la déduplication pourraient-ils être compatibles?
Bitcasa, un service de sauvegarde en ligne "qui entrera bientôt en version bêta", prétend avoir à la fois une déduplication (vous ne sauvegardez pas quelque chose déjà dans le cloud) et un chiffrement côté client.
Une recherche de brevet ne rapporte rien avec le nom de leur entreprise, mais les brevets pourraient bien être en préparation et pas encore accordés.
Je trouve la revendication assez douteuse avec le niveau d'information dont je dispose maintenant, quelqu'un sait-il plus sur la façon dont ils prétendent y parvenir? Si les fondateurs de la société n'avaient pas de solides antécédents commerciaux (Verisign, Mastercard ...), j'aurais tout de suite classé le produit dans l'huile de serpent, mais il y a peut-être plus.
Edit: a trouvé un Tweet inquiétant: https://Twitter.com/#!/csoghoian/status/113753932400041984 , la clé de cryptage par fichier serait dérivée de son hachage, donc définitivement pas comme l'endroit où stocker votre collection de films torrent, pas que je ferais jamais ça.
Edit2: Nous l'avons en fait deviné, ils ont utilisé ce qu'on appelle le chiffrement convergent et donc quelqu'un qui possède le même fichier que vous peut savoir si le vôtre est le même, car ils ont la clé. Cela fait de Bitcasa un très mauvais choix lorsque les fichiers que vous souhaitez garder confidentiels ne sont pas originaux. http://techcrunch.com/2011/09/18/bitcasa-explains-encryption/
Edit3: https://crypto.stackexchange.com/questions/729/is-convergent-encryption-really-secure avoir la même question et des réponses différentes
Je n'ai pas réfléchi aux détails, mais si un hachage sécurisé du contenu du fichier était utilisé comme clé, alors (et seulement) les clients qui "connaissaient le hachage" seraient en mesure d'accéder au contenu.
Essentiellement, le stockage en nuage agirait comme une table Rainbow collective partielle (très clairsemée, en fait) pour la fonction de hachage, lui permettant d'être "inversée".
De l'article: "Même si la RIAA et la MPAA frappaient aux portes de Bitcasa, assignations à la main, tout ce que Bitcasa aurait serait une collection de bits chiffrés sans aucun moyen de les déchiffrer." - true car bitcasa ne contient pas le mappage objectid/filename-to-hash/key; seuls leurs clients le font (côté client). Si la RIAA/MPAA connaissait les hachages des fichiers en question (bien connus pour les MP3 de chansons spécifiques, par exemple), ils seraient en mesure de décrypter et de prouver que vous en aviez une copie, mais ils devraient d'abord savoir quel objet de stockage dans le cloud/fichier détenu quelle chanson.
Les clients devraient conserver le hachage pour chaque objet stocké dans le cloud, et leur nom local, bien sûr, pour pouvoir y accéder et le décrypter.
Concernant certaines des autres fonctionnalités revendiquées dans l'article:
- "compression" - ne fonctionnerait pas côté serveur (le contenu chiffré ne se compressera pas bien) mais pourrait être appliqué côté client avant le chiffrement
- "accessible partout" - si le mappage objid-to-filename-and-hash/key est uniquement sur le client, les fichiers sont inutiles à partir d'autres appareils, ce qui limite l'utilité du stockage dans le cloud. Pourrait être résolu par ex. stockant également la collection de tuples objid-to-filename-and-hash/key, côté client chiffré avec une phrase de passe.
- "algorithmes de déduplication brevetés" - il doit y avoir plus de choses que ce qui précède pour justifier un brevet - éventuellement une déduplication au niveau d'un bloc plutôt qu'au niveau d'un fichier?
- la RIAA/MPAA pourrait venir avec une assignation et une copie cryptée avec son propre hash de la chanson/du film dont ils soupçonnent les gens d'avoir des copies. Bitcasa serait alors en mesure de confirmer si ce fichier avait été stocké ou non. Ils ne seraient pas en mesure de le décrypter (sans que RIAA/MPAA leur donne le hachage/la clé), et (en particulier s'ils n'appliquent pas les quotas par utilisateur car ils offrent un "stockage infini"), ils pourraient ne pas avoir conservé les journaux de quels utilisateurs l'ont téléchargé/téléchargé. Cependant, je soupçonne qu'ils pourraient être tenus de supprimer le fichier (en vertu des règles de la sphère de sécurité DMCA) ou éventuellement de conserver le contenu, puis de journaliser tous les comptes qui le téléchargent/téléchargent à l'avenir.
L'annonce commerciale à laquelle vous créez un lien et le site Web de la société contiennent très peu d'informations; et agiter "20 brevets" comme preuve de compétence est bizarre: les brevets ne prouvent pas que la technologie est bonne , seulement qu'il y a des gens qui ont misé quelques milliers de dollars sur l'idée que la technologie se vendra bien .
Voyons s'il existe un moyen de concrétiser ces promesses.
Si les données sont cryptées côté client, il doit y avoir une clé secrète Kf pour ce fichier. Le fait est que Bitcasa ne sait pas Kf. Pour implémenter la déduplication et la mise en cache et, plus important encore, le partage, il est nécessaire que chaque utilisateur crypte un fichier donné f finira par utiliser le même Kf. Il existe une astuce astucieuse qui consiste à utiliser le hachage du fichier lui-même, avec une fonction de hachage appropriée (par exemple, SHA-256), comme Kf. Avec cette astuce, le même fichier se retrouvera toujours dans le même format crypté, qui peut ensuite être téléchargé et dédoublonné à volonté.
Un utilisateur aurait alors un local store (sur son ordinateur) de tous les Kf pour tous ses fichiers, ainsi qu'un ID de fichier. Lorsque l'utilisateur A souhaite partager le fichier avec l'utilisateur B, l'utilisateur A "clique avec le bouton droit pour obtenir l'URL de partage" et l'envoie à B. Vraisemblablement, l'URL contient l'ID du fichier et Kf. Le texte dit que les utilisateurs A et B doivent être des utilisateurs enregistrés pour que le partage fonctionne, donc "l'URL" est probablement interceptée, sur la machine de B, par un logiciel qui extrait l'ID et Kf à partir de cette "URL", télécharge le fichier depuis le serveur et le déchiffre localement avec sa nouvelle connaissance acquise de Kf.
Pour une résilience et une facilité d'utilisation supplémentaires, l'ensemble de clés connues Kf pour certains utilisateurs pourrait également être stocké sur les serveurs - il vous suffit donc de "vous souvenir" d'un seul Kf, que vous pouvez transférer d'un ordinateur à un autre.
Je dis donc que ce que Bitcasa promet est possible - car je saurais le faire, et il n'y a rien de vraiment nouveau ou de technologiquement avancé ici. Je ne peux pas prétendre que c'est ce que fait Bitcasa , seulement que c'est ainsi que je le ferais. La partie "dure" intègre cela dans les systèmes d'exploitation existants (de sorte que "l'enregistrement d'un fichier" déclenche le processus de cryptage/téléchargement): certains fonctionnent, mais ne valent guère un brevet, sans parler de 20 brevets.
Notez que l'utilisation de Kf = h (f) signifie que vous pouvez essayer une recherche exhaustive sur le contenu du fichier . Cela est de toute façon inévitable dans un service avec déduplication: en "téléchargeant" un nouveau fichier et en chronométrant simplement l'opération, vous pouvez savoir si le fichier était déjà connu côté serveur ou non.
Bruce Schneier a abordé le sujet en mai http://www.schneier.com/blog/archives/2011/05/dropbox_securit.html lié au problème Dropbox de cette semaine. TechRepublic propose un excellent livre blanc de 7 pages sur le sujet pour le prix d'une inscription par e-mail à http://www.techrepublic.com/whitepapers/side-channels-in-cloud-services-the- cas de stockage avec déduplication dans le cloud/3333347 .
L'article se concentre sur les attaques de canal latéral et de canal secret disponibles dans la déduplication cloud. Les attaques tirent parti de la déduplication entre utilisateurs. Par exemple, si vous saviez que Bob utilisait le service et que son contrat salarial basé sur des modèles était là-haut, vous pouviez en créer des versions jusqu'à ce que vous touchiez son salaire. Succès indiqué par le temps de téléchargement du fichier.
Bien sûr, votre protection consiste à chiffrer avant d'utiliser le service. Cela empêchera toutefois les économies de coûts du service qui le rendent économiquement viable car il éliminerait presque toutes les opportunités de déduplication. Le service n'encouragera donc pas le choix.
En plus des autres bonnes réponses ici, je voudrais vous signaler les deux articles académiques suivants, qui ont été publiés récemment:
Martin Mulazzani, Sebastian Schrittwieser, Manuel Leithner, Markus Huber et Edgar Weippl, Dark Clouds on the Horizon: Using Cloud Storage as Attack Vector and Online Slack Space , Usenix Security 2011.
Cet article décrit comment Dropbox effectue la déduplication et identifie les attaques contre le mécanisme. Ils proposent une nouvelle façon de se défendre contre certaines - mais pas toutes - de ces attaques, en exigeant du client qu'il prouve qu'il connaît le contenu du fichier (pas seulement son hachage) avant d'être autorisé à accéder au fichier.
Danny Harnik, Benny Pinkas, Alexandra Shulman-Peleg. Canaux secondaires dans les services cloud, le cas de la déduplication dans le stockage cloud , IEEE Security & Privacy Magazine.
Ce document analyse trois services de stockage cloud qui effectuent la déduplication (Dropbox, Mozy et Memopal) et souligne les risques de sécurité et de confidentialité qui en découlent. Ils proposent une nouvelle défense contre ces risques, basée sur la garantie qu'un fichier ne sera dupliqué que s'il existe de nombreuses copies, réduisant ainsi la fuite d'informations.
Ces articles semblent directement pertinents pour votre question. Ils démontrent également qu'il y a de la place pour l'innovation sur les atténuations non triviales des risques de déduplication naïve.
Cryptage et déduplication entre utilisateurs arbitraires ne sont pas compatibles si vous souhaitez distinguer certains textes en clair. Si vous n'êtes pas préoccupé par ces types d'attaques, cela peut être sûr.
Si les données ne sont dédoublonnées que pour un certain utilisateur, le serveur ne sait rien de l'équivalence des textes en clair et les attaques qui restent sont vraiment mineures.
Si les données sont dédoublonnées entre un cercle d'amis qui partagent quelque chose qui n'est pas connu du fournisseur de services (faisable automatiquement), seules les personnes de ce cercle d'amis peuvent distinguer les textes en clair (via le timing, etc.).
Mais si les données sont dédoublonnées entre tous les utilisateurs, tout attaquant hypothétique, qui souhaite savoir quels textes en clair sont consultés, doit faire est de stocker le fichier dans le cloud lui-même, puis de surveiller les comptes d'utilisateurs accédant aux mêmes données. Bien sûr, le service peut simplement "ne pas enregistrer" les comptes d'utilisateurs/adresses IP accédant aux données - mais cela n'a rien à voir avec le cryptage et la même "protection" resterait même si les fichiers étaient en clair.
Aucune des autres réponses données ici ne semble proposer quoi que ce soit qui pourrait arrêter cette attaque et je crois que Bitcasa ne le fait pas non plus. Je serais heureux de me tromper cependant.
(Remarque: il y a sont quelques façons de réaliser quelque chose de proche - il y a eu pas mal d'articles publiés sur le stockage sécurisé dans le cloud utilisant toutes sortes de techniques innovantes - mais ce sont de nouvelles recherches et la plupart d'entre elles sera probablement cassé ou rendu irréalisable assez rapidement. Je ne ferais pas encore confiance à mes données sur aucun d'entre eux.)
La même question a été posée lors de l'échange de pile de cryptographie. Veuillez y voir ma réponse, car il existe une subtilité facile à ignorer et qui a été soigneusement analysée par le projet open source Tahoe-LAFS: https://crypto.stackexchange.com/questions/729/is -convergent-encryption-really-secure/758 # 758
Mis à part l'excellente réponse @Misha qui vient d'être publiée sur le `` hachage connu '', le chiffrement côté client supprime efficacement toute autre façon de faire la déduplication à moins qu'il n'y ait une clé d'entiercement, ce qui pourrait entraîner de toute façon d'autres problèmes logistiques.