Archive for the ‘identification’ Category

Exploitation de liens dissimulés

Mardi, août 11th, 2015

Dans l’article sur la Dissimulation de liens, multi-entités et anonymat, on a vu comment implémenter des liens dissimulés dans d’autres liens.

Ici, on va apporter quelques précisions pratiques.

Déjà, un lien dissimulé va apparaître avec une entité signataire et une entité destinataire du lien. On a vu que c’était le minimum vital pour que cela fonctionne et que l’on puisse partager les liens même si cela implique de travailler sur les entités pour parfaire l’anonymisation. Il y a le cas particulier du lien dissimulé pour soi-même, dans ce cas l’entité signataire est aussi l’entité destinataire.

Lorsque l’on regarde les liens d’un objet, on va voir tous les liens non dissimulés. Si une entité est déverrouillée, il faut en plus parcourir tous les liens de type c de l’objet de l’entité pour en extraire les liens dissimulés relatifs à l’objet que l’on regardait. Dans le cas de multiples entités esclaves d’une entité maîtresse, il faut faire de même pour extraire tous les liens dissimulés pour toutes les entités accessibles. Il faut veiller dans ce cas à ce que l’interface montre clairement qui est l’entité concernée pour éviter toute confusion de l’utilisateur.

Dissimulation de liens, multi-entités et anonymat

Samedi, juin 27th, 2015

La dissimulation de lien tel que prévu dans nebule n’est que la première partie permettant l’anonymisation des échanges entre entités.

Voir les articles précédents :
Liaison secrète et suite ;
Nouvelle version v1.2, Anonymisation de lien et correction du registre ;
Lien de type c, précisions ;
Entités multiples, gestion, relations et anonymat et Entité multiples ;
Nébuleuse sociétale et confiance – Chiffrement par défaut

Cette dissimulation d’un lien se fait avec un lien de type c. On a bien sûr dans le registre du lien visible l’entité qui génère ce lien, l’entité signataire. Et on a l’entité destinataire qui peut déchiffrer ce lien dissimulé et en extraire le vrai lien. Et comme dans la version publique de ce lien on a à la fois l’entité source et l’entité destinataire qui sont visibles, il n’y a pas d’anonymat. Ce type de lien permet juste de dissimuler l’usage d’un objet.

2015.06.27 lien c

Un lien dissimulé ne peut pas contenir un autre lien dissimulé. On interdit donc les multi-niveaux de liens dissimulés qui seraient un véritable calvaire à traiter.

Un lien peut être dissimulé pour soi-même. C’est à dire que l’entité signataire est aussi l’entité destinataire.

Si un lien doit être dissimulé pour plusieurs destinataires, il faut générer un lien pour chaque destinataire. La seule façon de réduire le nombre de liens pour un grand nombre de destinataires est d’utiliser la notion de groupe disposant de son propre bi-clé. Ce type de groupe est pour l’instant purement théorique.

Ce maintien comme public des entités sources et destinataires est une nécessité au niveau du lien, c’est une des bases de la confiance dans les liens. Pour que le lien puisse être validé et accepté par une entité ou retransmit par un relais, l’identification des entités est incontournable. Et donc avec l’identification nous avons aussi l’imputabilité et la non répudiation.

Si on veut assurer de l’anonymat pour les entités, puisque l’on ne peut pas travailler au niveau du lien, il faut travailler au niveau de l’entitié. On va dans ce cas travailler sur la notion de déception, c’est à dire faire apparaître des entités pour ce qu’elles ne sont pas ou tromper sur la nature des entités.
L’idée retenu consiste, pour chaque entité qui souhaite anonymiser ses échanges avec une autre entité, à générer une entité esclave avec laquelle elle n’a aucun lien. Ou plutôt, le lien d’entité maîtresse à entité esclave est un lien dissimulé pour l’entité maîtresse uniquement. Ici, personne à par l’entité maîtresse ne peut affirmer juste sur les liens que l’entité esclave lui est reliée.
Lorsque l’on veut échanger de façon anonyme, on transmet à l’entité destinataire l’identifiant de l’entité esclave, et vice versa. Cette transmission doit bien sûr être faîte par un autre moyen de communication ou au pire par un seul lien dissimulé.

L’anonymisation complète est donc la combinaison des liens de dissimulation de liens et d’une capacité multi-entités des programmes.

La dissimulation est en cours d’implémentation dans sylabe en programmation php orienté objet. Mais le plus gros du travail sera à faire dans la librairie nebule puisque c’est elle qui manipulera les liens et présentera ceux-ci à l’application, c’est à dire sylabe, dans une forme exploitable. L’application n’a pas à se soucier de savoir si le lien est dissimulé, elle peut le lire ou elle ne peut pas. Tout au plus peut-elle afficher qu’un lien est dissimulé pour information de l’utilisateur.
La capacité multi-entités de sylabe est maintenant beaucoup plus facile à gérer en programmation php orienté objet. Mais il reste à implémenter la génération des entités esclaves avec dissimulation de leur entité maîtresse.

Une autre dimension n’est pas prise en compte ici, c’est le trafic entre les serveurs pour les échanges d’informations. Il faudra faire attention à la remontée possible aux entités maîtresses par leurs échanges.

Enfin, pour terminer, aujourd’hui c’est la course au chiffrement par défaut de tous les échanges pour tout un tas de programmes et services sur Internet. Ce chiffrement par défaut est bon pour l’utilisateur en général. Et il masque dans la masse les échanges pour qui la confidentialité est critique. Ainsi il ne suffit plus d’écouter le trafic chiffré pour retrouver ses ennemis.
Mais cette logique est perverse. Le chiffrement par défaut est une aberration, un remède de cheval posé en urgence faut de mieux. Nous avons besoin d’échanger aussi des choses publiquement, comme sur un forum ou dans la presse. Nous ne devrions pas avoir des outils de communication tout chiffré et d’autres tout public, chaque outil devrait permettre les deux et clairement indiqué ce qui est protégé de ce qui ne l’est pas…

Cosignature

Samedi, mai 9th, 2015

Une réflexion depuis quelques temps porte sur la cosignature (cf Les entités et le code / Redéfinition de puppetmaster). Et elle est toujours d’actualité. Le but est de permettre d’avoir une entité unique mais dont la clé privée soit répartie en plusieurs morceaux, chaque morceau sous la responsabilité d’une personne différente. On doit avoir plusieurs entités qui peuvent communément, et non individuellement, signer pour l’entité unique.

Le problème peux être résolu en ayant un mécanisme qui valide la signature de l’entité unique par la présence d’un nombre pré-définit de signatures d’entités pré-validées. On n’a plus dans ce cas une entité mais un groupe d’entités dont la cosignature est reconnue comme signature du groupe. Dans ce cas, la notion d’entité s’étend et ne sous-entend plus seulement un objet avec une clé cryptographique mais un objet qui constitue un groupe d’entités avec des règles de fonctionnement.

Jusqu’ici, je n’ai trouvé que des solutions matériels avec un seul bi-clé cryptographique conservé dans une puce et dont l’usage est contraint par l’authentification de plusieurs personnes physiques. Ce n’est pas satisfaisant puisque toutes les personnes doivent être présentes au même endroit au même moment pour activer la clé privée. Les solutions de cosignatures que j’ai trouvé se contentent de gérer de multiples signatures d’un document mais sans gérer cette notion de communauté.

Gestion du temps et anonymisation

Mardi, février 10th, 2015

L’horodatage des liens est important pour leur interprétation. C’est particulièrement vrai pour démêler les suppressions. L’horodatage est placé dans les liens, ce qui veut dire que ce n’est pas l’objet qui est daté mais son usage.

On traite ici la suite des articles Horodatage, suite, Gestion temporelle partielle, Transfert de liens et de confiance, et cela entrera dans l’Etude du temps.

Vis-à-vis de l’anonymisation des entités, et surtout des personnes derrières, la gestion du temps nécessaire à l’horodatage peut poser problèmes.

Le problème c’est la synchronisation sur une source unique. Utiliser deux ou trois source réduit le problème mais uniquement de façon linéaire. Cette source unique sera régulièrement consultée et donc verra la source des demandes, notamment d’un point de vu adresses sur le réseau. Mais qui dit demande de synchronisation de temps ne veut pas dire présentation de l’entité qui le demande. La corrélation peut être faite après coup en comparant les marques de synchronisation de temps d’une entité avec les logs de connexion. Le risque ici est de récupérer la localisation d’une entité. Pour beaucoup de personnes, la connexion à son système d’information se résume à son ordinateur à la maison, son téléphone/tablette et à son travail. Avec la connexion depuis le domicile, on peut casser assez facilement l’anonymisation.

