Sécurité

Sommaire :

• Introduction
• Sûreté de fonctionnement
  • Fonctionnement de nebule
  • Environnement
• Sécurité du code
• Sécurité des entités
  • Entité puppetmaster
  • Entité cerberus
  • Entité bachue
  • Entité asabiyya
  • Entité kronos
• Architecture
  • Pare-feu spartacus
  • Serveur xue
  • Poste de contrôle warhole
  • Serveur thor
  • Serveur relais puppetmaster
  • Serveur relais bachue
• Problèmes et évolutions

Introduction

L’un des trois principes soutenus par le projet nebule, c’est la confiance. Cette confiance n’est pas un élément technique spécifique, c’est une évaluation globale du projet.

Le projet nebule étant en phase expérimentale, un certain nombre de fonctions de sécurité et de concepts sont à considérer comme eux aussi expérimentaux. Ils sont appelés à s’améliorer avec le temps.
Plus que le caractère expérimental du projet, c’est la volonté de transparence qui pousse à rendre public les modèles de sécurités en place. Le but est de les améliorer et de ne pas se contenter du niveau de fonctionnalité et de sécurité actuel.

Sûreté de fonctionnement

La sûreté de fonctionnement permet de s’assurer de la fiabilité, la disponibilité, la maintenabilité et la sécurité d’un dispositif. On va ici s’attacher au fonctionnement propre de nebule et au fonctionnement de son environnement, c’est à dire les machines. C’est la mesure de la confiance, la capacité du système à fonctionner tel que l’on s’attend à ce qu’il fonctionne et à être résistant aux tentatives de détourner son fonctionnement.

Fonctionnement de nebule

Le fonctionnement propre de nebule repose sur le concept d’objet et de lien. Le code, quel qu’il soit, doit permettre de manipuler les objets et les liens en toute confiance.

La fiabilité est assuré au niveau des objets par leur empreinte propre. C’est l’empreinte qui identifie un objet de façon univoque. L’empreinte doit impérativement respecter des propriétés cryptographies : universel, atemporel, univoque et infalsifiable.
La fiabilité des liens est assurée par la signature cryptographique d’une entité. Cette signature atteste de l’intégrité du lien et de sa provenance. Tout lien pour lequel la signature est invalide ou ne peut être vérifié est ignoré.
La fiabilité du code est vérifié par des essais tout au long du développement.

La disponibilité des objets repose sur le modèle du P2P (Peer to Peer). Les objets sont hébergés par une ou plusieurs entités, ou par aucune. On peut s’assurer de la disponibilité d’un objet en le faisant héberger à plusieurs endroits.
La disponibilité des liens fonctionne de la même façon que pour les objets. Le code étant un objet à part entière, sa disponibilité répond au même fonctionnement.

La maintenabilité n’a de sens que pour le code. Celui-ci doit être amélioré dans sa lisibilité, son organisation et ses commentaires.

La sécurité des objets repose sur leur fiabilité, c’est à dire leur empreinte cryptographique. Un objet corrompu n’est pas utilisé, il est même directement supprimé. Si un objet corrompu venait à être malgré tout diffusé, les autres entités n’en tiendront pas compte.
La sécurité des liens repose sur les signatures cryptographiques. Un lien corrompu est ignoré lors du traitement des liens. Si un lien corrompu venait à être malgré tout diffusé, les autres entités n’en tiendront pas compte.
La sécurité du code repose sur la chaîne de confiance dans les liens générés par l’entité bachue. La confiance en l’entité bachue repose sur sa reconnaissance par l’entité puppetmaster. Enfin, la sécurité du code repose sur les différentes machines gérant les entités du projet nebule à l’exception des machines relais et machines publiques.

Environnement

…

Sécurité du code

…

Sécurité des entités

Les entités du projet nebule sont hiérarchisées en fonction de leur importance. Cette importance est strictement dépendante des risques sur tout ou partie du projet nebule qu’un problème pourrait engendrer.

