Archive for the ‘confiance’ Category

Pondération et structure hiérarchique

Mercredi, août 30th, 2017

Suite de la gestion de la pondération.

Dans une structure ou une organisation hiérarchique, forme courante d’organisation, une autorité peut être amenée à déléguer son pouvoir à un autre individu. C’est le cas notamment leur d’une vacance.

Rapporté à une entité dans nebule, une entité a qui on donne une forte pondération, à qui on fait confiance, sera toujours prioritaire sur une autre de moins forte pondération. Comment permettre une vacance ? Est-ce que l’on peut mettre en place une forme de délégation de pondération ? Est-ce que ce lien de délégation est simplement annulé en fin de vacation ?

Cela pose aussi question sur la forme de la pondération. Elle est normalement globale. Mais ne faut-il pas gérer une pondération par rôle en plus ? Doit-il être géré comme une pondération avec un contexte social ?

Bugg d’affichage des autorités globales dans option

Vendredi, juin 2nd, 2017

Il y a un petit problème dans l’affichage des autorités globales dans l’application option. Par exemple ici :

https://sylabe.com/?a=21215100000000…0000000212151&view=gauth
shot-2017-06-02_19-51-13

Mais une partie de l’affichage est bon est correspond bien à l’entité bachue qui gère le code. Un petit tour par le bootstrap permet de s’en assurer :

https://sylabe.com/?b
shot-2017-06-02_19-57-13

Entités de recouvrement – implémentation

Jeudi, décembre 8th, 2016

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é.

Entités de recouvrement

Dimanche, février 28th, 2016

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.

Sondages et votes

Vendredi, septembre 11th, 2015

Dans un article La Suisse pourrait imposer l’open-source pour le vote électronique de Numerama, il est de nouveau question de la mise à disposition du code source du programme sous forme de logiciel libre.

L’avenir du vote électronique ne fait aucun doute, seule sa réalisation pose problème aujourd’hui. Beaucoup de débats comparatifs et contradictoires ont lieux vis-à-vis de la pertinence du vote électronique et de la confiance que l’on peut apporter aux machines de vote et au processus dans son ensemble. Ces débats peuvent paraître très conservateurs mais ils sont néanmoins nécessaires puisque le vote est un acte fondamental de nos démocraties, c’est le moyen d’expression de chacun d’entre nous.

La confiance en ce genre de machine de vote et du code qui l’anime ne peut être assurée sans l’ouverture du code à minima en lecture. Il faut aussi connaître précisément l’environnement de compilation et d’exécution pour le code soit parfaitement reproductible. Et bien sûr, il faut être sûr ce c’est bien ce code qui a été utilisé et pas un autre.
Invoquer le secret industriel sur du code pour un processus parfaitement connu et un enjeu majeur de démocratie, c’est particulièrement malhonnête. Tout au plus une société éditrice peut-elle demander un droit de paternité et une restriction de commercialisation à son seul bénéfice. Mais il suffit à l’état qui fait la commande du code de demander, et payer, explicitement la libre diffusion ou la libéralisation complète du code.

Le code doit être capable dans son ensemble de permettre la centralisation des votes, l’anonymisation des électeurs ainsi que la vérification en temps réel et à postériori du décompte des votes. L’authentification de l’utilisateur devrait être le principal problème mais il apparaît que c’est en fait le décompte et sa vérification qui interpellent le plus souvent les détracteurs du vote électronique.

Un vote a un point de départ dans le temps et une fin à partir de laquelle le décompte des votes est considéré comme définitif.

L’anonymisation est aussi un problème pour la vérification de conformité du vote à postériori puisqu’elle casse le lien sûr entre le votant et le vote unitaire. On peut ainsi affirmer que le votant à voté (il a posé un papier et signé le paraphore) mais on ne peut pas le prouver à postériori (était-ce vraiment lui).
La capacité de multi-entité et la dissimulation de liens dans nebule permettent de résoudre ce problème.

