Catégorie : transcodage

Transcodage et translation

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage, Transcodage des liens dissimulés et Anonymisation des fichiers transcodés, il était apparu un problème avec le contenu des fichiers transcodés.

Le transcodage des identifiants des objets pour lesquels on dissimule des liens permet de stocker ces liens dans des fichiers non directement associés à l’identifiant de l’objet concerné. C’est en fait une translation d’identifiant.

Ces objets ‘virtuels’ translatés doivent pouvoir être partagés par transfert ou synchronisation sans risquer de dévoiler l’association entre l’identifiant en clair et l’identifiant translaté.

Le système de translation aujourd’hui mis en place est basé sur une clé unique de translation par entité. Cette translation doit être une fonction à sens unique, donc à base de prise d’empreinte (hash), y compris lorsqu’une ou plusieurs translations sont connues. Enfin, la translation doit être dépendante de l’entité qui les utilise, c’est à dire qu’une même clé peut être commune à plusieurs entités sans donner les mêmes translations.

Anonymisation des fichiers transcodés

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle, transcodage et Transcodage des liens dissimulés, il apparaît un problème avec le contenu des fichiers transcodés.

Le fait qu’une entité synchronise des liens dissimulés que d’autres entités partagent et les range dans des fichiers transcodés peut révéler l’ID de l’objet transcodé. Et par tâtonnement on peut retourner ainsi le transcodage de tous les objets.

Il suffit qu’une entité attaquante génère un lien dissimulé à destination d’une entité attaquée concernant un objet en particulier. L’entité attaquée va alors ranger le lien dissimulé dans le fichier transcodé. L’entité attaquante peut alors rechercher quel fichier transcodé contient sont lien dissimulé et en déduire que ce fichier transcodé correspond à l’objet.

En plus, si le lien dissimulé n’a aucune action valable, il ne sera pas exploité, donc pas détecté par l’entité attaquée.

Il faut trouver une parade. Peut-être que l’on peut chiffrer les fichiers transcodé avec la clé de transcodage. A voir…

L’algorithme de transcodage doit être non réversible.

Transcodage des liens dissimulés

Suite aux articles Anonymisation/dissimulation des liens – ségrégation partielle et transcodage, voici le nommage des liens transcodés :

/l/HashEntitéDestinataire_HashObjetTranscodé

Cela répond aussi au problème du nettoyage puisque la forme du nom n’entre pas en conflit avec les ID des objets, il est discernable des fichiers de ségrégation des liens dissimulés et il est clairement rattaché à une entité.

La clé de transcodage ainsi que l’algorithme seront abordés plus tard.

Dissimulation, transcodage et dossier privé

La réflexion de l’article Anonymisation/dissimulation des liens – transcodage est très intéressante parce qu’elle rejoint la réflexion originel de nebule implémenté en bash pour les expérimentations. Cette implémentation en bash est clairement mono-entité, c’est à dire à l’usage exclusif d’une entité là où une implémentation en php comme l’application sylabe permet un usage multi-entités simultané.

L’implémentation en bash utilise un dossier nommé /pub pour recevoir les dossiers o et l contenants les objets et les liens dits publiques, ou plutôt publiables. Ce dossier /pub peut être partagé via un serveur web. Mais il y a aussi un dossier nommé /priv qui lui reçoit des dossiers o et l contenants les objets et les liens dits privés, donc non publiables. Le dossier des objets privés permet de recevoir le contenu des objets protégés et déchiffrés le temps de leur utilisation. Le dossier des liens privés n’a jamais été utilisé mais il correspond tout à fait à ce que l’on essaye de faire aujourd’hui avec le transcodage pour les liens de dissimulation.

La structure typique des dossiers de l’implémentation en bash :

/home/user
   +-> /neb
       +-> /pub
       |   +-> /l
       |   +-> /o
       +-> /priv
           +-> /l
           +-> /o

Or le problème de la dissimulation est facile à résoudre sans transcodage dans l’implémentation bash. Mais ce n’est pas transposable dans l’implémentation en php à cause de la notion cité plus haut de capacité multi-entités simultané. Les fichiers transcodés contenants les liens dissimulés répartis par ID d’objets sont le pendant direct des liens du dossier /priv/l.

Anonymisation/dissimulation des liens – transcodage

Suite à l’article Anonymisation/dissimulation des liens – ségrégation et temporalité et ségrégation partielle, la réflexion et l’implémentation sur le stockage et l’échange des liens dissimulés progresse.

La méthode de ségrégation des liens dissimulés développée est suffisante pour retrouver les liens dissimulés et les partager. Mais si le partage est efficace parce que l’on ne récupère que les liens dissimulés des entités connues, la lecture des liens n’est clairement pas efficace.

Lors de la consultation des liens d’une objet particulier, il faut lire tous les liens de l’objet, facile, et lire l’intégralité des liens dissimulés parce que l’on ne sait pas à l’avance quelle entité à dissimulé des liens pour cet objet. Il manque de pouvoir localement (indépendamment du partage) stocker les liens en fonction des objets source, cible et méta. Mais il faut aussi ne pas dévoiler cette association d’objets cités dans la partie dissimulée du lien, ce qui permet rapidement de lever la partie dissimulée.
Il est possible de transcoder les identifiants des objets cités par le lien dissimulé. On parle bien de travailler toujours sur des fichiers de stockage dédiés aux liens dissimulés, et donc indépendamment des liens non dissimulés. Ce transcodage doit permettre de ne pas révéler l’association entre les objets cités par le lien dissimulé. Ce transcodage peut être commun à tous les objets avec une clé de codage commune, ou chaque objet peut disposer de sa propre clé de codage. Et bien sûr, chaque entité dispose de sa/ses clés de transcodage, donc chiffrées avec la clé privée.
Un transcodage avec une clé unique est plus facile puisque l’on peut chiffrer cette clé et la stocker à un endroit unique, mais il est moins sûr que le transcodage à clés individuelles.
Pour commencer on va partir sur la base de la clé unique de transcodage.

Les liens dissimulés dans des fichiers transcodés sont lisibles publiquement et peuvent potentiellement être synchronisés mais ils n’ont pas vocation à remplacer les liens dissimulés dans les fichiers dédiés à la ségrégation et utilisés lors du partage des liens.

Le nettoyage des fichiers des liens dissimulés et transcodés devient un nouveau problème.
Plusieurs entités pouvant localement générer des liens dissimulés, et donc utiliser des clés de transcodage différentes, il n’y a pas de méthode de nettoyage générique des liens dissimulés dans les fichiers transcodés. Seule une entité peut faire le nettoyage de ses propres fichiers transcodés. Il faut donc que ces fichiers transcodés soient clairement associés à une entité.

Il est possible par contre de supprimer tous les fichiers transcodés d’une entité (ou plus). Il faut dans ce cas que l’entité, une fois déverrouillée, reconstitue ses fichiers transcodés.
Cela lève un nouveau problème, comment savoir que tous les fichiers transcodés sont présents et qu’ils sont à jour. Avec cette méthode, il ne faut pas que les fichiers dédiés à la ségrégation des liens dissimulés pour une entité soient manipulés par une autre entité parce que les fichiers transcodés ne seront pas synchrones. Et les transferts ne sont pas possibles.

Les entités ne doivent pas synchroniser les liens dissimulés des autres entités !

Il reste encore des réflexions à mener autour de cette méthode de transcodage.