Chaque entité de nebule à son propre fonctionnement et sa gestion propre. La sécurisation des entités est à l’image de la sécurisation de tout système d’information. Il faut trouver un juste milieu entre l’utilisation, l’utilisabilité et la disponibilité, et le risque de cette utilisation. Bien qu’ayant un caractère fortement lié à la sécurité, la disponibilité est très souvent mis en opposition avec la confidentialité et l’intégrité.

Toutes les entités sont vulnérables au vol de la clé privée et du mot de passe associé. Pour certaines entités, afin de contrer ce problème, certaines solutions organisationnelles et techniques ont été mise en place. La première est de restreindre la diffusion de l’objet contenant la clé privée en vérifiant sa non présence lors de l’export d’objets. Ainsi, aucune action en force brute par exemple ne peut être réalisée. Pour le mot de passe, cela se passe sur deux niveaux. Un mot de passe à saisir est nécessaire pour l’entité et un mot de passe est aussi nécessaire pour accéder au support de l’entité. Le mot de passe du support de l’entité est positionné sur une clé USB différente et est automatiquement généré et utilisé sans intervention au clavier. Ainsi un keylogger présent dès l’installation peut voler le mot de passe de l’entité mais ne peut pas capturer le mot de passe du support. Enfin, la clé USB contenant le mot de passe du support de l’entité n’est jamais conservée à côté de ce support sans surveillance. Voir, cette clé USB est détenue en permanence par une personne.

L’organisation globale de la sécurité des entités repose sur un modèle commun dans les systèmes d’information, c’est une forme hiérarchique. Cette forme d’organisation permet de gérer plus facilement la reconnaissance des entités et leur remplacement en cas de compromission. L’inconvénient reste classiquement la forte vulnérabilité du sommet de l’organisation.

Entité puppetmaster

C’est l’entité de plus haut niveau, celle qui valide toutes les autres. Sa compromission remet en cause toute la confiance dans le projet. Elle ne doit agir que comme validation des entités et peut notamment à ce titre bannir toute entité. Tous les autres rôles sont délégués aux autres entités du projet nebule.

La protection de cette entité se fait sur trois niveaux :
– public
– diffusion
Рpriv̩

Voici le schéma de cheminement des informations autour de l’entité :

Le niveau public permet le partage à grande échelle des liens de l’entité. C’est le serveur web public xue. L’entité est accessible aux adresses http://puppetmaster.nebule.org/ et http://puppetmaster6.nebule.org/.
Ce serveur protégé assez classiquement comme tout serveur sur Internet. Il ne contient cependant aucune donnée sensible et aucune entité ne peut se déverrouiller dessus. La compromission du serveur ne peut être qu’une atteinte à la disponibilité de la diffusion des nouveaux liens, les anciens liens étant naturellement rediffusés par toutes les entités. Il peut être à tout moment reconstruit ailleurs sur Internet, voir être simplement dupliqué en plusieurs endroits.
En cas de perte de disponibilité du serveur, les liens peuvent être diffusés par d’autres entités. La propagation de ces liens sera dans ce cas plus lente mais ce mode de fonctionnement permet d’assurer la diffusion des liens quoi qu’il arrive.

Le niveau de diffusion n’a pas pour vocation à permettre le partage des liens de l’entité, c’est à dire qu’il ne diffuse rien publiquement. Il fait simplement l’interface entre le niveau privé et le niveau public.
Cette fonction d’interface est hébergée sur une machine dédiée. Elle est installée en OpenBSD 5.4 sur une vieille machine PC de type i586. Elle ne supporte que IPv6 et est protégée de l’Internet par le pare-feu spartacus.
Le disque dur est chiffré avec un mot de passe au démarrage.