Voici un scénario possible de vote avec les objets et liens de nebule :

  1. Pour un vote, une entité maîtresse du vote est générée. Elle est explicitement reconnue par les autorités comme telle. Son seul rôle est de générer les jetons de vote et de les attribuer aux électeurs.
  2. L’entité maîtresse du vote va générer autant d’objets jetons qu’il y a de votants. Ces jetons sont aléatoires et n’ont pas de relation directes avec les électeurs. Chaque jeton est en fait la partie publique d’un bi-clé cryptographique (RSA par exemple). La clé privée de chaque jetons est protégé par un mot de passe stocké dans un objet protégé par et pour l’entité maîtresse (dans un premier temps).
  3. Le jeton est en fait l’entité qui réalisera le vote via la clé privée. Chaque vote peut être vérifié par rapport au jeton, c’est à dire la clé publique.
  4. Pour chaque objets de clés privées de chaque jetons, l’entité maîtresse va partager le secret de chiffrement de l’objet contenant le mot de passe. Le lien entre objet chiffré et objet non chiffré est dissimulé, c’est à dire que c’est un lien de type c masquant le vrai lien.
  5. La clé privée de l’entité maîtresse est détruite. Il n’est ainsi plus possible de retrouver l’intégralité des relations en les jetons et les électeurs mais il est possible de vérifier que tous les électeurs ont reçus un lien dissimulé et de vérifier tous les jetons réalisant le vote.
  6. Pour un vote, une entité de décompte du vote est générée. Elle est explicitement reconnue par l’entité maîtresse Son seul rôle est de recueillir et de valider les votes. La période de vote démarre.
  7. L’électeur, c’est à dire l’entités votantes, va récupérer auprès de l’entité maîtresse du vote l’intégralité des jetons et des clés privées associées (et pas juste son jeton). Il va ainsi obtenir tous les liens dont le lien dissimulé le concernant. Via le lien dissimulé, il va savoir quel est la clé privée du jeton que l’entité maîtresse lui a attribué. Disposant de cette information il peut déprotéger à son profit l’objet contenant le mot de passe de la clé privée du jeton.
  8. L’électeur, mettant à profit la clé privée du jeton, peut réaliser un ou plusieurs votes, seul le dernier est pris en compte. Le vote consiste en un lien entre le jeton et le choix de vote dans le contexte de l’entité de décompte du vote (champs méta).
  9. L’entité de décompte du vote vérifie régulièrement auprès de tous les électeurs la présence de liens dont elle est le contexte. au fur et à mesure de la récupération des liens, elle se les approprie (signature du lien de vote).
  10. A la fin de la période de vote, la clé privé de l’entité de décompte du vote est détruite. Plus aucun vote ne peut être ajouté, modifié ou supprimé. Les votes comptabilisés sont ceux qui ont été signés par l’entité de décompte du vote.
  11. L’électeur qui souhaite rendre publique son vote a juste à prouver qu’il dispose du jeton en utilisant sa clé privée pour autre chose que le vote en relation avec sa véritable entité. Il peut aussi révéler le lien dissimulé que lui avait généré l’entité maîtresse du vote.

Un des aspects des liens dissimulés est qu’il est possible de les dissimuler pour plusieurs entités. Ainsi il est possible de générer une entité d’audit du vote à qui l’entité maîtresse partagera les liens dissimulés, de façon également dissimulé.L’entité d’audit devient capable à postériori de vérifier la bonne association entre jetons de vote et électeurs sans être elle-même capable d’émettre de nouveaux jetons.

Le sondage est moins contraignant et surtout peut être à choix multiples.

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…

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.

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é…

Nébuleuse sociétale et confiance – Chiffrement par défaut

Mercredi, juillet 16th, 2014

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.

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.

Modes de traitement

Jeudi, juin 19th, 2014

Le projet nebule en lui-même donne un cadre stricte dans la forme des objets et des liens. Mais il ne donne que des orientations sur le traitement, c’est à dire l’interprétation, de ces objets et surtout de leurs liens.

Il existe aujourd’hui trois stratégies dans le traitement des objets et des liens.

Le mode ouvert

C’est la façon la plus simple d’utiliser les objets et les liens puis qu’aucune vérification n’est réalisée.

