Gnuk, NeuG, FST-01 : entre cryptographie et matériel libre

Posté par (page perso) . Édité par ZeroHeure, Benoît Sibaud, palm123 et Davy Defaud. Modéré par ZeroHeure. Licence CC by-sa.
50
30
juin
2018
Sécurité

Depuis quelques années, la Free Software Initiative of Japan (FSIJ, association de promotion des logiciels libres au Japon) travaille sur un ensemble de projets à la croisée des chemins entre cryptographie, informatique embarquée et matériel libre.

Ces projets sont l’œuvre de Niibe Yutaka (Gniibe ou g新部), qui, entre autres casquettes, est président de la FSIJ, coordinateur des traductions japonaises du projet GNU, développeur Debian et contributeur à GnuPG (où il travaille notamment sur la cryptographie à courbes elliptiques et la gestion des cartes à puce — deux aspects qui sont directement liés aux projets dont il va être question dans cette dépêche).

Votre serviteur avait déjà très brièvement évoqué l’existence de deux de ces projets (Gnuk et le FST-01) dans une dépêche précédente consacrée à la carte OpenPGP (dont la lecture est recommandée avant de poursuivre), mais sans donner aucun détail, ce que la présente dépêche va corriger.

Sommaire

Gnuk, le jeton cryptographique USB

logo Gnuk
Gnuk (GnuPG toKen, mais le nom est en réalité dérivé d’une marque de produits pour bébés, comme le rappelle le logo du projet) est une implémentation logicielle d’un « jeton » (token) cryptographique USB, ciblant les microcontrôleurs de la famille STM32F103. Un tel microcontrôleur relié à un port USB et exécutant Gnuk sera vu par l’ordinateur hôte comme un lecteur de cartes à puce qui contiendrait une carte OpenPGP inamovible.

Gnuk est une implémentation complètement libre de la carte OpenPGP, à la différence par exemple de la carte OpenPGP physique de FLOSS-Shop (anciennement Kernel Concepts) qui n’est que partiellement libre (son auteur n’a pas pu publier le code de certaines routines obtenues sous couvert d’un Non-Disclosure Agreement) ou de la Yubikey 4 dont le firmware est complètement propriétaire.

Plate-formes cibles

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 token Gnuk prêt à l’emploi.

Note

En plus de la Nitrokey Start, la gamme Nitrokey contient deux autres tokens 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 :

  • la carte STM32-H103 de Olimex ;
  • la carte Maple Mini de Leaflabs, parfois décrite comme un « Arduino-like dopé » (Leaflabs en a cessé la fabrication mais des clones sont disponibles auprès d’autres constructeurs) ;
  • la carte « Blue Pill », ou « STM32F103C8T6 Minimum System Board », une des moins chères du marché (entre deux et trois dollars la carte auprès de revendeurs chinois) ;
  • la carte d’évaluation et de développement NUCLEO-F103RB de STMicroelectronics (qui est aussi le constructeur des microcontrôleurs STM32) — c’est la carte recommandée par Gniibe si vous cherchez avant tout à expérimenter ;
  • les cartes STBee et STBee Mini de Strawberry-Linux.

Fonctionnalités et conformité

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 :

  • la courbe secp256r1 (aussi appelée NIST P-256, parce que définie dans le standard FIPS 186-4 du National Institute of Standards and Technology) ;
  • la courbe secp256k1, notoirement utilisée par Bitcoin ;
  • la courbe Curve25519, définie dans le RFC 7748.

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 :

  • Gnuk offre une prise en charge encore considérée « expérimentale » du mécanisme KDF-DO introduit dans la version 3.3 de la spécification et visant à assurer une meilleure protection des clefs privées (décrit dans une section suivante).
  • Les « champs à usage privé » (Private-Use DOs), une partie optionnelle de la spécification, ne sont pas supportés.
  • Pour des raisons liées à des détails d’implémentation, le PIN utilisateur ne peut pas être changé si le jeton ne contient aucune clef privée. Lors de la première utilisation d’un nouveau jeton, il faut importer ou générer sur place au moins une clef avant de pouvoir changer le PIN utilisateur installé par défaut par un PIN personnalisé.
  • Gnuk propose un mode admin-less, dans lequel le PIN utilisateur et le PIN administrateur (PW1 et PW3, dans le jargon de la spécification) sont confondus. Dans ce cas, la taille imposée minimale du PIN utilisateur est de huit caractères (elle est normalement de six caractères en mode « normal »).

Protection des clefs

L’objectif premier d’un token 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 cryptographiques) 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 champ 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 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 ...: D276000124010200FFFEF1420A7A0000
[…]
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épiautant 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.

Utilisation avec GnuPG

logo GnuPG

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 une dépêche précédente. 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 ID20a0 et la Nitrokey Start a pour Product ID4211.

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 123456. Souvenez-vous que vous ne pouvez changer le PIN utilisateur qu’après avoir importé au moins une clef privée, et que pour 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.

NeuG, le générateur de nombres aléatoires

logo Neug

NeuG (le nom est dérivé de la prononciation japonaise de noisy) est une implémentation d’un générateur de nombres aléatoires pour microcontrôleurs STM32F103, utilisant comme source d’entropie le bruit des convertisseurs analogique/numérique intégrés à ces microcontrôleurs.

NeuG a été initialement développé comme composant de Gnuk, fournissant le générateur de nombres aléatoires pour le jeton OpenPGP (notamment utilisé pour la génération de clefs directement sur le jeton) ; NeuG est une version stand-alone du générateur de nombres aléatoires intégré à Gnuk.

