Génération de clés privées et qualité du hasard en cryptographie blockchain

Une clé privée est la pierre angulaire de la sécurité dans les systèmes blockchain. Sans elle, vous ne pouvez pas signer une transaction, prouver la propriété d’un actif numérique, ou accéder à vos fonds. Mais ce qui compte vraiment, ce n’est pas seulement d’avoir une clé privée - c’est comment elle a été générée. Si le hasard utilisé pour la créer est faible, votre clé peut être devinée, copiée, ou volée - même si vous utilisez Bitcoin, Ethereum ou tout autre protocole considéré comme « sécurisé ».

Pourquoi le hasard est plus important que l’algorithme

Beaucoup pensent que la sécurité vient du fait que la clé privée est générée avec un algorithme compliqué comme RSA ou ECDSA. Ce n’est pas vrai. L’algorithme est public. Tout le monde le connaît. Ce qui rend une clé inviolable, c’est la qualité du hasard utilisé pour la créer.

Imaginez que vous écriviez un mot de passe en utilisant des lettres tirées au sort. Si vous utilisez un dé à six faces pour choisir chaque lettre, vous avez très peu de combinaisons possibles. Un attaquant peut essayer toutes les possibilités en quelques minutes. Maintenant, imaginez que vous utilisez un générateur de nombres aléatoires qui tire des milliards de possibilités par seconde. C’est la différence entre une serrure de porte et une vault bancaire.

En cryptographie, on appelle cela l’entropie. Plus l’entropie est élevée, plus il est difficile de prédire ou de reproduire la clé. Pour une clé ECDSA utilisée dans Bitcoin (secp256k1), il faut au moins 128 bits d’entropie. Cela signifie qu’il y a 2^128 combinaisons possibles - un nombre si grand qu’il dépasse le nombre d’atomes dans la galaxie. Si vous avez moins de 100 bits, vous êtes dans une zone dangereuse. Moins de 64 bits ? Vous êtes presque certain d’être volé.

Comment les clés privées sont-elles vraiment générées ?

Sur votre ordinateur ou votre téléphone, la génération de clé privée ne se fait pas par magie. Elle dépend de sources physiques d’aléatoire : le moment exact où vous tapez sur le clavier, le bruit des disques durs, les variations de température du processeur, ou même les micro-délais entre les interruptions du système.

Linux, par exemple, utilise deux interfaces : /dev/random et /dev/urandom. La première bloque si l’entropie tombe en dessous de 128 bits - ce qui peut vous faire attendre des secondes, voire des minutes, sur un serveur sans souris ni clavier. La seconde, /dev/urandom, ne bloque jamais. Elle utilise une méthode plus intelligente : elle mélange l’entropie disponible avec des algorithmes cryptographiques pour produire des nombres qui semblent aléatoires, même si l’entropie initiale est faible. C’est ce que la plupart des systèmes modernes utilisent - y compris les portefeuilles blockchain comme MetaMask ou Ledger.

Le problème ? Les machines virtuelles, les conteneurs Docker, les serveurs headless (sans interface graphique), et les appareils embarqués comme les routeurs ou les Raspberry Pi n’ont pas accès à beaucoup de sources d’entropie. En 2012, une étude a montré que 0,75 % des certificats TLS sur Internet avaient des clés identiques - parce que les appareils ont été démarrés en même temps avec le même état d’entropie. Des routeurs entiers ont généré la même clé privée. Imaginez si c’était votre portefeuille Bitcoin.

Les erreurs courantes qui rendent vos clés vulnérables

Voici les trois erreurs les plus fréquentes que les développeurs et les utilisateurs font :

1. Générer une clé au démarrage d’un serveur - Si vous lancez un script qui génère une clé dès que le système démarre, vous êtes en train de tirer un nombre dans un réservoir d’entropie presque vide. Les serveurs cloud comme AWS Lambda ou Google Cloud Functions sont particulièrement vulnérables à cela.
2. Utiliser un générateur de nombres pseudo-aléatoires mal initialisé - Certains frameworks, surtout en JavaScript ou Python, utilisent Math.random() ou random.randint() pour générer des clés. Ce n’est pas cryptographiquement sûr. Ces fonctions sont conçues pour les jeux ou les simulations, pas pour la sécurité.
3. Copier des machines virtuelles - Si vous clonez une VM avec une clé privée déjà générée, vous dupliquez aussi l’état de l’entropie. Deux machines identiques = deux clés identiques. C’est un cauchemar pour la sécurité.

En 2021, un administrateur système a généré 10 000 clés RSA sur un serveur headless. 17 d’entre elles étaient identiques. Il n’avait pas installé haveged ou jitterentropy - des outils qui augmentent l’entropie en mesurant les micro-délais du processeur. Sans eux, le serveur n’avait pas assez de « bruit » pour créer des clés uniques.