L’utilisation de plusieurs moyens informatiques pas forcément synchronisés entre eux en terme de temps introduit des problèmes pour calculer un décalage de temps et une dérive éventuelle. Dans ce cas, la relation entre entité et localisation ou entre entité et individu est plus dure à obtenir, mais pas impossible.

On peut utiliser la même entité source de synchronisation de temps mais en passant par des relais. Il faut dans se cas récupérer les dernières marques de l’entité de gestion du temps et le rejouer. En passant par une entité intermédiaire, on casse la corrélation possible entre les connexions et les marques de temps. C’est au prix d’une moins grand précision dans le calcul du décalage de temps.

Si on utilise un système de synchronisation des machines, tel que NTP, les machines se synchronisent sur des références de temps cohérentes. Noyé dans la masse des connexions, les synchronisations d’une entité ne permettent pas de lever son anonymat. Malheureusement, cela ne fonctionne que si les machines sont en réseau. Tout au plus peut-on se contenter d’une synchronisation irrégulière et espacée dans le temps. Dans ce cas, l’absence de marques de temps d’une entité ne permettra pas de calculer son décalage, et donc on en sera réduit à supposer qu’elle est à peu près à l’heure.

Dans tous les cas, il est possible d’utiliser en même temps une synchronisation précise par NTP et un calcul de décalage de temps. Des machines synchronisées devraient avoir un décalage proche de 0. Pour ne pas affaiblir l’anonymat des utilisateurs, il est préférable d’avoir une synchronisation NTP et d’utiliser les marques de temps mais horodatées sur son heure propre. Les marques de temps seront récupérées aléatoires chez les entités connues.

La gestion du temps va générer un trafic propre tant en réseau qu’en terme d’objets et de liens. Il faudra prévoir un nettoyage fréquent et à court terme de ces objets et liens avant qu’ils ne saturent les échanges entre entités.

Enfin, cela n’a peut-être pas trop d’importance à première vue mais c’est quand même une entorse à l’anonymisation, générer des marques de temps régulières pour permettre les synchronisations ne peut se faire que lorsque l’entité est déverrouillée. C’est à dire que l’on a des marques de temps que quand on est connecté, ce qui trahi les heures de présence effective mais aussi fait office de marqueur de présence. La parade est de ne faire des marques synchronisation de temps que… de temps en temps. Cette parade se fait au prix d’une perte de précision dans le calcul du différentiel de temps, surtout avec des machines multiples.

Entités multiples

Mardi, décembre 23rd, 2014

Dans la suite des réflexions sur Entités multiples, gestion, relations et anonymat, le développement de la librairie nebule en php continue en tenant compte de cette possibilité.

En gérant le mot de passe d’une entité dans l’objet (php) de cette entité, on peut avoir plusieurs entités déverrouillées à un instant donné. Et comme plusieurs entités sont potentiellement déverrouillées, lorsque l’on consulte un objet chiffré, il ne faut plus seulement regarder si l’entité courante est déverrouillée et donc peut le lire, mais il faut regarder dans tous les destinataires si une des entité n’est pas déverrouillée aussi. Une seule suffit pour déchiffrer l’objet et afficher son contenu.

Il faut cependant faire attention à ce que l’entité courante ait bien l’accès à l’objet chiffré avant de permettre son utilisation parce que cela dévoilerait immédiatement le lien de parenté entre les deux entités. Il est imaginable de basculer immédiatement d’entité courante sur une action de ce genre.

Si on souhaite une bascule complète sur une entité esclave sans interférence d’autres entités, il suffit de vider le mot de passe de tous les objets (php) des entités que l’on ne souhaite plus voir. Cela inclut aussi l’ancienne entité courante qui peut avoir été préalablement sauvegardée avec sont mot de passe pour une restauration ultérieure.

Une des applications de cette capacité multi-entité, c’est le cumule d’entité lors d’un Changement d’identifiant d’entité. Il est possible, le temps de migrer les liens, de pouvoir continuer à consulter les objets de l’ancienne entité tout en utilisant la nouvelle entité.

Changement d’identifiant d’entité

Jeudi, novembre 13th, 2014

On avait déjà vu qu’une entité pouvait être amenée à changer d’identifiant, donc en fait de clé publique et de clé privée. On avait vu que renouveler son entité n’est pas un problème facile à résoudre de façon satisfaisante, c’est à dire vraiment sécurisée et facile pour l’utilisateur.

Du point de vue interface, la nouvelle entité change aussi de couleur propre. Donc on ne peut pas demander à l’utilisateur par ailleurs de se fier à cette couleur propre des objets puisqu’elle va changer complètement à chaque mise à jour de ceux-ci. C’est ici que se fait sentir le besoin d’une référence d’objet stable dans le temps quelque soit les mises à jours, mais cette référence est par nature source de conflit d’une entité à l’autre et surtout elle est impossible à sécuriser.

Le problème est plus simple si l’entité est dépendante d’une autre entité, d’une entité maitresse. A condition que cette entité maitresse soit publiquement déclarée, comme le puppetmaster, il est possible de vérifier de façon sûr qu’une entité à changé de clé privée. CF Entités multiples, gestion, relations et anonymat

Par contre, une entité autonome ou assimilée ne peut pas se reposer sur une entité supérieure. Il faut prévoir un mécanisme qui permette à l’utilisateur d’une entité lambda de valider automatiquement ou manuellement la mise à jour d’une autre entité. Cela ne veut pas dire que l’autre entité ne changera pas d’identifiant, mais que cet identifiant ne sera pas reconnu tant que l’entité lambda n’aura pas validé (pour elle) son changement.

Pour le changement d’une entité qui potentiellement remet gravement en question la sureté de fonctionnement, une acceptation inconditionnelle de la mise à jour serait catastrophique. Il peut être utile dans ce cas particulier de générer un lien d’annulation de l’opération, mais un lien qui n’est pas actif, c’est à dire qui n’est pas diffusé. Ce lien de type x, serait affiché à l’utilisateur et serait donc valide mais pas pris en compte parce que non diffusé avec les autre liens.

Si on prend le cas spécifique de puppetmaster, cette entité valide des entités esclaves ayant des rôles près-définis. On retrouve notamment l’entité bachue qui diffuse les mises à jours logiciels liées au projet nebule. La compromission d’une telle entité poserait de graves problèmes de sécurité pour toutes les entités. Sa mise à jour vers une nouvelle entité serait dans ce cas obligatoire.
Mais ce problème pourrait être plus restreint dans la mesure où une fausse entité bachue serait générée et diffusée à des entités tierces. Si, par un autre moyen, on arrive à convaincre les entités tierces à l’utiliser en place de la vraie entité bachue, ces entités seront à considérer comme compromises. Le lien d’annulation serait alors le seul moyen pour ces entités de pouvoir revenir en arrière, faisant immédiatement un bond en arrière en terme de versions de logiciels, revenant à une version validée par l’entité bachue légitime.
Sauf que cela ne marche que si l’on peut enregistrer le lien de suppression hors du système nébulisé ou hors d’atteinte. Ce qui sera une vraie difficulté sur des systèmes entièrement nébulisés. Aujourd’hui, avec les systèmes d’informations actuels, on s’en sort en régénérant une nouvelle identité à l’utilisateur ou en nettoyant son compte. Peut-être faudra-t-il dans un premier temps garder ce fonctionnement avant d’aller vers quelque chose de plus ouvert…

Affichage de la couleur d’un objet

Samedi, novembre 8th, 2014

Une des orientations actuelles dans les interfaces graphiques centrées sur nebule, c’est de représenter les objets par leurs identifiants et pour chacun par des carrés de couleur spécifiques. Chaque objet a sa couleur propre calculée par rapport aux 6 premiers digits de son identifiant.

2014.11.11 21h03 ecran

Mais du point de vue de l’interface visuelle, si la représentation de l’identifiant équivoque d’un objet est indispensable, sa place encombrante n’est ni ergonomique ni pratique ni vraiment sécurisante à elle seule. Garder systématiquement la place pour un nombre hexadécimal de 128 caractères au minimum, fut-il l’objet en cours de consultation, c’est encombrant. L’ergonomie en prend un coups puisque l’on doit grader un grand espace variable pour une information certes importante mais peu pertinante pour l’utilisateur la plupart du temps. Enfin, puisqu’il est illusoire de penser pouvoir mémoriser l’intégralité des identifiants que l’on utilise pour les vérifier, à part quelques cas spécifiques l’affichage des identifiants des objets n’amène pas directement de sécurité pour l’utilisateur. Le problème de mémorisation est le même que pour les mots de passes multiples, passé un certain nombre, très restreint, cela affaiblie la sécurité de l’ensemble.

