Créer une toile de confiance avec GnuPG

Publié par Mickael Rigonnaux le

Bonjour à tous ! Aujourd’hui nous allons aborder ensemble un sujet que j’ai pu traiter dans le cadre de mon alternance, la mise en place d’une toile de confiance GnuPG.

Introduction

PI : je parle souvent de « clé » GPG, il faut comprendre biclé car il y a toujours une clé publique et une clé privée.

Le chiffrement GnuPG a déjà été abordé sur ce blog, mais moins précisément. La mise en place d’une toile de confiance peut se faire dans le cadre d’un chiffrement entre une entité A et une entité B, ce qui était mon cas.

La mise en place de cette procédure permettra de créer une zone de confiance entre les deux entités. Le principe reste le même qu’avec les autorités de certification pour SSL/TLS sauf que nous n’aurons pas la possibilité de passer par des autorités de confiance, cela se fera en direct. L’entité A devra signer la clé publique maître de l’entité B et inversement, tout cela en garantissant l’intégrité des données.

Dans mon article je parle plus au niveau des entreprises/entités, mais tout cela est également vrai pour les échanges entre personnes.

Clé maître et clé applicative

Dans les différents exemples que j’ai pu traiter il y avait souvent des notions de clés maître et de clés applicatives. Il faut voir les clés maîtres comme des autorités de certification interne à l’entité, une fois validée et signée par l’entité adverse elle permettra de générer des clés applicatives qui seront de confiance.

Un schéma vaut mieux qu’une longue explication :

Les biclés applicatives sont directement issues et signées des clés maîtres de chaque entité, ce qui permet d’avoir cette toile de confiance.

Le schéma peut également être simplifié en utilisant seulement les biclés « maître » si les échanges sont entre deux personnes par exemple.

L’utilisation de ce système permet cependant un meilleur niveau de sécurité, car les clés maîtres ne sont jamais utilisées pour chiffrer des données mais seulement pour signer des clés publiques.

Procédure

Tout cela doit bien entendu être tracé dans une procédure pour garantir l’intégrité et le bon traitement des données et des clés.

Nous allons maintenant aborder les différentes étapes pour générer les clés maîtres et applicatives, ainsi que toutes les étapes nécessaires à la mise en place de cette toile de confiance.

Dans mon exemple je vais montrer les étapes des deux entités pour que vous puissiez suivre les étapes dans l’intégralité.

Génération des biclés

Il faut dans un premier temps générer les bi-clés maîtres GPG de chaque côté :

gpg --full-gen-key

Cette commande permet de générer une clé GPG avec toutes les options :

Vous allez devoir entrer des caractéristiques comme :

  • Les protocoles à utiliser
  • La taille de la clé
  • La durée de validité (à définir selon vos besoins)
  • La passphrase pour protéger la clé privée

Vous pouvez ensuite vérifier la présence des clés publiques et privées :

gpg -k # Clé publique
gpg -K # Clé privée

Les clés sont maintenant générées pour les deux entités.

Partage des biclés

Les biclés générées il faut maintenant les partager entre les partager entre les entités. Vous pouvez pour cela définir de chaque côté des personnes responsables des clés si vous êtes un société. Cette personne devra être chargée de transférer la clé à l’entité adverse et de vérifier l’intégrité.

Il faut tout d’abord exporter les clés en utilisant l’ID récupéré avec les commandes gpg -k :

gpg --export --armor ID_KEY > entite-x-master-pub.gpg

Il faut maintenant envoyer la clé publique exportée vers l’entité deux. Vu que la clé est publique vous pouvez le faire via le moyen de votre choix, le plus important est de valider l’empreinte de cette clé pour être sûr de son intégrité.

Cela doit être réalisé avant l’envoi par l’entité une et à la réception par l’entité deux :

sha256sum entite-x-master-pub.gpg

L’action doit être réalisée dans les deux sens.

Import et signature des clés

Après avoir reçu et vérifier la clé, chaque entité devra importer la clé publique de l’entité distant dans son keystore GPG afin de la signer avec leur clé privée.

Pour cela il faut importer la clé de la façon suivante :

gpg --import entite-x-master-pub.gpg

Vous pouvez vérifier la présence de la clé avec gpg -k après l’import.

