Gnuk, NeuG, FST-01

La plate-forme de prédilection pour exécuter Gnuk est le FST-01, un circuit spécifiquement conçu dans ce but par gniibe et qui sera détaillé dans une section dédiée plus loin.

Gnuk est aussi le moteur de la Nitrokey Start, qui est probablement le moyen le plus simple de se procurer un jeton Gnuk prêt à l’emploi.

	Note
	En plus de la Nitrokey Start, la gamme Nitrokey contient deux autres jetons compatibles avec la spécification de la carte OpenPGP. Toutefois, seule la Nitrokey Start est basée sur Gnuk. La Nitrokey Pro et la Nitrokey Storage, qui descendent du projet Crypto-Stick, embarquent en leur sein un exemplaire de la carte OpenPGP physique de FLOSS-Shop, et n’ont aucun lien avec Gnuk.

Gnuk peut aussi fonctionner sur plusieurs circuits construits autour d’un contrôleur STM32, parmi lesquels :

Gnuk implémente la dernière version de la spécification de la carte OpenPGP (version 3.3.1, publiée en août 2017), et de manière générale suit d’assez près l’évolution de la spécification (en 2015, Gnuk a été la première implémentation à prendre en charge la version 3.0 de la spécification, quelques semaines seulement après sa publication).

Comme toutes les cartes OpenPGP, Gnuk permet d’utiliser trois clefs privées (une clef de signature, une clef de déchiffrement, une clef d’authentification). Gnuk prend en charge à la fois les clefs RSA et les clefs basées sur les courbes elliptiques (qui sont la principale nouveauté de la carte OpenPGP en version 3.x).

Du côté de RSA, en pratique seules des clefs de 2048 bits sont utilisables. Il est en théorie possible d’utiliser des clefs de 4096 bits, mais les performances du microcontrôleur STM32F103 avec des clefs de cette taille sont rédhibitoires (une opération de signature avec une clef RSA 4096 peut prendre jusqu’à dix secondes) ; il n’est d’ailleurs même pas possible de générer une clef RSA de 4096 bits directement sur le jeton, la mémoire disponible n’est tout simplement pas suffisante — si vous tenez absolument à utiliser une clef RSA de 4096 bits malgré tout, il vous faudra la générer sur l’ordinateur hôte puis l’importer sur le jeton.

	Note
	Notez que seules les clefs de 2048 et 4096 bits sont prises en charge ; Gnuk ne permet pas l’utilisation de clefs de taille inférieure (par exemple 1024 bits), intermédiaire (par exemple 3072 bits), ou « exotique » (par exemple 2768 bits).

Du côté de la cryptographie à courbe elliptique, Gnuk prend en charge les courbes suivantes :

Officiellement, à l’heure actuelle seule la courbe secp256r1 fait partie du standard OpenPGP (depuis le RFC 6637). Il ne fait guère de doutes que la courbe Curve25519 sera intégrée à la prochaine révision du standard (elle a été introduite dès le premier brouillon du RFC 4880bis, introduction qui n’a jamais été contestée depuis), on peut donc générer aujourd’hui des clefs utilisant cette courbe sans crainte pour la compatibilité future. En revanche l’avenir de la courbe secp256k1 dans OpenPGP est incertain ; GnuPG la prend en charge, de même que OpenPGP.js, mais personne n’a jamais proposé de l’ajouter au standard.

Au-delà des types de clefs pris en charge, il y a quelques autres points à noter concernant l’implémentation de la spécification par Gnuk, pêle-mêle :

L’objectif premier d’un jeton cryptographique comme la carte OpenPGP est de protéger les clefs privées. Comment Gnuk remplit-il cet objectif ?

Les routines cryptographiques utilisées dans Gnuk proviennent de la bibliothèque mbedTLS (anciennement PolarSSL). Le code de ces routines fournit une première ligne de défense contre certaines attaques par canaux cachés (par exemple les timing attacks, basées sur le temps passé à effectuer les opérations crytographiques) ou certaines attaques par faute (par exemple l’attaque de Boneh, Demillo et Lipton, où l’injection d’une faute matérielle — glitch — lors d’une opération de signature RSA permet de déduire la clef signante). De telles contre-mesures sont aujourd’hui classiques dans tout logiciel de cryptographie (on les trouve aussi dans GnuPG par exemple).

