Catégorie : Crypto

Installer scdaemon sur un Pi déconnecté du réseau

Dans un article précédent décrivant la partie génération de clefs PGP et transfert sur YubiKey, j’avais évoqué qu’il était envisageable de réaliser le processus complet sur un ordinateur exclusivement réservé pour cet usage. Je me suis donc procuré un Raspberry Pi Zéro, afin de vérifier la validité de cette hypothèse.

Mes premiers tests ont néanmoins été quelque peu retardés, car il est nécessaire d’adjoindre au Pi un hub USB disposant d’une alimentation dédiée, afin de pouvoir connecter, et surtout utiliser les différents périphériques : clavier, YubiKey et support de sauvegarde.

Le principal point bloquant par rapport à la génération des clefs PGP testée la première fois, se situe du côté de l’absence dans le système du composant scdaemon. Sans lui, impossible de dialoguer avec la YubiKey et d’exporter les clefs. Passons donc aux étapes permettant son installation.

Dans un premier temps, et après avoir récupéré la dernière version de Raspbian, en étant particulièrement attentif à la vérification de l’image récupérée par comparaison des sommes de hachage, il faut également récupérer le paquet scdaemon. Une page du wiki debian nous indique par ailleurs, que la bonne architecture à choisir pour le Raspberry Pi Zéro est armel ou armhf, à priori.

Sur le site web du projet raspbian, je parviens par ailleurs à trouver la liste des paquets de la distribution disponible. Dans ce fichier, une recherche de la chaîne « Package: scdaemon », nous permet de déterminer le chemin (propriété filename) où trouver le paquet recherché dans l’arborescence du même site, à savoir ici :

pool/main/g/gnupg2/scdaemon_2.1.18-8~deb9u2_armhf.deb

Nous pouvons alors nous rendre sur la page suivante afin d’explorer les différents versions du paquet à notre disposition: https://archive.raspbian.org/raspbian/pool/main/g/gnupg2/. Une fois le paquet récupéré et le système installé sur la carte SD, on pourra alors monter le système de fichier présent sur la carte et déposer le .deb quelque part dans l’arborescence (par exemple, dans /home). On en profite également pour comparer la somme de hachage du paquet avec celle présente dans le fichier « Packages ». Il ne nous reste plus qu’à démarrer le système depuis le Pi et à exécuter la commande dpkg -i <paquet>.deb pour installer scdaemon.

À ce stade, nous disposons désormais d’un ordinateur ayant tous les pré-requis nécessaires à la génération et à l’exportation des clefs PGP sur la YubiKey. J’ai rencontré quelques difficultés lors des premières tentatives d’export vers la YubiKey, car cette dernière, bien que détectée, ne semblait pas disponible. Il semble que deux processus scdaemon étaient démarrés et j’ai donc pu résoudre mon problème avec un simple « killall scdaemon ». Autre point l’export devait être réalisé en mode root, l’option -E de sudo devient alors incontournable pour transmettre la variable d’environnement « GNUPGHOME ». Pas grand-chose à ajouter de plus, si ce n’est qu’il faut faire preuve de patience pour les opérations de génération des clefs, qui mettent plusieurs minutes à s’exécuter sur un Pi zéro.

Connexion SSH avec gpg-agent

Dans l’épisode précédent, je décrivais comment j’avais créé mes clefs et sous-clefs et la façon dont j’avais exporté les sous-clefs sur une YubiKey. Place à une mise en application du côté de la connexion SSH entre un poste client et un serveur. J’utilise déjà le processus d’authentification par clef SSH pour me connecter sur mes machines serveurs, distantes géographiquement ou pas, virtuelles ou non. Le principe est donc d’utiliser la clef d’authentification pour se connecter en SSH aux machines.

On gagne en praticité, car une seule clef va nous permettre de nous connecter à chacune de nos machines une fois celles-ci configurées. Cela passe néanmoins par une configuration de la machine cliente pour utiliser gpg-agent en lieu et place de ssh-agent, chose qui n’est pas forcément aisée. Je vais décrire la configuration que j’ai mise en place, résultat de plusieurs échecs successifs avant d’arriver à quelque chose de fonctionnel et en sachant que j’utilise Xorg et I3 pour la partie affichage et interface.

Configuration côté serveur

La première étape consiste à récupérer les informations de la clef nécessaires à la configuration du serveur. Après avoir inséré notre YubiKey, nous exécutons donc la commande suivante :

$ ssh-add -L
ssh-rsa BFFEB3NzaC ... pdqsdfwX6m1 cardno:000123456789

Nous pouvons alors copier les informations renvoyées par cette commande et les insérer dans le fichier authorized_keys de notre serveur.