Le niveau privé est dédié à la manipulation de l’entité. C’est à ce niveau uniquement que la clé privé de l’entité est disponible, donc que l’on peut déverrouiller l’entité pour signer des liens.
La machine sur laquelle est utilisée l’entité ne l’héberge pas à proprement parler. Elle est de type PC 64bits et ne supporte aucun réseau. Le système repose sur deux clés USB interdépendantes dont une sert à démarrer le système et à stocker les données. Le disque dur de la machine n’est pas utilisé. Les deux clés ne sont jamais réunis en un même lieu sauf pour accéder à l’entité. L’une des clés USB est stockée en lieu sûr, l’autre accompagne en permanence une personne. Il est impossible d’accéder aux données ou à l’entité avec une seule clé USB. Voir les documentations Système bootable chiffré sur deux clés USB interdépendantes et suite.
En cas de problème, toute machine de type PC est capable de démarrer le système.
Le système ainsi lancé échange avec le monde extérieur unique via une clé USB pré-définie. Aucun support amovible n’est monté sur le système lors de l’insertion.
Il existe une copie de sauvegarde des deux clés USB dans deux lieux différents. Une des clé de sauvegarde accompagne en permanence une personne. En cas de problème, les liens précédemment signés peuvent être resynchronisés depuis d’autres entités sur Internet.
Les mises à jours sont réalisées à la main en cas d’extrême nécessité. Un script est prêt à être lancé à la main au besoin.
A aucun moment la clé privé de l’entité ne doit sortir de son support chiffré.

Le schéma de principe du fonctionnement d’un système à deux clés USB interdépendantes :

Entité cerberus

Cette entité permet de bloquer des objets. Elle permet de ne pas mettre en avant puppetmaster pour bloquer ces objets. Typiquement, dans le cadre du projet nebule, les objets bloqués sont typiquement porteurs de codes malveillants.

L’enfer n’ayant pas encore officiellement ouvert, cette entité n’est pas utilisée.

Entité bachue

Cette entité permet la diffusion des différents codes nécessaires au bon fonctionnement du projet nebule et des projets annexes comme sylabe.

La protection de cette entité se fait sur trois niveaux :
– public
– diffusion
Рpriv̩
Рd̩veloppement

Voici le schéma du cheminement des informations autour de l’entité :

Le niveau public permet le partage à grande échelle des liens de l’entité. C’est le serveur web public xue. L’entité est accessible aux adresses http://bachue.nebule.org/ et http://bachue6.nebule.org/.
Ce serveur protégé assez classiquement comme tout serveur sur Internet. Il ne contient cependant aucune donnée sensible et aucune entité ne peut se déverrouiller dessus. La compromission du serveur ne peut être qu’une atteinte à la disponibilité de la diffusion des nouveaux liens, les anciens liens étant naturellement rediffusés par toutes les entités. Il peut être à tout moment reconstruit ailleurs sur Internet, voir être simplement dupliqué en plusieurs endroits.
En cas de perte de disponibilité du serveur, les liens peuvent être diffusés par d’autres entités. La propagation de ces liens sera dans ce cas plus lente mais ce mode de fonctionnement permet d’assurer la diffusion des liens quoi qu’il arrive.

Le niveau de diffusion n’a pas pour vocation à permettre le partage des liens de l’entité, c’est à dire qu’il ne diffuse rien publiquement. Il fait simplement l’interface entre le niveau privé et le niveau public.
Cette fonction d’interface est hébergée sur une machine dédiée. Elle est installée en FreeBSD Release 10.0 sur une vieille machine PowerPC. Elle ne supporte que IPv6 et est protégée de l’Internet par le pare-feu spartacus.
Le disque dur n’est pas encore chiffré. Le système est cependant sommairement offusqué.