Cela implique pour commencer que les empreintes des objets ne sont pas vérifiées. Ces empreintes sont donc de pures URI avec un faible attachement au contenu des objets qu’elles référencent. Cette considération entre en conflit avec l’un des fondements du projet nebule puisque l’empreinte est strictement attaché à un objet, son contenu en fait, et que toute modification de cet objet entraîne implicitement la création d’un nouvel objet avec une empreinte propre.

Les liens ne sont pas vérifiés, ce qui veut dire que leur provenance, n’étant pas assurée, ne peut pas être non plus utilisée. Ainsi, les liens sont vus sont leur forme la plus réduite, c’est à dire la forme équivalente RDF avec la date et l’action.

Le traitement s’en trouve extrêmement accéléré. Il est pas contre impossible d’établir un échange digne de ce nom ne serait-ce qu’entre deux entités. Les notions de propriétés public et privée n’ont pas de fondement dans ce cas. On ne peut envisager ce fonctionnement que sur un périmètre restreint d’un centre de calcul et dédié à une tâche unique. On peut tout au plus envisager une passerelle vers le monde extérieur qui vérifierait scrupuleusement les entrées et signerait les sorties.

Ce mode de traitement n’est pas recommandé dans le cadre du projet nebule.

Le mode social

La prise en compte du côté social implique que l’on tienne compte de l’émetteur des liens, et donc de la validité de ceux-ci. A l’opposé du mode ouvert, cette façon de procéder est la plus complexe et la plus lente. Mais c’est aussi la plus intéressante.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Comme nous sommes dans un environnement social, c’est à dire avec de multiples entités, nous devons procéder à un tri des liens en fonction de leur provenance. Les objets sont vérifiés mais leur usage dépend exclusivement de leurs liens, et donc notamment des émetteurs de ces liens.

Lorsque deux actions sont contradictoires, il faut tenir compte de l’environnement sociale et plus seulement du facteur temporel. Il y a des différences dans la confiance que l’on accorde aux autres entités, et donc dans les liens quelles génèrent. Le tri des liens est réalisé suivant une pondération qui reflète la relation avec les entités émettrices. C’est une pondération en tout point sociale et est attachée aux entités.

L’offuscation de liens permet de cacher ou de tromper une entité sur la vraie pondération qu’on lui accorde. Mais il fait garder à l’esprit que plus elle est discordante plus elle a de chance d’être découverte ou au minimum de provoquer de la confusion.

Une pondération peut aussi être envisageable sur les objets. Cela permet en augmentant la pondération de réduire proportionnellement l’influence des autres entités sur un objet précis.

Enfin, une pondération peut être réalisée sur le type de lien et éventuellement en fonction d’un des objets référencés par un lien.

Ici, pour le projet nebule, clairement tout est quasiment à faire. La pondération des entités n’est pas encore formalisée. La pondération des objets et théorique. Et la pondération sur le type de lien n’est qu’une prévision par rapport aux modèles actuels.

Le traitement des objets et des liens, déjà ralentis par les vérifications de base, est encore plus complexe du faire des calculs de pondérations, et donc plus lent encore.

Ce mode de traitement est celui adopté par la librairie nebule de référence en php. Par extension, c’est aussi le mode de traitement utilisé dans le projet sylabe.

Le mode strict

La prise en compte du côté social est partielle, elle a même une forme exclusive. On se situe à mi chemin entre le mode ouvert et le mode social en terme de complexité.

Chaque objet et chaque lien utilisé est scrupuleusement vérifié. Contrairement au mode social, la prise en compte des entités n’est pas globale mais au contraire exclusive. On ne reconnaît que les liens de certaines entités précises. Afin de simplifier encore plus le traitement, il n’y a pas de priorisation ou de pondération dans l’exploitation des liens. Si plus d’une entité est reconnu, toutes ont le même poids et donc le même pouvoir de décision dans l’utilisation des objets. On attend ici des décisions rapides, fiables et reproductibles dans un environnement large mais avec un groupe très restreint d’objets et de liens à prendre en compte. Tout le reste est ignoré.

C’est un fonctionnement de type paranoïaque. Les notions de propriétés publique et privé sont assurées mais les échanges avec d’autres entités sont très limités et potentiellement conflictuels parce que non pondérés, non régulés. Ce fonctionnement est tout indiqué pour gérer la sécurisation de certains outils informatiques comme le déploiement de code.

