Jeton cryptographique de dépannage avec Gnuk

Après avoir commencé à étendre l’usage de mes clefs gpg via Yubikey à différents aspects de mon informatique, se pose la question de la résilience du système. Que faire en cas de perte, détérioration ou malfonction de l’outil qui sert à accéder à mon répertoire de mot de passe et à me connecter à mes serveurs. L’idéal reste de posséder une seconde Yubikey NFC vierge en réserve, pour pouvoir redéployer rapidement ses clefs de sécurité à partir de l’une des sauvegardes que l’on aura pris soin d’effectuer. Une autre solution consiste à détourner un matériel de son usage premier pour en faire une clé de sécurité prête à accueillir mes clés le temps d’effectuer la transition vers une nouvelle Yubikey, ou un autre support du même type.

Pour répondre à ce besoin, j’ai découvert un programme nommé Gnuk, qui permet de transformer un microcontrôleur de type STM32F103 en une clé de sécurité supportant le protocole OpenPGP card version 2. Il se trouve que ce type de processeur équipe les cartes de programmation ST-Linkv2 et qu’on trouve ces dernières pour moins de 2 euros sur Aliexpress. Afin de réaliser quelques tests, j’en ai donc commandé trois chez deux vendeurs différents et j’ai reçu l’ensemble des cartes après environ deux dizaines de jours. Il faut un minimum de deux ST-Linkv2, car l’un sera utilisé pour programmer l’autre.

Une fois en possession des ST-Linkv2, je commence donc par retirer leur boîtier métallique afin d’avoir accès à la carte. Je vérifie la version du microcontrôleur équipant les cartes: STM32F103C8T6, ça ne devrait pas poser de problème. En examinant les cartes, je constate que j’ai reçu deux modèles différents, l’un avec des pastilles métalliques, l’autre avec des trous pour l’accès au processeur. Autre point gênant que je constaterai lors de mes premiers essais de reprogrammation du processeur, l’alternance des « pins » de connexion au bout du ST-Link au boîtier rouge ne correspond pas à ce qui est inscrit sur le boîtier, attention donc en branchant les câbles, de bien vérifier directement sur le PCB à quoi correspond chaque pin.

Avant de s’intéresser au câblage et à la reprogrammation, je commence donc par récupérer les éléments nécessaires à la compilation du programme.

sudo pacman -S arm-none-eabi-binutils arm-none-eabi-gcc arm-none-eabi-newlib arm-none-eabi-gdb
git clone https://salsa.debian.org/gnuk-team/gnuk/gnuk.git
cd gnuk/
git submodule update --init

On peut ensuite passer à la compilation de Gnuk.

./configure --vidpid=234b:0000 --target=ST_DONGLE
make
make build/gnuk-vidpid.bin

Passons à l’étape de câblage. Le principe est relativement simple sur le papier (ou sur l’écran), connecter les sorties SWDIO, GND, SWCLK et 3V3 de la carte qui servira à programmer, aux entrées SWDIO, GND, SWCLK et 3V3 présentes sur la carte cible. Si les entrées ne sont pas nommées sur la carte, leur ordre est à priori le suivant (en commençant par le plus proche du connecteur USB): SWDIO, GND, SWCLK, 3V3. Pour ma part, j’ai dû faire preuve d’un peu d’astuce pour connecter le tout, ne disposant pas de matériel spécifique pour me connecter sur les pastilles métalliques (Existe-t-il un tel matériel ?) et impossible de faire connecter les câbles sur la version de la carte à trou : trous trop petits ou pointe métallique des fils trop épaisses, au choix. J’ai bien envisagé de sortir le fer à souder pour raccorder le tout, mais la perspective de tout devoir dés-souder ensuite m’a poussé à chercher une autre solution. Solution qui a donc pris la forme suivante :

Maintenant que mes ST-Link sont connectés, je peux donc passer à la dernière étape, à savoir reprogrammation de la carte cible. Je commence donc par installer openocd pour interagir avec le programmateur.

sudo pacman -S openocd

Puis vient l’étape de connexion, dont voici un retour indiquant une réussite de connexion.

$ sudo openocd -f interface/stlink-v2.cfg -f target/stm32f1x.cfg
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read 
  http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v31 API v2 SWIM v7 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.175194
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints

Tout est prêt pour commencer la reprogrammation. On établit une liaison telnet en local sur le port 4444 afin d’envoyer nos instructions à la carte de programmation.

telnet localhost 4444

Puis place aux instructions (depuis le dossier gnuk):

halt
stm32f1x unlock 0
reset halt
flash write_bank 0 ./src/build/gnuk-vidpid.bin 0
stm32f1x lock 0
reset halt

Voici le contenu des logs dans le terminal exécutant openocd dans le cas d’une programmation réussi.

Info : accepting 'telnet' connection on tcp/4444
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x08002246 msp: 0x20000794
Info : device id = 0x20036410
Warn : STM32 flash size failed, probe inaccurate - assuming 128k flash
Info : flash size = 128kbytes
Info : Device Security Bit Set
target halted due to breakpoint, current mode: Handler HardFault
xPSR: 0x61000003 pc: 0x2000003a msp: 0x20000794stm32x unlocked.
INFO: a reset or power cycle is required for the new settings to take effect.
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffcwrote 109568 bytes from file ./src/build/gnuk-vidpid.bin to flash bank 0 at offset 0x00000000 in 3.311114s (32.315 KiB/s)
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000003a msp: 0xfffffffcstm32x locked
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000250 msp: 0x20005000
Info : dropped 'telnet' connection

On peut alors débrancher la carte cible, la brancher dans un port USB et vérifier que celle-ci est bien détectée par gpg.

$ sudo gpg --card-status
Reader ...........: 0000:0000:FSIJ-1.2.14-XXXXXXXX:0
Application ID ...: D276000124010200FFFEXXXXXXXX0000
Version ..........: 2.0
Manufacturer .....: unmanaged S/N range
Serial number ....: XXXXXXXX
Name of cardholder: [non positionné]
Language prefs ...: [non positionné]
Sex ..............: non indiqué
URL of public key : [non positionné]
Login data .......: [non positionné]
Signature PIN ....: forcé
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
KDF setting ......: off
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]

À l’issue de ces opérations, je dispose d’une clé prête à accueillir mes clefs GPG en cas de problème avec ma clé de sécurité principale. Il reste bien évidemment à valider le processus de réécriture des clefs sur la nouvelle clé, mais celle-ci étant détectée correctement, cela ne devrait pas soulever de difficulté particulière. Les possibilités offertes par Gnuk et le détournement du ST-Linkv2 sont à creuser, mais on pourrait envisager de laisser une telle clé branchée en permanence sur son PC fixe, avec bien sûr tous les risques de sécurité que cela comporte étant donné qu’on ne conserve plus la clé en permanence sur soi. De plus, le micro-contrôleur étant facilement accessible, on peut envisager qu’il soit plus facile de récupérer les clefs stockées que sur un autre jeton cryptographique. Dans le même style, il existe également un programme permettant de transformer un STM32F103 en clé U2F.

Source

• $2 USB crypto token for use with gpg and ssh – danman’ blog
• Gnuk on the ST-LINK v2
• GNUK – Wiki Debian