Il est tentant de remplacer purement et simplement l’affichage de l’identifiant d’un objet juste par son carré de couleur propre. Cela entraînerait l’impossibilité de vérifier immédiatement si l’objet que l’on visualise est le bon. On peut savoir avec la couleur si l’objet est celui que l’on attend. Mais la représentation des couleurs ne dépasse pas 24 bits d’information. C’est à dire qu’en ajouter plus que les 24 bits n’est pas perceptible par l’oeil humain. Ainsi, la couleur est un moyen de tri rapide mais pas un moyen de sécurité.

Le problème de ne pas pouvoir vérifier immédiatement et de façon sûr un objet est déjà un problème en soit mais peut être comblé par l’usage des liens. Par contre, la gestion des entités et notamment la reconnaissances de nouvelles entités uniquement sur leurs couleurs propres est un vrai problème de sécurité. Il est facile de générer une nouvelle entité ayant la même couleur propre. Avec 24 bits à respecter, cela ne présente pas une grande difficulté. L’identification d’une nouvelle entité doit dans tout les cas être parfaitement sécurisée, donc elle doit être basée sur l’intégralité des identifiants.

Il faut donc soit conserver l’affichage de l’identifiant des objets, même partiel(tant qu’il est suffisamment grand). Soit il faut trouver une méthode alternative de représentation simple des objets tout en conservant un espace de valeur correct.

Au moins deux méthodes peuvent être envisagées, liste non exhaustive.

On peut utiliser un petit pictograme de plusieurs couleurs successives calculées à partir de l’identifiant d’un objet. Le prictograme peut disposer d’un espace de valeurs suffisamment grand tout en étant facilement mémorisable.

On peut imaginer qu’une entité spécifique utiliser certaines valeurs choisies au hasard parmi tous les digits des identifiants pour calculer les couleurs propres des objets. Comme il faut 6 digits hexadécimaux pour constituer une couleur, ceux-ci sont choisis non pas au début des identifiants mais à l’intérieur. ce choix doit être aléatoire, secret pour l’entité et non recalculable par une entité tierce. Dans ce cas, la couleur affichée pour un même objet serait différente pour chaque entité qui consulte cet objet.

Entités multiples, gestion, relations et anonymat

Mercredi, octobre 8th, 2014

On peut raisonnablement penser que chaque personne, sauf problème, a une personnalité unique. Et donc qu’une personne a un comportement unique et un réseau sociale unique.

Mais la réalité n’est malheureusement pas aussi simple.
Ne prenons que l’exemple de l’individu employé dans une société. Cet environnement est à considéré comme différent de l’environnement de vie normal, c’est à dire chez soi, dans la vie privée. Au travail, nous avons des « amis imposés par l’employeur » qui forment un réseau social souvent fortement découplé du réseau social privé. Nous avons aussi des attitudes différentes, en phase avec les attitudes que l’entreprise attend de nous. Nous sommes en short à la maison, avachi devant la télévision alors que l’on est en costume 3 pièces au travail, bien assit devant son ordinateur. Les réseaux sociaux ainsi que les échanges avec les autres individus évoluent avec l’environnement dans lequel on se situe. Chacun de nous est unique mais chacun de nous adopte une pseudo-identité variable dans l’espace et le temps. Enfin, on mélange rarement les informations de ces différentes pseudo-identités. On parle rarement en détail de sa journée de travail avec des amis le weekend autour du barbecue.
Sur un réseau social numérique, comme Facebook ou Google+, imposer une identité unique est donc une vision réductrice de l’individu humain. En cherchant à n’avoir que des identités réelles des individus, on se coupe de toutes leurs identités annexes. Et une relation de travail fait typiquement d’une identité annexe.

On ne s’attardera pas ici plus longtemps sur la justification des entités multiples mais plutôt sur la technique et les possibilités que cela ouvre.

Les premières expériences avec les identités dans nebule montrent qu’un individu peut, bien évidemment, avoir plusieurs entités différentes. Chaque entité peut avoir une « vie » propre, c’est à dire un réseau social à part. Une entité peut mettre en place des entités esclaves, elles sont dans ce cas parfaitement autonomes. Elles restent autonomes même si elles sont tenues par une entité maitresse.
L’entité puppetmaster est le premier exemple d’entité maitresse. Il y a dans ce cas une idée de validation forte. On peut avoir d’autres types de relations entre entité maitresse et entités esclaves. On peut avoir des cas où la validation serait au contraire réduite voir dissimulée, dans les cas où l’anonymat est recherché.

Vis-à-vis de l’interface homme-machine, la notion même d’entités multiples n’est pas triviale. Sur nos systèmes d’information actuels, sur nos ordinateurs, téléphones, tablettes, etc… il est courant de disposer de plusieurs comptes utilisateurs. Mais on ne peut utiliser simultanément qu’un seul compte à la fois. Tout au plus peut-on changer temporairement d’identité (élévation de privilèges par exemple). Chaque action se fait sous une et une seule identité.
Si on utilise plusieurs comptes de messagerie ou comptes de réseaux sociaux numériques, il faut quitter un compte pour pouvoir accéder à un autre.

Dans une interface exploitant nebule, il est cependant possible de travailler de la même façon ou différemment.
On peut disposer de plusieurs entités et se connecter à une et une seule entité à un instant donné.
On peut aussi se connecter à une entité maitresse et basculer, immédiatement après, vers une des entités esclaves. C’est déjà fonctionnel dans sylabe. Il est même possible de revenir facilement vers l’entité maitresse pour éventuellement repartir sur une autre entité esclave. Ainsi on évolue dans des environnements isolés via des entités autonomes. De plus, la relation entre l’entité maitresse et les entités esclaves peut être masqué (offusqué).
Mais il est possible d’aller plus loin. On peut tout à fait imaginer exploiter simultanément plusieurs entités. Cela permet d’avoir une vue synthétique de plusieurs réseaux sociaux ainsi que des échanges associés. Le cloisonnement dans ce cas est invisible pour la consultation tout en restant potentiellement très fort entre chaque entités. En pratique, on pourrait voir les activités de tous les « amis » de toutes les entités esclaves que l’on contrôle même si chaque entité esclave n’a strictement aucun rapport ou aucun lien avec les autres entités esclaves. Il faut par contre définir une entité avec laquelle on agit par défaut, au risque de casser le cloisonnement des entités par des liens inappropriés. On peut même imaginer que des interactions avec un réseau social particulier se fassent avec l’entité esclave attaché au réseau en question, on conserve ainsi le cloisonnement des entités mais pas celui de l’information. En somme, c’est un peu ce que l’on fait déjà avec un logiciel client messagerie et plusieurs comptes de messagerie…

Facebook et l’anonymat

Mercredi, octobre 8th, 2014

Les positions bougent aussi du côté de Facebook. Dans la suite de l’article précédent sur Google+ et l’anonymat, c’est au tour du premier réseau social de faire des concessions sur la possibilité de créer des comptes anonymes… dans une certaine mesure.

Depuis le 1er octobre, il est possible d’utiliser un pseudonyme. Tout n’est pas encore permit mais l’avancée est de taille alors que la vie privée n’était clairement pas la priorité de Facebook. Et l’anonymat était même malvenu jusque là pour inciter les internautes à avoir de vraies relations d’amitié. Il était aussi quand même plus intéressant pour les publicitaires de disposer d’informations fiables sur les utilisateurs…

Depuis peu, une nouvelle messagerie est en cours d’élaboration, par Facebook, pour permettre des échanges volontairement anonymes. Un vrai retournement… ou une opportunité commerciale de plus…

CF :
http://www.lemonde.fr/economie/article/2014/10/02/les-pseudonymes-finalement-autorises-sur-facebook_4498801_3234.html
http://www.lemonde.fr/pixels/article/2014/10/08/facebook-va-lancer-une-application-permettant-des-echanges-anonymes_4502637_4408996.html

Transfert de liens et de confiance

Dimanche, septembre 14th, 2014