Il se présente comme un périphérique USB CDC/ACM (Communication Device Class/Abstract Control Model), autrement dit un périphérique USB émulant un port série ; un tel périphérique est typiquement représenté sous GNU/Linux par un fichier /dev/ttyACM0. Il suffit de lire depuis ce fichier pour extraire des octets aléatoires du périphérique.

Si vous voulez utiliser le générateur depuis un compte utilisateur normal, assurez-vous d’avoir accès au périphérique en lecture et en écriture (l’accès en écriture est nécessaire pour configurer correctement le périphérique comme on le verra ci-dessous), par exemple avec la règle Udev suivante :

ACTION=="add", SUBSYSTEM=="tty", \
  ATTRS{idVendor}=="234b", ATTRS{idProduct}=="001", \
  GROUP="users", MODE="660"

Note

Comme déjà vu plus haut, 234b est le Vendor ID de la FSIJ ; 0001 est le Product ID de NeuG.

Avant de pouvoir lire des octets aléatoires, il faut configurer la discipline de ligne du (pseudo-)port série en mode brut (raw) :

$ stty -F /dev/ttyACM0 -echo raw

Enfin, il faut choisir le mode de conditionnement, qui détermine le(s) filtre(s) appliqué(s) sur les octets extraits des convertisseurs analogique/numérique. Le choix du mode se fait en réglant les options de parité du port série.

  • Aucun filtre : configurez le port série pour utiliser un bit de parité pair (stty -F /dev/ttyACM0 parenb -parodd).
  • Filtre CRC-32 : configurez le port série pour utiliser un bit de parité impair (stty -F /dev/ttyACM0 parenb parodd).
  • Filtres CRC-32 et SHA-256 : désactivez le bit de parité (stty -F /dev/ttyACM0 -parenb).

Vous pouvez maintenant extraire des octets aléatoires du périphérique. Par exemple, pour créer un fichier de 32 kB avec dd :

$ dd if=/dev/ttyACM0 of=random_data bs=1024 count=32

Fraucheky, le conteneur GPL

Fraucheky est un projet annexe de Gniibe visant à résoudre un problème bien spécifique se posant à quelqu’un qui voudrait distribuer un périphérique USB dont le microcode est un logiciel libre sous licence GPL (par exemple un jeton Gnuk ou NeuG). La GPL, entre autres obligations, demande de transmettre une copie de la licence aux utilisateurs (give all recipients a copy of this License along with the Program) ; comment satisfaire cette obligation lorsque le programme en question est exécuté sur un microcontrôleur branché sur un port USB, sans interface utilisateur propre (donc sans menu du genre « à propos de ce logiciel ») ?

Une solution non-technique qui serait sans doute tout à fait valable vis-à-vis de la GPL serait de fournir le texte de la licence sur un livret accompagnant le périphérique, mais ce ne serait ni écologique ni amusant.

À la place, Fraucheky, la solution imaginée par Gniibe, est une implémentation minimaliste du protocole USB Mass Storage, permettant au périphérique de se faire temporairement passer pour une clef USB. Concrètement, lorsqu’il est connecté à l’ordinateur, le périphérique embarquant Fraucheky apparaît initialement comme une banale clef USB étiquetée FRAUCHEKY, contenant un exemplaire de la licence GPL ainsi qu’un fichier README décrivant le périphérique. C’est seulement lorsque le volume FRAUCHEKY est démontée que Fraucheky fait apparaître la vraie nature du périphérique (NeuG par exemple) et que celui-ci devient utilisable.

Pour éviter à l’utilisateur d’avoir à monter et démonter le volume FRAUCHEKY avant chaque utilisation du périphérique, Fraucheky a un mécanisme de désactivation permanente représenté par un dossier appelé DROPHERE. Toute opération d’écriture dans ce dossier (par exemple un glisser-déposer de n’importe quel fichier, comme le fichier de la GPL commodément situé juste « à côté ») entraîne la disparition de Fraucheky : dès lors, le périphérique USB apparaîtra systématiquement sous sa véritable identité dès la connexion à l’ordinateur hôte, sans plus nécessiter un cycle de montage/démontage.

FST-01

Le FST-01 (Flying Stone Tiny 01) est un circuit imprimé spécifiquement imaginé par Gniibe pour faire tourner Gnuk ou NeuG. Sa conception se veut minimaliste et le circuit n’accueille, autour d’un microcontrôleur STM32F103 (avec ses 128 ko de mémoire Flash et 20 ko de RAM), qu’un terminateur USB, un oscillateur à quartz, un régulateur de tension et une LED témoin d’activité.

Le FST-01 est un matériel libre dont Gniibe fournit tous les plans, Vous pouvez donc construire vous-même votre propre FST-01.

Si vous n’êtes pas à ce point adepte du Do-It-Yourself (ou si votre insoleuse est en panne), vous pouvez obtenir un FST-01 déjà tout fait directement auprès de Gniibe, soit via son site personnel (en japonais uniquement), soit en personne si vous avez l’occasion de le rencontrer lors d’un évènement du monde libre (DebConf par exemple) — il a généralement quelques exemplaires sur lui pour ces occasions. Un FST-01 pré-chargé avec NeuG est également en vente auprès de la Free Software Foundation.

photo du circuit imprimé FST-01
Le FST-01 de l’auteur, similaire à celui vendu par la FSF.

Note

Le FST-01 a aussi été disponible pendant un temps auprès de Seeed Studio, mais il a depuis été retiré, même si le produit apparaît toujours sur leur wiki.

Charger Gnuk ou NeuG sur un FST-01

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.