Le cas le plus représentatif est par exemple la reconnaissance des entités puppetmaster, bachue et cerberus dans la validation de la librairie nebule de référence en php mais aussi du code du projet sylabe.

Ce mode de traitement est utilisé par le bootstrap en php et la librairie nebule de référence en bash. Le bootstrap ne reconnaît que les objets de bachue ou de l’autorité locale moyennant un bannissement de cerberus et sous la supervision de puppetmaster.

Gestion de la pondération

Samedi, octobre 19th, 2013

Cela fait longtemps que la pondération est en réflexion et en attente d’implémentation. Par exemple Mémoire fini, Objets privés et fonctionnement interne, RSE et Nettoyage des liens.

La cryptographie s’occupe de la sûreté de fonctionnement.

La pondération permet de gérer l’importance des objets et donc notamment des entités.
La pondération appliquée à des entités permet de gérer la confiance. Cette gestion de la confiance est en fait synonyme de la gestion de la sécurité.

Cependant, la pondération elle-même doit être exclu de la relation de confiance, c’est à dire que l’on ne doit pas tenir compte de la pondération définit par les autres entités même si on leur fait confiance. Sinon il y a danger !
Si elle est acceptée malgré tout, la confiance sur la pondération des autres entités doit être strictement délimitée et le danger pour l’utilisateur doit être clairement affiché. En fait, elle ne devrait jamais être utilisée…

Comment rester sécurisé face à la NSA

