Catégorie : Programmation

Avancement

La cryptographie vient d’être corrigée dans la librairie nebule en php. Elle est de nouveau complètement opérationnelle. Plusieurs essais ont été notamment réalisés sur le même objet qui a été protégé/déprotégé plusieurs fois de suite : ça marche.
Il faut encore corriger l’implémentation de référence de nebule en bash, mais ça ne devrait pas poser de problème.
De plus, le code a été complété pour pouvoir déprotéger un objet soit depuis l’objet en clair soit depuis l’objet chiffré.

Dans la continuité du déchiffrement d’objet, il est maintenant possible d’afficher en ligne d’un objet chiffré avec donc le déchiffrement à la volé. Il faut bien sûr déverrouiller l’entité et avoir accès à la clé de session de l’objet. Cela se traduit par la possibilité de voir directement dans sylabe, dans le mode aff, certains objets chiffrés. Son concernés les images jpeg et png, les fichiers audio mp3 et ogg, les textes brutes et les clés RSA.
C’est étonnant à voir dans le mode lnk puisque l’objet protégé apparaît rouge dans les liens puisqu’il a été effacé, mais il s’affiche quand même en haut des liens!

Un début de support existe pour les fichiers mp3 et ogg bien qu’il y ai encore un problème de définition du type mime lors de l’envoi d’un nouveau fichier de ce type.

Interop̩rabilit̩ du chiffrement Рsuite

Suite à un problème dans le déchiffrement dans sylabe d’objets chiffrés via la commande openssl, et vice versa, la diffusion des nouvelles versions de la librairie de nebule en php avait été suspendu.

Le problème ayant été trouvé, la diffusion va pouvoir reprendre.

Les corrections qui vont être apportées à sylabe vont casser les objets précédemment chiffrés à la fois dans sylabe et dans l’implémentation bash de nebule.

Voir la description du problème de OpenSSL et la cryptographie, et la résolution OpenSSL et la cryptographie – suite.

Publication du code source

Le code source de sylabe en php en date du 24/10/2013 est publiée sur le wiki de nebule.

En attendant d’avoir tout le nécessaire pour une auto-publication, c’est à dire sous forme d’objets et liens nebule (par l’entité bachue), la diffusion du code source se fera sous cette forme.
Il en est de même pour la librairie de référence de nebule en php.

La page contenant le code : http://wiki.nebule.org/index.php/Documentation_-_Impl%C3%A9mentations_de_r%C3%A9f%C3%A9rences_-_projet_sylabe

La page concernant la librairie de référence nebule: http://wiki.nebule.org/index.php/Documentation_-_Impl%C3%A9mentations_de_r%C3%A9f%C3%A9rences_-_php

CF : nebule РLibrairie de r̩f̩rence php

Problème de signature

Je coince sur la génération de lien, plus exactement sur la signature. Le résultat pour un lien déjà connu ne me donne pas la même signature… alors que le code pour vérifier la signature des liens existants marche bien maintenant.

Le code qui ne me retourne pas la bonne valeur :

function _l_gen($dat, $typ, $src, $dst, $met)
{ global $nebule_publ_entite, $nebule_priv_entite, $nebule_pass_entite;
  if ($nebule_publ_entite == '') return(false);
  if ($nebule_priv_entite == '') return(false);
  if ($nebule_pass_entite == '') return(false);
  if (! file_exists("o/$nebule_priv_entite")) return(false);
  if ($typ == '') return(false);
  if ($src == '') return(false);
  if ($dst == '') return(false);
  if ($met == '') return(false);
  if ($dat == '-') $dat = date(DATE_ATOM);
  $privcert=(nebReadObjText($nebule_priv_entite,10000));
  $private_key=openssl_pkey_get_private($privcert, $nebule_pass_entite);
  if ($private_key === false) { return(false); }
  $data='_'.$nebule_publ_entite.'_'.$dat.'_'.$typ.'_'.$src.'_'.$dst.'_'.$met;
  $hexsign='';
  $binary_signature='';
  $hashdata=hash("sha256", $data);
  $binhash = pack("H*", $hashdata);
  $ok=openssl_private_encrypt($binhash, $binary_signature, $private_key, OPENSSL_PKCS1_PADDING);
  unset($private_key);
  unset($hashdata);
  unset($binhash);
  if ($ok === false) return(false);
  $hexsign = bin2hex($binary_signature);
  return("$hexsign.sha256$data");
}

