puppetmaster

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.

Son identifiant : 88848d09edc416e443ce1491753c75d75d7d8790c1253becf9a2191ac369f4ea

C’est la première des entités créées. Son nom peut se traduire par le maître des marionnettes, sous entendu le maître des autres entités. C’est aussi une référence à Ghost in the Shell.

Cette entité contrôle plusieurs entités esclaves :

  1. cerberus
  2. bachue
  3. asabiyya
  4. kronos

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é :


20140427 nebule - schema data puppetmaster

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 :

20131108-cryptsetup-sur-2-cles-usb1