Dimanche, septembre 22nd, 2013

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 :

  1. Caché dans le réseau. Implémentez des services cachés. Utilisez TOR pour protéger votre anonymat. Oui, la NSA cible les utilisateurs de TOR, mais cela est efficace sur eux. Moins vous serez à découvert, plus vous serez en sécurité.
  2. Chiffrez vous communications. Utilisez TLS. Utilisez IPsec. Encore une fois, bien qu’il soit vrai que la NSA cible les communications chiffrées (et ils connaissent peut-être des failles spécifiques contre ces protocoles), vous serez bien mieux protégés que si vous communiquez en clair.
  3. Prenez pour acquis que, bien que votre ordinateur puisse être compromis, cela nécessite du travail et représente un risque pour la NSA (donc il ne l’est probablement pas). Si vous avez quelque chose de vraiment important, utilisez un transfert par un moyen déconnecté. Depuis que j’ai commencé à travailler avec les documents de Mr Snowden, j’ai acheté un nouvel ordinateur qui n’a jamais été connecté à internet. Si je veux transférer un fichier, je chiffre le fichier sur l’ordinateur sécurisé puis l’emmène à pied jusqu’à mon ordinateur sur internet, sur une clé USB. Pour déchiffre quelque chose, j’inverse le processus. Cela ne doit pas être infaillible, mais suffisamment bon.
  4. Soyez méfiants envers les logiciels de chiffrement commerciaux, spécialement des grands éditeurs. Mon avis, c’est que la plupart des produits de chiffrement des grandes entreprises US ont des portes dérobées pour la NSA, et il est probable que les entreprises étrangères fassent de même. Il est prudent de considérer que les équipements étrangers aient aussi des portes dérobées pour une puissance étrangère. Il est plus facile pour la NSA de placer une porte dérobée dans un logiciel à sources fermées que dans un autre aux sources ouvertes. Les systèmes reposants sur un important secret sont vulnérables à la NSA, que ce soit pour leurs activités légales ou plus clandestines.
  5. Essayez d’utiliser des algorithmes de chiffrements dans le domaine public qui nécessitent d’être compatibles avec d’autres implémentations. Par exemple, il est plus difficile pour la NSA de placer une porte dérobée dans TLS que dans BitLocker. Parce que tous les implémentations de TLS doivent être compatibles entre elles alors que BitLocker ne doit être compatible qu’avec lui-même, donnant à la NSA plus de libertés pour apporter des changements. Et parce que BitLocker est propriétaire, il est beaucoup moins probable que ces changements soient découverts. Préférez la cryptographie symétrique plutôt que la cryptographie à clé publique. Préférez les systèmes conventionnels à logarithmes discrets plutôt que les systèmes à courbes elliptiques. Ces derniers ont des constantes que la NSA influence dès qu’elle le peut.

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 :

  1. Le projet nebule, une fois diffusé, peut être hébergé partout sur le réseau. Par défaut, les entités ont des emplacements connus. Mais rien n’empêche une entité d’avoir un emplacement dont l’objet contenant est chiffré, et l’URL d’une forme difficile à deviner même si on connaît le serveur. Par contre, si les objets et liens d’une entité sont échangés avec une autre entité, elle se retrouve à découvert sur d’autres emplacements. Ceci ne devrait cependant arrivé que si des liens relient ces objets aux deux entités. Le chiffrement des objets la seule parade définitive, ce qui est logique. L’anonymisation tel que proposé par TOR n’a pas de sens dans nebule.
  2. Dans nebule, on a le choix. Rien n’empêche de chiffrer toutes les informations vitales et de placer les liens suspects dans des objets chiffrés. Ce dernier point n’est pas encore implémenté mais est prévu et est techniquement réalisable. Utiliser TLS est recommandé au risque de révéler les liens et objets échangés, et donc d’affaiblir l’anonymisation.
  3. Le risque de l’ordinateur compromis est assez actuel malheureusement. Tant qu’un système ne sera pas intégralement nébulisé, le projet nebule n’apportera pas grand chose à ce niveau. On peut cependant profiter de la signature native des objets contre la modification malveillante. Par contre, nebule permet assez facilement de faire des échanges à sens unique, via des relais d’isolation, et via des supports amovibles. Et le chiffrement peut être entièrement réalisé sur un ordinateur isolé, même à destination d’une autre entité.
  4. Pour résumer, il faut utiliser des logiciels open sources et qui ne sont pas restreints à un seul éditeur dans leur utilisation. Le projet nebule par dès le début avec un choix d’utilisation par défaut de logiciels libres (et open sources). Ceux retenus sont très utilisés, et donc très régulièrement vérifiés. L’inter-opérabilité avec d’autres systèmes et implémentations est aussi à ce prix.
  5. Le début a les mêmes réponses que pour le point 4. Il est impossible de gérer des entités avec la cryptographie symétrique. La cryptographie asymétrique est irremplaçable. Mais il ne faut pas utiliser ces algorithmes pour faire des choses pour lesquels ils ne sont pas prévus. Par contre, si l’algorithme à logarithmes discrets est principalement utilisé aujourd’hui, tout algorithme peut être utilisé en parallèle ou en remplacement. Cela n’a pas d’importance structurelle forte. Le projet nebule s’appuie sur la cryptographie asymétrique pour les signatures et chiffrements (pour les clés de sessions).

Liens :
https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html

RSE ou RSE ?

Mardi, septembre 10th, 2013

En recherchant la définition de l’acronyme RSE, je tombe sur deux définitions… Problème assez récurrent en fait avec les acronymes puisque n’importe qui peut en inventer et les utiliser sur la place publique à son bénéfice.

D’un côté j’ai une belle page bien fournie sur Wikipédia et une page gouvernementale officielle parlant de Responsabilité Sociétale des Entreprises :
Responsabilité Sociétale des Entreprises – Wikipédia
Qu’est-ce-que la responsabilité sociétale des entreprises – Ministère du développement durable
On y parle donc de responsabilité des entreprises, de développement durable, de gestion de risques, des impacts environnementaux et sociaux, enjeux, investissements, outils, normes, médiatisation, aspects juridiques, etc…

De l’autre un article sur 01net.com qui surfe sur la vague des révélations sur PRISM, ce qui n’est pas un mal en soi :
Le RSE : un lanceur d’alerte en entreprise – 01net
On retrouve bien en fin d’article un paragraphe sur le RSE, l’environnement et les risques. Mais RSE, répété à l’envie tout au long de l’article, désigne ici Réseau Social d’Entreprise. En gros un simili Facebook restreint au périmètre de l’entreprise.
Mais n’y a-t-il pas déjà un terme pour cette fonctionnalité? Oui, c’est le groupe de travail (groupware). Ah oui, c’est vrai, le créneau sur ce nom est déjà bien plein. D’un autre côté, la RSE ne doit pas plaire à beaucoup de chef d’entreprises. Bref, Voila typiquement un article à visée commerciale…

