Catégorie : canaux cachés

Sch̩ma lien dissimul̩ Рtimestamp

Suite à l’article sur le nouveau schéma des liens dissimulés, une précision s’impose concernant les champs Timestamp, les marques de temps.

Le lien à dissimuler contient une marque de temps qui est très souvent nécessaire à l’interprétation du lien, et notamment lors de sa suppression. De l’autre côté nous avons aussi une marque de temps sur le lien dissimulé cette fois. Mais nous ne devons pas avoir une copie directe de la marque de temps du lien à dissimuler vers le lien dissimulé parce que cette marque de temps va se retrouver potentiellement dans d’autres liens générés au même moment… et pourrait donner des indications sur le lien à dissimuler.

Il faut donc que la marque de temps du lien dissimulé soit clairement non reliée à la marque de temps du lien à dissimuler.

Du coup, un autre problème émerge, comment fait-on pour supprimer un lien à dissimuler, et donc en même temps le lien dissimulé ?

Le lien de suppression du lien à dissimuler doit être le même avec comme champs action x. Mais comme il contient toutes les informations, à part le champs action, du lien à dissimuler, il faut aussi dissimuler le lien de suppression. Jusque là, c’est facile il a une marque de temps différente et en lisant les liens dissimulés on peut voir la suppression.

Mais faut-il aussi un lien de suppression du lien dissimulé de suppression ? Et où celui-ci doit-il être stocké ?

La notion de lien dissimulé et à dissimuler est assez pénible à écrire, et donc à lire. Il faut peut-être aussi revoir le vocabulaire à ce niveau pour que ce soit plus fluide…

Canaux cachés dans les liens

Il est difficile de lutter contre les canaux cachés dans les protocoles. C’est notamment le cas pour nebule avec les liens. Tous les champs du registre sont potentiellement concernés mais différentes stratégies peuvent être mises en place pour détecter à postériori le canal ou réduire fortement le débit utile à la transmission de données.

Le champs le plus facile à utiliser pour un canal caché est le champ action. Sa vérification doit être vérifiée pour que sa taille soit strictement limité à un caractère et uniquement à un des types de liens attendus.

Le champs date peut être exploité dans ses valeurs de plus faible poids comme la seconde ou ses sous multiples. Tant que l’ordre temporel des liens est respecté, il est tout à fait possible de mettre des valeurs arbitraires et donc du contenu encodé en chiffres décimaux.
De plus, comme on ne s’oriente pas vers une interprétation stricte de la norme ISO 8601, il devient possible d’utiliser une grande précision dans les sous multiples de la seconde. C’est à dire que l’on peut placer un grand nombre de chiffres en fin de date tant que ce sont des chiffres décimaux.
La vérification de la date peut inclure une taille limite pour réduire la quantité de données cachées.

Les champs des objets peuvent référencer des objets fictifs, et donc en fait ces champs peuvent contenir des données convertis en hexadécimal. Il est possible de vérifier que ces champs objets ont une taille compatible avec les algorithmes de hash. Il est possible de vérifier si ceux-ci ont tous les attribut que l’on attend d’un objet, voir qu’ils sont bien disponibles.

Le champs de l’entité signataire ne peut pas être modifié n’importe comment, mais en utilisant plusieurs entités différentes on peut faire un canal caché sous forme d’une sorte de morse. Cela peut peut-être être détecté en regardant les entités en question.

Le champs signature n’est pas facilement exploitable. Tout au plus peut-on faire du morse en jouant sur la date pour générer une signature qui commence ou termine par un chiffre précis. Il est plus probable que le champs date soit exploité à la place pour un canal caché.

La documentation va être modifiée pour réduire les problèmes avec les champs date et action.