Les réseaux fragmentés posent des problèmes plus importants que le maintient de la cohérence du système d’horodatage. CF Gestion temporelle partielle.

Certains protocoles de sécurisation des échanges deviennent bancales sans synchronisation de temps. Mais il y a plus grave. La cohérence du temps entre plusieurs machines peut être négligé sur une courte période, les horloges ne vont pas dériver exagérément et il y a peu de change que des certificats expirent. Par contre, il devient difficile de transmettre de nouveaux contacts avec un grand niveau de confiance. les relations de confiance sont souvent dépendantes de services centralisés, services qui ne sont plus forcément joignables. Ces services ont le rôle d’annuaires globaux. Il faut dans ce cas faire confiance aux seuls intermédiaires que l’on a sous la main, et que l’on connaît (au moins dans nebule). On doit utiliser des entités comme des annuaires locaux.

Dans ce cas, il est peut-être utile de voir si la définition d’un nouveau type de lien ne pourrait pas répondre à ce besoin. Ce serait un lien signé par une entité que l’on connaît et qui transmettrait un lien d’une autre entité, inconnue. Un lien serait encapsulé dans un autre de la même façon que pour un lien offusqué. La validité et la pondération du lien de l’entité inconnue seraient les mêmes que si le lien venait de l’entité connue. Ce serait une forme de relais de liens.

Ce type de lien aura peut-être aussi une utilisé pour les annuaires d’entités. Cela pourrait faciliter la mise en relation entre deux entités qui ne se connaissent pas.

Mais, c’est aussi un risque qui faut analyser. On commence dans ce cas à prendre en compte des liens d’une entité que l’on ne connaît pas et que l’on ne peut directement vérifier. Il faut voir ça comme si l’entité qui fait le relais des liens s’appropriait elle-même le lien. Cette entité peut diffuse des liens invalides, c’est à dire dont la signature est invalide, sans que l’on puisse le vérifier. L’affiche de ces liens ou leur interprétation doit être peut-être adapté pour montrer cette particularité…

Partage simplifié d’une entité

Jeudi, juillet 24th, 2014

Pour l’utilisateur d’un logiciel de communication, mémoriser un mot de passe complexe est une tâche ardue, voir sans intérêt.

Le problème est le même avec les pages web, leurs noms doivent être facile à retenir et à retaper sans faute. Et il en est ainsi pour les correspondants dont il faut se souvenir au pire de leurs adresses emails ou au mieux de leurs noms ou pseudonymes. Dans certains cas, il faut se souvenir du pseudonyme et du site web sur lequel on peut trouver un correspondant.
Le projet nebule vise notamment à fédérer des identités en même temps que les données. Mais cela entraîne inévitablement l’utilisation d’identifiants globalement uniques, donc longs.
Certains projets comme minilock visent à essayer de réduire ces identifiants avec des encodages comme le Base58.

On peut aussi utiliser uniquement une localisation, c’est à dire adresse de type http ou email. Ainsi, pour une adresse http, il faut héberger à une adresse précise une entité par défaut. Si un hébergeur veut gérer plusieurs entités, il ne pourra pas les garder facilement dans le même espace, le même nom de domaine, mais il devra au contraire les séparer dans des espaces différents. Mais est-ce vraiment la solution ?

Dans l’article sur le Détournement de liens de mise à jour (CF blog sylabe), on a vu qu’il était possible de créer une sorte de pseudonyme d’entité nebule. C’est un détournement du lien de mise à jour depuis un objet fictif vers, dans notre cas ici, une entité définie. Prenons comme exemple un prénom Fabio auquel correspondrait un objet fictif fab10. Ainsi, sur une instance de nebule, cet objet reverrait systématiquement vers l’entité de l’utilisateur. Ça résout le problème localement.

Cependant, on peut facilement imaginer que tous les utilisateurs qui ont se prénom vont avoir des prétentions sur cet objet fictif. Comment va se résoudre le conflit ?
Assez mal en fait. Si on a des amis en commun, on devrait rapidement retrouver le bon identifiant de l’entité. Mais ça se corse si on a deux entités avec des prétentions sur ce pseudo dans nos entité proches. Dans ce cas, c’est le calcul social qui va déterminer l’entité qui pourra hériter du pseudo, et cela fait une chance sur deux de ne pas tomber sur la bonne entité…
En plus, on peut imaginer aussi que dans une situation de harcèlement ou de dénigrement, des entités agressives essayent aussi de s’approprier le pseudo. Cela pourrait rendre le pseudonyme difficile à utiliser puisqu’il ne renverrait que rarement à la bonne entité.

Cette méthode est donc loin d’être parfaite. Elle peut être raisonnablement utilisée soit dans un petit groupe d’utilisateurs soit si elle est associée à une localisation http, email, etc…

Nommage multiple et protéiforme

Vendredi, juillet 18th, 2014

Dans nebule, les objets ont forcément un identifiant. Ils ont aussi parfois un nom. Typiquement, c’est le cas lorsque l’objet a pour source un fichier nébulisé.

shot-2014-07-18_20-07-59

Le nom est un texte de caractères compréhensible par les humains. Déjà, en fonction des langues, il se peux que ce texte ne soit pas compréhensible pas tout le monde. Mais on exclut déjà par principe les caractères non imprimables, même si en réalité ça n’a pas beaucoup d’importance. Il vaut mieux que le texte n’ai pas de retour à la ligne, mais ça peut être interprété, traduit et pris en compte à l’affichage.

Pour un fichier, le nom (qui inclus le chemin) a deux rôles :

  1. le classement sommaire par sujets en fonction du chemin et parfois du nom ;
  2. la description sommaire du contenu, un peu comme un titre.

Dans nebule, le nom que l’on peut donner à un objet a le même rôle que le nom pour un fichier. Il donne un titre à l’objet. Par contre, le classement des objets intervient peu avec le nom que ceux-ci pourraient avoir. Ce serait plutôt le rôle de groupes et de nœuds, concept encore en cours d’affinement. Pour un objet, lui donner un nom c’est le lier à un autre objet qui contient le nom avec un lien de type l.

Si un fichier ne peut avoir qu’un seul nom, un objet peut en avoir plus. Il est possible de créer plusieurs liens vers différents objets à utiliser comme noms. Les propriétés de liens multiples et concurrents sont valables aussi pour le nommage.
Lors de l’affichage, comme dans l’exemple ci-dessus, il faut faire un choix. Soit on affiche tous les noms, ce qui peut rapidement devenir problématique et difficilement compréhensible par l’utilisateur. Soit on affiche qu’un seul nom, celui affiché étant celui qui a le plus grand score dans le calcul des relations sociales. C’est cette dernière solution qui est adoptée aujourd’hui.

Mais on peut faire encore mieux. Rien n’interdit un lien pour un titre de renvoyer vers une image. D’ailleurs, ce peut être tout objet sans distinction. C’est l’interprétation du titre qui ici prend son importance. Si on n’interprète que du texte alphanumérique sur une seule ligne, les autres objets seront ignorés comme titre.
Si on décide de prendre en compte aussi les images, il ne sera peut-être pas opportun d’utiliser une image de grande résolution, lourde. On peut utiliser à la place les miniatures, des images dérivées, pour l’affichage comme titre. Les miniatures d’images seront d’ailleurs très régulièrement utilisées lors de l’affichage.
Pour un film, on va peut-être utiliser soit une image fixe soit une petite séquence animée, l’une comme l’autre extraite du film.

L’affichage final peut dans certains cas prendre en compte simultanément plusieurs objets titres mais de types différents. Par exemple accepter une image et un texte, ou un morceau de film, un son et un texte…
Protéiforme ne veut pas dire en forme de protéine mais bien de formes multiples.
Tout est question d’interprétation et de stratégie d’affichage. Tout est possible, aussi.

Dans sylabe, comme dans nebule, une entité a un nom constitué d’un petit texte, un prénom et même un préfixe sur le même principe. Mais elle peut aussi depuis peu avoir une image, typiquement une photo d’identité. Le nommage multiple et protéiforme existe donc déjà.

Google+ et l’anonymat

Mercredi, juillet 16th, 2014

Dans un article, le réseau social Google+ revient sur les restrictions de nommage de ses utilisateurs. Il va maintenant être possible de choisir des pseudonymes de façon à profiter du réseau social en ligne tout en permettant un certain anonymat.

Il était temps…