Compiler Gnuk

Dans tous les cas, il faut bien sûr commencer par compiler le programme de votre choix (disons Gnuk, pour cet exemple — la procédure pour NeuG est similaire).

Pour ça, il vous faut une chaîne de compilation ciblant l’architecture arm-none-eabi. Votre distribution vous en fournit peut-être une (c’est le cas par exemple sous Debian, il vous suffit d’installer le paquet gcc-arm-none-eabi ; pour Slackware, un SlackBuild est disponible), sinon vous pouvez en obtenir une auprès de Arm, pré-compilée ou sous forme de sources.

ARMé de votre compilateur, vous pouvez maintenant télécharger les sources de Gnuk :

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

Lors de la configuration des sources, choisissez la cible FST_01 ou FST_01G selon votre modèle (le FST-01 est le modèle initial ; le FST-01G est la seconde génération).

Vous devez aussi choisir le Vendor ID et le Product ID de votre futur jeton. Pour un usage personnel, vous pouvez utiliser le Vendor ID de la FSIJ (234b) et le Product ID de Gnuk (0000). Pour un usage commercial (comme ce que fait Nitrokey avec la Nitrokey Start par exemple), il vous appartient d’obtenir votre propre Vendor ID auprès de l’USB Implementers Forum.

Je vous suggère d’activer également l’option --enable-factory-reset, qui rend possible la ré-initialisation du jeton OpenPGP après blocage (certes, si vous bloquez votre jeton vous pouvez toujours le re-flasher contrairement à une carte OpenPGP physique, mais utiliser la commande factory-reset de GnuPG est quand même plus simple).

Selon vos besoins, activez également l’option --enable-certdo, qui rend possible le stockage d’un certificat X.509 directement sur le jeton.

$ ./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   

À l’issue de la compilation, vous devez obtenir deux fichiers build/gnuk.elf et build/gnuk.bin. Le premier est l’exécutable au format ELF généré par le compilateur, le second est une version binaire « brute ». Vous aurez besoin de l’un ou l’autre selon la méthode utilisée pour flasher votre FST-01.

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 le schéma :

  • 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).

schéma FST-01
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 (puis réactive la protection de la mémoire). Notez que cette commande attend un fichier binaire (build/gnuk.bin), pas un fichier au format ELF.

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.

Attention

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

Émuler Gnuk/NeuG sous GNU/Linux

En plus des cibles matérielles listées plus haut, Gnuk et NeuG peuvent fonctionner sous GNU/Linux en émulant un périphérique USB. Cela n’apporte bien sûr aucun des bénéfices que fournit l’utilisation d’un vrai périphérique (par exemple, dans le cas de Gnuk, ça ne met pas les clefs privées hors d’atteinte du système hôte ; dans le cas de NeuG, ça ne constitue pas une source physique d’entropie), mais peut être utile à des fins de développement et de tests. Dans le cas de Gnuk, ça peut notamment représenter un moyen simple d’essayer sans frais une pseudo-carte OpenPGP.

L’émulation repose sur le protocole USB/IP, normalement conçu pour permettre le partage de périphériques à travers le réseau mais légèrement détourné dans le cas présent, les programmes Gnuk ou NeuG se faisant passer pour un serveur USB/IP exportant un pseudo-périphérique.

Pour tester ce mode émulation, assurez-vous d’abord que les modules usbip-core et vhci-hcd sont chargés :

# modprobe usbip-core
# modprobe vhci-hcd

Puis, assurez-vous que vous disposez du programme client usbip. S’il n’est pas fourni par votre distribution, vous le trouverez dans les sources du noyau Linux, dans le répertoire tools/usb/usbip.

Rendez-vous alors dans les sources de Gnuk et compilez le programme en choisissant pour cible GNU_LINUX :

$ cd gnuk/src
$ ./configure --target=GNU_LINUX
Header file is: board-gnu-linux.h
Debug option disabled
Configured for bare system (no-DFU)
PIN pad option disabled
CERT.3 Data Object is NOT supported
Card insert/removal by HID device is NOT supported
Life cycle management is NOT supported
$ make

À l’issue de la compilation, vous devez obtenir un exécutable build/gnuk.

Avant de pouvoir vous en servir, vous devez préparer un fichier qui représentera la mémoire Flash de votre pseudo-périphérique Gnuk. Le script gnuk/tool/gnuk-emulation-setup fera ça pour vous :

$ ../tool/gnuk-emulation-setup mon-image-flash

Lancez l’émulateur en lui passant en paramètres les identifiants de périphérique USB à utiliser ainsi que l’image que vous venez de créer :

$ ./build/gnuk --vidpid=234b:0000 mon-image-flash

Maintenant que l’émulateur tourne, le client usbip doit vous indiquer la présence d’un serveur USB/IP sur l’adresse locale, exportant un seul périphérique :

# usbip list --remote=127.0.0.1
Exportable USB devices
======================
 - 127.0.0.1
        1-1: unknown vendor : unknown product (234b:0000)
           : /sys/devices/pci0000:00/0000:00:01.1/usb1/1-1
           : (Defined at Interface level) (00/00/00)

« Attachez » ce périphérique pour le rendre disponible sur votre machine :

# usbip attach --remote=127.0.0.1 --busid=1-1

Et voilà. Vous pouvez expérimenter avec votre (pseudo-)périphérique comme si vous aviez un vrai périphérique connecté à votre ordinateur. Par exemple, demandez à GnuPG de vous donner les détails du jeton :

