PGP – Première exploration

J’ai décidé de m’intéresser plus sérieusement à la cryptographie et plus particulièrement au standard PGP (Pretty Good Privacy) et à son implémentation GNU Privacy Guard (GnuPG ou GPG). Voici donc certains points à considérer; en vrac, pour commencer à défricher le sujet.

Clé publique, clé privée

Les clés viennent par paire, une privée, l’autre publique. La clé privée est à « protéger » car celle-ci sert aux opérations de déchiffrement et de signature (Maj: Incorrect, voir commentaire).

Type de clé

Il existe plusieurs types de clés, en particulier, la clé de signature (signing key) et la clé de chiffrement (encryption key), la première servant à signer un mail (ou un contenu) et la seconde, à le chiffrer.

Confidentialité et génération des clés

Afin de s’assurer au maximum de la sureté de ses clés, l’idéal est de générer les clés sur une machine n’ayant jamais été connectée au réseau et sur un système d’exploitation dédié, à jour et dont on aura au préalable vérifié la somme de hashage du fichier iso utilisé pour installer l’OS (il me semble que le point faible se situe alors dans le média utilisé pour réaliser l’installation de l’OS, clé USB, CD, carte SD. CD et carte SD me semble moins susceptible d’être compromis en amont, ou lors d’une utilisation sur un PC vérolé.). Il est indispensable de vérifier les sommes de hashage après écriture de l’OS sur le support. Sur cette machine isolée du réseau, il convient alors de générer un ensemble de clé et plusieurs sous-clés (subkey). La clé maîtresse sera sauvegardée sur plusieurs supports chiffrés. Seul les sous-clés seront utilisées. Enfin, l’idéal semble être d’exporter les sous-clés sur une smartcard telle qu’une YubiKey. A défaut d’une machine dédiée à la génération des clés, on pourra se limiter à un système live chargé en RAM et coupé du réseau.

A priori, il semble envisageable et possible d’exporter les clés sur 2 smartcard : les sous-clés sur l’une des smartcards et la clé maîtresse sur l’autre. Cela pourrait peut-être permettre de simplifier la signature de clés (implications en termes de sécurité de la clé maître ?). Néanmoins, je n’ai pas été en mesure de trouver un témoignage de l’utilisation d’une telle configuration lors de mes recherches.

Terminologie
  • sec ‘SECret key’
  • ssb ‘Secret SuBkey’
  • pub ‘PUBlic key’
  • sub ‘public SUBkey’
  • S ->Sign, Signer
  • C -> Certify, Certifier
  • E -> Encrypt, Chiffrer
  • A -> Authenticate, Authentifier
Limitations
  • La signature de clés doit s’effectuer avec la clé maîtresse.
  • Taille des clés limitée à 2048 pour un export sur une YubiKey Neo (sauf YubiKey 4 qui supporte les clés jusqu’à 4096).
Étapes à vérifier
  • Génération des clés, sauvegarde sur support chiffré et export vers YubiKey.
  • Expiration d’une clé et mise à jour de la date d’expiration.
  • Export vers une nouvelle YubiKey à partir de la sauvegarde en cas de perte, vol ou bris de matériel.
  • Redéploiement des clés sur les périphériques à partir de la sauvegarde (si pertinent).
  • Test d’utilisation sur GNU/Linux et Windows.
  • Test d’intégration avec pass.
  • Test de la signature d’une clé.
  • Test de la signature de commit et tag dans Git.
  • (Test d’authentification SSH par clé. Pertinence ?)
Conclusion

Après lecture de plusieurs articles sur le sujet, je commence à avoir une vue d’ensemble du fonctionnement et de l’utilisation des clefs GPG. Il me reste donc à passer à la phase d’expérimentation et de mise en place afin de valider ma compréhension du sujet et de vérifier que rien n’a été oublié.
Aux lecteurs avisés et spécialistes du sujet, n’hésitez pas à pointer d’éventuelles erreurs ou zones d’ombre qui m’aurait échappé, et à partager  les ressources incontournables sur le sujet.

Sources

GPG : comment créer une paire de clefs presque parfaite – NextInpact
Clefs GPG :  comment les stocker et les utiliser via une clef USB OpenPGP Card ? – NextInpact
Offline GnuPG Master Key and Subkeys on Yubikey NEO Smartcard – Simon Josefsson
Guide to using YubiKey as a SmartCard for GPG and SSH – drduh
Email Encryption with the Yubikey-NEO, GPG and Linux (Part 1, Part 2) – ankitrasto

Anonyme

Auteur/autrice : Victor

Ingénieur en informatique de formation et de métier, j’administre ce serveur et son domaine et privilégie l'utilisation de logiciels libres au quotidien. Je construis progressivement mon "cloud" personnel service après service pour conserver un certain contrôle sur mes données numériques.