Contre l’extraction directe des clefs privées, Gnuk se repose en partie sur le mécanisme de protection de la mémoire Flash (RDP, Read Data Protection) fourni sous une forme ou sous une autre par la plupart des microcontrôleurs, dont le microcontrôleur STM32F103. Une fois le RDP activé, il n’est en principe pas possible de lire le contenu de la mémoire Flash, et la désactivation de la protection entraîne automatiquement son effacement complet. Ce genre de protection n’est toutefois pas à toute épreuve, comme l’ont par exemple montré des chercheurs allemands l’année dernière en contournant le mécanisme RDP d’un microcontrôleur STM32F0, permettant une extraction complète du contenu de la Flash en quelques heures (tester si l’attaque fonctionne sur un modèle STM32F103 est laissé en exercice au lecteur — STMicroelectronics affirme que non). Et cette protection est probablement inopérante contre les attaques dites invasives (où l’attaquant peut aller jusqu’à détruire physiquement le microcontrôleur) — il existe des entreprises chinoises spécialisées dans ce genre d’attaques, y compris contre le STM32F103, vraisemblablement à des fins de contrefaçon.

Gnuk implémente une protection supplémentaire en stockant les clefs privées sous forme chiffrée, le PIN utilisateur servant de clef de chiffrement, de sorte qu’un attaquant qui réussirait à extraire les clefs du microcontrôleur devrait aussi réussir à obtenir le PIN. Une limitation évidente de cette protection est que le PIN est typiquement choisi dans un espace assez petit (Gnuk autorise des PIN de 127 caractères Unicode, mais la plupart des utilisateurs choisiront sans doute un PIN numérique de 6 à 10 chiffres) et donc possiblement brute-forceable.

Pour renforcer le chiffrement des clefs sur le jeton, la version 3.3 de la spécification de la carte OpenPGP a introduit le mécanisme KDF-DO. Le principe est qu’avant d’être envoyé au jeton le PIN saisi par l’utilisateur est passé à la moulinette d’une fonction de dérivation de clef (KDF, Key Derivation Function), qui transforme un PIN de taille arbitraire en une clef de 32 à 64 octets (selon l’algorithme de condensation utilisée au sein de la fonction de dérivation). Les paramètres de la fonction de dérivation sont eux-mêmes stockés dans un champs dédié du jeton (KDF-DO, KDF Data Object). L’objectif est de rendre la recherche exhaustive du PIN trop longue et/ou trop coûteuse, même si le PIN lui-même est choisi dans un espace de taille restreinte.

Gniibe a ajouté le support du mécanisme KDF-DO dans la version 2.2.6 de GnuPG. Pour mettre en œuvre ce mécanisme, il suffit d’appeler la commande kdf-setup dans l’éditeur de de cartes de GnuPG, avant de stocker une clef sur le jeton :

$ gpg --card-edit
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.2.10) 00 00
Application ID ...: D276000124010200FFFE123456780000
[…]
Signature key ....: [not set]
Encryption key ...: [not set]
Authentication key: [not set]

gpg/card> admin
Admin commands are allowed.

gpg/card> kdf-setup

gpg/card> 
      

Une critique parfois formulée à l’encontre de Gnuk est qu’une implémentation de la carte OpenPGP sur un microcontrôleur généraliste ne saurait offrir la même protection qu’une carte à puce spécialisée, et que Gnuk ne serait au mieux qu’une sorte de « carte à puce du pauvre ». On retrouve cette idée dans le tableau comparatif de Nitrokey, qui met en avant le fait que seules la Nitrokey Pro et la Nitrokey Storage embarquent une tamper-resistant smart card qui « empêche l’extraction des clefs » — sous-entendu, la Nitrokey Start de son côté laisse vos clefs vulnérables.

Pour autant, d’une part Gnuk ne laisse pas les clefs dénuées de toute protection comme on vient de le voir, et d’autre part la « résistance aux attaques physiques » (tamper resistance) n’est ni l’apanage des cartes à puce, ni absolue. Carte à puce ou pas, il est toujours prudent de considérer qu’un adversaire motivé et équipé pourra extraire des données du jeton, si besoin en dépiotant la puce et en allant directement lire la valeur des bits au microscope. Faire reposer votre sécurité sur une vague assurance de tamper resistance est simpliste (et dangereux s’il s’avère que votre adversaire est motivé et équipé).

	Note
	Pour ce que ça vaut, mon opinion personnelle est que je préfère un jeton m’offrant une protection peut-être imparfaite mais dont je connais le code et les mécanismes, à une carte à puce m’offrant une protection certainement imparfaite également mais qui dépend d’informations que le constructeur de la puce refuse de dévoiler.