L’étape suivant serait de permettre à tout utilisateur de pouvoir nativement créer des pseudonymes partiellement autonomes. L’idée est en cours de mise en place sur le projet sylabe. La condition du succès est bien sûr que qu’un pseudonyme puisse avoir une vie propre, ses propres relations et groupes (cercles sur G+) et que l’on bascule de façon équivoque de l’entité principale vers un pseudonyme. C’est un bon moyen de répondre à des besoins d’anonymisation tout en facilitant la gestion de l’anonymisation par les vrais utilisateurs.
Il faudra aussi déterminé si un pseudonyme apparait clairement comme tel dans les utilisateurs ou si sa vraie nature reste cachée pour préserver son efficacité.
Bien sûr, il faudra garder à l’esprit que monsieur Google aura accès à toutes les entités, que ce soit les vrais utilisateurs ou leurs pseudonymes. Cela répond dans ce cas aux problèmes légaux pour pouvoir remonter, sur décision d’un juge, à la personne physique derrière un pseudonyme.

Prise d’empreinte homomorphique

Vendredi, juillet 11th, 2014

Les objets manipulés par nebule sont identifiés, et donc référencés, par leurs empreintes respectives. Ces empreintes sont cryptographiques afin de pouvoir s’assurer que c’est bien le bon objet, afin de pouvoir avoir confiance dans l’intégrité de son contenu. Il est possible dans un seul cas d’avoir plus d’une empreinte par objet, c’est si celles-ci sont calculées avec des algorithmes différents (cf Collisions d’empreintes multi-algorithmique).

Cependant, si la propriété cryptographique des empreintes est indispensable à la confiance, elle entraîne un manque de souplesse dans le référencement des objets. Rien dans la valeur de l’empreinte ne trahis une partie de son contenu. L’empreinte cryptographique reflète uniquement l’intégralité de l’objet. On ne peux pas s’en servir pour retrouver des objets proches dans leur contenu. Tout au plus peut-on vérifier si deux objets sont identiques… ce qui n’a pas d’intérêt puisque dans ce cas c’est tout simplement le même objet.

Sub-division d’objet

La première solution pour résoudre ce problème est d’utiliser des sous-parties d’un objet comme des objets propres, et de les identifier comme tels. Le lien de type s permet justement de lié l’objet principal à ses morceaux.

C’est notamment ce qui est fait dans les logiciels de Paire-à-Paire (P2P – Peer to Peer). Pour qu’un fichier puisse être téléchargé depuis de multiples sources, celui-ci est pré-découpé en morceaux de taille identique pré-définit. Chaque morceau à une empreinte propre et peut être vérifié à la réception. Chaque morceau est téléchargé sur une et une seule source, mais plusieurs morceaux sont téléchargés simultanément depuis plusieurs sources. On augmente ainsi le débit réel de réception du fichier voulu même si les sources ont individuellement un faible débit d’émission. Évidemment, si chaque morceau est valide, le fichier dans son ensemble ne peut qu’être valide.

Une recherche sur mot clé peut avantageusement tirer partie de ce système puisqu’une recherche se fera uniquement sur l’empreinte du morceau correspondant à la recherche. Toute la difficulté est de bien choisir ces morceaux.

Pour du texte, c’est facile. Pour une recherche sur des images ou des vidéos, c’est déjà beaucoup moins évident. Mais quoique l’on trouve, c’est toujours une liste d’objets qui contiennent cette petite sous-partie même si le reste n’a absolument aucun rapport.

Empreinte homomorphique

Une autre solution consiste à essayer de trouver des objets qui ont le plus de contenu en commun. Ce serait une sorte de représentation miniature du contenu de l’objet. On veut quelque chose qui se rapproche plus de l’empreinte des doigts de pieds. On regarde d’abord que cela à bien la forme d’un pied, puis on regarde plus en détail certaines parties morphologiques pour déterminer si les deux pieds sont proches.

On pourrait partir sur le système de sous-découpage utilisé par le P2P. Chaque objet est découpé en petits morceaux de taille identique. Ainsi, si deux objets ont un ou des morceaux en commun, on pourra en déduire que ceux-ci sont proches.
Mais cette méthode pose un problème. Si on prend un objet et que l’on en fait une copie avec pour seule différence un caractère supplémentaire dans le premier bloc de données, alors tous les blocs seront vus comme différents alors que les objets ont clairement des parties communes.
On pourrait imaginer essayer d’optimiser la méthode en travaillant sur des blocs de tailles variables. Mais quels critères adopter pour ajuster les tailles de blocs en fonction des données ?

Je propose une méthode comme base de réflexion à défaut pour l’instant d’être adoptée.
Si on regarde le travail d’un logiciel de compression de données, on constate qu’il recherche les occurrences multiples de données dans l’ensemble d’un document. Il le fait sans tenir compte de la sémantique de ce qu’il trouve. Ainsi des mots très proches sémantiquement ne seront pas agrégés parce que différents. Ensuite, le logiciel de compression fait un classement statistique pour déterminer les occurrences multiples qu’il serait avantageux de réduire. Une phrase qui apparaît quelques fois permet une bonne optimisation. Un mot qui apparaît plusieurs permet aussi un gain de place facile.
Si on reprend le même principe d’analyse, même sans tenir compte de la sémantique des mots, on peut s’attendre à ce que les plus grandes occurrences de mots ou de phrases représentent le ou les sujets du document. C’est ce que fontnotamment les moteurs de recherches (Google, Bing, Yahoo…) lorsqu’ils moulinent les pages web, mais avec l’analyse sémantique en plus.
L’empreinte homomorphique est constituée des 20 premières occurrences redondantes avec leur poids respectifs. L’occurrence peut être représentée par une petite empreinte (CRC) de façon à avoir une taille fixe, mettons 16 caractères hexadécimaux. Le poids peut être représenté en pourcentage sur 4 caractères hexadécimaux (entre 0000 et ffff).
Vue comme ça, l’empreinte générée n’est plus tout à fait homomorphique et n’a pas de propriétés cryptographique.On obtient une empreinte homomorphique de 400 caractères hexadécimaux.

Ainsi, plusieurs documents parlants d’un même sujet ont de fortes chances d’avoir une même empreinte parque bien que différents ils auront les mêmes occurrences redondantes.

Un certain nombre de données annexes vont figurer dans les données utilisées pour la comparaison. Par exemple on peut retrouver les en-têtes internes des documents bureautique. Il faut peut-être pré-filtrer les documents en fonction de leur type pur. Par exemple, un simple fichier texte et un fichier complexe de traitement de texte se verront expurgés de tout ce qui est en-tête et données internes, puis on en gardera que les caractères imprimables convertis en minuscule, sans ponctuation…

Conclusion

Une empreinte homomorphique peut être utilisée avantageusement en complément de l’empreinte cryptographique. Elle n’a d’intérêt que pour des objets ayant suffisamment de contenu. Il faut prévoir un seuil minimum en dessous duquel elle n’est pas calculée. Cette empreinte homomorphique est liée à l’objet par un lien de type l avec comme objet méta « nebule/objet/homomorphe ». Cet objet à usage réservé est ajouté à la documentation.

Mais dans tous les cas, en l’absence de propriétés cryptographique, une empreinte homomorphique ne doit pas être utilisée dans les liens. L’usage n’est pas le même, on fait soit de l’intégrité, soit du référencement.

Marqueur de groupe multidimensionnel

Mercredi, mars 12th, 2014

Les objets sont aujourd’hui identifiés par une valeur unique qui, de part ses propriétés, n’est pas pré-calculable ou prévisible. Ce comportement est indispensable pour distinguer parfaitement et de façon univoque les objets, et donc leur contenu. Il résulte de ces propriétés que toute modification d’un objet, quelle qu’elle soit et aussi infime qu’elle soit, entraîne un changement complet et quasi-aléatoire de son empreinte, et donc de l’identifiant correspondant.

Mais il peut être aussi intéressant de disposer d’une autre valeur plus prévisible. On va essayer de définir ici ce que l’on appellera un marqueur.
On peut imaginer par exemple que deux images très proches puissent avoir un marqueur de valeur identique ou proche. Pour de la musique, le marqueur peut être un dérivé atemporel du spectre de fréquences. Ce marqueur doit avoir une structure en accord avec la structure de l’objet. On doit pouvoir comparer les marqueurs de deux objets différents et déterminer rapidement si ils ont une structure proche, donc si ils sont ressemblants. La structure doit être multidimensionnelle et de profondeur variable. L’ajustement de la profondeur de comparaison des marqueurs doit permettre de retrouver les objets très proches ou au contraire vaguement ressemblants.