Le niveau privé est dédié à la manipulation de l’entité. C’est à ce niveau uniquement que la clé privé de l’entité est disponible, donc que l’on peut déverrouiller l’entité pour signer des liens.
La machine se laquelle est utilisée l’entité est de type PC 64bits et ne supporte aucun réseau. Le système repose sur un disque dur chiffré et sur une clé USB pour démarrer le système. La clé USB contient le mot de passe du disque chiffré. Il existe un système d’offuscation sommaire sur cette machine.
L’entité bachue est sauvegardée sur le système de l’entité puppetmaster. En cas de problème, il est possible de remonter une nouvelle machine hôte.
Le système ainsi lancé échange avec le monde extérieur unique via une clé USB pré-définie. Aucun support amovible n’est monté sur le système lors de l’insertion.
Les mises à jours sont réalisées à la main en cas d’extrême nécessité. Un script est prêt à être lancé à la main au besoin.
L’entité est potentiellement vulnérable puisqu’elle exécute du code pour signer les liens. Ce code peut avoir été compromis sur le poste de développement. L’interface web sylabe ne peut pas modifier les fichiers de la machine autres que les objets et liens. Mais cette interface web pourrait faire d’autres actions comme essayer d’exfiltrer la clé privée. Pour cette raison, c’est sous forme de script bash que les liens sont signés.
A aucun moment la clé privé de l’entité ne doit sortir de son support chiffré.

Le niveau développement permet de travailler facilement sur les différents codes.
Ce poste de développement est assez sensible puisqu’il peut constituer le premier point d’entrée pour une attaque. Le but d’une attaque peut être essayer d’exfiltrer la clé privée de l’hôte en modifiant le code qui lui est transmis. Une autre attaque peut être de tout simplement modifier le code pour retirer à posteriori des mots de passes ou des clés privées d’autres entités.
La mise en place de poste de développement n’est pas encore terminée…

Entité asabiyya

Non fonctionnelle actuellement.

Entité kronos

Non fonctionnelle actuellement.

Architecture

Le point d’accès à l’Internet pour les machines relais est centré sur le pare-feu spartacus.

Toutes les machines ont leurs disques durs intégralement ou quasi-intégralement chiffrés (ou sont prévues de l’avoir). Ainsi, chaque machine nécessite pour démarrer soit un mot de passe soit une clé USB contenant un mot de passe. La perte des machines ne représente qu’une perte matérielle.

Seul IPv6 est utilisable sur ces réseaux. Il n’est pas utilisé de translation d’adresses, le pare-feu s’occupe de étanchéité des réseaux entre eux et avec Internet.

Les machines sont allumées au cas par cas en fonction des besoins.

Voici le schéma d’architecture du point d’accès :

Pare-feu spartacus

Ce pare-feu protège le réseau du point d’accès des serveurs relais, du poste de contrôle et du serveur de sauvegarde.

Cette machine est installée en Debian Linux 7.0 sur architecture PC 64bits se connectant uniquement en IPv6 et protégée d’Internet par elle-même.

Aucune connexion réseau n’est permise vers ce pare-feu, y compris de l’intérieur du réseau. Il n’héberge aucun service.

Seul le poste de contrôle warhole peut se connecter au serveur thor, mais pas réciproquement. Les autres machines ne peuvent pas se connecter entre elles. Toutes les machines peuvent faire leurs mises à jours sur Internet (vers certaines adresses) et se connecter au serveur xue en icmp/echo request, http et https.

Les mises à jours sont réalisées à la main en cas d’extrême nécessité. Bien qu’ayant une connexion à Internet à disposition, rien n’est fait automatiquement. Un script est prêt à être lancé à la main au besoin.

La clé USB de démarrage contient le noyau du système et la clé de déchiffrement du disque dur (intégralement chiffré). Une fois le démarrage terminé, elle peut être retirée.

Serveur xue

Ce serveur est le serveur public des différentes entités. C’est lui qui héberge et diffuse largement les liens et objets des entités du projet nebule.

Ce serveur est installé avec FreeBSD Release 10.0 sur architecture PC et supporte IPv4 et IPv6.

Les mises à jours sont réalisées à la main depuis le poste de contrôle warhole et automatiquement une fois par jour.

Poste de contrôle warhole

C’est une machine dédié au contrôle des serveurs xue et thor. Elle gère les mises à jours et la sauvegarde. Elle permet aussi l’administration au jour le jour.