3 réflexions sur « PGP – Première exploration »

  1. Bonjour,
    Quelques informations et précisions pour faciliter la compréhension.
    —————————
    GnuPG permet de faire de la cryptographie asymétrique (clef publique et clefs secrète)
    Celles-ci peut être réalisées à partir de deux types d’algorithmes :
    — le type RSA (celui dont vous parlez)
    — le type elliptique (P256…du NIST, les courbes Brainpool et EC25519) : clefs plus courtes et à privilégier aujourd’hui même si tous les supports matériels ne les supportent pas.
    La courbe EC25519 est aujourd’hui privilégiée sur ordinateur, car d’origine non étatique comme les Pxxx ou les BrainPool.
    —————————
    On distingue 4 types de clefs :
    — clefs de certification qui sert à certifier qu’une clef appartient bien à une certaine personne (notion de web de confiance) et sert à générer des sous-clefs
    –sous-clef d’authentification pour faire de l’authentification double facteur ou accès SSH
    –sous-clef de chiffrement pour chiffrer/déchiffrer de l’information comme des courriels
    –sous-clef de signature qui sert à de la non répudiation à l’origine et permet par exemple de signer un courriel.

    Seules les trois dernières sous-clefs sont réellement utiles au quotidien. La clef de certification ne sert que rarement :
    — pour certifier les clefs d’autres personnes
    — pour recréer des sous-clefs
    — pour générer un certificat de révocation
    —————————
    Quant aux supports, il n’y a pas que la Yubikey, chère au demeurant mais aussi les Nitrokeys, les clefs Gnuk et les applications pour smartcard

    — Gnuk : https://blog.danman.eu/2-usb-crypto-token-for-use-with-gpg-and-ssh/
    — Smartcard : https://github.com/ANSSI-FR/SmartPGP
    —————————
    Quelques précisions :
    La Yubikey n’est pas une smartcard mais un token usb
    Il n’y a pas besoin de stocker sa clef secrète sur plusieurs supports chiffrés, un seul suffit. On la sauvegarde en général sur plusieurs support en la découpant pour des raisons de sécurité forte. Par exemple si je veux créer une clef pour un serveur et ne veut pas qu’une seule personne puisse reconstruire un serveur avec la même clef (ex IGC), j’utilise un mécanisme « n parmi m » qui découpe la clef en m parties ; n étant nécessaires pour reconstituer la clef initiale. Par conséquent, si j’ai donné les m morceaux à m personnes, je dois avoir la présence de n d’entre-elles pour reconstituer la clef.

    La phrase « Les clés viennent par paire, une privée, l’autre publique. La clé privée est à « protéger » car celle-ci sert aux opérations de déchiffrement et de signature. » est erronée pour es raisons suivantes :

    Dans la cryptographie à clef publique, on génère effectivement des paires de clefs appairées c.-à.-d. que l’opération mathématique faite par l’une va pouvoir être « défaite par l’autre » ou « inversée ». Il y a donc une clef publique que je peux communiquer à tous, mettre sur mon site Web….et une clef privée que je conserve précieusement. On va ensuite associer une identité à la clef publique pour créer un certificat électronique et c’est lui que par vulgarisation la presse appelle clef publique.

    — On me chiffrement une information avec ma clef publique de chiffrement et je la déchiffre avec ma clef privée.
    — Je signe une information avec ma clef privée de signature et le destinataire vérifie la signature avec ma clef publique de signature.
    — Je m’authentifie avec ma clef privée d’authentification et le service vérifier que c’est bien moi avec ma clef publique d’authentification.

    En deux mots, les clefs privée sont privée et ne se divulguent pas tandis que les clefs publique ou certificats doivent être accessibles à tous.

    Pour ce qui est de la génération des clefs, si vos propos sont judicieux, il faut y ajouter une entropie correcte et un fichier de configuration de GnuPG plus élaboré que ceux fournis de base sur les SE.

    —————————
    C’est d’ailleurs parce que la cryptographie avec GnuPG n’est pas simple mais intéressante et libre au regard des certificats X509, que j’envisage de créer une association qui aurait pour but de fournir des clefs correctement élaborées et mises à disposition sur support matériel : token USB puis Carte à puce selon les usages : ordinateur ou mobile multi-fonction/Tablette. L’association ayant aussi en charge la gestion d’un annuaire correct et sécurisé (ldaps), ce qui n’est pas le cas de ceux présents sur le WEB, ainsi que la gestion des révocations de certificats ; choses qui n’est pas fait sur le Web et nuit au développement de l’usage de GnuPG et de la confiance que l’on peut accorder à cet outil.

    C’est en gros le projet d’appliquer certains principes des IGC X509 au monde GnuPG ; ce qu’autorise la norme OpenPGP

    Bien cordialement

    Yokosano

    1. Merci Yokosano pour toutes ces précisions !

      Pour la sauvegarde de la clé secrète sur plusieurs supports, l’objectif est avant tout de se prémunir contre un éventuel défaut de l’un des supports.

Répondre à yokosano Annuler la réponse

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