Je ne détaillerai pas trop l’utilisation de Gnuk, puisqu’un jeton Gnuk se comporte exactement comme une carte OpenPGP (et pour cause, c’est une carte OpenPGP), dont l’utilisation a déjà été couverte dans un précédent article. Quelques points méritent tout de même d’être mentionnés ou rappelés.

Gnuk est compatible avec la norme CCID, ce qui signifie d’une part qu’un jeton Gnuk est reconnu sans heurts par PCSC-Lite, le middleware standard de gestion des cartes à puce, et son pilote ccid ; et d’autre part qu’un tel jeton est aussi reconnu nativement par le pilote CCID intégré à Scdaemon, le démon auxiliaire de GnuPG chargé de l’interaction avec les cartes à puce.

Vous avez donc le choix entre deux chemins différents pour permettre à GnuPG d’utiliser votre jeton : soit vous utilisez PCSC-Lite, qui accèdera exclusivement au jeton, Scdaemon communiquant alors avec PCSC-Lite ; soit vous n’utilisez pas PCSC-Lite, et Scdaemon accèdera au jeton directement. Dans le premier cas, c’est le compte utilisateur associé au démon PCSC-Lite qui doit avoir les droits d’accès au jeton ; dans le second, c’est votre propre compte utilisateur, sous lequel tournent les démons auxiliaires de GnuPG dont Scdaemon, qui doit avoir ces droits d’accès.

Dans la règle Udev suivante, tout périphérique Gnuk — identifié par le Vendor ID de la FSIJ (234b), et le Product ID de Gnuk (0000) — est assigné au compte scard, qui chez moi est le compte sous lequel tourne le démon de PCSC-Lite. Adaptez cette règle à votre situation et à votre système.

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="234b", ATTRS{idProduct}=="0000", \
  OWNER="scard", GROUP="scard", MODE="660", ENV{ID_SMARTCARD_READER}="1"
      

Si vous utilisez une Nitrokey Start, notez que Nitrokey utilise ses propres identifiants USB, distincts de ceux de la FSIJ : Nitrokey a pour Vendor ID 20a0 et la Nitrokey Start a pour Product ID 4211.

Vérifiez ensuite que GnuPG a connaissance de votre jeton :

$ gpg --card-status
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.2.10) 00 00
Application ID ...: D276000124010200FFFE123456780000
[…]
      

Je vous renvoie à l’article susmentionné pour remplir les différents champs du jeton (nom du titulaire, préférences linguistiques, etc.) et importer des clefs privées. Le PIN administrateur par défaut, qui vous sera demandé avant toute modification, est normalement 12345678, et le PIN utilisateur est 12356. Souvenez-vous que vous ne pouvez changer le PIN utilisateur qu’après avoir importé au moins une clef privée, et que si voulez bénéficier du mécanisme KDF-DO pour une protection accrue des clefs comme décrit dans la section précédente, vous devez l’activer avant d’importer la moindre clef.

Vous pouvez être amenés à devoir flasher votre FST-01 pour plusieurs raisons : vous avez obtenu (ou fabriqué vous-même) un FST-01 « vierge » ; vous avez obtenu un FST-01 pré-chargé avec NeuG (par exemple celui vendu par la FSF) alors que vous avez plutôt besoin de Gnuk, ou inversement ; ou vous souhaitez remplacer le Gnuk ou le NeuG pré-chargé par une version plus récente.

$ git clone git://git.gniibe.org/gnuk/gnuk.git
[…]
$ cd gnuk/src
$ git submodule update --init
        

$ ./configure --target=FST_01G \
  --vidpid=234b:0000 \
  --enable-factory-reset \
  --enable-certdo
Header file is: board-fst-01g.h
Debug option disabled
Configured for bare system (no-DFU)
PIN pad option disabled
CERT.3 Data Object is supported
Card insert/removal by HID device is NOT supported
Life cycle management is supported
$ make
[…]
arm-none-eabi-objcopy -O binary build/gnuk.elf build/gnuk.bin
        

4.1.2. Flashage via SWD

C’est la seule méthode possible si votre FST-01 est « vierge » ou s’il est chargé avec autre chose que Gnuk ou NeuG. Vous aurez besoin d’un débogueur SWD (Gniibe recommande le ST-Link/V2 ou un ses clones) et éventuellement d’OpenOCD.

Connectez le débogueur ST-Link/V2 au FST-01 comme indiqué sur la Figure 2 :