Une notion de groupe apparaît. On fait un regroupement à géométrie variable des objets par rapport à leur contenu.

Le côté multidimensionnel du marqueur doit refléter les caractéristiques multidimensionnelles d’un objet. Voici quelques exemples :

  1. Un texte simple contient des données qui s’expriment en deux dimensions : la position spatial et pour chaque position une valeur (caractère).
  2. Un texte enrichit contient des données qui s’expriment en trois dimensions : la position spatial et pour chaque position deux valeurs (caractère et encodage).
  3. Un son mono contient des données en deux dimensions : la position temporelle et pour chaque position une valeur (amplitude).
  4. Un son stéréo contient des données en trois dimensions : la position temporelle et pour chaque position deux valeurs (amplitude).
  5. Une image en noir et blanc contient des données en trois dimensions : la position spatial horizontale, la position spatial vertical et pour chaque couple de position spatial on a une valeur (amplitude).
  6. Une image en couleur (RVB) contient des données en cinq dimensions : la position spatial horizontale, la position spatial vertical et pour chaque couple de position spatial on a trois valeurs (amplitude).
  7. Un film en couleur muet contient des données en six dimensions : la position spatial horizontale, la position spatial vertical, la position temporelle et pour chaque couple de position spatial/temporelle on a trois valeurs (amplitude).
  8. Un film en couleur avec son stéréo contient des données en huit dimensions : la position spatial horizontale, la position spatial vertical, la position temporelle et pour chaque couple de position spatial/temporelle on a cinq valeurs (amplitude).

Ce marqueur n’est pas destiné à remplacé l’identifiant !
L’identifiant reste le seul moyen de
discerner sans ambiguïté tous les objets, y compris les plus ressemblants.

Ne reste plus qu’à formaliser précisément ce marqueur.

Renouveler son entité

Dimanche, décembre 8th, 2013

Pour l’instant, les entités sont figées. Mais il faudra prévoir de changer leurs mots de passes et de les migrer vers de nouvelles entités au besoin.

Le changement de mot de passe nécessite de régénérer l’objet de clé privé qui change. Il faut évidemment préalablement déverrouiller l’entité, donc sa clé privée. Une fois le mot de passe changé, il faut lier la nouvelle clé privée à la clé publique puis supprimer le lien de l’ancienne clé privé. Il faut marquer à supprimer l’objet de l’ancienne clé privée.

Dans le cas d’une migration d’entité, c’est un peu plus complexe. Ce besoin répondra souvent suite à un problème de compromission ou de corruption d’entité.
Il faut générer une nouvelle entité autonome. Faire un lien de mise à jour de l’ancienne entité vers la nouvelle. Dans la mesure du possible, ce lien de mise à jour doit être signé à la fois par l’ancienne et la nouvelle entité. Puis l’objet de la clé privée de l’ancienne entité doit être marqué à supprimer à la fois par l’ancienne et la nouvelle entité.
Si l’entité avait été corrompue, c’est à dire qu’il était impossible de la déverrouiller, c’est un vrai problème. Dans ce cas, les liens de mise à jour d’entité et de suppression de clé privée ne pourront être signés par l’ancienne entité. rien ne permet de distinguer une opération légitime suite à un problème d’une tentative de détournement par une autre entité. Il peut tout au plus être possible de regarder si l’entité génère de l’activité, donc qu’elle n’est pas corrompue.
En cas de compromission de l’entité, on peut faire une mise à jour vers une nouvelle entité. Mais celui qui a volé la clé privée de l’entité peut le faire aussi de son côté. Il est difficile dans ce cas de déterminer qui est la véritable nouvelle identité et pas une usurpation… Peut-être le côté sociale, comportemental, d’une entité peut nous aider à posteriori?

Le SPAM, déficience d’identification

Dimanche, septembre 22nd, 2013

Qu’est ce que le SPAM?
« Le spam, pourriel ou polluriel est une communication électronique non sollicitée, en premier lieu via le courrier électronique. Il s’agit en général d’envois en grande quantité effectués à des fins publicitaires. »
CF Wikipedia

La définition est un peu floue. On note cependant plusieurs détails dans la première phrase. C’est d’abord une communication, donc un échange d’informations. Ensuite, cela prend une forme électronique, critère correspondant à une vision un peu réduite. Et enfin, c’est quelque chose de non sollicité, c’est à dire une communication initiée par l’autre partie, quelques chose que l’on a pas demandé.
Jusque là, une communication électronique sur deux rentre dans cette catégorie. Il y a un consensus général sur ce que cela désigne, mais la définition est trop imprécise. La précision concernant le courrier électronique est optionnelle, pas vraiment contraignante. C’est surtout un exemple qui aide le lecteur à raccrocher le SPAM à quelque chose qu’il connaît déjà. Cela veut aussi dire que le SPAM affecte potentiellement d’autres médias de communication. Le FAX par exemple…
La deuxième phrase reste aussi très générale, donc très imprécise. Ce serait donc des envois de grandes quantités de messages publicitaires. Ou est le problème ici? La grande quantité d’envois? Le caractère publicitaire? Il n’est fait aucune référence à un problème dans cette définition, mais on assimile automatiquement la combinaison quantité/commercial à un problème.
Le problème serait-il pas tout simplement de recevoir beaucoup de messages publicitaires que l’on n’aurait pas sollicité !? On notera la transformation entre l’envoie massif de messages et la réception massive de ces mêmes messages. Se soucierait-on du SPAM si un envoie massif aboutissait à un seul message par semaine dans notre boite aux lettres ? Assurément pas.

Un e-mail non sollicité ventant les propriétés d’une lessive est un SPAM.
Un prospectus papier dans notre boite aux lettres, non. Ce n’est pas une communication électronique. Pourtant, en pratique, c’est le même phénomène : on remplit nos boites aux lettres de messages publicitaires non sollicités. Messages dont il faut se débarrasser.
Allons encore plus loin. Un panneau publicitaire, diffusant d’autorité un message dans notre environnement, n’est pas non plus du SPAM. Ce n’est pas une communication électronique et cela ne vous est pas directement adressé. Pourtant nous sommes bien dans la diffusion massive d’un message publicitaire. Elle est massive parce que adressée à toutes les personnes qui passent devant. Finalement, le panneau publicitaire peut de la même façon être assimilé à du SPAM. Mais là on ne peut rien faire, il n’y a pas de bouton suppression. Bien que la dégradation de notre environnement visuel soit manifeste, cela ne rentre pas dans la catégorie SPAM. Je vous laisse en déduire la raison.
En terme informationnel, c’est l’insertion d’informations parasites en grand nombre qui provoques une gène. Tant que cela ne demande pas trop de temps pour être traitée, c’est toléré. Le traitement de ces informations parasites veut dire d’analyser chaque information afin de déterminer sa pertinence et la suite à donner, c’est à dire la supprimer ou l’ignorer dans le pire des cas.

Revenons au SPAM tel que communément accepté. Face au déluge de messages à trier (à supprimer), il est rapidement apparut nécessaire de traiter le problème. Ce traitement peut intervenir à plusieurs niveaux et de plusieurs manières. Évidemment, il est préférable de pouvoir fortement automatiser ce processus de traitement.
Il y a aujourd’hui un large panel de méthodes différentes pour traiter ce problème spécifique, des plus artisanales aux plus industrielles. Les résultats ne sont pas toujours à la hauteur des investissements en argent ou en temps. Mais comment mesurer l’efficacité de ces méthodes ?
On peut mesurer les performances de plusieurs façons. La première idée est de mesurer le pourcentage de SPAM réellement détectés. Oui, mais ce n’est pas suffisant, que fait-on du nombre de messages légitimes qui ont été supprimés en même temps? Une société commerciale doit pouvoir recevoir des messages de toute provenance et doit éviter un maximum de pertes de messages, sinon ce sont des clients en moins et donc des bénéfices en moins. Ces sociétés vont donc investir dans des solutions très sophistiquées qui maximisent la détection et minimise les dommages collatéraux.

Une des caractéristiques que l’on retrouve souvent dans les SPAM, c’est que l’adresse de l’expéditeur est fantaisiste bien que de forme correcte. Une des méthodes de lutte est de renvoyer un message à l’expéditeur pour demander une confirmation. Il n’est malheureusement pas infaisable pour un robot de pouvoir répondre positivement à cette confirmation, même avec un captcha.

