As I wrote in the previous post dedicated to the Vanish/Unvanish competition, I was quite lukewarm about the new defensive features proposed by the Vanish team. As the Unvanish team clearly stated, those new features [limit the current aggressive Vuze replication strategy, set a threshold replication factor for each DHT entry, spread the secret key shares among 2 DHTs : OpenDHT and Vuze], for sure it will raise the bar for an attacker [in terms of capability to harvest the DHT] but not that much, or at least far from being in an order of magnitude that can resign anybody/any company/any hacker group to spend their expensive time elsewhere.

That’s something to, in my humble and inexperienced opinion, all what is related on security & privacy is based on the fact that breaking the system should be really more expensive/time & resources consuming than the secret itself. That’s the paradigm of current crypto-systems and especially on key length strategies.  So if this ratio value/time is not that bad, the system cannot be qualified as secure and that’s what the Unvanish team has shown with success.

Based on that, and defensive strategies which rely on the DHT replication strategy seems irrelevant, the figures associated are not as big as needed, even if we talk about 1 million Vuze nodes, regarding the consistent living time of a self-destruct message [currently 8 hours or more using a proxy, but I guess the useable delay in the real world should be something between a week and a month], crawling enough nodes to gather all DHT keys is really not that much [considering the time to break a 128bits AES key for example].

So for a while, I really thought those Unvanish guys were right, as they conclude in their paper :

[…] for the time being, Vanish’s security should be viewed with skepticism. Whether DHTs are the best choice for key-share storage remains an open question.

However, as I don’t like to feel I made a mistake or at least I believed Vanish was a wonderful concept [and for sure Bruce Schneier’s last CryptoGram convinced me a little bit more], I tried to think differently, instead of trying to tweak Vuze to only raise the bar, why not setting the privacy as a requirement for a DHTs and according to this assumption, what could help.

And as a result, one answer is really straight forward [maybe too much… I may have forgotten something], the Vuze DHT is a public DHT, any client can join, participate, get and store data… Nice. But what about adding a new option like be able to get and store data but restricted to a part of the clients and then adding some privacy to what could be propagated among the DHT ?

We can think on some complex protocols and so on but let’s try to keep things simple. For example take the example of a huge tree data structure, if you know the path to access the data you’re looking for, that’s extremely fast, but if you only want to crawl the tree (linearly or not) and expect to find something, it is going to be quite long and cpu intensive.

So based on this simple example, let’s do the same, why not adding a code access to private entries ? Any client which wants to store an entry will add an access code, in the case of Vanish it could be as simple of the original message hashing [SHA1, Skein, any kind of hash function as secure and long enough to discourage brute force attack] and any client which wants to retrieve the entry will have to provide the access key (can be hashed to increase security, as usual), in the case of Vanish the message hashing can be added to the self-destruct message header in addition to the L access key [the n key shares DHT indexes].

It looks simple and effective, isn’t it ?

Like that, only the Vuze clients clients which want to decrypt the VDO will be able to retrieve the key shares, any massive crawling attack [means without any Vanish messages as sources] won’t be able to gather any key shares in a realistic time [else it would require some brute force attack on every entry so logically irrelevant].

This add-on would obviously requires some changes on he current Vuze implementation but compared to the current Vanish proposed features :

  • It is fully backward compatible as that’s a new feature to retrieve DHT entries and the “old” way is still possible for public entries
  • It should be easy to implement, only an access code to store and to check to return the hashtable entry
  • It doesn’t affect the current Vuze reliability and replication strategy
  • It doesn’t change really the public DHT philosophy, in letting Vanish to store key shares, it stores private data and more generally if we hope to use DHTs to enable cloud storage, privacy is needed.

Je n’ai pas eu le temps de consacrer un post à Vanish (et tout le bien que j’en pense) mais la publication récente de Unvanish m’a tellement perturbé que quelques mots autour du “comment être sûr que notre vie privée reste privée” me paraissent bienvenus.

Histoire de ne pas parler dans le vide, petit rappel sur Vanish et son concept. Vanish, proposé par des étudiants de l’université de Washington, est un système permettant à chacun de publier [dans “publier”, il y a public, important] des informations sur le web qui au bout d’un certain temps [8 jours prolongeables dans le prototype] disparaitront d’elles-mêmes. Ainsi, prenons un exemple concret, si sur un site communautaire [Facebook, MySpace,…] je décide d’exprimer un point de vue ou plus simplement d’ajouter des informations me concernant [adresse, photos, parcours professionnel,…], comment garantir que ces informations ne seront pas utilisées contre moi [de la simple publicité à un entretien d’embauche en passant par un passage à la douane d’un pays moins ouvert que le notre] dans un futur plus ou moins proche ? C’est le but de Vanish, fournir un mécanisme qui rendent ces informations volatiles.
Certes le site communautaire, un individu peut toujours faire une copie des ces informations lorsqu’elles sont encore “visibles” mais en tout cas, la source originale aura disparue (et d’un point de vue juridique, n’est-elle pas la seule à faire foi ?).

Techniquement parlant, le concept de Vanish est aussi simple que brillant (enfin de mon point de vue, un peu comme Rijndael/AES), le message original, avant d’être publié, est tout d’abord crypté avec une clef symétrique fraichement générée [i.e. à usage unique], cette clef est ensuite découpée (selon le secret partagé de Shamir) et stockée sur les noeuds de DHTs publiques (OpenDHT et Vuze).