Les solutions fiables : ce que font les pros

Les entreprises sérieuses ne prennent pas de risques. Elles utilisent :

• getrandom() sur Linux - Une appelle système introduite en 2014 qui garantit un accès sécurisé à l’entropie du noyau. C’est la méthode recommandée par NIST.
• BCryptGenRandom() sur Windows - Équivalent fiable pour les environnements Windows.
• Hardware Security Modules (HSM) - Des appareils physiques comme ceux de Thales ou YubiKey qui génèrent des clés avec des générateurs de nombres aléatoires vrais (TRNG). Ils coûtent entre 15 000 et 50 000 €, mais sont indispensables pour les banques, les exchanges et les fonds de pension.
• Cloudflare’s LavaRand - Une solution originale : des lampes à lave filmées par des caméras. Le mouvement aléatoire du liquide est converti en 1 024 bits d’entropie par image, puis traité par SHA-256. Cloudflare utilise ça pour générer des millions de clés par jour - sans aucun doublon.

Les portefeuilles logiciels comme Ledger et Trezor intègrent des puces sécurisées (Secure Element) qui isolent la génération de clé du reste du système. Même si votre ordinateur est infecté, la clé privée ne sort jamais de la puce.

Que faire si vous êtes un particulier ou un petit développeur ?

Vous n’avez pas besoin d’un HSM à 50 000 €. Voici ce que vous pouvez faire :

• Sur Linux : attendez que /proc/sys/kernel/random/entropy_avail dépasse 2048 bits. Vous pouvez le vérifier avec la commande cat /proc/sys/kernel/random/entropy_avail. Si c’est en dessous de 500, attendez ou lancez haveged.
• Sur Windows : utilisez toujours BCryptGenRandom() ou les bibliothèques comme libsodium - jamais Math.random().
• Sur un Raspberry Pi ou un serveur sans interface : installez haveged ou jitterentropy. Ce sont des services légers qui génèrent de l’entropie à partir des variations de performance du processeur.
• Ne générez jamais de clés dans un conteneur Docker ou une VM sans vérifier l’entropie. Utilisez rng-tools pour connecter un générateur externe.
• Si vous utilisez une bibliothèque comme OpenSSL, lisez la documentation. Beaucoup de gens utilisent RAND_bytes() sans le bien initialiser. Libsodium, en revanche, est plus simple et plus sûr pour les débutants.

Les tendances futures : la vérification du hasard

Un nouveau domaine émerge : la vérification du hasard. Comment savoir que votre clé privée a bien été générée avec suffisamment d’entropie, sans révéler la clé elle-même ?

Le protocole KEGVER (Key Generation with Verifiable Randomness), proposé par A. Juels en 2013, permet de prouver qu’une clé a été créée selon des règles strictes - sans montrer la clé. C’est comme prouver que vous avez bien mélangé un jeu de cartes sans montrer les cartes. Cloudflare a déjà mis en œuvre une version de ce protocole pour sa propre autorité de certification.

Le NIST travaille aussi sur de nouvelles normes pour la cryptographie post-quantique. Même si les ordinateurs quantiques ne menacent pas encore les clés RSA-2048 avant 2030, les exigences en matière d’entropie ne changent pas. Une clé quantiquement résistante générée avec un mauvais hasard reste une clé vulnérable.

Les chiffres qui parlent

• En 2023, 63,7 % des projets open-source génèrent correctement leurs clés cryptographiques - contre 42,1 % en 2020.
• 78,3 % des entreprises du Fortune 500 utilisent des HSM pour générer leurs clés racines.
• 12,7 % des appareils IoT génèrent encore des clés avec moins de 64 bits d’entropie - ce qui les rend cassables en quelques heures.
• Le marché mondial des HSM devrait atteindre 2,8 milliards de dollars d’ici 2027.

Les réglementations suivent. Le PCI DSS 4.0 (entré en vigueur en mars 2024) exige explicitement « un hasard suffisant pour les opérations cryptographiques ». Les audits de sécurité ne se contentent plus de vérifier que la clé existe - ils vérifient comment elle a été faite.

Conclusion : votre clé privée n’est pas plus sécurisée que son origine

Vous pouvez avoir le meilleur portefeuille, la meilleure interface, le plus beau design. Mais si la clé privée a été générée sur une machine sans entropie, avec un générateur mal configuré, ou en copiant une VM - vous n’avez pas de sécurité. Vous avez une illusion.

La blockchain repose sur la cryptographie. La cryptographie repose sur le hasard. Et le hasard, s’il est mal fait, devient une faille. Pas une faille logicielle. Pas une faille de code. Une faille de compréhension.

Ne générez pas une clé privée comme si c’était un mot de passe pour un forum. Générez-la comme si votre vie financière en dépendait. Parce que c’est le cas.