Le particulier à potentiellement moins de problème qu’une société. Il peut facilement mettre de côté tous les messages dont les expéditeurs ne lui sont pas connus. Il suffit de temps en temps de regarder le dossier des SPAM (les inconnus) si on attend un message d’un nouveau destinataire. Mais même cette méthode a ses limites. Certaines sources de SPAM essayent de pirater des boîtes aux lettres d’utilisateurs légitimes (vos amis) pour leur faire envoyer à leur insu des SPAM. Un certain nombre de virus sont spécialisés, une fois qu’un nouvel ordinateur est contaminé, pour aller dépouiller le carnet d’adresse. Et pour rendre plus difficile la détection du poste contaminé, d’envoyer les SPAM en se faisant passé pour un des contacts du carnet d’adresse.
Si la méthode du filtrage est assez efficace tant en détection quand tant que rejet de messages légitimes, elle peut au besoin être complétée par une autre méthode comme un filtre bayesien par exemple.

Les filtres de type RBL sont un moyen de défense dynamique assez performant avec peu de dommages collatéraux. Mais d’un autre côté, si ils bloquent des plages entières d’adresses IP (plages IP des clients des ISP), ils deviennent catastrophiques par le nombre de messages légitimes bloqués.
Le filtre greylist est quand à lui basé sur le bon fonctionnement du serveur émetteur du SPAM. Ça marche encore très bien aujourd’hui avec aucun rejet de message légitime, mais cela ne tient qu’à la volonté des diffuseurs de SPAM d’améliorer (un peu) leurs outils.

On voit que la lutte contre le SPAM utilise des outils qui ont tous leurs limites. Ils sont tous par principe faibles parce que le protocole n’a pas été prévu pour lutter contre ce problème.
Dans la plupart des SPAM, on a clairement une carence dans l’identification de l’expéditeur.

Le moyen naturel d’y répondre est d’être capable d’identifier tous les acteurs générateurs d’information. Cela veut dire que, n’étant pas capable de pouvoir identifier toutes les sources possibles et légitimes dans le monde, on va devoir se fier à un système plus global qui se base sur des autorités de confiances. Un système sur le principe du DNS mais aussi des certificats x509.
Mais imposer une identification globale remet directement en cause l’anonymat. Et se reposer sur des autorités de confiance n’est pas sans conséquences. Les problèmes récurrents de piratage des autorités de certification nous montre que c’est loin d’être infaillible.

Que faire? Comment palier le manque d’identification sans remettre en question l’anonymat? Vu comme ça, cela semble impossible.
La réponse la plus simple serait de couper toute communication. Mais l’être humain a la nécessité (absolue) d’accepter des échanges, qu’ils soient de forme électronique ou pas d’ailleurs. Et l’être humain sait naturellement faire le tri des informations, de juger le risque de sélectionner une information plutôt qu’une autre. Il sait aussi se tromper et se faire manipuler.
L’humain doit revenir au centre de la décision lorsque le temps et la quantité d’informations ne sont pas saturantes. Il faut afficher l’information qui permet la prise de décision. Et si certaines actions sont fortement automatisées, il faut afficher le résultat de ces actions que l’automatisme a jugé nécessaires.

Comment se positionne nebule vis-à-vis de ce problème?
Il propose un système capable de gérer des utilisateurs localement mais qui peuvent être reconnus globalement. Ainsi, un utilisateur n’est valide que parce-qu’il est reconnu par ses paires, en gros ses voisins. Mais on est capable d’adresser un utilisateur à l’autre bout du monde, ce même si on ne le connaît pas. On peut éventuellement se fier à des autorités locales de confiance qui déterminent qui sont de vrais utilisateurs et qui ne le sont pas. On peut aussi dire que l’on accepte ou rejette certains utilisateurs en fonctions de critères comme la proximité sociale ou géographique.
Mais le risque, c’est la manipulation de ces règles de sélections à l’avantage du diffuseur de SPAM. Diffuseur qui peut être plus facilement bannis aussi.L’autre risque, c’est la compromission du poste de l’utilisateur, et donc l’envoie de SPAM à son insu. Mais ça c’est un problème d’une toute autre dimension…

Liens :
http://fr.wikipedia.org/wiki/Spam
http://fr.wikipedia.org/wiki/Courrier_%C3%A9lectronique
http://fr.wikipedia.org/wiki/Lutte_anti-spam
http://fr.wikipedia.org/wiki/CAPTCHA

Localisation de fichiers

Samedi, mars 30th, 2013

Une étape importante dans l’utilisation de nebule, c’est d’importer des données. Ces données sont typiquement des fichiers existants. Cette opération d’importation de fichiers, c’est la nébulisation de fichiers.

La nébulisation de fichiers ne présente pas à priori de difficultés. On calcule son empreinte et on lui associe tout un tas d’informations telles que son type mime, sa taille, etc…

Il y a cependant une propriété des fichiers qui pose un problème.
Un fichier est classiquement reconnu par son nom. ce nom est une propriété du fichier au même titre que sa taille par exemple. L’extension de fichier n’est qu’un indicateur, peu fiable, de son type. L’extension de fichier est repris comme suffixe du nom.
Il peut y avoir plusieurs fichiers qui portent le même nom (et même suffixe) et qui ont ou non le même contenu. Ils doivent dans ce cas être disposés dans des emplacements différents. Cet emplacement peut être repris comme préfixe. L’emplacement est la traduction textuelle de l’arborescence de répertoires dans lequel se trouve un fichier. Et l’emplacement peut être soit relatif (à un autre emplacement), soit absolu. Dans tous les cas, il fait implicitement ou explicitement référence au disque, la distinction entre les deux dépendant de la notation faite par les différents systèmes d’exploitations. Nous ne prendrons ici que l’emplacement absolu, seul à pouvoir discriminer de façon certaine deux fichiers au même nom.
On peut aussi avoir deux fichiers de même nom/suffixe dans le même répertoire, mais sur deux machines différentes. Dans les différentes notations, il est donc préférable de se restreindre à l’utilisation de notations impliquant le nom de machine. Sinon on risque de pouvoir restaurer correctement un fichier en cas de besoin (si c’est le but).

Le problème de la notation des noms de fichiers peut se poser aussi dans le cas de deux fichiers identiques au même emplacement sur deux machines différentes. Si un des fichiers est modifié, cela va entraîner la création d’un lien u pour l’objet correspondant. Si rien ne distingue les deux fichiers, cela implique que l’autre fichier non modifié sera marqué comme lui aussi modifié…

Références :
Nebule blog – Empreinte d’objets et URI
Nebule blog – Fiches perforées
- Nebule blog – Fichiers et chemins
Nebule blog – Système de fichiers
Nebule wiki – Réflexion – analyse des applications – Système de fichiers

Le maître des poupées et le gardien de l’enfer

Mercredi, février 27th, 2013

1/Le maître des poupées

Le maître des poupées, alias puppetmaster, vient de révoquer son ancienne incarnation :

63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

Contrairement à ce qui avait été annoncé, c’est un lien de type d qui à été utilisé, et non un lien de type u. Ceci pour un problème de sécurité. Ainsi son ancienne incarnation ne peut pas révoquer ce type de lien… et ressusciter.
Le détail ici : puppetmaster.nebule.org/l/63864e42204080051f524d5be0171920e0117a0e83d2131ac506ce3cbff7f1f4

D’autres anciennes incarnations ont elles aussi été révoquées, à la fois pour la clé publique et la clé privée :
70668497b6a0ad481aa7e0c08131bc0d0be40cd7dde30a7de8613290d7c35543 puppetmaster (priv)
9e85d7d25af97760f8611b85c2765912606c7eec8307dc58c7782e34cc373c18 cerberus (pub)
905296b7070b8e7d601d9509893683d072bb22083006a9e545ceaf0228787c8c cerberus (priv)
d756efe28847a3723639aed49a40f08c22a576ff3f002750a18ad6a192717621 kronos (pub)
5f951d41db3b18001fbc8baf895d84cb4d460a6143b273b4f5b2d0e9b0d5c67b kronos (priv)

Dans le même temps, puppetmaster a reconnu plusieurs nouvelles entités :
01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4 cerberus cerberus.nebule.org
abdbaa31e404463ecc644f1eecdeb9b5f94428eb140fa5c66a7687ee96ed47aa kronos kronos.nebule.org
975571a8a470a6d975662e284f5ef1bd0396c06b31a2207b81bef2e24c5bf0c5 stéphane stephane.nebule.fr
Voir le détail ici : puppetmaster.nebule.org/l/88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

