Mois : mars 2013

Localisation de fichiers

Une étape importante dans l’utilisation de nebule, c’est d’importer des données. Ces données sont typiquement des fichiers existants. Cette opération d’importation de fichiers, c’est la nébulisation de fichiers.

La nébulisation de fichiers ne présente pas à priori de difficultés. On calcule son empreinte et on lui associe tout un tas d’informations telles que son type mime, sa taille, etc…

Il y a cependant une propriété des fichiers qui pose un problème.
Un fichier est classiquement reconnu par son nom. ce nom est une propriété du fichier au même titre que sa taille par exemple. L’extension de fichier n’est qu’un indicateur, peu fiable, de son type. L’extension de fichier est repris comme suffixe du nom.
Il peut y avoir plusieurs fichiers qui portent le même nom (et même suffixe) et qui ont ou non le même contenu. Ils doivent dans ce cas être disposés dans des emplacements différents. Cet emplacement peut être repris comme préfixe. L’emplacement est la traduction textuelle de l’arborescence de répertoires dans lequel se trouve un fichier. Et l’emplacement peut être soit relatif (à un autre emplacement), soit absolu. Dans tous les cas, il fait implicitement ou explicitement référence au disque, la distinction entre les deux dépendant de la notation faite par les différents systèmes d’exploitations. Nous ne prendrons ici que l’emplacement absolu, seul à pouvoir discriminer de façon certaine deux fichiers au même nom.
On peut aussi avoir deux fichiers de même nom/suffixe dans le même répertoire, mais sur deux machines différentes. Dans les différentes notations, il est donc préférable de se restreindre à l’utilisation de notations impliquant le nom de machine. Sinon on risque de pouvoir restaurer correctement un fichier en cas de besoin (si c’est le but).

Le problème de la notation des noms de fichiers peut se poser aussi dans le cas de deux fichiers identiques au même emplacement sur deux machines différentes. Si un des fichiers est modifié, cela va entraîner la création d’un lien u pour l’objet correspondant. Si rien ne distingue les deux fichiers, cela implique que l’autre fichier non modifié sera marqué comme lui aussi modifié…

Références :
– Nebule blog – Empreinte d’objets et URI
РNebule blog РFiches perfor̩es
– Nebule blog – Fichiers et chemins
РNebule blog РSyst̬me de fichiers
РNebule wiki РR̩flexion Рanalyse des applications РSyst̬me de fichiers

Chiffrement et type mime

Suite de la réflexion sur l’Introduction à la cryptographie.

Il n’existe pas de type mime généralistes pour des fichiers chiffrés. Comme les objets chiffrés ne sont liés à aucune application en particulier, je gratte un peu ce qui se rapproche le plus de mon besoin.

Il se trouve qu’il existe le type mime application/octet-stream un peu fourre tout pour les contenus… binaires. Mais il est standardisé en l’état.
Il faut aussi un moyen de préciser l’algorithme de chiffrement derrière. Une application aura besoin de connaître cet algorithme pour déchiffrer le flux d’octets.
Bref, en suivant la rfc2046, il reste la possibilité de créer quelque chose en application/x-…

Voici donc comment seront définis les objets chiffrés dans nebule :
– application/x-encrypted/aes-256-ctr
– application/x-encrypted/aes-256-cbc
– application/x-encrypted/rsa
Etc…

En fonction de l’algorithme invoqué, on sait si c’est du chiffrement symétrique ou asymétrique, et donc en principe si c’est pour une clé de session ou pas.

Gestion de programmes Рcr̩ation

Suite à la précédente réflexion sur la gestion des programmes, l’entité correspondante a été créée.

Cette entité s’appelle bachue, dérivé de Bachué. Son empreinte :

19762515dd804577f9fd8c005a7803ddee413f264319748e30aa2aedf318ca57
http://bachue.nebule.org

bachue

Tuer l’ordinateur pour le sauver – 2

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

Gestion de programmes – suite

La précédente réflexion sur la gestion de programmes peut être complétée.

Les programmes doivent être validés par des entités. Il faut des entités dédiées à cette tâche. La validation et les mises à jours se font par les liens de ces entités.

Une des propriété qui va rapidement ressortir, c’est qu’une entité peut, sans grand risque de refus, demander à toutes les entités qu’elle connaît les objets et liens signés par une entité de gestion de programmes. En fait, il y a de grandes chances que toutes les entités partagent la même source de programmes. Cela rend la diffusion de mises à jours particulièrement rapides. On a un peu un effet virus sur la diffusion des objets.
Évidemment, comme cela se passe aujourd’hui, nous risquons d’avoir une hégémonie de certains programmes. C’est pour cela qu’il faut aussi être capable d’accepter simultanément plusieurs entités de gestion de programmes… et de strictement respecter la diffusion des liens et objets tel que définit par le projet nebule.

L’entité cerberus n’a pas vocation à diffuser des programmes, mais elle peut être amenée à interdire l’utilisation de certains programmes si ceux-ci sont reconnus malveillants. Cela ne bloque pas les mises à jours du-dit programmes mais oblige à le mettre à jour.

Il me faut donc maintenant créer la première entité de gestion des programmes, et il faut commencer par lui trouver un nom.

Objets privés et fonctionnement interne

Il existe des informations que l’on ne peut gérer par les liens nebule sous peine de fortement complexifier son fonctionnement, et donc la compréhension que l’on en a dans son ensemble.