Cette machine est installée en OpenBSD 5.4 sur architecture Sparc se connectant uniquement en IPv6 et protégée d’Internet par le pare-feu spartacus.

Les mises à jours sont réalisées à la main en cas d’extrême nécessité.

Serveur thor

C’est un serveur qui permet à la fois la sauvegarde du serveur xue et va permettre de réaliser des tests d’archivage.

Ce serveur est installé en Debian Linux 7.0 sur architecture PC 64bits se connectant uniquement en IPv6 et protégé d’Internet par le pare-feu spartacus.

Les mises à jours sont réalisées à la main depuis le poste de contrôle warhole et automatiquement une fois par jour.

Serveur relais puppetmaster

Ce serveur fait l’interface entre la machine isolée hôte de l’entité puppetmaster et le serveur public xue qui diffuse les liens de cette entité.

Ce serveur est installé en OpenBSD 5.4 sur une vieille machine PC de type i586. Il ne supporte que IPv6 et est protégé de l’Internet par le pare-feu spartacus.
Aucun service sur le réseau n’est utilisé.

Le disque dur est chiffré avec un mot de passe au démarrage.

Les mises à jours sont réalisées à la main en cas d’extrême nécessité.

Serveur relais bachue

Ce serveur fait l’interface entre la machine isolée hôte de l’entité bachue et le serveur public xue qui diffuse les liens de cette entité.

Ce serveur est installé en FreeBSD Release 10.0 sur une vieille machine PowerPC. Il ne supporte que IPv6 et est protégé de l’Internet par le pare-feu spartacus.
Aucun service sur le réseau n’est utilisé.

Le disque dur n’est pas encore chiffré. Le système est cependant sommairement offusqué.

Les mises à jours sont réalisées à la main en cas d’extrême nécessité.

Problèmes et évolutions

Pour commencer, le projet nebule est expérimental. Cela veut dire qu’un certain nombre de concepts utilisés sont du domaine de l’expérience, ils peuvent se révéler fonctionnels et cohérents, ou pas. Mais un certain nombre d’éléments de ce projet sont aussi des expériences.

D’un point de vue global, l’organisation des entités sous forme hiérarchique pose un gros problème de vulnérabilité. Le problème, c’est que cette entité est détenue par une seule personne. Le risque, c’est la mauvaise utilisation de l’entité. Cette mauvaise utilisation peut être le fait de la seule personne qui détient l’entité, ou le fait d’autres personnes qui auraient pris le contrôle de l’entité.
Pour réduire le risque, il ne faut pas partager l’entité avec plusieurs personnes puisque cela augmente d’autant le risque de compromission de l’entité, et donc de sa mauvaise utilisation. Il faut trouver une méthode sûr pour répartir l’entité entre plusieurs personnes, c’est à dire faire en sorte d’une seule personne ne puisse utiliser seule l’entité. Il est peut-être possible de permettre un déverrouillage avec une partie seulement des personnes. On entrerait ainsi dans un mode de fonctionnement démocratique.
Cette évolution nécessite une recherche théorique.

La sûreté de fonctionnement est la traduction technique d’un sentiment humain, la confiance. Elle est ici appuyée fortement à la fois sur le facteur humain et le facteur technique. Mais il semble nécessaire de faire encore quelques ajustements et équilibrages en technique et humain.

Les objets peuvent être protégés, mais pas encore les liens. Le chiffrement des liens, tout en permettant leur bonne diffusion doit permettre de renforcer la confidentialité des informations traitées ainsi que l’anonymat de façon générale. Cette évolution va nécessiter une montée en version de nebule vers la v1.2.

La machine relais de bachue n’a pas son disque dur chiffré. C’est à corriger.
Il serait intéressant de pouvoir faire démarrer à la fois FreeBSD et OpenBSD , y compris sur une machine PowerPC, avec des clés USB de démarrage contenant les mots de passe des disques durs.

A compléter…

(2014)