|
|
Le contenu de Dropbox est chiffré, mais pas confidentiel
Guillaume Champeau -
publié le Mercredi 15 Juin 2011 à 12h56 -
posté dans High-Tech
La gratuité a un coût. Lorsqu'un utilisateur envoie des fichiers sur Dropbox, ceux-ci sont chiffrés avec un algorithme et une clé de chiffrage en principe suffisants pour garantir la confidentialité des données stockées. Mais Dropbox conserve un double de la clé, et ne se prive pas de l'utiliser pour réaliser des économies dans ses data-centers.
Parmi ses promesses, Dropbox annonce que "tous les fichiers stockés sur Dropbox sont chiffrés (AES-256)", ce qui doit garantir la confidentialité de leur contenu. Impossible de les lire sans posséder la clé de déchiffrage. Or c'est là que réside l'ambiguïté, comme l'explique Sylvain Métille :
Dropbox a ainsi mis son contrat en conformité avec ses pratiques, sans abandonner le stockage de la clé de chiffrement. Il apparaît d'ailleurs évident que le service utilise cette clé dont il possède le double, puisque "pour éviter de stocker un fichier déjà téléchargé par un autre utilisateur, Dropbox compare les fichiers avec ceux déjà enregistrés et n'en conserve qu'une seule version". Or il serait techniquement impossible de comparer les fichiers sans les déchiffrer. L'option choisie par Dropbox se fait au détriment de la vie privée de ses clients. "Les services de sauvegarde en cloud n'ont pas besoin de concevoir leurs produits de cette manière", faisait remarquer Christopher Soghoian en avril dernier, lors de ses révélations. "Spideroak et Tarnsap sont deux services concurrents qui chiffrent les données de leurs utilisateurs avec une clé connue seulement de l'utilisateur. Ces sociétés ont choisi de privilégier d'abord la vie privée de leurs utilisateurs, mais l'effet de bord est qu'ils ont besoin de davantage d'espace de stockage. Si 20 utilisateurs uploadent le même fichiers, les deux sociétés conservent 20 copies ce fichier". à lire aussi
  Prix indiqués avec livraison
40
Commentaires à propos de «Le contenu de Dropbox est chiffré, mais pas confidentiel»
 Inscrit le 06/07/2010