2/Le gardien de l’enfer

Le gardien de l’enfer, alias cerberus, vient d’être régénéré en tant que :

01351dd781453092d99377d94990da9bf220c85c43737674a257b525f6566fb4
cerberus.nebule.org

Il est reconnu par puppetmaster. cf Cerberus et la mise en quarantaine d’objets.

Pour son rôle spécifique, il dispose de deux objets spécifiques :
nebule/danger
nebule/warning

Actuellement, les enfers n’ayant pas encore officiellement ouverts, cette entité est au chômage.
Seul le temps nous dira pour combien de temps…

Yubikey et la double authentification

Samedi, janvier 26th, 2013

Une des bêtes noires de la sécurité des utilisateurs et de leurs informations sur l’Internet est le mot de passe. Ou plutôt devait-on dire la multitude de mots de passes et de comptes utilisateurs qui vont avec.

Chaque service web nécessite un compte utilisateur pour être utilisé, normal. Ce qui est moins normal, c’est que cette identification reste assez strictement localisée au service en question. A part quelques tentatives qui n’ont remportée qu’un succès d’estime, chaque service gère jalousement ses utilisateurs. Il en résulte un multitude de comptes utilisateurs différents avec potentiellement autant de mots de passes.
La gestion de l’identité sur l’Internet est un vrai problème. La gestion des mots de passes associés encore plus. Même si l’on met le même mots de passe partout, il faut régulièrement le retaper. Et bien sûr, avec un mot de passe unique, on devient vulnérable au premier service qui ne sécuriserait pas correctement ceux-ci.

Yubico propose une solution basé sur le mot de passe à usage unique (OTP – One Time Password). L’ensemble fonctionne sur le principe de ‘ce que je connais‘ et ‘ce que j’ai‘. La double authentification repose donc sur deux moyens combinés de prouver son identité. On doit fournir les deux ou prouver que l’on détient les deux.

  1. Ce que je connais‘, c’est typiquement un nom d’utilisateur et un mot de passe.
  2. Ce que j’ai‘, c’est un objet dont je dispose. Cet objet doit être capable de prouver sa présence de façon numérique. C’est ici la YubiKey.
  3. Ce que je suis‘, c’est le plus dur à obtenir… puisque c’est généralement ce que l’on cherche.

La clé YubiKey branchée en USB émule un clavier et envoie un mot de passe OTP lorsque l’on appuie sur un bouton de la clé. Ce mot de passe unique est dérivé de l’identifiant de la clé, d’un numéro de séquence, d’une empreinte CRC et de divers autres champs. Le tout est converti en caractères imprimables et envoyé comme si il était tapé sur un clavier.
Ce OTP est transmis au serveur en même temps que le nom d’utilisateur et éventuellement un autre mot de passe (double authentification). Le serveur le transmet au YubiCloud pour vérification et attend une réponse positive ou négative sur la validité de l’OTP pour donner l’accès au service à l’utilisateur… ou pas.
L’OTP change à chaque fois et ne peut être rejoué. Il peut donc être divulgué une fois utilisé.
La YubiKey peut être volée, sans le compte à utiliser (ou le deuxième mot de passe) elle est inutilisable.
Si double authentification, le mot de passe peut être volé (keylogger), il n’est pas utilisable sans la YubiKey à côté.

Une des propriétés intéressante de cet implémentation, c’est que l’on peut voir l’ensemble comme la transmission de messages chiffrés (symétrique) entre la YubiKey et la YubiHSM. Toutes les clés connaissent l’unique (ou pas loin) mot de passe secret de chiffrement. On fait confiance au matériel (les clés USB) pour savoir garder le secret.

Le système est de loin préférable à la simple authentification par mot de passe. Mais il n’en présente pas moins des problèmes :

  1. Une petite polémique est apparue sur la robustesse réelle du système. Un CRC16 permet de vérifier la validé du paquet. Ce CRC est inclus dans les données chiffrées et couvre donc 128-16=112bits. En jouant des paquets au hasard, il y a 1/(2*2^16) chances que la signature du CRC16 soit cohérente avec le reste. Si l’on compte qu’il faut statistiquement parcourir la moitié des valeurs pour en trouver une bonne, cela donne une probabilité de 1/(2^16). Cependant, dans les données chiffrées, il y a aussi le champ private identity de 6 bytes=48bits. Ce champs étant vérifié comme nul ou valide par les serveurs, la probabilité remonte à 2*1/(2^(16+48)) soit 1/(2^63). Ce qui sauve les meubles c’est que l’attaque doit passer par le réseau, la solidité réelle de l’ensemble est de 2^63 et non de 2^128…
  2. Il faut la coopération active des services qui authentifient les utilisateurs. La méthode d’authentification doit être modifiée pour supporter la vérification de l’OTP en liaison avec le YubiCloud, l’infrastructure qui valide réellement l’authentification. Pour les personnes qui gèrent elles-même leurs blogs ou autres services, c’est un réel gain. Mais pour un gros acteur de l’Internet c’est plutôt une ingérence sur un sujet sensible que sont les utilisateurs et tout ce qu’ils rapportent. Cela à donc autant de chance d’être adopté que d’autres solutions par le passé comme OpenID, faible.
  3. La solution nécessite une connectivité vers l’Internet et le YubiCloud pour valider l’authentification. Impossible donc de travailler hors-ligne. Il y a 5 serveurs dans le monde, c’est déjà pas mal mais c’est aussi encore trop peu pour résister à un DDOS ciblé. Et en cas d’absence de connexion prolongée aux serveur, tous les services associés sont eux-aussi paralysés. On a un point de défaut unique.
  4. Comment va se comporter l’ensemble lorsque le compteur anti-rejeu va boucler ? La clé ne marchera plus. La taille du compteur est de 15bits=32768 utilisations (avec branchement de la clé).
  5. Volontairement, la YubiKey ne peut être mise à jour. La clé est accessible en lecture seule, ce qui empêche la diffusion de virus et réduit la surface d’attaque de celle-ci. Mais que se passera-t-il quand, inévitablement, une faille sera trouvée sur cette clé ? Poubelle.

D’autres questions restent en suspend. L’analyse rapide de la documentation sur le site web de Yubico ne permet pas d’y répondre.

  1. Clé unique de chiffrement AES entre toutes les clés YubiHSM ? Ou une clé AES par YubiHSM ? Ce système de clés secrètes interdit notamment toute concurrence avec les mêmes clés. Utiliser la cryptographie asymétrique plutôt que symétrique aurait permit bien plus de choses et relevé la sécurité à plus long terme.
  2. Et si un serveur d’authentification du YubiCloud répond toujours OK même si les OTP sont invalides ? Quelle est la robustesse de l’infrastructure du YubiCloud ? La liaison entre les API côté clients et les serveurs API Validation Servers est chiffrée avec une clé partagée. Les serveurs KSM avec leurs YubiHSM sont indépendants des API Validation Servers. Mais si la clé AES semble bien protégée dans les YubiHSM, je n’ai pas vu de mécanisme de signature de la réponse.
  3. Yubico ne semble pas aimer la cryptographie symétrique, elle n’est employée nulle part. Dans un contexte entièrement centralisé autour de quelques serveurs, la cryptographie symétrique appliquée à tous les échanges reste cependant acceptable. Mais on en revient à une critique précédente, cela renforce l’unicité du point de défaillance de ces serveurs.

Qu’en penser ?
Toute la sécurité repose sur la/les clés AES des YubiHSM, la robustesse de la clé YubiKey et sur l’implémentation du chiffrement de l’OTP. La solution semble viable à court terme. Trop de défauts la condamne malheureusement à long terme.
Bref, c’est mieux que de se reposer uniquement sur le user/password, mais il faudra l’abandonner sans regrets au premier signe de faiblesse.

Liens :
http://www.yubico.com/
http://www.wired.com/wiredenterprise/2013/01/google-password/all/
http://www.yubico.com/products/yubikey-hardware/
– http://static.yubico.com/var/uploads/pdfs/YubiKey_manual-2.0.pdf
http://www.yubico.com/wp-content/uploads/2012/10/YubiCloud-OTP-Validation-Service-v1.1.pdf
http://www.schneier.com/blog/archives/2013/01/googles_authent.html
http://gonzague.me/yubico-yubikey#axzz2IzWaf5Dr
https://bitcointalk.org/index.php?topic=85648.msg943612#msg943612
http://openid.net/