Mais ce post n’est pas là pour critiquer l’article. Les acronymes posent un problème de gestion de leurs définitions. Celles-ci ont rarement une portée globale, elles n’ont souvent qu’une définition de portée locale ou régionale. C’est cette absence de centralisation qui, à priori, serait la source des conflits.

Comment vont se comporter les acronymes dans nebule?
Reprenons le cas de la RSE. En pratique, c’est l’objet cec7b8a511f6d30def09266e7595f1dd9a301b3ba868444d2b14236dccc127b1. Aujourd’hui, cet objet n’existe sur aucune machine supportant nebule, mais si il était créé ce serait avec cette empreinte (sha256).

Premièrement, cet objet peut être marqué par des liens de type subdivision s. Il est en effet possible avec ce type de lien de savoir qu’un texte, un article de presse par exemple, contient cet acronyme. Cela facilite la recherche.
Cet exemple d’acronyme est trop petit mais le principe reste valable, le même article de presse peut être téléchargé morceaux par morceaux par ses abonnés. C’est un fonctionnement de type P2P. Chaque morceau connu peut être téléchargé à des endroits différents, puis l’article de presse peut être reconstitué. En pratique, on accélère donc les échanges d’objets.

Ensuite, L’objet de l’acronyme peut aussi être marqué par des liens de type dérivation f. Ces liens peuvent renvoyer vers d’autres objets contenant la ou les définitions de l’acronyme.
C’est un intérêt pour résoudre les conflits autour des définitions d’acronymes. En effet, chaque lien est signé par une entité, donc on sait qui en est l’initiateur. Et comme toute entité gère individuellement ses propres relations de confiances, la définition d’un acronyme sera donc dépendante des entités à qui on fait confiance, mais aussi en fonction de leur niveaux de confiance relatifs.
Donc, si on a une forte confiance en l’état, ce sera la RSE. Si on a une grande confiance en l’auteur de l’article de 01net, alors ce sera le RSE. Si on est chef d’entreprise, il y a de fortes chances que ce soit la RSE de toute façon…

Tuer l’ordinateur pour le sauver – 2

Vendredi, mars 15th, 2013

Il est encore aujourd’hui difficile de dire quel est le principal problème dans l’architecture de nos systèmes d’information. Il est d’ailleurs fort probable que ce soit un cumul de plusieurs causes qui rendre l’ensemble du SI si difficile à sécuriser. La conséquence, c’est que nous avons bien du mal à endiguer des attaques toujours plus complexes et nombreuses malgré les moyens considérables que nous déployons. Ces moyens sont de plusieurs ordres : financiers, organisationnels, humains et technologiques.

Est-ce la façon qu’on nos machines de communiquer sur l’internet qui est à revoir ?
A cette question, il est très tentant de répondre oui. Il faut filtrer, segmenter. Si l’on bloque l’internet mondial en le fermant au niveau des frontières, on résoudra une grande partie des problèmes. Mais on ne résoudra pas vraiment les vraies causes de nos problèmes. Cela ne fera que réduire la portée des conséquences. Et, en faisant cet enclavement, je pense que l’on ne fait que repousser à plus tard la résolution de ces problèmes.
Il faut peut-être plus simplement revoir comment nos machines communiquent et modifier la pile réseau. Mais cela ne tient pas compte des autres moyens de communication comme les périphériques de stockage amovibles.