Par exemple, c’est le cas pour mettre un poids à un objet. C’est à dire lui attribuer une méta information qui décrit son importance relative aux autres objets. C’est une notation en quelque sorte.
Un poids peut être fixé arbitrairement. Ce n’est pas le meilleur cas même si c’est réalisable en pratique. Le poids d’un objet a surtout de forte chance de refléter l’importance que l’on donne à cet objet. A cet objet pondéré sont liés d’autres objets. Ces autres objets, si leurs poids ne sont peut-être pas explicitement définis, vont hériter d’une moyenne des poids des objets autour. Ainsi, un objet va gagner de l’importance si il est lié à un objet jugé (donc pondéré) très important.
De ce poids peut en découler des conséquences concrètes. Par exemple si l’on permet l’oublie et l’effacement d’objets anciens de façon calculé et contrôlé, la pondération permet de conserver très longtemps un objet important.

Cette pondération des objets qu’une entité va réaliser est un travail ‘personnel’. Le fruit de ce travail peut avoir un intérêt public. Et une autre entité ayant fait le même travail ne donnera pas les mêmes pondérations.
Cependant, une partie de ce travail de pondération peut être jugé privé. Si le partage d’une pondération d’objets peut être réalisée simplement par des liens, comment protéger les pondérations privées ?

Une des possibilités est d’exploiter les objets stockants des liens.

Hash et type des objets – suite

Suite à la décision de modifier deux objets de base niveau, hash function et mime-type, les premières répercussions ont été faites sur puppetmaster, cerberus et kronos.

De fait, les premiers liens de type x ont été générés. C’est à dire que ce sont les premiers liens qui permettent la suppression d’autres liens précédemment créés.

Cela se voit sur le graph de l’objet entité de puppetmaster :

C’est un peu fouillis parce que le précédent lien supprimé est remplacé par un nouveau lien dont l’objet meta est différent. Il faudra améliorer le tracé de ces liens…

Chiffrement et vecteur initial

Dans l’Introduction à la cryptographie, le vecteur initial (IV) était définie comme était égale à la clé de session. Bien sûr, de fait, le vecteur initial n’était plus publiable comme on le fait habituellement.

Après consultation du fonctionnement du mode CTR (CounTeR), je me rends compte qu’il n’est peut-être pas opportun d’avoir l’IV identique à la clé de chiffrement. La première étape du chiffrement consiste en un ou exclusif (XOR) entre l’IV et la clé de chiffrement. Cela donne une clé pour ce tour égale à 0.
CF Wikipedia.org – Mode_d’opération (cryptographie).

Donc, un IV est ajouté. Il est lié à l’objet chiffré pour pouvoir déchiffrer celui-ci. Par défaut, sa valeur est aléatoire. Du fait du fonctionnement du mode CTR, l’IV s’incrémente à chaque bloc chiffré.

Si pas précisé, il est égale à 0.

Chiffrement et compression

Il est préférable d’associer de la compression avec le chiffrement.

La compression des données déjà chiffrées est impossible, non que l’on ne puisse le faire, mais le gain de compression sera nul. L’entropie détermine la limite théorique maximum vers laquelle un algorithme de compression sans pertes peut espérer compresser des données. Quelque soit l’entropie des données d’origine, une fois chiffrées leur entropie est maximal. Si un algorithme de compression arrive à compresser des données chiffrées, il faut sérieusement remettre en question la fiabilité de l’algorithme de chiffrement. CF Wikipedia – Entropie de Shannon.

A cause de l’entropie après chiffrement, si on veut compresser les données il est donc nécessaire de le faire avant le chiffrement.

Ensuite, il faut choisir l’algorithme de compression. On pourrait forcer par défaut cet algorithme, pour tout le monde. C’est notamment ce qui se passe pour le HTML5 avec le WebM ou le H.264… et c’est précisément ce qui pose problème. En dehors des problèmes de droits d’utilisation à s’acquitter, c’est une facilité pour l’implémentation de cette compression par défaut dans les programmes. Cela évite de devoir négocier préalablement l’algorithme de compression. Mais si il est difficile de présenter des vidéos en plusieurs formats à pré-négocier, ce n’est pas le cas de la plupart des données. On perd la capacité d’évolution que l’on a en acceptant de nouveaux algorithmes de compression. Et plus encore, on perd la capacité du choix de l’algorithme le plus adapté aux données à compresser.
Il faut donc permettre l’utilisation de différents algorithmes de compression.

Cependant, si l’objet à chiffrer est déjà compressé en interne, comme le PNG ou OGG par exemple, la compression avant chiffrement est inutile. Ce serait une sur compression qui bien souvent n’apporte rien. Le chiffrement n’implique donc pas automatiquement une compression.

Lors du chiffrement, l’objet résultant chiffré est lié à l’objet source non chiffré par un lien k. Il est aussi marqué comme étant un objet de type-mime correspondant à l’algorithme de chiffrement, via un lien l. CF Introduction à la cryptographie.
Pour marquer la compression avant chiffrement, un autre lien l est ajouté comme type-mime vers l’algorithme de compression utilisé. Ce lien n’est ajouté que dans le cas d’une compression réalisée en même temps que le chiffrement.

La seule contrainte, c’est l’obligation d’utiliser un algorithme de compression sans perte. L’objet, une fois décompressé doit être vérifiable par sa signature. Il doit donc être strictement identique, aucune modification ou perte n’est tolérée.