• Broche 2 du ST-Link/V2 (MCU VDD) vers le port +3V3 du FST-01 (dans le coin en haut à gauche, si le FST-01 est orienté avec le port USB vers la droite) ;

• Broche 4 (GND) vers le port GND 2 (en-dessous du précédent) ;

• Broche 7 (SWDIO) vers le port SWDIO (dans le coin en haut à droite, juste derrière le connecteur USB) ;

• Broche 9 (SWCLK) vers le port SWCLK (à gauche du précédent).

Figure 2. Schéma du FST-01 indiquant les ports de connexion au débogueur SWD

Si nécessaire, désactivez la protection de la mémoire Flash du microcontrôleur STM32F103 (cela effacera la mémoire en question) :

$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg \
  -c init \
  -c "reset halt" \
  -c "stm32f1x unlock 0" \
  -c reset -c exit
        

Puis procédez au flashage proprement dit :

$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg \
  -c "program build/gnuk.elf verify reset exit"
        

Et réactivez la protection de la mémoire Flash derrière vous :

$ openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg \
  -c init \
  -c "reset halt" \
  -c "stm32f1x lock 0" \
  -c reset -c exit
        

OpenOCD peut éventuellement être remplacé par le script tool/stlinkv2.py fourni avec les sources de Gnuk et de NeuG, et que Gniibe a écrit à une époque où OpenOCD ne prenait pas encore en charge le débogueur ST-Link/V2. L’équivalent des commandes ci-dessus est dans ce cas :

$ ../tool/stlinkv2.py -u
$ ../tool/stlinkv2.py build/gnuk.bin
        

La première commande désactive la protection de la mémoire, la deuxième reprogramme le microcontrôleur (et active à nouveau la protection de la mémoire après). Notez que cette commande attend un fichier binaire (build/gnuk.bin), pas un fichier au format ELF.

4.1.3. Flashage via reGNUal

Si votre FST-01 est déjà chargé avec Gnuk ou NeuG, vous pouvez le reflasher sans avoir besoin d’un débogueur. Tant Gnuk que NeuG permettent la mise à jour du logiciel exécuté sur le microcontrôleur directement via le port USB. Cela peut être utilisé soit pour passer à une version plus récente du même programme (par exemple, de Gnuk 1.2.8 à Gnuk 1.2.9) ou pour passer d’un programme à l’autre — le cas probablement le plus typique étant le remplacement de NeuG par Gnuk, sur le FST-01 vendu par la Free Software Foundation.

Avertissement

Cette fonctionnalité est encore considérée comme expérimentale et Gniibe conseille de se munir tout de même d’un débogueur SWD « au cas où » — si la mise à jour se passe mal, votre FST-01 peut se retrouver « briqué » et il vous faudra alors vous rabattre sur le flashage via SWD comme décrit dans la section précédente. Pour ce que ça vaut, j’ai expérimenté cette méthode à plusieurs reprises sans jamais rencontrer de problèmes, mais évidemment your mileage may vary…

Pour utiliser cette méthode, après avoir compilé Gnuk comme ci-dessus, compilez également reGNUal, le programme de mise à jour. Il est dans le dossier regnual dans les sources de Gnuk.

$ cd ../regnual
$ make
[…]
arm-none-eabi-objcopy -Obinary regnual.elf regnual.bin
        

Les choses diffèrent ensuite selon que le FST-01 que vous voulez reflasher contient déja Gnuk ou NeuG.

S’il contient une copie de Gnuk, utilisez le script tool/upgrade_by_passwd fourni avec Gnuk (notez que le script doit être appelé avec les droits du superutilisateur) :

$ cd ../tool
$ sudo ./upgrade_by_passwd.py ../regnual/regnual.bin ../src/build/gnuk.bin
        

Le PIN administrateur de votre jeton Gnuk vous sera demandé, puis le script chargera sur le microcontrôleur le programme de mise à jour (regnual.bin) qui lui-même s’occupera de reprogrammer le microcontrôleur ave le programme final (gnuk.bin).

Si votre FST-01 contient déjà NeuG, vous aurez besoin d’utiliser le script tool/neug_upgrade.py, fourni avec les sources de NeuG.

$ cd ../..
$ git clone git://git.gniibe.org/gnuk/neug.git
$ cd neug/tool
$ sudo ./neug_upgrade.py ../../gnuk/regnual/regnual.bin ../../gnuk/src/build/gnuk.bin