Est-ce l’architecture de nos machines qui est vulnérable ?
Les attaques sur le SI ont de multiples formes parce qu’elles ont autant de buts différents. Le réseau est rarement la cible d’une attaque, alors qu’un serveur est une cible de choix. Et le serveur est une cible exposée si il veut remplir son rôle : servir. Les attaques sur les serveurs sont toujours passées par les interfaces, les entrées/sorties. Mes ces attaques n’ont de raison d’être que parce que le serveur est un objet actif, interactif. Et cette activité siège avant tout dans le processeur.
Le processeur permet l’exécution du code des programmes et notamment le système d’exploitation. Tous les systèmes d’exploitations actuels ont un (ou plusieurs) compte ou pseudo compte super-administrateur, qu’il s’appelle root ou SYSTEM. Or, le processeur ne sait pas reconnaître un compte. Il se contente d’exécuter le système d’exploitation qui, lui, contient toute la logique d’exploitation des comptes et de séparation des privilèges. Qu’est ce qui garantie aujourd’hui l’intégrité de cette logique ? Pas grand chose. Les élévations de privilèges sont courantes suite à des attaques.
D’un autre côté, le système d’exploitation repose sur un ordonnanceur. Celui-ci permet de répartir le temps de calcul du processeur entre les différents programmes, et donc de faire du multitâches entre les applications. Mais le processeur lui-même est fondamentalement monotâche. Le processeur dispose aussi d’un mécanisme, le RING, mais les systèmes d’exploitation ne l’exploitent qu’à moitié. La séparation entre les différents programmes est de fait artificielle parce que logiciel, et donc faible.
On en arrive à une aberration conceptuelle. Le super-utilisateur a plus de pouvoir sur le système que l’utilisateur qui manipule ses données, ce qui est normal. Mais ce qui l’est moins, c’est qu’il a aussi plus de pouvoir sur les données de l’utilisateur que ce dernier. En l’état de la technologie actuelle, le problème de confidentialité est insoluble sauf à considérer que l’utilisateur est le super-utilisateur. Et c’est sans compter les élévations de privilèges.
Et dire qu’un utilisateur est super-utilisateur de son système est aujourd’hui reconnu comme une aberration. La boucle est bouclée.

Le projet nebule est un premier pas vers une solution. Il est encore trop tôt pour savoir si c’est le début de la bonne solution. On permet à l’utilisateur de se réapproprier ses données. Malheureusement, l’architecture actuelle des machines ne permet pas de protéger efficacement l’identité d’une entité une fois déverrouillée, c’est à dire une fois la clé privée chargée en mémoire. Le super-utilisateur peut directement lire cette clé en mémoire. Aucune protection de prévaut dans ce cas, quelque soit sa complexité. Certes, il faut corrompre ce super-utilisateur… mais c’est justement ce qui est fait lors de la plupart des attaques informatiques actuelles.

CF : Tuer l’ordinateur pour le sauver

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…

Autorité temporaire : le maître des poupées

Mercredi, février 27th, 2013

Une entité avait été généré en novembre 2012. Elle avait pour rôle de simuler une autorité de haut niveau. Voir l’article Autorité temporaire.

Le bi-clé de cette entité n’ayant pas été généré et manipulé dans des conditions spartiates de sécurité, il était difficile d’avoir pleinement confiance en cette entité.
Il fallait donc régénérer une nouvelle entité de façon plus propre.

Une machine a été installée de façon renforcée, et est prévue pour être manipulée hors réseau.
Tous les systèmes ont leurs faiblesses, et ont donc un besoin récurrent de mise à jour. Le système le moins vulnérable face à l’absence prolongée de mises à jours, c’est OpenBSD. C’est aussi actuellement le système le moins vulnérable par défaut. La non utilisation du réseau réduit très fortement les problèmes potentiels. Il est cependant possible, en cas de nécessité, de réaliser une mise à jour manuelle.
Le disque dur est partiellement chiffré.

Cette machine a donc permit de générer une nouvelle entité racine.
Ce rôle est toujours temporaire. Il ne se justifie que pour coller à un modèle de sécurité actuel, basé sur des autorités racines de confiance. On ne peut faire confiance à une entité que si elle est validée par l’entité racine. Cependant, ce modèle de sécurité n’a pas vocation à subsister en l’état. Soit il y aura d’autres autorités racines, soit elles disparaîtront toutes.

Puppetmaster, le nouveau maître des poupées est identifié comme :

88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

Et il reprend l’emplacement de l’ancien puppetmaster :

http://puppetmaster.nebule.org/

