La mise en place dans sylabe du code nécessaire à la résolution du graphe des mises à jours d’un objet montre que l’on peut créer une sorte de raccourci d’objet.
Ce détournement ne pose à priori pas de problème puisqu’il sera impossible de créer un objet avec cette empreinte réduite et que toute tentative se traduira par un rejet de l’objet lors de la vérification d’intégrité.
L’utilisation des liens de mise à jour d’objets est utilisé dans des cas biens spécifiques mais revêt une grande importance par exemple dans la mise à jour de programmes. Cela a notamment des implications sur la sécurité des programmes gérés sous forme d’objets.
Les liens de mise à jour n’ont pas de contraintes et peuvent donc créer des graphes de liens entre objets de forme quelconque. Cependant, l’usage de ces liens dans nebule nécessite que pour un objet donné on obtienne un unique autre objet. Cet objet doit être disponible puisque l’on est dans le cas d’un usage, c’est à dire de son utilisation immédiate.
La résolution d’un graphe de liens permet d’obtenir l’identifiant un objet dérivé unique et disponible pour un objet de départ en tenant compte de la validité des liens. Cette résolution est spécifique à nebule et se fait sous forme arborescente en ne tenant compte de des liens descendants et non bouclés.
Table des matières :
Cette méthode de résolution va maintenant être expérimentée grandeur nature dans sylabe pour la gestion des versions des programmes. Continuer la lecture de Résolution d’un graphe de relations de mise à jour
Le code de sylabe, en php, est corrigé pour répondre au problème d’interopérabilité du chiffrement.
CF Avancement
Le code en bash doit encore être corrigé.
Maintenant que l’IV est utilisé par défaut avec une valeur nulle, il n’a plus à être précisé. Le lien qui était généré vers l’objet nebule/objet/encode/InitialVector pour le préciser n’a plus de raison d’être utilisé.
Il en est de même pour la clé de session. L’objet de la clé de session apparaît naturellement dans les deux liens de chiffrement. Il n’est donc pas nécessaire de re-préciser que c’est une clé de session. Il n’est d’ailleurs pas utilisé dans le processus de déchiffrement. Le lien vers nebule/objet/encode/SessionKey ne sera donc plus généré.
Et de fait, l’objet nebule/objet/encode n’a plus d’utilité non plus. La documentation de nebule v1.1 est mise à jour en conséquence. On supprime ces objets réservés :
Voici la suite sur les problèmes d’implémentations de la cryptographie symétrique tel que décris dans OpenSSL et la cryptographie et Interopérabilité du chiffrement(blog sylabe).
Après quelques tests sur le chiffrement symétrique avec la commande openssl et son équivalent en php, j’ai trouvé les bonnes implémentations pour obtenir le même chiffre à partir des mêmes valeurs en entré.
Il y a à la fois une erreur dans l’implémentation de openssl dans nebule en bash, et une autre erreur d’implémentation de openssl dans sylabe en php.
En bash, la commande openssl enc était appelée avec l’option -kfile alors qu’il faut utiliser l’option -K.
Il faut en plus utiliser l’option -nosalt pour ne pas ajouter de sel et donc notamment avoir un objet chiffré de taille strictement identique à l’objet en clair.
Voici une courte implémentation qui marche, dans le cadre d’emploi de nebule exclusivement :
#!/bin/bash nebule_symalgo="aes-256-ctr" iv='00000000000000000000000000000000' echo -n "477fd3f3a32dc5de70cf13d1e46d8663f5f23873826572ea8359064b6d63c60c2d76f29a5e34fac2aebb157975517ef23110f4a5e415d9d0408f6fe7b9fe17bdd6bbb2df3fb819ecbd5216835ecccc559e7eb84e0517e92538d9a81fec333498a64b90df3429abe857ba1666fc93b24509e63d05fd619da9eef12c8d70dbacca" > /tmp/bdata key='8fdf208b4a79cef62f4e610ef7d409c110cb5d20b0148b9770cad5130106b6a1' openssl enc -e -$nebule_symalgo -in "/tmp/bdata" -out "/tmp/bcode" -K $key -iv $iv -nosalt -p sha256sum /tmp/bcode
En php, la commande openssl_encrypt recevait la clé de chiffrement hexadécimale alors qu’il faut la transmettre sous forme binaire.
Par défaut, aucun sel n’est utilisé.
Enfin, l’IV peut avoir une valeur nulle contrairement à ce qu’affirme la documentation. Ce doit être une erreur de traduction. La valeur de doit pas avoir une taille nulle.
Voici une courte implémentation qui marche, dans le cadre d’emploi de nebule exclusivement :
<?php
$nebule_symalgo = 'aes-256-ctr';
$data="477fd3f3a32dc5de70cf13d1e46d8663f5f23873826572ea8359064b6d63c60c2d76f29a5e34fac2aebb157975517ef23110f4a5e415d9d0408f6fe7b9fe17bdd6bbb2df3fb819ecbd5216835ecccc559e7eb84e0517e92538d9a81fec333498a64b90df3429abe857ba1666fc93b24509e63d05fd619da9eef12c8d70dbacca";
$hiv='00000000000000000000000000000000';
$iv=pack("H*", $hiv);
$hkey="8fdf208b4a79cef62f4e610ef7d409c110cb5d20b0148b9770cad5130106b6a1";
$key=pack("H*", $hkey);
$cryptobj=openssl_encrypt($data, $nebule_symalgo, $key, OPENSSL_RAW_DATA, $iv);
$hashcryptobj=hash('sha256', $cryptobj);
echo "E=$hashcryptobjn";
?>
Un article de Wired parle de WatchDox, une (relativement) nouvelle solution de partage de données incluant une protection au niveau de la donnée elle-même.
En résumé, c’est un système type nuage (cloud computing) qui s’interface avec la suite Office de Microsoft et la visionneuse de PDF de Adobe. L’utilisation est donc assez pratique pour qui est full Microsoft, mais aussi assez bridée de fait.
Le véritable intérêt, et ce qui le démarque de la concurrence, c’est que la protection de la donnée se fait au niveau de la donnée elle-même. Ce n’est pas géré de façon globale sur un serveur par des droits génériques et hérités mais qui ne s’appliquent que sur le serveur.
Il est notamment possible d’interdire la retransmission d’un document ou son impression, et plus encore. Cela ressemble beaucoup comme ça à ce que permet le PDF si on utilise les outils de Adobe, justement…
Il y a aussi une fonctionnalité de traçage des consultations. Chaque destinataire légitime d’un document peut l’ouvrir. Le propriétaire, l’expéditeur, sait qui l’a consulté et quand.
Au début, je me dis que j’ai enfin quelque chose qui ressemble à nebule, une gestion et une sécurisation des documents pensées au niveau du document lui-même. Il va être possible de confronter les principes sous-jacents à nebule avec quelque chose de proche…
L’enchantement ne dure pas longtemps. Pour remettre tout de suite le contexte de WatchDox, la société n’est pas encore rentable avec 10M$ de revenus annuels.
Ensuite, oui on gère des droits de diffusion au niveau de chaque documents. Mais on est finalement loin de nebule dans le fonctionnement. La donnée est chiffrée et taguée avec des droits. Ces droits sont des droits dits faibles parce qu’ils vont à l’encontre d’une règle simple : toute information que l’on transmet, on en perd irrémédiablement le contrôle.
Alors, ou est l’ambiguïté ? C’est simplement que cette solution repose sur le programme qui gère les données. La cryptographie permet de s’assurer que la donnée ne sera pas volée en cours de transmission, mais la sécurité des restrictions de (re)partage des données ne tient que sur le programme. De plus, bien que l’on puisse imaginer un cache local des données chiffrées, il faut impérativement être connecté pour exploiter les données et ainsi permettre à la traçabilité de fonctionner.
Cela veut dire qu’il est impossible de rendre publique le code du programme ou même son fonctionnement. Sinon il deviendrait possible de concevoir un programme pour manipuler les données en récupérant (légitimement) la clé de chiffrement mais aussi par exemple en permettant d’outrepasser les restrictions de partage.
Cela exclu aussi de fait toute standardisation ou interopérabilité de cet outil à d’autres produits plus ouverts, une implémentation libre par exemple.
Cette solution ne peut donc prétendre interdire la perte d’information, c’est conforme à la théorie. D’ailleurs, l’article reconnaît qu’il est toujours possible de voler l’information qui s’affiche à l’écran, même en mode paranoïaque. Elle permet quand même d’augmenter sensiblement la difficulté du vol d’information. Il reste à voir comment la gestion des droits va se passer au bout de quelques années et avec plusieurs centaines de milliers de documents…
Il reste la partie chiffrement des données dans le nuage qui peut sérieusement justifier la mise en place d’une solution comme WatchDox. Mais quelle confiance peut-on avoir en un système pour lequel on ne peut espérer obtenir le fonctionnement réel, et donc sur lequel aucun audit de sécurité sérieux et impartial ne peut être mené ?