Certificats de securité

MilleGrilles utilise les certificats X.509 avec clés Ed25519 comme identification des modules et usagers. Les certificats ont une durée de vie différente en fonction de leur rôle.

Certificat de MilleGrille (CA)

Le certificat CA (Certificate Authority) d’une MilleGrille est généré lors de la création du système. La clé de ce certificat est appelé la clé de la MilleGrille, c’est une clé chiffrée avec un mot de passe et conservée dans un fichier .json.

Exemple de certificat CA

Le certificat CA expire après 20 ans. Une millegrille qui utilise un certificat CA expiré doit être migrée vers un nouveau système (nouvelle clé). Le processus de migration est similaire à une restoration de backup du système.

Discussion : considérant le changement des technologies cryptographiques et la possibilité prochaine d’ordinateurs quantiques performants, il est peu probable qu’un système utilisé conserve la même clé système pour une période aussi longue que 20 ans sans devenir complètement désuet du point de vue de sécurité asymétrique.

Identificateur de MilleGrille (IDMG)

Le certificat de MilleGrille est utilisé pour calculer l’identificateur de MilleGrille. Cet identificateur peut être utilisé en remplacement du certificat CA au besoin pour référer à la MilleGrille ou à l’ensemble des certificats valides sur cette MilleGrille.

Exemple d'IDMG : zbaTeMFXpvuALGcPLx7UYFjW2oCz8fbDpyyse5boZB22VX8NvSQfMaSR

Par exemple, pour donner accès à un File Host, il suffit de créer un sous-répertoire au nom de l’IDMG du système à héberger. Ceci donne accès à tout composant qui peut signer un document d’authentification avec un certificat valide pour la MilleGrille qui correspond à l’identificateur.

Certificats de signature

Certissuer, valides pour 18 mois.

Certificats système

Roles et domaines. Valids 31 jours.

CN = instance id OU = domaine ou role O = IDMG

Exemple de certificat système

Paramètres inclus dans le certificat

sujet:
- commonName (CN): aad875a5-0b74-48b0-ad0f-ce14543bd2d7
- organizationalUnitName (OU): core
- organizationName (O): zUBGErt4Dc84B5HnuQRbYtZRgjFghEWgk5cSs1axd2TfZXFmYTgdfGdE
clé publique : 67cbebb725d11014def1869978b9be0a90c6d7bbcc77c0438d1b64662156fbeb
not_valid_after : 2023-05-29T23:08:29.000Z
not_valid_before : 2023-04-28T23:08:09.000Z
extensions MilleGrilles
- domaines : CoreBackup,CoreCatalogues,CoreMaitreDesComptes,CorePki,CoreTopologie
- exchanges : 4.secure,3.protege,2.prive,1.public
- roles: core

Certificats usager

Role usager ou navigateur, userId.

CN = nom usager OU = valeur ‘usager’ O = IDMG

Exemple de certificat usager

Paramètres inclus dans le certificat

sujet
- commonName (CN) : proprietaire
- organizationalUnitName (OU) : usager
- organizationName (O) : zbaTeMFXpvuALGcPLx7UYFjW2oCz8fbDpyyse5boZB22VX8NvSQfMaSR
clé publique : 6610dd8c66656b9180047327b60d1bdbe62cf68de37ef7ab623ac4df16c5c0bf
not_valid_after : 2025-04-19T12:30:07.000Z
not_valid_before : 2025-03-19T12:29:47.000Z
extensions MilleGrilles
- user id : z2i3XjxJiW3MevcVcz3hhhpE95wynmj4GzMRMhECzsP2c9SNveq
- roles : usager,navigateur
- delegation globale : proprietaire

Extensions custom

Des extensions X.509 v3 sont ajoutées aux certificats pour permettre l’autorisation de l’accès aux ressources sans accéder à un composant de permission externe dans bien des cas. Ces extensions remplacent un serveur LDAP avec forte granularité de permissions.

Noter que les permissions usagers sont gérées avec des permissions particulières à chaque domaine. Ces permissions sont vérifiées avec le userId conservé dans le certificat.

Les extensions d’un composant serveur ne sont pas appelées à changer durant la période de validité d’un certificat. Les certificats usagers sont remplacés si les permissions de l’usager changent (e.g. role public ou privé).

Niveaux de sécurité sur le bus (exchanges MQ)

Id : 1.2.3.4.0
Valeurs possibles : 4.secure,3.protege,2.prive,1.public
Notes
- la première valeur de la liste est utilisée comme référence par défaut pour le niveau de sécurité du certificat. Il est préférable de mettre le plus haut niveau de sécurité en premier. Par exemple : 2.prive,1.public.
- les exchanges ne communique pas entre-eux. Si un module doit se connecter aux exchanges 3.protege et 1.public, il faut les inclure dans la liste.
- les niveaux 3.protege et 4.secure, lorsque combinés à un attribut Domaine (1.2.3.4.2) dans le même certificat, donnent le droit d’accéder à toutes les clés de chiffrage de ce domaine auprès du Maitre des clés.

Liste de roles internes

Id : 1.2.3.4.1

Liste des domaines

Id : 1.2.3.4.2
Exemple de valeurs : SenseursPassifs,GrosFichiers,CoreMaitredescomptes
Notes :
- Lorsque combiné à un attribut de sécurité (1.2.3.4.0) 3.protege ou 4.secure, donne accès à toutes les clés du domaine dans le Maitre des clés.

ID unique de l’usager (userId)

Id : 1.2.3.4.3
Exemple de valeur : z2i3XjxCG211bY3F4WL4c1cAtrrZZPkriKRWBDXWudg8NkzgZ4h

Role usager ‘administrateur’ qui s’applique a toute la MilleGrille.

Id : 1.2.3.4.4
Valeur : proprietaire

Création des certificats

Le certificat de MilleGrille (CA) est créé durant l’installation d’une nouvelle MilleGrille.

Les certificats de signature sont crées lors de la configuration des instances de serveurs 3.protege et 4.secure. Ces certificats sont bons pour 18 mois et doivent être renouvelés manuellement en utilisant la clé de Millegrille. Les certificats de signature sont installés dans le module certissuer et servent à créer tous les autres certificats d’une MilleGrille.

Les autres certificats sont générés par le module certissuer lors d’une demande de signature d’un Certificate Signing Request (CSR). La requête CSR peut être faite par un gestionnaire d’instance (mginstance) 3.protege ou 4.secure pour installer ou renouveler les modules d’un serveur ou par le domaine CorePki au nom d’un usager qui relai une demande à partir du bus MQ. L’accès au certissuer est local et connecté via http non sécurisé.

Discussion : la connexion http ne cause pas de problèmes de sécurité. L’information qui transite est publique (CSR et certificat) et la signature du document demandeur est utilisée comme autorisation pour procéder à la signature du certificat.

Autorisation de création de certificats

Par exemple, un module mginstance est autorisé à demander des certificats avec un niveau de sécurité égal ou inférieur à son propre niveau et toujours associés à son instanceId (CN).

Attention :

La clé de signature du certissuer permet de créer tous les certificats de module et d’usager du système.
Les instances 3.protege et 4.secure peuvent demander un certificat pour installer un Maitre des clés. Ces certificats donnent accès à toutes les clés chiffrées du système.

Les clés privées des modules nommés précédemment doivent être traitées avec attention. MilleGrilles offre plusieurs topologies de déploiement qui permettent de réduire l’exposition de ces clés pour augmenter la sécurité du système.