A première vue, et probablement du fait que le cerveau humain a bien du mal à percevoir ce qui grand [compter jusqu’à un million c’est très long pour le commun des mortels mais une broutille pour un ordinateur], je me suis laissé abuser par la taille d’un réseau tel que Vuze [1 millions de noeuds en moyenne] et la capacité à une personne plus ou moins mal intentionnée à parcourir le DHT, bénéficier de la stratégie très aggressive de Vuze en termes de réplications [en gros pas besoin (et loin de là) de parcourir le un million de noeuds pour récupérer tranquillement toutes les parties de clefs Vanish] et rapidement et à moindre coût.

C’est ce qu’ont montré des étudiants de Princeston et de l’université du Texas [2] en développant un client Vuze très optimisé (en empreinte mémoire et cpu) qui sur une seule machine peut être lancé un bon millier de fois et donc représenté un millier de noeuds Vuze. En multipliant les connexions/réplications des entrées du DHT des noeuds à proximité [XOR metric]/déconnexion, très rapidement, ces petits futés ont montré qu’ils étaient capables de récupérer pratiquement 100% des clefs pour décrypter les messages Vanish après leur hypothétique temps de vie.

Suite à ces derniers développements, ces détracteurs de Vanish se sont empressés d’affirmer :

Unvanish shows that the Vanish system does not provide the privacy guarantees it claims, by making Vanish messages recoverable after they should have disappeared. Our goals with this work are to discourage people from relying on the privacy of a system that is not actually private.

Unvanish montre que Vanish n’apporte pas les garanties de confidentialité contrairement à ce qu’il affirme, en récupérant les messages après qu’ils eussent dû disparaître. Nos buts avec ce travail [Unvanish] sont de décourager quiconque de se reposer sur la confidentialité d’un système qui n’est pas réellement privé.

Cette affirmation m’a tout d’abord paru gratuite et “à justifier”. En effet, l’expérience a montré  qu’un système dit “privé” ne le reste souvent pas bien longtemps sous l’effet de pressions. Dans le cas de procès, il n’est pas rare qu’il soit demandé la mise à disposition des clefs de cryptage si cela est nécessaire et affaire symbolique, Hushmail, entreprise promettant la confidentialité et la sécurité des emails envoyés par son biais, a dû se plier à la justice Canadienne [3]. Alors si qu’il soit privé ou non… je ne suis pas sûr que le problème soit ici. Et c’est bien ce qui est intéressant dans le cas de l’utilisation d’un DHT public, par essence distribué, sans contrôle, immatériel… Si personne ne se donne le mal de profiter du système et d’en copier le contenu, je pense que l’on peut vraiment dire que les données disparaissent bien d’elles-mêmes.

Cependant…. dans sa forme actuelle, l’implémentation de Vanish (0.1 du moins) ne garantit pas qu’un tiers veuille un jour stocker les clefs utilisées par Vanish pour une utilisation ultérieure (compagnie, gouvernement, pirates…). Mais c’est à mon goût un problème technique, et je suis persuadé que le concept Vanish n’est pas mort pour autant…

A suivre !

Comme chaque mois, j’ai reçu avec plaisir et impatience le Crypto Gram de Bruce Schneier (que je ne cesserai de paraphraser, soyez-en sûr) et un article m’a particulièrement titillé : Les protocoles auto-appliqués (Vous pardonnerez la traduction plus ou moins littérale, je n’ai aucune idée de la locution exacte dans notre belle langue). En un mot commençant, les protocoles auto-appliqués forment une catégorie de protocoles pour lesquels un tiers n’est pas nécessaire pour garantir le bon déroulement de celui-ci.

En effet, plus le temps passe et plus notre société [individualiste] forge des protocoles nécessitant une tierce personne pour assurer les deux parties que tout s’est déroulé normalement [du moins justement]. Aujourd’hui la parole donnée n’a probablement plus la valeur qu’elle pouvait avoir il y a quelques siècles et qui aujourd’hui irait acheter sur ebay un quelconque bien en faisant totallement confiance à un inconnu plus ou moins immatériel ?

Et ces protocoles à 3 parties sont certes relativement efficaces mais coûteux et en général la tierce personne n’intervient qu’en cas de litige [quand les problèmes surviennent].

Though, there are ways to avoid this complexity [and troubles], that’s self-enforcing protocols, as Bruce mentionned, for example, how kids share a cake equally, the first one cut the takes in 2 parts and the second one decides which part he will take. So in this case, respecting the protocol [no cheating] is the only way to do not loose anything.

Read the rest of this entry »

Hello Metaverse !

20/09/2009

One question still struggles me… Should this blog be in french or not ? Both ? Bah we’ll see :)

The real question would probably be something else, like “What the hell, again a blog ?”. Yes, and as most of the times, that’s a way for me to put my ideas, questions, projects, whatever on “paper” instead of forgetting them… And as I totally forgot how to use a pen, let’s use that black keyboard which lies in front of me a couple of hours a day.

Et grosso modo, sans se prendre pour Neo, j’espère poser ici toutes mes réflexions sur le Métavers, façon un peu guindée de représenter cet univers au delà de notre univers fait de chair et de sang, enfin les fans l’auront compris, tel que Neal Stephenson le décrit dans son livre le Samourai Virtuel. Au programme, sécurité, cryptographie, gestion des risques, respect de la vie privée…. et toujours en filigrane, comment ces technologies et autre préoccupations digitales influent notre vie toujours plus virtuelle.

Follow

Get every new post delivered to your Inbox.