147 messages publiés
Envoyer un message privé
Diti
le 15/06/2011 à 13:09
Arf… Bon ben, vivement Syncany (voire FTPBox ) ! Dommage pour Dropbox.
[message édité par Diti le 15/06/2011 à 13:09
]
Répondre
Le problème était connu.
De plus pas mal de gens mettent aussi pas mal de photos dans l'espace public. Il faut prendre ce service pour ce qu'il est: échanger des fichiers légaux et sans données sensibles sur plusieurs de ses plateformes (PC tablettes & téléphones). Ni plus ni moins. [message édité par L-observateur le 15/06/2011 à 13:52
]
Sur quels critères considèrent ils que c'est le meme fichier et par conséquent , qu'il peuvent le supprimer . Taille, extention, nom ????
exemple: X et Y downloadent ubuntu-11.04-desktop-fr.iso , taille 643Mo. à la fin du down; X l 'envoi direct sur dropbox. à la fin du down; Y envoi par mégarde Kubuntu mal renommé en ubuntu-11.04-desktop-fr.iso , taille 643Mo aussi . dropbox vire un doublon , celui de X , Donc quand X récupère son fichier il récupère Kubuntu ?????????? Des détails sur le principe de fonctionnement du "repérage doublon" ? Je vois pas comment ça peut marcher sans aucune erreur.  [message édité par speed le 15/06/2011 à 13:26
]
Une des solutions possible serait de faire une somme de contrôle (Checksum, voir http://fr.wikipedia....wiki/Checksum). Si deux checksums sont identiques, les fichiers sont les mêmes. 
speed, le 15/06/2011 - 13:20 Non ! car il doit en plus y avoir une vérification sur le hashage Si les deux sommes sont différentes alors les deux fichiers sont différents (l'inverse n'est pas vrai !) le nom et la taille ne suffisent pas !
guicab, le 15/06/2011 - 13:28 Non, c'est l'inverse : si deux sommes sont différentes, alors les fichiers sont différents ! [message édité par ccomp le 15/06/2011 à 13:33
]
Hash MD5 a la volée, lors de la reception du fichier, une signature est créée, à l'issue du transfert le système est alors capable de voir si le fichier est déja stocké ou pas. En clair cela permet d'économiser du stockage mais en aucun cas de la bande passante puisque techniquement le fichier est envoyé à DropBox qui choisit alors de le stocker ou non 
franch, le 15/06/2011 - 13:37 Y a un truc, que je ne comprends pas.....En quoi le fait que Dropbox possède la clé lui permet d'effectuer une comparaison de checksum (si c'est bien la méthode utilisée) (si la clé est envoyée en meme temps que le fichier)? Et inversement en quoi les autres services de cloud ne peuvent pas faire pareil lorsqu'ils recoivent le fichier ainsi que la clé ?
@ guicab;Killua , ccomp et franch . Merci pour vos réponses , je comprends mieux maintenant .
Allez savoir pourquoi ,j' étais persuadé que le hashage était une chose qui ne fonctionnait uniquement que dans l' univers du p2p  un petit coup de wiki hash MD5 et hop , je me coucherais moins bete ce soir  Edit : Par contre ça ouvre des perspectives que j' imaginai pas . tout dépends si l'identification ne peut se faire que fichier 100% uploadé ou pas , mais s' il est possible de savoir à 15% du up que le data center le possède j 'imagine le gain de temps pour l utilisateur , l économie de BP toussa . ça reviens presque à envoyer une requette as tu le fichier untel , si non upload et si oui link et hop . [message édité par speed le 15/06/2011 à 13:54
]
Il est possible de savoir si deux fichier sont identiques même s'ils sont chiffré si le mode d'opération est de l'ECB... enfin, j'immagine que c'est réalisable.
http://fr.wikipedia.org/wiki/Mode_d'opération_(cryptographie)#Dictionnaire_de_codes_:_.C2.AB_Electronic_codebook_.C2.BB_.28ECB.29 
Pour utiliser ce genre de services, il suffit de chiffrer soi-même ses données avant de les envoyer dans le nuage. On peut par exemple coupler Dropbox et encfs et utiliser la même clé sur les machines synchronisées. Ce qui est dans le nuages reste inaccessible aux curieux.
Je suis utilisateur pro de dropbox, il est effectivement vrai, qu il y a quelques temps, il y avait bien un system de cache pour les fichier, aujourd'hui c est fini
speed, le 15/06/2011 - 13:20 Plutôt par hashage je pense. Il y a vraiment peu de chance qu'un même fichier ait le même nom, même taille et même hash.
bah 7zip chiffré et protégé par mot de passe et voila... edit : liladou dit que ce serait possible de déchiffrer un fichier malgré tout. qqun a un avis ? si on fait 7zip avec un chiffrement aes par dessus et mdp ca protège ou pas ? [message édité par pleindeuss le 15/06/2011 à 14:13
]
Zut alors. J'utilise l'offre gratuite de Dropbox à des fins professionnelles pour le backup de mes bases de données et comme plateforme de téléchargement pour les fichiers trop lourds pour envoyer par mail. Elle est commercialement la meilleure offre sur le marché avec ses 2Go (il ne m'en faut pas plus, mais pas moins de 1 Go). Son pire inconvénient reste la quantité de mémoire nécessaire au programme qui tourne en permanence en arrière-plan (de l'ordre de 50 Mo sur mes 4Go et entre 5 et 10 % de CPU sur un quadricoeur 2,8 Ghz en cours de synchronisation). C'est plutôt lourd pour un programme de veille.
Alors, qu'un employé lambda de chez Dropbox puisse supposément accéder à mes dernières factures ou à mes lexiques est gênant mais pas un danger pour mes activités. en revanche, qu'un hacker récupère des clés stockées chez Dropbox et foute le boxon dans l'espace de stockage (pour distribuer un logiciel malicieux par exemple, qui sera automatiquement téléchargé sur les PC connectés pour synchronisation), ça, ça fout les boules. De plus, il y a légalement tout simplement un certain problème de confidentialité. Théoriquement, je dois respecter la confidentialité de tous les échanges avec mes clients. Le fait de savoir qu'un tiers peu dans l'absolu accéder à mes fichiers, me met en tort. Bref, on n'est jamais aussi bien servi que par son propre serveur FTP, encore faut-il avoir les connaissances requises pour en assurer la sécurité.
Ah je suis désolé avec mes tas de questions mais j' aime bien comprendre .
Le principe décris dans l'article est visiblement pour le data center d éviter la redondensce des fichiers et gagner en espace de stockage . l'aspect économie je le cerne bien , mais l' aspect débit me pose une interrogation. si 100 personnes téléchargent simultanément un meme fichier (mais unique) ce fichier vas provenir selon le downloadeur du hd 127 du hd 254,du hd 752 etc . Mais là le fichier mutualisé ne proviens que d une seule source . Alors j imagine les hd des datas center differents de ceux de mon pc , gros cache , vitesse elevée mais quand meme ...... [message édité par speed le 15/06/2011 à 14:20
]
En même temps, s'ils cherchent à économiser de l'espace de stockage, ils peuvent tout simplement supprimer l'option de récupération de fichiers historiques, hein. Le back-up de versions précédentes d'un même fichier n'a d'utilité que pour une infime partie de la clientèle (tout du moins en offre gratuite).
Ce n'est pas une preuve: le hash peut très bien être calculé du côté client *avant* d'envoyer le fichier. De cette manière, la sécurité est conservée, et le fichier n'a même pas besoin d'être envoyé s'il existe déjà, donc économise de la bande passante. 
Quelque chose m'échappe peut-être, mais il me semble que si j'avais besoin de stocker des données sensibles dans le nuage, je les crypterais en local avant de les expédier.
speed, le 15/06/2011 - 14:17 Il peut y avoir des economies en bande passante, mais legere, en effet, on parle d'un hash pour comparer les fichiers, sauf qu'il y a un client lourd, si c'est ce client lourd qui genere ce dit hash et l'envoie au serveur, le serveur peut repondre "je le connais deja, pas besoin de le DL". Donc economie de bande passante pour l'upload. Maintenant pas dans l'autre sens, sur internet il n'existe pas de Broadcast ou de multicast a proprement parler, seulement de l'unicast. Comprendre, quand on envoie des fichier a 10 personnes, il y aura 10 connection sortante et pas une seule avec les clients qui prennent ce qu'ils veulent (comme le broadcast), donc 10 personnes telecharge le meme fichier, 10 fois la bande passante necessaire... Voir Broadcast, multicast unicast sur wikipedia pour le completement necessaire
Je vous conseille plutot un service comme spideroak, là c'est du "zéro knowledge managment". Inconvénient c'est que si on perd son mot de passe on ne peut rien récupérer mais par contre personne d'autre que moi ne peut accéder à mes données !
https://spideroak.co...e0636e9f3b56d14 Il pourrait même peut être devenir open source d'ailleurs, mais bon ils l'annoncent depuis longtemps sans le faire...
Je vous conseille plutot un service comme spideroak, là c'est du "zéro knowledge managment". Inconvénient c'est que si on perd son mot de passe on ne peut rien récupérer mais par contre personne d'autre que moi ne peut accéder à mes données !
https://spideroak.co...e0636e9f3b56d14 Il pourrait même peut être devenir open source d'ailleurs, mais bon ils l'annoncent depuis longtemps sans le faire...
Ce que je comprends pas c'est qu'on peux effectivement gagner de la place sans déchiffrer: Il suffit de comparer les hash des fichiers (à condition de choisir un algo de hash fiable, donc sans méthode connue pour créer des collisions). Ensuite on stocke le fichier binaire (chiffré) à l'identique... non ? (ça implique que chaque fichier soit chiffré séparément, et non pas comme dans une seule grosse archive)
Nul besoin de savoir la clé pour ça: Si 2 fichiers chiffré ont le même hash , alors ce sont les mêmes, et on ne peux les stocker qu'une fois. C'est de la déduplication "classique". Il n'en est pas moins vrai que le chiffrement de dropbox se fait coté serveur, via une clé que le client n'a pas généré: C'est donc potentiellement vulnérable, à la fois par malice (employé indélicat, intrusion,..) ou par réquisition judiciaire. La "solution" est simple, et valable pour TOUT services de ce type, quel qu'ils soient: Chiffrer localement avant d'envoyer si les documents sont confidentiels, quitte à utiliser une méthode qui supporte plusieurs clés pour plusieurs utilisateurs (type fichier image LUKS sous linux, FreeOTFE sous windows) Dans le cas de fichiers publics , par définition pas de chiffrement nécessaire.
bunam, le 15/06/2011 - 15:33 C'est pas que une question de simplicité, c'est que ce serait stupide: si les utilisateurs sont pas trop cons, ils chiffrent en local d'abord. Et alors la technique du hash sert plus à rien. Donc pourquoi implementer une technique qui tend à être peu efficace, en plus d'être vraiment douteuse niveau sécurité/confidentialité? spideroak a raison (encore que tarsnap est plus a recommender car open source). Dropbox fout par terre sa feature "chiffrement" avec cet histoire de hash.
obcd -> Non ça ne fonctionne pas, si le serveur n'a pas la clef il ne peut pas économiser de la place.
Parce que si effectivement stocké en clair le hash d'un fichier chiffré permettrait de savoir quand un autre utilisateur poste le même, cela ne permettrait pas à l'autre utilisateur de pouvoir lire le fichier chiffré du premier utilisateur, il faut donc stocké son fichier chiffré à lui également (à moins que tout le monde est la même clef et du coup le chiffrement n'aurait aucun intérêt). Sinon un service de stockage où l'on poste des fichiers sans pouvoir les relire c'est pas terrible. Ensuite pour des raisons de sécurité ce serait nul de stocké un hash clair d'un fichier chiffré. Sinon quand on détecte que deux fichiers sont identiques il suffit de connaître celui de l'un des deux utilisateurs pour connaître celui de l'autre. Et puis qu'un fichier soit publique ne signifie pas forcément que tu veuille que l'on soit au courant que tu l'ai. [message édité par mac.aque le 15/06/2011 à 15:56
]
@obcd
Nan, ce que tu dis ne fonctionnerait que si tout le monde chiffrait avec la même clé, ce qui aurait peu d'interet. Après chiffrage avec 2 clé différentes du même fichier, on obtient deux "fichiers" différents... qui auront donc un hash différent ;-). C'est le "prix" du chiffrage. Autre exemple: impossible de mettre du traffic SSL en cache. D'ailleurs si tu réussissais à le faire, tu te transformerais en attaquant du type man-in-the-middle. [message édité par thedarklord le 15/06/2011 à 16:31
]
@mac.aque , @thedarklord :
Oui, en fait vous avez carrément raison. Désolé pour le bruit, me suis complètement fourvoyé.
Et bien renseigne toi sur le net, il y a des tonnes de softs qui font ca depuis des années sans jamais eliminer un faux doublon ( par contre en cas de doute ils conservent le doublon soupsonné mais non avéré pour eviter la perte de data). Le fonctionnement de ces logiciels est connu ( tu as tous les details en ligne) et efficace, j en utilise depuis des annes sur les serveurs que j administre dans ma boite, et jamais perdu de fichier, mais quelques doublons sont présent...
Waylandes, le 15/06/2011 - 14:00 peut etre mais l article ne parle pas du cache ! 
speed, le 15/06/2011 - 13:20 Après avoir comparé le nom, puis la taille, il n'est pas difficile de comparer bit à bit (ou tranche par tranche) le contenu de deux fichiers. Surtout que dès qu'il y a un bit de différence, cela s'arrête. Il faudrait pas de bol pour que ce soit le dernier bit du dernier octet qui soit différent.
1) Ton serveur ftp peut être en interne dans ta société, sans accès Web. 2) Tu peux crypter tes fichiers AVANT de les envoyer à DropBox (il existe plein de solutions pas chères - Steganos par exemple)
Liane_, le 15/06/2011 - 14:34 Je ne pense pas... Tu calcules le hash cote client: - il est different des hashs deja connus, ton fichier est different, il faut le transmettre - il est egal a un autre hash: c'est peut-etre le meme fichier, ou non. Il faut le transmettre en entier, et faire la comparaison avec l'autre fichier, ce qui explique que les clefs soient conservees pour pouvoir dechiffrer le fichier deja en stockage. [message édité par mif92 le 15/06/2011 à 18:54
]
mif92, le 15/06/2011 - 18:53 Non, le calcul du hash, quel qu'il soit, est sensé être bon, que ce soit côté client ou serveur. L'algorithme n'est pas en cause, seule la procédure. Par contre... comme mentionné précédemment, cette méthode n'est pas utilisable car même si le fichier *non crypté* est identique, un 2ème utilisateur du même fichier ne peut/doit pas connaître ma clé de cryptage, et donc ne pourra pas récupérer *ma* version cryptée de ce fichier. Mon intervention était donc... au moins à moitié fausse: - il est effectivement possible de déterminer si un fichier est identique avant de l'encrypter - mais cela ne sert à rien :-/ Je suis donc d'accord avec les contributeur précédents, ainsi bien sûr que l'auteur de l'article: il n'est pas possible de manière sécurisée de procéder à ce genre *d'optimisation* 
Sans vouloir faire de pub le service Wuala de LaCie fournit à peu près le même service que DropBox (1GO gratuit) mais les fichiers sont chiffrés côté client avant d'être envoyé.
Si on perd la passphrase on est mort par contre.
Liane_, le 15/06/2011 - 14:34 C'est même lamentable que les développeurs de DropBox n'aient pas pensé à le faire côté client plutôt que côté serveur... P'tet que les développeurs de solutions proprios centrées sur l'infrastructure serveur devraient parfois, quand même, regarder un peu plus les technos utilisées par les solutions distribuées client-to-client, style P2P. Franchement, recevoir 600 Mo de données puis les déchiffrer illégalement pour calculer le hash le tout en consommant et bande passante et ressource de stockage temporaire et ressource de calcul alors qu'on maîtrise le code du logiciel côté client qui intervient en *amont* de tout cela et sur lequel la ressource de calcul et de stockage ne vous coûte pas un rond à vous entreprise, c'est tellement... tellement... Pfff. J'préfère pas y penser, tiens.
Réactif sur le coup, mais le log sans mp ça la fout vraiment mal... [message édité par ddgun le 21/06/2011 à 11:58
]
Tous les champs doivent être remplis. Tous les champs doivent être remplis. Tous les champs doivent être remplis. |
A LA UNE
LES + COMMENTÉS
  6 offres à partir de 43 €
 10 offres à partir de 37 €
Télécharger
pro evolution soccer,
libreoffice,
virtualgirl hd,
bittorrent emule island,
navigateur web tor,
anti spam,
firefox,
ssc service utility,
Accès rapide :
eMule (et mods eMule) |
Photo numérique |
Outils Réseau |
Codecs et plugins |
Nettoyeurs |
Optimisation |
Navigateur Web |
|
Sylvain Métille, auteur du blog 