Configuration côté client

Le but est maintenant de remplacer ssh-agent par gpg-agent. Nous commençons donc par configurer ce dernier en éditant le fichier .gnupg/gpg-agent.conf :

enable-ssh-support 
pinentry-program /usr/bin/pinentry-curses 
max-cache-ttl 300 
default-cache-ttl 300

Dans le fichier .pam_environment, nous ajoutons les lignes suivantes :

SSH_AGENT_PID   DEFAULT= 
SSH_AUTH_SOCK DEFAULT="${XDG_RUNTIME_DIR}/gnupg/S.gpg-agent.ssh"

Et enfin dans .zshrc :

export GPG_TTY=$(tty) 
gpg-connect-agent updatestartuptty /bye >> /dev/null

Il me semble que cette configuration est suffisante pour obtenir quelque chose de fonctionnel. Sur mon poste, j’ai quelques déclarations supplémentaires du côté des fichiers .profile, .zprofile qui font doublon pour la déclaration de la variable GPG_TTY. Il devrait être possible de les supprimer sans risques.

Test unique

Pour réaliser un test unique, après configuration de gpg-agent et avant d’effectuer toutes les modifications ci-dessus et de tester la persistance au redémarrage, j’ai utilisé les commandes ci-dessous pour tester la connexion au serveur avec la clef d’authentification et vérifier cette première étape.

sudo killall gpg-agent
sudo killall ssh-agenteval $( gpg-agent --daemon --enable-ssh-support )

Nous pouvons alors essayer la connexion SSH vers notre serveur et retrouver la configuration utilisant ssh-agent après un simple redémarrage. L’utilisation de l’option -vvv étant particulièrement utile pour suivre les étapes de connexion et détecter d’éventuels problèmes.

ssh user@server -vvv

Conclusion

Avec cette configuration, je suis donc en mesure de me connecter à mes serveurs via SSH en utilisant ma clef d’authentification stockée sur ma YubiKey et le PIN associé à la clef. S’il est plutôt aisé de réaliser une première connexion réussie, la principale difficulté concerne la persistance de la configuration et le lancement correcte des composants à l’ouverture de la session; en particulier pour l’affichage de l’interface de saisi du PIN via pinentry-curses.

Sources

Using GnuPG (2.1) for SSH authentication
YubiKey for SSH, Login, 2FA, GPG and Git Signing

GnuPG, clefs, YubiKey : c’est parti

L’enchaînement  et le choix des commandes et des configurations qui vont suivre sont essentiellement extraites du blog de Simon Josefsson dans son article Offline GnuPG Master Key and Subkeys on Yubikey NEO Smartcard.

Après m’être documenté sur la génération de clefs, GnuPG et les possibilités  d’intégration au système, je me suis donc naturellement tourné vers la pratique et l’expérimentation. J’essaye ici d’en retracer les étapes, afin d’être en mesure de le reproduire au besoin.

Quelques points restent à améliorer et à solutionner, notamment l’absence dans les systèmes live testés (Kali Linux, Debian 9.5.0 et Parrot Security 4.2.2), du composant scdaemon permettant de communiquer avec la YubiKey et conduisant à l’échec de la commande gpg –card-edit.

Dernière petite note avant d’entrer dans le vif du sujet. Pourquoi une YubiKey (Neo) ? Tout simplement parce que j’avais fait l’acquisition de ce matériel il y a de cela quelques années, mais n’avais pas réussi à l’intégrer à mon utilisation quotidienne. Ce dispositif été donc tout indiqué pour servir de support de stockage à mes sous clefs.

Pour rappel, les opérations effectuées ci-dessous sont à réaliser sur une machine hors ligne et dans un système « Live ». Les plus soucieux de leur sécurité pourront aller jusqu’à utiliser un ordinateur dédié à cette tâche (un raspberry pi zéro peut-être ?).

Continuer la lecture de « GnuPG, clefs, YubiKey : c’est parti »

Chiffrer un fichier (protégé par mot de passe)

Petit point rapide sur la façon de chiffrer un fichier avec gpg et une protection par mot de passe. Très utile par exemple s’assurer qu’un contenu  ne sera lisible qu’après une manipulation d’un utilisateur disposant du mot de passe. Par exemple, s’assurer que la sauvegarde d’une clé PGP maîtresse reste illisible même après montage et ouverture du support de stockage chiffré.

gpg -ca archive.tar

Il est possible de se limiter à l’option c de chiffrement symétrique. L’option –a  permet de forcer la sortie en ASCII et n’est donc pas forcément nécessaire.

L’opération de déchiffrement s’effectue de la manière suivante :

gpg archive.tar.asc

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