T̩l̩chargement et suivi de liens u Рsuite

Suite au post Téléchargement et suivi de liens u, la réflexion peut être poussée plus loin.

Le dossier /o/ va recevoir tout un tas d’objets, dont du code divers, varié et avarié. Si le serveur web qui héberge sait interpréter du code (donc autre chose que du HTML), alors le dossier /o/ ne doit pas être accessible directement. Dans ce cas la redirection et le traitement par une interface dédiée telle que sylabe est obligatoire.

Téléchargement et suivi de liens u

Avant de mettre en place le téléchargement d’objets et de liens via sylabe et non sur une URL directe, je voulais terminer la résolution du suivi des liens de type mise à jour u.

Mais la mise à jours des icônes dans sylabe est bloquée en l’état faute de pouvoir les faire télécharger. Encore que leur chargement peut être fait par une URL directe. C’est dans ce cas le serveur web qui donne le bon type mime.
Et puis ce n’est pas au serveur, donc aux programmes derrières, de déterminer si on envoi l’objet demandé ou sa version la plus à jour, c’est à dire un autre objet. Le serveur doit qui qu’il arrive transmettre le bon objet ou une erreur.

Cependant, la méthode de chargement direct par une URL ne permet pas le chargement de contenus chiffrés. Ou plutôt ils sont bien téléchargés, mais chiffrés. Il n’est pas possible de les faire afficher directement dans le navigateur. La seule possibilité est de déchiffrer l’objet chiffré dans une zone réservée, puis de permettre le transfert vers le navigateur.

De base, on peut donc tout simplement accéder aux objets et liens publics sans modifier le serveur web. Il n’est donc pas besoin d’insérer non plus de code dans le programme index.php .
Pour les objets chiffrés (privés), il faut cependant être authentifié. Cela ne peut être réalisé que par programme sylabe.php .

Si l’on veut rester dans un fonctionnement standard de nebule, y compris pour les objets privés, il faudra ajouter un fichier .htaccess (pour Apache) qui transformera les demandes en /o/ et /l/ vers leur équivalent, c’est à dire /?o= et /?l= . Le programme sylabe.php se chargera ensuite de transmettre l’objet en zone public ou privée en fonction de l’état de l’authentification…

EDIT 13/09/2013 : Grosse erreur corrigée, ce n’est pas un lien f mais un lien u…

Arborescence sur serveur web

L’implémentation de référence de nebule en bash utilise cette arborescence pour son fonctionnement :

  • pub
    • o
    • l
  • priv
    • o
    • l
  • tmp

On trouve notamment dans pub et priv un fichier e contenant l’identifiant de l’objet entité, la clé publique pour le premier et la clé secrète pour le seconde.

Dans pub, on peut encore trouver sur certaines machines gnav.php et un répertoire g. C’est la page de tracé du graphe d’un objet. Cette page php est vouée à disparaître sous cette forme.

Le contenu du répertoire pub avait été volontairement séparé, c’est à dire les répertoires o et l en dessous, des scripts et autres fichiers bash, clés RSA, etc… Est apparu avec le temps les dossiers priv et tmp pour manipuler les objets soit qui ne devaient pas être diffusés soit les fichiers temporaires. Et le répertoire pub à rapidement servit à stocker aussi de nouvelles pages web en php comme gnav.php et webcli.php . Ce répertoire devenait donc directement public, ce pour quoi il est fait dès le début en fait…

Lors de la mise en place de sylabe, j’ai conservé cette arborescence par défaut. Mais elle pose problème.
Les objets et liens sont téléchargés sur des url du type http://site.net/o/ ou http://site.net/l/ . Or le serveur web utilise par défaut le dossier parent pour l’affichage des pages. Cela nécessite de faire le lien entre le pseudo dossier o et son réel emplacement en pub/o . En fonction du système d’exploitation et du logiciel serveur web, la manière de contourner ce problème est différente. Ce n’est pas vraiment optimal.