Pour l’instant, puppetmaster ne reconnaît aucune autre entité. Ce sera fait bientôt. Et le nouveau puppetmaster réformera (lien u) aussi officiellement l’ancien puppetmaster.
Le maître des poupées est mort, vive le maître des poupées!

Autorité temporaire

Jeudi, novembre 8th, 2012

Quels incidents peut-on rencontrer sur un système d’information reposant sur une cryptographie moderne ?
Et comment peut-on y répondre ?

La cryptographie est un formidable outil mathématique. Ses propriétés sont sans équivalents dans le monde réel et palpable du commun des mortels. A cause de cela, l’outil et ses usages restent abstraits et méconnus pour beaucoup de gens. Mais, loin d’être anecdotique, la cryptographie est présente partout autour de nous, dans tout ce qui est numérique. Et il ne suffit pas d’un bon discours commercial à grand renfort de sigles abstraits suivis de quelques chiffres pour que l’ensemble remplisse son rôle : sécuriser nos données.
On se connecte à un ordinateur, le mot de passe est transformé en hash. On se connecte au site web de la banque, la connexion est sécurisée. On envoie des emails chiffrés et signés. Notre ordinateur vérifie la signature des mises à jours qu’il doit appliquer, idem pour notre box internet. Notre téléphone cellulaire chiffre la conversation avec le réseau opérateur, mais pas avec notre correspondant. La puce de notre carte bancaire valide une transaction chez notre marchant de légumes. Notre réseau wifi est protégé par mot de passe. etc…

Mais au fait, n’y a-t-il vraiment que les données à sécuriser ?
L’utilisateur est au centre de ces données, celles-ci n’ont d’utilité que pour l’utilisateur légitime et pour celui qui pourrait trouver un bénéfice à les exploiter à la place de l’utilisateur légitime.

(suite…)

Collisions d’empreintes multi-algorithmique

Vendredi, septembre 7th, 2012

On peut utiliser de multiples algorithmes pour calculer l’empreinte des objets. Certains algorithmes sont plus résistants, plus fiables ou plus sûrs que d’autres. Cette résistance est représenté par l’impossibilité (relative) d’inverser la fonction algorithmique, c’est à dire de retrouver l’objet source à partir de l’empreinte. Il en découle l’impossibilité (relative aussi) de calculer une collision dans les empreintes entre deux objets, c’est à dire de calculer un objet qui a une empreinte précise, par exemple la même empreinte qu’un autre objet pré-existant. Ces impossibilités sont relatives parce qu’il sera toujours possible dans le pire des cas (pour l’attaquant) de tester toutes les combinaisons possible afin de trouver une collision, mais cela lui prendra un temps tel que c’est jugé équivalent à impossible dans l’état actuel de nos connaissances mathématiques et de nos moyens informatiques.

Première conclusion, inutile de s’attarder sur des algorithmes de prise d’empreinte triviales comme CRC qui n’ont pour vocation que de permettre une vérification extrêmement rapide de données transmises (par exemple sur la couche TCP sur IP). Ces algorithmes ne sont pas prévus pour résister aux collisions volontaires.

Seconde conclusion, rappel de principes de base en sécurité informatique, on ne doit pas utiliser des algorithmes qui sont reconnus non fiables ou pour lesquels on est sur le point de réussir des collisions. Exit donc MD5, SHA0 et SHA1 par exemple.

Jusque là, on reste en territoire connu. SHA256 est encore aujourd’hui reconnu comme sûr et ne semble pas présenter de faiblesse à moyen terme. Il peut servir sans risque intrinsèque aux premières expériences nécessitant un bon niveau de sécurité. D’autres algorithmes connus sont susceptibles d’être utilisés dans un futur proche.

Mais que ce passe-t-il si on mélange plusieurs algorithmes différents pour le calcul d’empreinte ?
Ne risque-t-on pas d’affaiblir non pas les algorithmes mais le système dans son ensemble ?

En présentant un objets sous différentes empreintes générées par des algorithmes différents, ne risque-t-on pas d’affaiblir un ou plusieurs algorithmes ?

De façon plus générale, si une faille importante est découverte dans un algorithme et que celui-ci n’est plus jugé sûr, quelles conséquences pour l’ensemble du système ?