Pour la signature, vous pouvez lancer les commandes suivantes :

gpg --sign-key nom_de_clé_à_signer
gpg --sign-key ID_clé_à_signer
gpg --sign-key mail_clé_à_signer

Il faut une nouvelle fois réaliser l’export de la clé que vous venez de signer avant de la renvoyer vers la personne compétente :

gpg --export --armor ID_KEY > entite-x-master-pub-sign.gpg

La clé ainsi que le hash devraient être différents de la clé initiale car les informations ont changées. Il faut suivre la même procédure pour renvoyer la clé en vérifiant les empreintes à l’envoi et à la réception.

Vérification de la signature

Une fois les clés publiques réceptionnées dans chaque entité, il faut vérifier si la signature est correcte. Il faut d’abord réimporter les clés dans les keystore :

gpg --import entite-x-master-pub-sign.gpg

Vous devriez voir un message vous indiquant que la clé importée est signée.

Pour vérifier plus concrètement il faut utiliser les commandes suivantes :

gpg --list-sig
gpg --list-sig ID_KEY

Par exemple pour la clé de l’entité 1 :

Nous avons maintenant des clés maîtres publiques signées de chaque côté ! La toile de confiance est créée entre les entités 1 & 2. Si vous n’avez pas besoin d’utiliser de biclé applicative, vous pouvez vous arrêter ici.

Génération des biclés applicatives

Les clés applicatives sont des clés qui sont issues de la clé maître d’une entité. Elle sera forcément de confiance vu qu’elle sera signée avec clé publique maître validée par les deux entités.

Pour générer une biclé applicative, il suffit de réaliser les opérations suivantes, tout d’abord créer une nouvelle clé, sur l’entité 1 par exemple :

gpg --sign-key nom_de_clé_à_signer

Il suffit en suite de signer cette clé avec la commande utilisée précédemment :

gpg --sign-key nom_de_clé_à_signer
gpg --sign-key ID_clé_à_signer
gpg --sign-key mail_clé_à_signer

Et maintenant il suffit de vérifier la signature de la clé :

gpg --list-sig
gpg --list-sig ID_KEY

La clé applicative est bien signée, il suffit maintenant de l’exporter de la transmettre à l’entité 2.

Envoi et vérification des biclés applicatives

La procédure est la même que précédemment, il faut d’abord exporter la clé dans un fichier :

gpg --export --armor 025FBFC5BB23279452C8B3A0010B1FE19BB25100 > entite-1-app-key-sign.gpg

Et il faut également vérifier l’empreinte du fichier à l’envoi ainsi qu’à la réception :

sha256sum entite-1-app-key-sign.gpg

Pour terminer, vérifier la signature une fois réceptionnée :

gpg --import entite-1-app-key-sign.gpg
gpg --list-sig 025FBFC5BB23279452C8B3A0010B1FE19BB25100

Voilà, nous avons maintenant généré des clés maîtres et applicatives pour former une toile de confiance entre les deux entités ! Si vous voulez aller plus loin vous pouvez utiliser la librairie Python de GnuPG pour automatiser tout cela.

J’espère que cet article vous aura plu, si vous avez des questions ou des remarques sur ce que j’ai pu écrire n’hésitez pas à réagir avec moi par mail ou en commentaire ! N’hésitez pas à me dire également si ce genre d’article vous plaît !

Merci pour votre lecture et à bientôt !


3 commentaires

bob · 30 novembre 2020 à 10 h 47 min

Trop compliqué à utiliser pour des utilisateurs. En 25 ans de carrière, je n’ai jamais vu personne utiliser gpg à part quelques interlocuteurs de la sécurité.

    Mickael Rigonnaux · 30 novembre 2020 à 11 h 02 min

    Bonjour Bob !

    Je suis d’accord que ça reste complexe à mettre en place avec une toile de confiance, mais de mon côté j’utilise régulièrement GPG avec pas mal de partenaire, peut être pas de cette façon mais ça reste assez répandu je pense

simpleUser · 1 décembre 2020 à 8 h 16 min

L’article est intéressant, mais il pourrait être sympa de complexifié davantage le scénario avec une troisième entité. et de voir ce qu’il est possible de faire en terme de confiance à ce moment la.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.