Il faut cependant pouvoir faire cohabiter simultanément les scripts bash et les pages php, voir peut-être d’autres choses par la suite.

Il y a une solution, remettre le dossier pub comme répertoire par défaut dans le serveur web, c’est à dire l’arborescence racine. Les scripts bash peuvent rester dans le répertoire parent sans entrer en conflit avec les pages php dans pub, tout en exploitant la même base d’objets et de liens. En bash, les objets sont dans pub/o alors que en php ils sont dans o tout simplement.

Et comment dans sylabe va-t-on gérer les fichiers temporaires et fichiers à ne pas partager ?
Cela peut être fait de deux façons. Soit on crée un sous dossier avec des restrictions via un fichier .htaccess. Cette méthode à inconvénient de se restreindre à un seul type de serveur web. Et plus grave, tous les objets privés de toutes les entités connectées sont ainsi mélangés… Soit on fait du déchiffrement à la volée et du stockage de petits objets dans la session php.
Les fichiers temporaires peuvent eux être mélangés tant qu’ils ne sont pas écrasés ou réutilisés entre deux sessions différentes. Dans ce cas il faut peut-être prévoir un sous dossier tmp.

Avancement

Cette fois-ci, la vérification de la signature des liens marche enfin !
C’est une étape importante, la première en fait, puisque c’est ce qui permet de vérifier la validité des échanges, c’est à dire les liens.

Suite à ça, on peut maintenant espérer permettre la génération de nouveaux liens, mais aussi la réception de liens déjà signés. Cette réception marche d’ailleurs, pas la génération, mais si les liens existants sont bien vérifiés, il y a encore un petit bugg qui empêche la vérification d’un lien importé. Ça progresse…
Il y a aussi des variables permettant de désactiver la synchronisation d’objet ou de liens depuis le serveur, mais aussi le transfert d’objet ou de lien vers le serveur. CF upl sur zulu :

capture2013081101

D’un autre côté, il y a des problèmes avec certaines fonctions dans php.
La fonction hex2bin n’est pas reconnu avant la v5.4.0 alors que la fonction inverse bin2hex était déjà présente dans la v4. Il faut à la place utiliser la fonction pack (v4).
La fonction openssl_verify est bien présente depuis la v4.0.4, mais sha256 n’est pas reconnu dans les fonctions de hashage supportées avant la v5.4.8 . Il faut à la place utiliser des fonctions plus basiques comme hash (v5.1.2) et openssl_public_decrypt (v4.0.6). Les anciennes versions stables de Debian et Ubuntu incluaient déjà php en v5.3, je pense que c’est maintenant suffisamment ancien pour ne pas risquer la perte de fonctionnalité.
Donc soit on est compatible uniquement avec des versions très récentes de php, et donc adieux les versions pré-packagées pour serveur (Debian ou Ubuntu par exemple). Bienvenue à la compilation à la demande et tous les problèmes de maintenances inhérents. Soit on utilise d’autres fonctions au prix peut-être de performances moindres, c’est donc le cas pour l’instant, et ça marche :

capture2013081102

Vérification de mot de passe de clé RSA

J’ai eu un peu de mal à vérifier si le mot de passe saisie dans sylabe pour déverrouiller une entité était le bon mot de passe.

Il semble y avoir un petit bugg de la fonction openssl_pkey_get_private. Lorsque l’on charge le fichier contenant la clé privée chiffrée et qu’on le passe à cette fonction, on a le code erreur suivant :

error:0906D06C:PEM routines:PEM_read_bio:no start line

En fait, il faut envoyer la concaténation de la clé publique puis de la clé privée…

Le code php qui fonctionne :

$publcert = file_get_contents("pub/o/$nebule_publ_entite");
$privcert = file_get_contents("pub/o/$nebule_priv_entite");
$cert = "$publcert$privcert";
$r = openssl_pkey_get_private($cert, $nebule_pass_entite);
if ( $r === false ) { return false; } else { return true; }

Ce serait bien si le message d’erreur était plus clair… comme dirait l’autre…

Maintenant que je peux m’assurer si le mot de passe est bon, je peux essayer d’utiliser la clé RSA :-)