La méthode de PFS sans connexion spécifique à nebule est sensible à la capture de trafic ou la surveillance des créations de fichiers directement sur un serveur compromis. C’est aussi vrai en regardant simplement la date des fichiers.
L’article décrivant le mécanisme est encore à rédiger.
Cependant, peut-être que la dissimulation de liens et le travail sur une système de fichier sans mémoire temporelle peuvent aider à renforcer cette PFS. A voir…
Les messages que l’on protège peuvent être courts ou peuvent être dans certains cas facilement recalculés lorsque la seule partie variable du contenu a une faible entropie. C’est un problème général qui prend tout son sens dans la messagerie.
Le lien de chiffrement relie le hash de l’objet en clair avec le hash de l’objet chiffré. c’est indispensable si on veut pouvoir retrouver le contenu d’un objet en clair sans avoir à parcourir l’intégralité des hashs des objets protégés. C’est pour éviter le problème que l’on a avec l’implémentation des liens dissimulés.
Nous sommes dans le cas d’un modèle MAC-then-encrypt-then-MAC. Il faut trouver un moyen de renforcer l’entropie des objets protégés. Jouer sur le salage ou l’IV du chiffrement ne résout pas le problème puisque le problème vient du MAC avant chiffrement.
Et ce problème ne concerne pas des objets dont le contenu a une entropie supérieure à 128 bits et qui ne sont pas prédictibles. Il n’est pas utile, voire contre productif, de systématiser une solution de renforcement de l’entropie des objets protégés.
Il y a peut-être deux solutions. La première serait d’ajouter au contenu un aléa que l’on serait capable de retirer lors de l’exploitation de l’objet, comme du bourrage (padding). La seconde serait d’opérer sur l’objet une valeur d’un autre objet et de ne pas lié l’objet initial mais uniquement l’objet opéré. Cependant cette seconde méthode parait assez fragile en l’état.
La suite au prochain épisode…
Les objets que l’on affiche dans les applications sont déjà affublés de certains marquages, même si ils ne sont pas encore tous fonctionnels.
Par exemple, un objet peut être marqué comme dangereux et donc son contenu masqué par défaut. Cependant, les enfers n’ayant toujours pas ouverts, ce marquage n’est pas utilisé.
D’un autre côté, un objet protégé se verra affublé d’un message d’avertissement pour prévenir que son contenu ne doit pas être affiché en public. Ou dans certains cas comme sur les messages, c’est un indicateur qui donne l’état de protection d’un message.
Mais il est un autre type de message qu’il peut être utile de délivrer à un utilisateur. Au delà du fait qu’un objet est protégé, cette protection se justifie sûrement par rapport à la sensibilité du contenu de l’objet. Il est alors légitime de préciser une classification du contenu de l’objet dans certaines circonstances.
Cela permet d’avoir aussi une liste des informations importantes et de les tracer plus facilement.
C’est ce que font les militaires pour marquer les documents sensibles et classifiés. C’est ce que font les industriels pour marquer leurs secrets industriels.
La difficulté ici c’est qu’il n’y a pas de marquage type. Chacun emploie ses propres références de marquages. Il faut donc permettre cette souplesse. De plus, les marques doivent s’additionner et non se remplacer.
On peut imaginer un nouvel objet réservé destiné à gérer les marquages et qui servirait comme champ méta dans les liens de marquage. Les liens de marquages, type l, feront le lien entre l’objet à marquer et un objet de marquage via l’objet de référence.
Peut-être que l’objet de marquage sera lui-même aussi un objet de référence de ce marquage en particulier. Ceci permet de gérer des attributs liés au marquage comme un nom long, un nom court, une couleur, etc…
L’étape suivante sera ensuite de faire apparaître les marquages autours des objets. Est-ce géré comme les messages d’information actuels ? Est-ce géré différemment pour être clairement différencié ? Comme sera géré le multi-marquage ?
Enfin, comme ce système de marquage aura un impact sur les performances, il sera activable au besoin mais pas par défaut.
Pour l’instant c’est une idée non encore implémentée…
Il y a déjà une série d’articles en 2012 sur la Liaison secrète (et suite), puis en 2014 sur l’Anonymisation de lien (et correction du registre de lien), et enfin en 2015 sur la Dissimulation de liens, multi-entités et anonymat et l’Exploitation de liens dissimulés.
On trouve dès 2015 un schéma d’implémentation d’un lien dissimulé (offusqué) et le mécanisme cryptographique utilisé :
Mais la mise en pratique ne suit pas alors que la bibliothèque nebule en php orienté objet est prête à reconnaître les liens dissimulés.
Parce qu’en pratique, il ne suffit pas juste de générer ces liens et de les lire, il faut aussi les stocker de manière à pouvoir les retrouver tout en gardant des performances acceptables lors du passage à l’échelle.
Comme l’anonymisation attendue nécessite la mise en place d’un minimum de déception vis-à -vis d’un adversaire, il n’est pas possible de stocker les liens dissimulés dans les liens des objets concernés. Cela casserait presque immédiatement la confidentialité du lien dissimulé parce que les objets ont souvent chacun des rôles propres et donc des places privilégiées dans les liens qui servent aux usages de ces objets.
Les deux seules informations que l’on ne peut dissimuler sans bloquer le transfert et l’exploitation des liens dissimulés, c’est l’entité signataire et l’entité destinataire (si différente). Donc le stockage ne peut se faire que de façon connexe à des deux entités. Si ce n’est pas le cas les liens ne pourront pas être retrouvés et utilisés lorsque nécessaire.
Prenons le cas d’une entité qui décide de dissimuler la grande majorité de son activité, elle va donc dissimuler tous les liens qu’elle génère (ou presque). Là où habituellement le stockage des liens aurait été réparti entre tous les objets concernés, du fait de la dissimulation ils vont tous se retrouver attachés à un même objet, l’entité signataire. Cela veut dire que pour extraire un lien de cette entité il va falloir parcourir tous les liens. Cela peut fortement impacter les performances de l’ensemble.
Et c’est aussi sans compter le problème de distribution des liens parce que l’on les distribue aujourd’hui que vers les objets source, cible et méta… et non sur les entités signataires. L’entité destinataire est dans ce cas naturellement desservie directement, est-ce un problème si l’entité signataire ne l’est pas ?
Une autre méthode pourrait consister à créer un objet de référence rattaché à l’entité et spécifiquement dédié à recevoir les liens dissimulés. Mais les liens dissimulés ne contenant pas cette objet de référence, on doit créer un processus plus complexe pour la distribution des liens tenant compte des entités signataires et destinataires.
On peut aussi mettre tous les liens chiffrés dans les liens d’un objet c puisque c’est le type de lien après dissimulation. Mais cela veut dire que tous les liens dissimulés de toutes les entités se retrouvent au même endroit. On ne fait que déplacer le problème de la longue liste des liens à parcourir.
Enfin on peut rester sur une des premières idées qui consiste à stocker des liens dissimulés non plus dans la partie du stockage dédié au liens mais directement dans un objet. Le défaut de cette méthode est qu’à chaque nouveau lien dissimulé généré, il faut refaire un nouvel objet avec une novelle empreinte… et donc un nouveau lien pour le retrouver.
On rejoint le problème de la persistance des données dans le temps, de leurs objets et liens associés. Une solution déjà proposée, mais non implémentée, consiste à organiser un nettoyage par l’oubli des objets et des liens dans le temps en fonction d’une pondération.
Pour commencer à expérimenter, les liens dissimulés seront stockés uniquement avec l’entité destinataire. Cela ne remet pas en cause la distribution actuelle des liens. On verra à l’expérience comment gérer un flux massif de liens et son impact sur les performances.
La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.
Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.
La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).
La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.
De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.
Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…
Dans le précédent article sur les Entités de recouvrement qui date de plus de 6 mois, il était question de l’implémentation du mécanisme dans le code. Jusque là la liste des entités de recouvrement était renvoyée vide.
Ce mécanisme peut être une contrainte légale dans certains pays mais ce peut être aussi un moyen d’assurer plus sereinement la disponibilité des données sans remettre en question significativement la confidentialité de celles-ci. Sa portée est strictement local et ne doit pas devenir un comportement global sous peine de rompre la confiance dans l’ensemble du code de nebule.
La prochaine version de la bibliothèque nebule en PHP intègre le code nécessaire à la détection des entités marquées localement comme entités de recouvrement et le code qui se charge de dupliquer la protection des objets pour ces entités.
La définition des entités de recouvrement est purement locale et est attachée à l’entité instance locale. La détection d’entité de recouvrement se fait sur un lien de type f entre chaque entité définie comme entité de recouvrement et l’entité instance locale. Le champ méta du lien est l’objet de référence contenant nebule/objet/entite/recouvrement. Seuls les liens des autorités strictement locales sont pris en compte, c’est à dire à l’exception du puppetmaster, du maître de la sécurité et du maître du code.
La duplication de la protection se fait au niveau de la fonction (unique) de protection d’un objet setProtected(). Afin d’éviter la suppression du partage de protection avec une entité de recouvrement, la fonction cancelShareProtectionTo() ne supprime pas ce partage si l’entité est dans la liste des entités de recouvrement.
Afin de ne pas perturber l’utilisateur, les applications affichent tous les partages de protection mais n’affichent pas le bouton correspondant pour ces entités de recouvrement.
Les applications option, sylabe et klicty permettaient déjà l’affichage des entités de recouvrement même si elle était vide. Ces affichages ont été améliorés afin d’afficher en plus l’entité autorité locale qui a activé l’entité comme entité de recouvrement. Le but est d’avoir un mécanisme qui peut être contraignant et indiscret mais dont le fonctionnement doit être ouvert et loyal pour maintenir la confiance de l’utilisateur.
L’application option est maintenant le centre de gestion des entités de recouvrement. Il est possible, lorsque l’on déverrouille l’entité instance de serveur, d’ajouter ou de retirer des entités à la liste. Les autres entités ne peuvent faire que de l’affichage. Si un lien est généré par une autre entité, il est ignoré.
Le mécanisme de recouvrement des objets protégés et des liens dissimulés est en train d’être doucement mis en place.
D’un point de vue théorique, cela répond à deux problèmes similaires.
En entreprise, et pas que, il est recommandé d’utiliser une ou plusieurs autorités de recouvrement lorsque l’on utilise de la cryptographie pour protéger ses données. Les décideurs le prennent souvent comme une contraite et oublient de mettre en place ce mécanisme de restauration des données chiffrées. Et ce mécanisme est différent de celui de restauration classique alors qu’il est perçu comme étant le même. Résultat, lorsqu’un employé critique vient à manquer, ses données, critiques aussi, deviennent subitement inaccessibles. La disponibilité c’est aussi de la sécurité.
Pour différentes raisons, des états plus ou moins démocratiques peuvent imposer la mise en place d’un mécanisme de déchiffrement des données de leurs concitoyens.
Mais, afin de ne pas rompre la confiance, ce mécanisme doit être loyale, c’est à dire public, transparent et vérifiable.
D’un point de vue pratique, la mise en place comprend deux parties.
Il faut commencer par recenser les entités éligibles comme autorités de recouvrement. Pour l’instant dans le code de la librairie en php, la liste de ces entités est renvoyée vide. Les applications peuvent donc commencer à prendre en compte ces entités pour l’affichage public. C’est le cas dans klicty mais pas encore dans sylabe.
Il faut ensuite, lors de la protection d’un objet ou de la dissimulation d’un lien, dupliquer la protection ou le lien pour chacune des entités de recouvrement. Cela revient simplement à faire un partage de la protection pour un objet protégé en duplicant le lien de type k de chiffrement de la clé de session.
Pour terminer, la librairie n’intégrera pas par défaut d’entité de recouvrement. Si des entités sont définies comme tel, ce sera uniquement par choix (ou obligation) de l’entité responsable du serveur.
Le piratage de Sony Pictures a provoqué une véritable onde de choc dont les ramifications sont parfois inattendues. L’article The Security of Data Deletion de Bruce Schneier fait l’apologie d’une stratégie ‘agressive’ de suppression des données obsolètes dans les entreprises. Puisqu’il n’est pas possible de garantir la confidentialité des données d’une entreprise, même une parmi les plus grosses, il est préférable de supprimer ces données lorsqu’elles sont obsolètes.
On peut aussi parler de l’intégrité puisque si un pirate a réussi à récupérer quelques téraoctets de données sans se faire prendre, il a tout aussi bien pu en altérer au passage. Si la cryptographie peut nous aider à ce niveau pour signer les données et messages, elle ne pourra pas grand chose si les postes utilisateurs, leurs programmes et donc leurs clés sont compromises…
Mais revenons à la politique de suppression des données. Parler de politique agressive est un peu exagéré. La notion d’agressivité sous-entend de supprimer dès que possible une donnée lorsqu’elle n’est plus utilisé. Il est fait référence dans l’article à ce que l’on transmettait par téléphone avant l’informatique, les informations annexes que l’on ne notaient pas finissaient par être rapidement oubliées, au pire déformées… ou au mieux sujettes à confirmation.
Si la messagerie instantanée est assez informelle, la messagerie classique est beaucoup plus formelle, surtout en entreprise. On est dans ce dernier cas assez loin de la conversation libre par téléphone.
Une entreprise ne peut pas non plus supprimer sans discernement ses données sous prétexte qu’à un instant donné elles n’ont plus d’utilité. Ces données, c’est la mémoire de l’entreprise. Les supprimer c’est supprimer la mémoire de l’entreprise, une des choses les plus importantes puisque c’est l’accumulation de son savoir faire, de son savoir sur ses clients et ses racines. Supprimer les données anciennes d’une entreprise, c’est comme supprimer la mémoire à long terme des individus, c’est catastrophique pour eux et pour la société dans son ensemble.
Ce parallèle avec l’individu n’est pas anodin. La capacité d’une entreprise c’est la somme des individus qui la composent démultiplié par le patrimoine technique.
Et le parallèle peut aller plus loin. L’individu ne retiendra pas tout d’une conversation téléphonique. Des informations annexes seront perdus parce que non mémorisées par l’un ou l’autre des interlocuteurs. Ensuite, avec le temps, chaque interlocuteur va oublier certaines informations pas très importantes, progressivement. Au final, après un grand laps de temps, il ne subsistera de la conversation téléphonique que l’essentiel de l’information. Il faut donc bien de la même façon supprimer les données éphémères d’une entreprise mais il ne faut pas tout supprimer. Avec le temps, seul doit subsister l’essentiel des informations du passé. Les idées doivent être résumées et les informations techniques doivent être épurées de leurs pré-calcul et des données annexes.
Comme fil conducteur, on peut essayer d’avoir la vision d’un historien sur le passé de l’entreprise pour savoir ce qui a de l’intérêt ou pas. Et ainsi, naturellement, toutes les conversations hors champs vont disparaitre.
Tel que déjà définit précédemment pour le projet nebule, les données doivent pouvoir être supprimer automatiquement après un certain délai ou conservées explicitement. Une pondération appliqué aux objets déterminera le délai de conservation, ou plutôt de non-suppression. Et un seuil déterminera à partir de quelle pondération un objet sera à garder définitivement. Ce seuil peut évoluer avec le temps et faire disparaitre après coup des objets qui initialement étaient au dessus du seuil de suppression. La pondération reflète l’importance des objets, positivement ou négativement.
Pour finir, n’est-il pas plus simple d’être respectueux dans ses messages même à usage interne ? A défaut d’empêcher le vol d’information, au moins on évite déjà les propos embarrassants, une charge de moins dans la réparation des dégâts. Mais quelque part, cela reflète un état d’esprit dans l’entreprise, une certaine culture des individus qui la composent… bref, pas très sain…
La relation entre les êtres humains est resté assez stable dans son contenu mais à beaucoup évolué dans sa forme avec la technique. Le la taille d’un village, d’une tribu, la dimension du réseau social d’un individu a fortement grandi et a cessé de coller à sa zone géographique proche. Mais il n’a pas forcément grossi pour autant, il ne s’est que dilaté. Il garde d’ailleurs une forme nébuleuse dense au centre et distendu en périphérie.
Le téléphone a accéléré la vitesse de transmission des informations et de fait a permis d’étendre encore plus la portée des échanges, et donc l’influence des individus. Cette extension a fini par atteindre sa taille limite, celle du monde.
Mais les échanges d’informations ne se limitent pas à l’influence, politique, des autres. On y retrouve des choses qui n’ont pas grand intérêt à première vue comme la correspondance familiale ou la propagation de la culture. Cependant, ces deux exemple ont une importance profonde dans l’identité de l’individu d’une part et de la société d’autre part.
Le réseau social individuel n’est plus depuis longtemps calqué sur son influence physique directe. Si il n’est pas évident de parler de réseau social d’un groupe d’individus, ou société, on peut quand même se raccrocher à son influence directe. Et l’influence des sociétés ne sont que rarement exactement calquées sur leurs influences physique directe, c’est à dire sur les frontières d’un pays.
Une société ne doit pas être vue comme une forme nébuleuse unique de relations sociales mais comme une forme nébuleuse sociétale composée d’une multitudes de formes nébuleuses entremêlées. Une société est composée d’une multitude de formes nébuleuses individuelles avec quelques structures communes, mais surtout, pour les individus, avec une majorité de liens au sein de la nébuleuse sociétale. Le nationalisme ou communautarisme, du point de vue du réseau social, sont des tentatives pour imposer des structures uniques fortes et donc de forcer la nébuleuse sociétale à se scinder en de multiples formes sous-sociétales. Il existe une multitude de formes sous-sociétales susceptibles de développer une forme de communautarisme puisqu’il est en pratique impossible d’avoir une nébuleuse individuelle approchant la forme nébuleuse sociétale dans son ensemble. Le nationalisme use de sa forme de nébuleuse sociétale pour revendiquer une influence physique y compris hors des frontières de l’état qui le définit à l’origine.
Le réseau Internet est un support d’information, il permet de diffuser la connaissance à tout un chacun. Mais ce n’est pas sont seul rôle, il permet aussi de relier les individus. C’est à dire qu’il sert de support universel à la forme nébuleuse des relations sociales d’un individu. Nous avons encore des échanges sociaux directs entre individus, instantanés, mais ils ne sont plus ni exclusifs ni même nécessaires ou systématiques.
Le projet nebule se doit donc de faciliter le partage de l’information, de la connaissance, mais il se doit aussi de faciliter les échanges sociaux entre individus. Le projet nebule doit être capable de coller au plus prêt de la nébuleuse de l’information d’un individu, mais aussi de la nébuleuse de son réseau social.
La messagerie telle qu’elle a commencée était un message manuscrit sur un support papier ou équivalent et pouvait mettre plusieurs mois pour arriver à destination… quand ça arrivait…
Aujourd’hui, un message traverse le monde en quelques secondes avec une très grande probabilité d’arriver à destination. Le plus long, c’est maintenant d’attendre que le destinataire ouvre son message. Tout le monde fait confiance à la messagerie électronique et à une bonne confiance dans les échanges postaux nationaux et internationaux.
Et puis il y eu Edward SNOWDEN.
La confiance, c’est la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement.
Là , subitement, on a une grosse crise de confiance. On se dit qu’on ne va peut-être pas laisser tous ses Å“ufs dans le même panier. Le projet nebule peut sous cet éclairage paraître un peu trop intrusif et exclusif (des autres).
Cette crainte vis-à -vis du projet nebule est à la fois recevable, et non recevable.
Le projet sylabe, annexe de nebule, est une implémentation suivant les paradigmes actuels en terme d’échange de l’information, et surtout en terme de concentration de l’information. Il est conçu volontairement dès le début pour centraliser les données sur un serveur de l’Internet. C’est cette concentration sur une machine que l’on ne maîtrise pas qui pose de gros problèmes aujourd’hui. C’est cette concentration sur des machines chez des grosses sociétés au USA qui permet à la NSA (entre autres) de violer l’intimité numérique des individus sans raison valable. Et c’est fait de telle façon que les individus gardent confiance dans cette concentration de leurs données.
Mr SNOWDEN a cassé la confiance que nous avions dans la concentration de nos données, la confiance pour ces grosses sociétés américaines, et la confiance dans l’Internet même. Il a montré que quelque chose ne fonctionnait pas bien. Mais il l’a fait pour que ça s’améliore, pour que nous fassions les efforts nécessaires pour reconstruire l’Internet et la confiance que l’on attend de lui.
Le projet sylabe est donc un reliquat de ce passé. Mais il apporte quand même quelque chose pour le futur. Il centralise les données mais contient les graines de leur décentralisation complète.
Si tout le monde n’est pas prêt aujourd’hui à installer un serveur pour héberger ses données, on y arrive quand même de façon détournée. Certains installent des boîtiers NAS, c’est déjà une forme de réappropriation de ses données. Toutes les maisons ont une box qui fait office de centre multimédia, de NAS. La domotique arrive tout doucement (depuis 20 ans). Ainsi, une instance sylabe pourra être un jour implémentée facilement dans un boîtier pour non seulement héberger nos donnés mais aussi pour nous permettre d’échanger avec nos amis.
Le projet sylabe, une fois implanté ailleurs que sur des serveurs centralisés permettra la mise en place complète de la vision de la nébuleuse de nos informations, complètement décentralisée mais centrée sur nous.
Il reste à traiter le problème de l’anonymat. C’est en cours de définition et d’implémentation.
Cet objectif à part entière, dans le contexte actuel, nécessite qu’une entité puisse nativement et par défaut chiffrer tous ses objets et offusquer tous ses liens, ou presque tous. Cette possibilité sera intégrée rapidement dans le projet sylabe.
La documentation a été complétée pour le lien de type c :
Ce lien contient un lien chiffré. Il permet d’offusquer des liens entre objets et donc d’anonymiser certaines actions de l’entité.
Le champs HashSource fait référence à l’entité destinataire du lien, celle qui peut le déchiffrer. A part le champs de l’entité signataire, c’est le seul champs qui fait référence à un objet.
Le champs HashCible ne contient pas la référence d’un objet mais le lien chiffré et encodé en hexadécimal. Le chiffrement est de type symétrique avec la clé de session. Le lien offusqué n’a pas grand intérêt en lui même, c’est le lien déchiffré qui en a.
Le champs HashMeta ne contient pas la référence d’un objet mais la clé de chiffrement du lien, dite clé de session. Cette clé est chiffrée (asymétrique) pour l’entité destinataire et encodée en hexadécimal.
Lors du traitement des liens, si une entité est déverrouillée, les liens offusqués pour cette entité doivent être déchiffrés et utilisés en remplacement des liens offusqués originels. Les liens offusqués doivent être vérifiés avant déchiffrement. Les liens déchiffrés doivent être vérifiés avant exploitation.
CF : Documentation_-_nebule_v1.2 – Action_c_-_Chiffrement_de_lien
Mà J 11/06/2014 : le registre de lien a été changé : Anonymisation de lien – correction du registre
Dans la version 1.2 de nebule, le nouveau lien de type c a pour rôle d’anonymiser les actions des entités. Cette anonymisation doit permettre de cacher la relation entre l’entité d’un côté et ses actions sur des objets de l’autre. Il faut donc cacher non seulement le type de lien mais aussi que le lien relie ces objets. C’est la suite des articles liaison secrète et suite de fin 2012.
Il faut malgré tout permettre la libre diffusion des liens générés pour que ceux-ci soient transmis sur un réseau public et ouvert notamment via des entités relais. Cette transmission est assurée par le fait que l’entité signataire apparaît en clair puisqu’il faut être capable de vérifier la signature du lien.
L’anonymisation consiste en l’offuscation du vrai lien dans un lien caractéristique, le lien de type c. Le vrai lien, celui qui a un intérêt, est chiffré et intégré au lien de type c. Pour que la vérification des liens soit la plus simple possible, elle ne doit pas gérer le lien offusqué différemment. Le registre du lien doit donc être identique aux autres liens à l’exception de l’action et ce registre doit passer les mêmes tests de validation.
Si le lien offusqué mentionne l’entité signataire, il doit peut-être pouvoir être lisible par une autre entité. C’est le cas si l’on souhaite partage un lien de la même façon que l’on pourrait souhaiter partager un objet. Il faut donc que le lien offusqué fasse aussi référence à l’entité destinataire. L’entité destinataire, ou entité cible, qui peut être la même que l’entité signataire, sera positionnée dans le registre en 5ème position. Cette place est habituellement occupée par l’objet source.
Il faut prévoir une clé de session (un mot de passe) pour chiffrer le lien (chiffrement symétrique) parce que celui-ci n’a pas forcément une taille adéquate pour le chiffrement asymétrique. La clé de session chiffrée doit être encodé en hexadécimal. La clé de session chiffrée sera positionnée dans le registre en 6ème position. Cette place est habituellement occupée par l’objet destinataire.
Enfin, le lien offusqué, chiffré, doit être encodé en hexadécimal. Le lien offusqué sera positionné dans le registre en 7ème position.
Voici donc le registre de lien de type c :
Signature_Signataire_TimeStamp_c_EntitéCible_CléSession_LienChiffré
Le lien à offusquer est chiffré (symétrique) avec la clé de session et ajouté en position 7. La clé de session est chiffrée (asymétrique) avec la clé publique de l’entité cible et ajoutée en position 6. L’entité cible est ajoutée en position 5.
On ne peut dans ce cas pas offusquer la relation entre l’entité signataire et l’entité cible. La présence de la première entité est indispensable pour vérifier la signature du lien. La présence de la seconde entité est nécessaire pour que le lien puisse lui parvenir et lui indiquer que le lien la concerne. Le reste du lien est complètement offusqué.
Lors du traitement des liens d’un objet, Il faut à la fois consulter les liens de l’objet mais aussi consulter les liens offusqués attachés à l’entité courante. Ensuite seulement peut se faire le nettoyage des liens marqués supprimés.
On remarquera que cette façon de procéder permet bien sûr de ne pas révéler certains liens, mais aussi de marquer secrètement comme supprimés des liens alors qu’ils sont encore publiquement reconnus comme valides. Dans le même ordre d’idé, on peut camoufler un objet sous un type mime assez banal mais offusquer un lien dévoilant sa vraie nature. Un vrai terrain de jeux de cache cache en perspective !
Il reste un autre aspect de l’anonymat. Il peut être nécessaire de permettre des échanges entre deux entités sans qu’il n’y ai de lien entre elles, même de liens offusqués. Ce problème peut être résolu avec la génération d’entités esclaves le temps de quelques échanges. Il n’est pas possible dans ce cas de rattache directement ces entités esclaves à notre entité principale ni d’héberger cette entité sur son serveur personnel sous peine de dévoiler immédiatement la relation entre les deux. Il faut aussi prévoir un mécanisme pour que des entités puissent attendre des liens d’entités inconnues tout en étant capable de vérifier ces liens. Une fois le contact établit, il devient aisé, via l’offuscation de liens, de prouver sa véritable identité, c’est à dire de faire un lien entre entité esclave et entité maître. Il y a encore de la recherche à faire à ce niveau…
Comme nouveauté de la version 1.2, il y a la possibilité d’offusquer les liens afin de renforcer l’anonymisation des entités.
Pour cela, un nouveau type de lien vient d’être ajouté à la documentation : Action c – Chiffrement de lien
Autrement dit, c’est un lien de type c.
Il n’est pas encore pris en compte dans le code. Sa forme exacte n’est pas encore figée.
La mise en place des émotions sur les objets appelle plusieurs questions.
Vu le nombre d’émotions gérées, il va devenir nécessaire de les segmenter en catégories. On peut maintenir la catégorie ‘émotions‘ qui regroupe tout ressentit humain, plutôt subjectif. On peut ajouter une nouvelle catégorie ‘avis‘ pour tout ce qui est plus objectif.
Une réflexion qui commence à dater un peu sera la mise en place d’une pondération aux objets. Cette réflexion concerne avant tout la possibilité d’oublier progressivement dans le temps les objets avec le moins d’importance. L’oublie peut être réalisé automatiquement à partir d’un certain seuil. Le seuil peut progressivement augmenter dans le temps jusqu’à un seuil maximum au dessus duquel les objets concernés seront conservés, sauf suppression volontaire.
Cette pondération peut être bien sûr utilisable en permanence pour trier l’affichage des objets.
La mise en place des émotions est le bon moment pour introduire la mise en place de la pondération. Il ne reste plus qu’à en définir les modalités.
Une autre réflexion qui date un peu mais prend progressivement de l’importance, c’est la possibilité de chiffrer les liens. Le but est d’offusquer que l’on ne souhaite pas rendre publics tout en permettant leur bonne transmission aux destinataires légitimes.
Il y a plusieurs manières d’offusquer les liens :
La mise en place du chiffrement des liens va créer de fait une nouvelle version de nebule, la v1.2.
Voici la suite sur les problèmes d’implémentations de la cryptographie symétrique tel que décris dans OpenSSL et la cryptographie et Interopérabilité du chiffrement(blog sylabe).
Après quelques tests sur le chiffrement symétrique avec la commande openssl et son équivalent en php, j’ai trouvé les bonnes implémentations pour obtenir le même chiffre à partir des mêmes valeurs en entré.
Il y a à la fois une erreur dans l’implémentation de openssl dans nebule en bash, et une autre erreur d’implémentation de openssl dans sylabe en php.
En bash, la commande openssl enc était appelée avec l’option -kfile alors qu’il faut utiliser l’option -K.
Il faut en plus utiliser l’option -nosalt pour ne pas ajouter de sel et donc notamment avoir un objet chiffré de taille strictement identique à l’objet en clair.
Voici une courte implémentation qui marche, dans le cadre d’emploi de nebule exclusivement :
#!/bin/bash nebule_symalgo="aes-256-ctr" iv='00000000000000000000000000000000' echo -n "477fd3f3a32dc5de70cf13d1e46d8663f5f23873826572ea8359064b6d63c60c2d76f29a5e34fac2aebb157975517ef23110f4a5e415d9d0408f6fe7b9fe17bdd6bbb2df3fb819ecbd5216835ecccc559e7eb84e0517e92538d9a81fec333498a64b90df3429abe857ba1666fc93b24509e63d05fd619da9eef12c8d70dbacca" > /tmp/bdata key='8fdf208b4a79cef62f4e610ef7d409c110cb5d20b0148b9770cad5130106b6a1' openssl enc -e -$nebule_symalgo -in "/tmp/bdata" -out "/tmp/bcode" -K $key -iv $iv -nosalt -p sha256sum /tmp/bcode
En php, la commande openssl_encrypt recevait la clé de chiffrement hexadécimale alors qu’il faut la transmettre sous forme binaire.
Par défaut, aucun sel n’est utilisé.
Enfin, l’IV peut avoir une valeur nulle contrairement à ce qu’affirme la documentation. Ce doit être une erreur de traduction. La valeur de doit pas avoir une taille nulle.
Voici une courte implémentation qui marche, dans le cadre d’emploi de nebule exclusivement :
<?php
$nebule_symalgo = 'aes-256-ctr';
$data="477fd3f3a32dc5de70cf13d1e46d8663f5f23873826572ea8359064b6d63c60c2d76f29a5e34fac2aebb157975517ef23110f4a5e415d9d0408f6fe7b9fe17bdd6bbb2df3fb819ecbd5216835ecccc559e7eb84e0517e92538d9a81fec333498a64b90df3429abe857ba1666fc93b24509e63d05fd619da9eef12c8d70dbacca";
$hiv='00000000000000000000000000000000';
$iv=pack("H*", $hiv);
$hkey="8fdf208b4a79cef62f4e610ef7d409c110cb5d20b0148b9770cad5130106b6a1";
$key=pack("H*", $hkey);
$cryptobj=openssl_encrypt($data, $nebule_symalgo, $key, OPENSSL_RAW_DATA, $iv);
$hashcryptobj=hash('sha256', $cryptobj);
echo "E=$hashcryptobjn";
?>
La mise en place du chiffrement/déchiffrement dans sylabe, l’implémentation de nebule en php, révèle quelques problèmes et spécificités de OpenSSL.
Lorsque il a fallu déchiffrer avec la commande openssl les objets chiffrés depuis sylabe, ça n’a pas marché.
Les objets chiffrés par sylabe, qui utilise openssl dans php, peuvent être déchiffrés par sylabe. Les objets chiffrés par nebule en bash, qui utilise la commande openssl, peuvent être déchiffrés via la même commande en bash. Le point commun est l’utilisation de la librairie openssl. Mais en pratique un objet chiffré dans sylabe que l’on essaye de déchiffrer avec la commande openssl (via nebule en bash) retourne une erreur ‘Bad Magic Number’. Et l’inverse ne marche pas non plus. Ah, c’est moche…
Le problème ici est lié à l’utilisation d’un ‘salage’ (salt). Cette valeur est générée aléatoirement par openssl pour complexifier le mot de passe de chiffrement et réduire les attaques par dictionnaire de mots de passe pré-hashés (rainbow-table). Le sel est une valeur publique contrairement au mot de passe, et doit impérativement être envoyé avec le fichier chiffré. Le salage est un renforcement de la procédure de chiffrement et non du mot de passe lui-même. Pour que le sel soit transmit avec les données chiffrées, openssl ajoute un petit entête aux données chiffrées avec notamment la valeur du sel. Il en résulte une petite augmentation de la taille du fichier des données chiffrées de 16octets. Or, la librairie openssl utilisée dans php ne génère pas de sel, les données chiffrées et non chiffrées ont la même taille.
Quelle solution apporter ?
Il est possible de gérer cet entête de fichiers chiffrés dans le code php. Cela entraîne une augmentation de la complexité du chiffrement/déchiffrement mais permet de conserver un comportement commun avec les objets actuellement générés en bash. Cette compatibilité ‘commune’ n’est pas universelle puisqu’elle n’est pas gérée par la librairie openssl dans php, et donc peut-être pas non plus dans d’autres environnements.
On peut aussi ne pas permettre d’utiliser un entête particulier et de gérer le salage de la même façon que l’IV. Cette solution casse la gestion des objets chiffrés actuels mais surtout complexifie les liens de chiffrement.
Une autre solution serait de ne pas utiliser le salage du tout. Une option de openssl le permet : -nosalt. Cela permet d’avoir un chiffrement plus simple et des objets chiffrés plus propres, et donc une implémentation plus universelle du chiffrement. On va cependant à l’encontre des recommandations faites par les développeurs de OpenSSL. Et on ré-ouvre potentiellement par dictionnaire pré-calculés.
Mais a-t-on vraiment besoin du salage ?
Le salage permet en fait de renforcer la sécurité de mots de passes potentiellement faibles ou à la limite de l’attaque par force brute.
Le chiffrement des objets dans nebule impose l’utilisation d’une clé de session aléatoire. Si l’espace des valeurs des clés de sessions est aléatoire et suffisamment grand, une attaque par dictionnaire est impossible. C’est impossible parce qu’il est dans ce cas précis impossible de pré-calculer et encore moins de stocker dans un dictionnaire l’intégralité des valeurs possibles. Un espace des valeurs de clé suffisamment grand peut se comprendre par une entropie correspondant à 128bits et plus.
Le script bash référence de nebule génère actuellement une clé de session de 64octets de valeurs hexadécimales, soit 256bits d’entropie réelle. Le code php de sylabe génère actuellement une clé de session de 128octets aléatoires, soit 1024bits d’entropie réelle.
Donc, le salage va être volontairement supprimé dans le chiffrement des objets tel que mis en place dans nebule.
Un problème similaire existe avec l’IV (Initial Vector, vecteur initial ou semence).
Lorsque l’on réalise un chiffrement symétrique, celui-ci se fait typiquement par blocs de données. Ce découpage peut entrer en interférence, en quelque sorte, avec les données à chiffrer. Si ces données sont répétitives suivant la taille du bloc ou un multiple, alors les blocs de données chiffrées correspondantes vont être identiques. Et cette répétition est détectable et fourni des informations sur le contenu non chiffré…
Pour remédier à ce problème, il existe différentes méthode d’organisation du chiffrement (pour le même algorithme de chiffrement) que l’on appelle modes d’opération. Certains modes introduisent un chaînage entre des blocs contiguës pour camoufler les données répétitives. D’autres modes mettent en place d’un compteur par bloc qui sera combiné avec les données pour forcer un peu de variabilité entres blocs répétitifs.
Il reste cependant à traiter le premier bloc. Pour cela on utilise l’IV qui est soit la première valeur pour le chaînage soit la première valeur du compteur en fonction du mode d’opération. Parce que sinon ce premier bloc, chiffré avec le même mot de passe, donnera le même bloc chiffré et donc trahira un début de données identique entre plusieurs fichiers chiffrés. L’IV est une valeur publique contrairement au mot de passe, et doit impérativement être envoyé avec le fichier chiffré.
Mais a-t-on vraiment besoin de cet IV ?
Comme dans le cas du salage, l’utilisation de d’une clé de session aléatoire et différente pour chaque objet fait que, même pour un contenu identique dans les premiers blocs, cela donnera des blocs chiffrés différents.
Donc, le vecteur initial va être volontairement supprimé dans le chiffrement des objets tel que mis en place dans nebule.
Premier problème suite à ça, l’instruction en php openssl_encrypt nécessite un paramètre IV non nul…
Le chiffrement permet offusquer des données, c’est à dire de protéger celle-ci d’une diffusion inappropriée.
La subdivision consiste, à partir d’un objet unique, en la création de plusieurs objet dérivés plus petits. Ces petits objets sont des sous-ensembles de l’objet principal, c’est à dire des morceaux. Ce n’est pas encore implémenté aujourd’hui, mais le type de lien existe pour définir la relation de morcelage entre l’objet principal et les sous-objets.
La subdivision permet de découper un objet en bloc pour qu’il puisse être transmis par morceaux à la manière du P2P.
La subdivision peut aussi et simultanément être utilisée afin de constituer un index de certaines portions intéressantes. Cela peut être par exemple un index des mots dans un texte pour permettre une recherche accélérée sur des mots clés.
Cependant, la combinaison du chiffrement et de la subdivision pose un problème de confidentialité.
Que se passe-t-il si on décide de protéger un objet contenant du texte, c’est à dire le chiffrer, mais que l’on ne retire pas les liens de subdivision ?
Si ces liens de subdivision renvoient vers des parties d’un index des mots clés, alors il est possible de reconstituer les grandes idées du texte. Voir il est possible de reconstituer dans le pire des cas l’intégralité du texte déchiffré. On contourne ainsi la protection mise en place.
Il faut cependant noter que si un objet est protégé à posteriori, il a peut-être déjà été copié légitimement. Il pourrait en être de même de certaines parties marquées comme subdivisions.
Afin de minimiser ce problème de confidentialité, il y a plusieurs règles à appliquer :
Lorsqu’il sera possible d’offusquer des liens, ces règles pourront être revues.
En visitant le blog de Bruce Schneier, je suis tombé sur un long et intéressant article : How to Remain Secure Against the NSA
Je vais me concentrer sur les 5 points, traduits ici :
Petite remarque sur ce qui semble une incohérence. Il cite au point 4 d’essayer d’utiliser des logiciels à sources ouvertes. Et il dit utiliser plus bas un ordinateur sous M$ Windows : « And I’m still primarily on Windows, unfortunately. Linux would be safer. »
L’aveu est franc. Je pense que l’explication est simple, il se sent plus à même de sécuriser un système qu’il connaît bien plutôt qu’un système inconnu. Ça se défend.
Confrontons donc maintenant le projet nebule et ces cinq points :
Liens :
– https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html
L’affaire PRISM révélée par Edward Snowden n’en finit pas de provoquer des secousses numériques autour de la NSA, des grosses sociétés américaines et de la vie privée des citoyens/sociétés.
On entend parler régulièrement de la possibilité de créer de multiples chemins de communications entre individus. Ici multiple est à comprendre dans le sens où chaque connexion passe par un certain nombre de serveurs différents et ce de façon anonyme pour les serveurs. Ceci dans le but de garantir l’anonymat de l’internaute.
Il existe TOR pour la navigation. Ce pourrait être le cas avec la messagerie (Caliop ?). Mais est-ce une solutions suffisante?
Le journal Lemonde a publié un article sur un internet décentralisé pour des usages centralisés (cf lien). Rien que le titre suffit à exprimer tout le paradoxe de notre utilisation de l’internet…
Un autre problème s’ajoute, l’anonymisation est aussi utilisée par des criminels. Tout en sachant que les criminels d’un pays/communauté sont parfois les héros d’un autre. Comment distinguer l’utilisation légitime, ce qui est bien ou pas? Vaste débat.
Un outil ayant uniquement une structure globale mélange les usages légitimes et réprouvés, quel qu’en soit leur acceptation. Un outil qui respecte une structuration régionale ou locale est plus à même de coller à l’acceptation de certains usages, ou à leur régulation. Il est aussi capable de suivre l’évolution des mÅ“urs et usages tout en permettant des échanges globaux.
Le projet nebule peut-il apporter quelque chose? Je pense que oui, quelque chose de nouveau surtout. Aujourd’hui, tous les efforts portent sur des tentatives de sécuriser les serveurs centraux, les relais intermédiaires, les chemins empruntés et les protocoles. Cette nouvelle chose que propose nebule est de penser directement au niveau de la donnée, de gérer sa confidentialité et ses échanges.
La structure locale de nebule est de taille variable. L’individu est la base. Il met en place naturellement des échanges dits sociaux proches jusqu’à une organisation de la taille d’un pays. Il est aussi capable d’exploiter de façon universelle des informations quelles qu’en soient leurs localisations.
Liens :
РLemonde РBitcoin, BitTorrent, TOR : un internet d̩centralis̩ pour des usages centralis̩s
– http://fr.wikipedia.org/wiki/PRISM_%28programme_de_surveillance%29
– http://fr.wikipedia.org/wiki/Tor_%28r%C3%A9seau%29
– https://www.torproject.org/
– http://www.caliop.net/
Une avancée importante reste encore à faire. Elle est en théorie tout à fait réalisable et indispensable. Mais la mise en pratique doit se faire avec soin. Cette avancée, c’est le chiffrement des objets.
Ce chiffrement est optionnel. Il doit être résistant, c’est à dire correspondre à l’état de l’art en cryptographie appliquée. On doit être en mesure de parfaitement distinguer l’objet en clair de l’objet chiffré, même si le second est dérivé du premier.
Ceci est une proposition de travail.
Les entités sont des objets contenant le matériel cryptographique nécessaire au chiffrement asymétrique. Cependant, le chiffrement asymétrique est très consommateur en ressources CPU (calcul). On peut l’utiliser directement pour chiffrer les objets avec la clé publique d’un correspondant, mais cela devient rapidement catastrophique en terme de performances et donc en expérience utilisateur. D’un autre côté, le chiffrement symétrique est beaucoup plus performant, mais sa gestion des clés de chiffrement est délicate. Pour améliorer l’ensemble, on mixe les deux. On essaie de profiter des avantages de chacun tout en réduisant les défauts.
Ainsi, on va aborder le chiffrement en deux étapes distinctes. Voici le schéma de l’ensemble que l’on va décomposer.
Pour la compréhension, ne pas oublier que les propriétés des objets sont elles-mêmes des objets…
La réflexion sur la possibilité d’insérer des liens dans des objets (cf Liaison secrète) pose quand même un problème.
Comment vont être utilisés dans la vraie vie les liens insérés dans l’objet ?
Il faut en effet voir comment vont être pris en compte ces liens. Seront-ils ajoutés par certaines entités aux liens des objets concernés ? Ce qui du coup leur fait perdre leur caractère confidentiel, et donc l’intérêt du chiffrement de l’objet contenant ces liens. Et si ils ne sont pas ajoutés au reste des liens des objets concernés, comment vont faire ces entités pour exploiter ces liens ?
Deux réponses sont possibles.
La première est de déchiffrer l’objet pour extraire les liens et les stocker temporairement dans un emplacement strictement privé… et faire en sorte de les traiter en même temps que les liens naturellement attachés aux objets, c’est à dire aux liens publics. Cela nécessite à chaque déverrouillage d’une entité que celle-ci déchiffre tous ces objets pour en récupérer les liens, et de les supprimer systématiquement à chaque verrouillage. C’est facile et réalisable avec peu d’objets de ce type. Mais seront-ils si peu nombreux ? C’est loin d’être évident. Donc ce n’est pas une solution.
L’autre solution est de permettre d’insérer dans les liens un nouveau lien qui ferait référence à un autre objet comme contenant des liens. Cet objet peut ensuite être reconnu comme contenant des liens et être exploité en même temps que les liens normaux, c’est à dire non chiffrés. cette solution semble plus réaliste et viable que la première. Cependant, elle nécessite la mise en place d’un mécanisme pour les traiter spécifiquement.
Ne faut-il pas créer un nouveau type de lien dédié à ce problème ?
En l’état, le problème peut être résolu plus tard sans remettre en cause toute l’architecture des liens de nebule.