$ gpg --card-status
Reader ...........: Free Software Initiative of Japan Gnuk (FSIJ-1.2.10-EMULATED) 00 00
Application ID ...: D276000124010200FFFEF1420A7A0000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: F1420A7A
Name of cardholder: [not set]
Language prefs ...: [not set]
Salutation .......:
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key ...: [none]
Authentication key: [none]
General key info .: [none]

Pour « débrancher » votre pseudo-périphérique :

# usbip detach --port=0

La procédure pour émuler NeuG au lieu de Gnuk est identique, à cela près que l’émulateur NeuG n’a pas besoin d’un fichier représentant la mémoire Flash du microcontrôleur — NeuG n’a aucun état à stocker dans ladite mémoire, contrairement à Gnuk.

Aller plus loin

  • # Excellent article. Quelques précisions et ajouts

    Posté par . Évalué à 10.

    Bonjour,

    Excellent article qui m'a encore appris de nouvelles choses.

    Je vous propose quelques modestes ajouts et précisions :

    • ajoutez dans les circuits STM32 les clones ST-LINK V2, plus particulièrement ceux de type MX-LINK-V2 version 2018-02-18 qui sont construits autour d'un STM32F103VBU6 (72Mhz) au lieu d'un STM32F101CBT6 (36 Mhz) pour les autres. Leur protection en aluminium est particulièrement appréciable pour un usage quotidien (Option ST-DONGLE de Gnuk ou Neug). https://wiki.cuvoodoo.info/doku.php?id=jtag

    • précisez que plusieurs de options proposées comme les courbes Curve25519, l'option KDF-DO, l'option enable-factory-reset nécessitent une version très récente de GnuPG comme la 2.2.6.
      Le README de Gnuk 1.2.10 précise : "It has supports of EdDSA, ECDSA (with NIST P256 and secp256k1), and ECDH (with X25519, NIST P256 and secp256k1), but this ECC feature is somehow experimental, and it requires modern GnuPG 2.2 with libgcrypt 1.7.0 or later. It supports new KDF-DO feature. Please note that this is experimental. To use the feature, you need to use newer GnuPG (2.2.6 or later)"
      Or, plusieurs distributions Linux dont les plus célèbres (Debian stable, LinuxMint..) ne sont pas encore en version 2.2.x.

    • précisez pour les nouveaux venus que la courbe Curve25519 bénéficie d'une "confiance" accrue sur P-256 dans la mesure ou elle n'a pas été conçu par le NIST américain et que c'est cet aspect qui la rend si populaire et demandée bien qu'elle soit de "même résistance" : clefs elliptique de 256 bits.

    • dans les manques de GNuk, on a aussi le support d'un bouton de validation qui fait partie de la spécification OpenPGP card 3.3.1 : https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.3.pdf § 4.1.3 :"If the card supports additional hardware like buttons or fingerprint sensors for special user interaction EF.ATR/INFO should contain the
      General feature management DO ('7F74')
      "

    Enfin, le projet SmartPGP (OpenPGP pour JavaCard) de l'ANSSI a une "issue" ouverte pour le support de Curve25519.

    Bien cordialement.

    • [^] # Re: Excellent article. Quelques précisions et ajouts

      Posté par (page perso) . Évalué à 10.

      Excellent article qui m'a encore appris de nouvelles choses.

      Merci.

      Je vous propose quelques modestes ajouts et précisions :

      Une fois la dépêche publiée il ne m’appartient plus de la modifier, mais c’est à ça que servent les commentaires. :)

      plusieurs de options proposées comme les courbes Curve25519, l'option KDF-DO, l'option enable-factory-reset nécessitent une version très récente de GnuPG comme la 2.2.6.

      Seule l’option KDF-DO nécessite GnuPG 2.2.6 (sortie en avril 2018). L’option factory-reset ou la prise en charge des courbes elliptiques (y compris la courbe 25519) font partie des fonctionnalités introduites dans la branche de développement GnuPG 2.1 (par exemple, version 2.1.1 en décembre 2014 pour factory-reset) et à ce titre sont présentes depuis le début de la branche 2.2 sortie en août dernier.

      Or, plusieurs distributions Linux dont les plus célèbres (Debian stable, LinuxMint..) ne sont pas encore en version 2.2.x.

      Hélas, et il est grand temps que ça change. J’ai pris le parti de ne plus jamais parler des branches obsolètes et plus maintenues de GnuPG. Aujourd’hui, GnuPG, c’est GnuPG 2.2.

      Pour rappel ou information, les branches 2.0/2.1 ne reçoivent plus aucune mise à jour de la part des développeurs de GnuPG, y compris en cas de faille critique. Si une distribution continue à fournir une version 2.0/2.1, il appartiendra seulement aux mainteneurs de ladite distribution de rétroporter ce qui doit l’être.

      précisez pour les nouveaux venus que la courbe Curve25519 bénéficie d'une "confiance" accrue sur P-256 dans la mesure ou elle n'a pas été conçu par le NIST américain et que c'est cet aspect qui la rend si populaire et demandée bien qu'elle soit de "même résistance"

      Pas seulement. En fait, d’après Bernstein and Lange (2016) (full disclosure : Daniel J. Bernstein est l’un des principaux auteurs derrière la courbe 25519), les soupçons de manipulation de la part du NIST ne seraient même pas le véritable problème des courbes du NIST, qui de par leur conception sont intrinsèquement beaucoup plus susceptibles à toutes sortes d’attaques par canaux cachés (ce qui à mon humble avis reflète simplement le fait que ces courbes ont été conçues il y a une vingtaine d’années, au tout début de la cryptographie ECC — la courbe 25519 est « meilleure » non pas parce qu’elle n’a pas été manipulée, mais parce qu’elle bénéficie des progrès des quinze dernières années de recherche dans le domaine).

      • [^] # Re: Excellent article. Quelques précisions et ajouts

        Posté par . Évalué à 6.

        Bonjour,

        Seule l’option KDF-DO nécessite GnuPG 2.2.6 (sortie en avril 2018). L’option factory-reset ou la prise en charge des courbes elliptiques (y compris la courbe 25519) font partie des fonctionnalités introduites dans la branche de développement GnuPG 2.1 (par exemple, version 2.1.1 en décembre 2014 pour factory-reset) et à ce titre sont présentes depuis le début de la branche 2.2 sortie en août dernier.

        En fait, mon commentaire concernait l'utilisation des options présentées avec Gnuk.

        S'il est facile, avec GnuPG 2.2.x de choisir facilement la génération de clefs RSA ou EC sur les clefs Gnuk, ce n'est pas le cas avec GnuPG 2.1.x (nécessité de forcer au préalable la génération de clefs elliptiques comme expliqué ici https://www.nitrokey.com/news/2017/nitrokey-start-supports-elliptic-curves-ecc)

        De plus, GPG 2.1.11 (ex LinuxMint 18 LTS/Debian Stretch, Ubuntu 17.10 LTS maintenu -> 2022) ne connaît pas les clefs x25519 (chiffrement).

        Une commande gpg2 --card-status sur une clef GNUK contenant des clefs Curve 25519 donne :

        • "Key attributes : ed25519 (null) ed25519"
        • au lieu de "Key attributes …: ed25519 x25519 ed25519" avec GnuPG 2.2.x

        Pas seulement. En fait, d’après Bernstein and Lange (2016) (full disclosure : Daniel J. Bernstein est l’un des principaux auteurs derrière la courbe 25519), les soupçons de manipulation de la part du NIST ne seraient même pas le véritable problème des courbes du NIST, qui de par leur conception sont intrinsèquement beaucoup plus susceptibles à toutes sortes d’attaques par canaux cachés (ce qui à mon humble avis reflète simplement le fait que ces courbes ont été conçues il y a une vingtaine d’années, au tout début de la cryptographie ECC — la courbe 25519 est « meilleure » non pas parce qu’elle n’a pas été manipulée, mais parce qu’elle bénéficie des progrès des quinze dernières années de recherche dans le domaine)

        Mon observation portait sur le fait que la courbe Curve25519 fait l'objet de choix plutôt expliqués et documentés, ce qui n'est pas le cas des courbes du NIST comme des courbes ANSSI (https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000024668816), pourtant assez récentes : 2011.
        Courbes dont le choix des paramètres est "obscure" et laisse à penser qu'il peut y avoir "manipulation" comme expliqué ici §4.1.1 : https://connect.ed-diamond.com/MISC/MISCHS-013/Standardisation-des-courbes-elliptiques-a-qui-faire-confiance

        Je comprends parfaitement votre position de ne parler que de la version récente et maintenue de GnuPG (2.2.x) mais ayant été confronté au problème GnuPG 2.1.x par défaut sur ma distribution, je pense qu'il est préférable d'insister sur le fait que l'article n'est valable qu'à partir de GnuPG 2.2.x minimum,pour toutes personnes commençant à s'intéresser au sujet.

        Bien cordialement

        • [^] # Re: Excellent article. Quelques précisions et ajouts

          Posté par (page perso) . Évalué à 6.

          S'il est facile, avec GnuPG 2.2.x de choisir facilement la génération de clefs RSA ou EC sur les clefs Gnuk, ce n'est pas le cas avec GnuPG 2.1.x (nécessité de forcer au préalable la génération de clefs elliptiques comme expliqué ici https://www.nitrokey.com/news/2017/nitrokey-start-supports-elliptic-curves-ecc)

          Ça ne concerne que la génération de clefs directement sur le jeton, une option dont j’ai décidé de ne pas parler puisque c’est une mauvaise idée selon moi en raison de l’impossibilité d’avoir une sauvegarde des clefs ailleurs que sur le jeton.

          Mon observation portait sur le fait que la courbe Curve25519 fait l'objet de choix plutôt expliqués et documentés, ce qui n'est pas le cas des courbes du NIST comme des courbes ANSSI […]. Courbes dont le choix des paramètres est "obscure" et laisse à penser qu'il peut y avoir "manipulation

          J’ai bien compris. Mon point est qu’il y a d’autres raisons de préférer la courbe 25519 aux courbes du NIST (ou de l’ANSSI), basées sur les seules propriétés de ces courbes, sans qu’il ne soit nécessaire de spéculer sur ce qu’a fait ou aurait pu faire le NIST.

          On ne sait pas si les courbes du NIST ont été manipulées, mais on sait qu’elles sont par nature difficile à implémenter de façon sécurisée et potentiellement vulnérables à toutes sortes d’attaques par canaux cachés.

      • [^] # Re: Excellent article. Quelques précisions et ajouts

        Posté par (page perso) . Évalué à 6.

        Deux points de pinaillage concernant les deux messages précédents :

        précisez pour les nouveaux venus que la courbe Curve25519 bénéficie d'une "confiance" accrue sur P-256 dans la mesure ou elle n'a pas été conçu par le NIST américain et que c'est cet aspect qui la rend si populaire et demandée bien qu'elle soit de "même résistance" : clefs elliptique de 256 bits.

        Curve25519 offre 128 bits de sécurité équivalent symétrique, pas 256.

        En fait, d’après Bernstein and Lange (2016) (full disclosure : Daniel J. Bernstein est l’un des principaux auteurs derrière la courbe 25519)

        Pour être totalement full : DJB est bien l'auteur de la courbe, mais il faut rajouter que la la co-autrice de l'article, Tanja Lange, est sa femme à la vie publique.

        Mes messages engagent qui je veux.

      • [^] # Re: Excellent article. Quelques précisions et ajouts

        Posté par . Évalué à 1.

        Et entre les courbes Brainpool P-* et Curve 25519, quelles sont les différences et a priori les plus fiables ?

        Je souhaiterais changer mes vieilles clefs RSA pour d'autres en courbes elliptiques. Quel type de courbe serait le plus approprié a priori ? (compatibilité mise à part)

        • [^] # Re: Excellent article. Quelques précisions et ajouts

          Posté par (page perso) . Évalué à 4.

          Et entre les courbes Brainpool P-* et Curve 25519, quelles sont les différences

          Grosso modo les mêmes qu’entre la NIST P-256 et la Curve25519.

          Les courbes du NIST et les courbes Brainpool sont similaires. Elles sont décrites par une équation de Weierstrass dans les deux cas, seuls les paramètres étant différent :

          • NIST P-256: y² = x³ − 3x + 41058363725152142129326129780047268409114441015993725554835256314039467401291
          • BrainpoolP256: y² = x³ − 3x + 46214326585032579593829631435610129746736367449296220983687490401182983727876

          La vraie différence entre les deux réside dans la méthode utilisée pour générer les paramètres de la courbe. Le NIST a généré ses paramètres en condensant une graine sortie de nulle part (d’où les soupçons de manipulation évoqués plus haut : et si le NIST avait choisi cette graine en sachant que la courbe résultante était vulnérable à une attaque connue seulement de la NSA ?), alors que la graine utilisée pour la courbe Brainpool a été choisie selon une procédure décrite en annexe du RFC 5639.

          Personnellement, je ne vois pas vraiment d’intérêt aux courbes Brainpool. Mise à part le fait que leur génération est plus transparente, elles souffrent a priori des mêmes défaut que celles du NIST.

          La courbe 25519, elle, est décrite par une équation de Montgomery (y² = x³ + 486662x² + x). Entre autres avantages, cette forme permet de réaliser des opérations sur la courbe en temps constant, éliminant une source d’attaques par canaux cachés.

  • # Plus qu'à en commander

    Posté par (page perso) . Évalué à 4.

    Bonjour,

    Alors je connaissais les Yubikey, les Nitrokey, mais je ne savais pas qu'il existait une telle alternative libre :-) Merci pour l'article, j'ai appris énormément de choses (principalement sur les moyens de protéger les clés privées stockées)

    Malheureusement, enfin c'est le seul point négatif que je pourrais trouver, le matériel n'est pas Open Hardware (à ma connaissance, corrigez-moi si c'est le cas). Bien sûr, c'est une super initiative quand-même !

    • [^] # Re: Plus qu'à en commander

      Posté par . Évalué à 10.

      Bonjour,

      Tout dépend de ce que vous appelez de l'Open Hardware. Si c'est de n'avoir que des composants conçus et publié en "Open Hardware" ce n'est effectivement pas OpenHardware.
      Pour ce qui est du FST-01 ou de clef comme les ST-LINK-V2, le matériel se limite à un processeur STM32F1.x dont les spécifications et la documentation sont disponibles. Ce n'est pas forcément le cas de clefs comme certaines Yubikey qui utilisent des composants dont les spécifications sont uniquement disponible après une clause de non divulgation (NDA); c'est le cas pour certains compsant de sécurité.

  • # Comment choisir ?

    Posté par . Évalué à 5.

    Excellent article encore. Merci

    Cet article arrive à point, j'allais justement passer commande chez Nitrokey. Je me demande maintenant si je ne vais pas plutôt passer par la FSF même si le prix est quand même bien supérieur ($50 à la FSF, 29€ pour la NitroKey Start). Pourquoi avoir pris la clé de la FSF plutôt que la Start ? Referais-tu ce choix aujourd'hui ?

    J'aimerai mettre ma clé primaire sur un token aussi pour que ma clé ne soit jamais accessible. Est-ce que ça vaut le coût de payer un deuxième token (surtout s'il coûte $50) ?

    • [^] # Re: Comment choisir ?

      Posté par (page perso) . Évalué à 8.

      Pourquoi avoir pris la clé de la FSF plutôt que la Start ? Referais-tu ce choix aujourd'hui ?

      À vrai dire je n’ai rien choisi du tout, mon FST-01 m’a été offert en personne par Werner Koch. :)

      Si je devais choisir aujourd’hui, entre la Nitrokey Start et le FST-01 mon choix se porterait probablement toujours sur ce dernier, pour plusieurs raisons :

      a) À titre personnel, j’apprécie que le FST-01 soit de conception libre.

      b) Une des choses qui me dérangent avec la Nitrokey Start est que Nitrokey ne donne pas beaucoup d’informations sur la version de Gnuk utilisée et les options de compilation choisies.

      Sur la version, la seule information que j’ai trouvée est cette annonce de l’année dernière qui mentionne Gnuk 1.2 datant de mai 2016. Les Nitrokey Start en production actuellement utilisent-elles toujours cette version, ou bien sont-elles passées à une version plus récente ? À ma connaissance cette information n’est disponible nulle part.

      c) Je ne suis pas certain que la fonctionnalité de mise à jour « à chaud » (via reGNUal, comme expliqué dans la dépêche) soit utilisable sur la Nitrokey Start (et encore une fois, Nitrokey ne fournit aucune info).

      (J’exclus le critère du prix, le FST-01 de la FSF et la Nitrokey Start n’étant pas vraiment comparable à mon sens : on a d’un côté un produit commercial fini vaisemblablement produit en relativement grande quantité, de l’autre un « goodie » dont le principal but est de supporter financièrement la FSF.)

      À noter que si je devais me procurer un jeton Gnuk aujourd’hui, j’envisagerais sérieusement une troisième option : acheter un deuxième débogueur ST-Link/V2 et le convertir en jeton.

      J'aimerai mettre ma clé primaire sur un token aussi pour que ma clé ne soit jamais accessible. Est-ce que ça vaut le coût de payer un deuxième token (surtout s'il coûte $50) ?

      Pourquoi pas, mais si tu veux mettre ta clef primaire sur un jeton tu peux aussi te passer d’avoir une sous-clef de signature (la clef primaire est par défaut utilisable pour signer, sauf si tu as explicitement demandé à GnuPG de générer une clef primaire utilisable seulement pour certifier) et mettre ta clef primaire dans le slot de signature de la carte OpenPGP.

  • # Gniibe préfère aussi le hard générique et documenté

    Posté par . Évalué à 5.

    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.

    J'ai lu (il me semble) dans les publications de Gniibe qu'il préférait également l'utilisation d'un STM32 « standard » plutôt que d'un autre chip spécialement orienté crypto avec des fonctions « spécialisées » (et fermées), car il expliquait qu'on ne sait jamais ce que ça cache, et que ça finit toujours par être craqué un jour. Il est très orienté « liberté avant le reste », et comme tu le dis bien, la liberté et la documentation est préférable à tout autre argument de sécurité, même si le choix peut sembler moins sécurisé au début. Je partage cet avis aussi.

    Et pour l'anecdote, j'ai connu GnuK à l'époque où pour le tester seul le kit Discovery STM8S était vraiment accessible niveau prix (et ça le reste encore : 7,55 € chez Farnell, mais la différence avec le F103 est négligeable aujourd'hui) :
    https://www.st.com/en/evaluation-tools/stm8s-discovery.html
    Oui, le chip est un 8 bit, mais le chip qui fait l'interface UART-USB est un STM32F103, beaucoup plus puissant que la cible en question… Il contient moins de flash que le kit Nucleo, mais Gniibe a rajouté un hack car à priori, il aurait plus de flash que ce qu'indique la datasheet (perso, j'ai un patch pour désactiver des bouts afin que ça tienne dedans). Bon, ça reste un peu galère (en plus du port USB B assez gros), et je suis passé par un BusPirate pour le flash SWD, mais c'est drôle et pas cher.

    • [^] # Re: Gniibe préfère aussi le hard générique et documenté

      Posté par (page perso) . Évalué à 4.

      J'ai lu (il me semble) dans les publications de Gniibe qu'il préférait également l'utilisation d'un STM32 « standard » plutôt que d'un autre chip spécialement orienté crypto avec des fonctions « spécialisées » (et fermées), car il expliquait qu'on ne sait jamais ce que ça cache, et que ça finit toujours par être craqué un jour. Il est très orienté « liberté avant le reste »

      Je confirme, c’est également ce qui ressort de ses interventions sur les listes de GnuPG et de Gnuk.

      • [^] # Re: Gniibe préfère aussi le hard générique et documenté

        Posté par . Évalué à 3. Dernière modification le 13/07/18 à 09:47.

        Une fois, j'avais entendu parler d'un "hash hardware" sur un SoC, mais c'était simplement un bloc AES, or AES est connu pour être une mauvaise fonction de hachage. Le truc a été cassé.

        "La première sécurité est la liberté"

  • # Excellent article et question de béotien

    Posté par . Évalué à 6.

    Je vous remercie pour cet article très complet et très pédagogique.

    Je voudrai néanmoins savoir quel est l'avantage d'une telle clef sur une simple clef USB chiffrée avec luks et contenant les clefs GnuPG ? En effet, j'ai l'impression que pour un "débutant" la solution clef USB luks me semble plus facile à utiliser.

    • [^] # Re: Excellent article et question de béotien

      Posté par (page perso) . Évalué à 9.

      Je voudrai néanmoins savoir quel est l'avantage d'une telle clef sur une simple clef USB chiffrée avec luks et contenant les clefs GnuPG ?

      Principalement deux :

      D’abord et surtout, avec une carte OpenPGP les clefs privées sont et restent stockées sur la carte, l’ordinateur hôte ne les voit jamais, même temporairement.

      Ensuite, GnuPG a un support explicite pour la carte OpenPGP (qu’elle soit implémentée sous la forme d’une « vraie » carte à puce ou sous la forme d’un jeton USB comme Gnuk), ce qui rend l’utilisation de ce type de carte très facile (en gros, dès lors que GnuPG a besoin d’une clef privée, il demande à l’utilisateur d’insérer sa carte et de saisir son PIN, et il se débrouille avec le reste ; on peut difficilement faire plus facile). Alors qu’avec un support de stockage chiffré par LUKS et contenant les clefs privées, c’est à toi qu’il revient de faire en sorte que GnuPG sache où trouver les clefs privées quand il en a besoin.

  • # Petites typos

    Posté par (page perso) . Évalué à 2. Dernière modification le 02/07/18 à 14:24.

    Merci pour l'article.

    Dans le paragraphe de 4ème NeuG, le générateur de nombres aléatoires

    … assurez-vous d’avoir accès en périphérique au lecture et en …

    … assurez-vous d’avoir accès au périphérique en lecture et en …

    Dans le 5ème paragraphe de Émuler Gnuk/NeuG sous GNU/Linux

    Rndez-vous alors dans les sources de Gnuk et …

    R*e*ndez-vous alors dans les sources de Gnuk et …

    • [^] # Re: Petites typos

      Posté par (page perso) . Évalué à 3.

      Corrigé, merci.

    • [^] # Re: Petites typos

      Posté par . Évalué à 3.

      Je pense que cette ligne

      $ sudo ./neug_upgrade.py ../../gnuk/regnual/regnual/bin ../../gnuk/src/build/gnuk.bin

      devrait être corrigé pour contenir ../../gnuk/regnual/regnual.bin plutôt que ../../regnual/regnual/bin.

  • # euh...

    Posté par . Évalué à 5.

    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épiautant la puce et en allant directement lire la valeur des bits au microscope.

    Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret, car il est trop facile de détruire la puce pendant le processus. Ce n'est pas le cas d'un chip normal.

    Une carte à puce dispose d'un "shield", une grille que l'on doit "dériver" pour accéder au bus de la FLASH. Une protection de l'alimentation et des pin d'entré pour éviter les glitchs. Ils disposent aussi de capteur de laser qui détruit la mémoire, pour éviter l'injection de faute. Les mémoires internes sont cryptés. Des secrets peuvent être en dur, (genre fonction de dérivation de clef qui ajoute un grand nombre). Si vous voulez ce nombre pour avoir l'algo de dérivation de clef complet, il faut faire du reverse hardware ou avoir des bons contacts dans le service de sécurité du fabricants.

    "La première sécurité est la liberté"

    • [^] # Re: euh...

      Posté par (page perso) . Évalué à 2.

      Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret

      Oui mais non. Je ne suis pas spécialiste de la question, mais tous les papiers que j’ai eu l’occasion de lire sont d’accord pour dire que les protections des cartes à puce compliquent l’extraction des données et peuvent la rendre très chère (peut-être suffisamment pour la rendre hors de portée de la plupart des attaquants à part les « attaquants de classe III », i.e. les well-funded organisations), mais personne ne prétend que ça rend l’extraction impossible (à part peut-être les constructeurs de cartes à puce).

      Au final, c’est juste de la sécurité par l’obscurité.

      • [^] # Re: euh...

        Posté par . Évalué à 3.

        Pour avoir bosser pour le labo de canal+ sur le sujet, je peux dire qu'il y a un monde entre une carte à puce, et un microcontrôleur classique. Bien sur, je ne dirais pas que c'est impossible, mais conceptuellement être capable de sortir un secret d'une carte à puce particulière (et non un secret identique recopié sur 20 puces), c'est vraiment très compliqué, avoir un FIB, un LSM, un AFM, un microscope électronique, n'aide pas vraiment.

        Pour faire ça, il faut connaitre parfaitement le modèle de la puce elle-même, voir si elle a une faiblesse. Ensuite, il vaut mieux avoir une autre clef avec le logiciel utilisé dans la cible, pour voir si le soft à une faiblesse. Et ensuite, s'attaquer à la clef cible en question, sachant qu'il y a une haute proba de destruction.

        Dans un microcontrôleur, il suffit souvent d'utiliser le JTAG.

        La sécurité est forcément par la sécurité car chaque mesure est imparfaite. L'exemple du shield est intéressant. Ils ont fait une version avec un registre il fallait lire et écrire dedans pour voir si un fil était coupé. Mais cela laissait quelques milliers de cycle à l'allumage sans protection. Ensuite, ils ont fait des "versions analogiques" qui mesuraient la résistance du shield pour détecter un by-pass. L'emplacement des détecteurs de laser n'est pas connu, cela oblige l'attaquant a cartographier la puce, pour ne pas taper dedans. Si une sécurité repose sur un nombre secret, si il est connu, cela ne marche plus (clef de chiffrage de la mémoire, ou autre), etc…

        Le comportement du CMOS est connu, c'est presque une boite blanche, le seul moyen de planquer quelques choses dedans, c'est de faire une boite et de faire grossir la meule de foin.

        "La première sécurité est la liberté"

      • [^] # Re: euh...

        Posté par (page perso) . Évalué à 2.

        Au final, c’est juste de la sécurité par l’obscurité.

        qui coûte des centaines de fois plus cher à casser que l'espérance de gain.
        Donc ça fonctionne très bien.

        Les attaques se font par d'autres canaux. Et ça fonctionne très bien aussi :-)

        • [^] # Re: euh...

          Posté par . Évalué à 3.

          Tu penses à quel genre d'attaque concernant des systèmes protégés par carte à puce ? En général, les attaques les plus bête sont simplement un bug dans le soft de gestion. J'ai mis vu des implémentations hardware du driver de lien série pour éviter des attaques dessus (genre glitch d'alimentation sur la fonction qui demande la version (une string) qui permet de faire sauter le test de fin de boucle de copie de la string pour continuer de lire la suite de la mémoire).

          "La première sécurité est la liberté"

          • [^] # Re: euh...

            Posté par (page perso) . Évalué à 1.

            Tu penses à quel genre d'attaque concernant des systèmes protégés par carte à puce ?

            À toutes celles qui ne font pas appel à la protection de la puce. :-)
            La mini-caméra au dessus du distributeur, le coup de boule pour récupérer le contenu d'un portefeuille, le vol de CB en serrant le cou de mémé tant qu'elle ne crache pas le code, les yes-card à 100 €, etc etc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.