Phrases de semence BIP39 Ce que ces 12 mots représentent réellement et comment fonctionne la dérivation des portefeuilles HD

Un mot de mémoire BIP39 est 128 ou 256 bits de données aléatoires, encodées sous forme de mots lisibles par l'homme à l'aide d'une liste fixe de 2048 mots. C'est tout le truc. Le « magique » réside simplement dans le fait que les mots sont plus faciles à écrire sur papier que des chaînes hexadécimales — cryptographiquement, il n'y a rien de spécial dans les mots eux-mêmes.

Ce qui devient intéressant, c'est la pile à quatre niveaux construite sur ce codage : BIP39 (la liste de mots et le codage), BIP32 (la dérivation hiérarchique des clés), BIP43 (les conventions de champ d'usage), et BIP44 (la structure de monnaie/compte/adresse). La plupart des explications confondent ces quatre éléments. Cette explication les sépare.

La liste de mots : 11 bits par mot, incluant le contrôle de cohérence

Le Liste de mots en anglais BIP39 comporte exactement 2048 mots. 2¹¹ = 2048, donc chaque mot encode 11 bits d'information. Une phrase de 12 mots contient au total 132 bits ; une phrase de 24 mots contient 264 bits.

Ce n'est pas tout le contenu de ces bits qui correspond à l'entropie. Les derniers bits du dernier mot sont un contrôle de cohérence — les premiers ENT/32 bits de SHA256(entropie_bytes), où ENT est la longueur de l'entropie en bits :

Longueur de la phrase	Bits d'entropie (ENT)	Bits de contrôle de cohérence (CS = ENT/32)	Total des bits
12 mots	128	4	132
15 mots	160	5	165
18 mots	192	6	198
21 mots	224	7	231
24 mots	256	8	264

Le contrôle de cohérence est la raison pour laquelle les mnémoniques « presque valides » échouent. Inverser un seul bit d'entropie fait changer le byte de contrôle, rendant la phrase invalide. Cela détecte les erreurs de transcription — spécifiquement celles qui se produisent dans les bits de contrôle. Les portefeuilles qui valident avant la dérivation des clés rejettent entièrement la phrase. Certains ne valident pas ; ils dérivent simplement un portefeuille à partir d'entropie corrompue.

La correspondance entre l'entropie et les mots dans Python :

import hashlib, os

# Generate 128 bits of entropy
entropy = os.urandom(16)  # 16 bytes = 128 bits

# Compute checksum: first 4 bits of SHA256(entropy)
h = hashlib.sha256(entropy).digest()
checksum_bits = format(h[0], '08b')[:4]  # first 4 bits of SHA256 output

# Combine entropy bits + checksum bits
all_bits = format(int.from_bytes(entropy, 'big'), '0128b') + checksum_bits
# all_bits is now 132 bits

# Split into 11-bit groups -> 12 word indices (0-2047)
word_indices = [int(all_bits[i:i+11], 2) for i in range(0, 132, 11)]
# Look up each index in the BIP39 word list to get the mnemonic

La phrase mnémonique n'est pas la clé : l'étape PBKDF2

C'est là que la plupart des explications se trompent. Les 12 mots ne sont pas votre clé privée et ne sont pas utilisés directement pour la signature. Ils constituent un encodage intermédiaire. Avant que tout matériel de clé ne soit dérivé, la phrase mnémonique est étirée par PBKDF2-HMAC-SHA512 :

import hashlib

mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about"
passphrase = ""  # optional; empty string = no passphrase

seed = hashlib.pbkdf2_hmac(
    'sha512',
    mnemonic.encode('utf-8'),                    # password: the mnemonic words
    ('mnemonic' + passphrase).encode('utf-8'),   # salt: always "mnemonic" + passphrase
    2048,                                         # iterations
    dklen=64                                      # 512 bits output
)
# seed is 64 bytes (512 bits) -- this is what actually seeds key derivation

Deux choses à noter :

• Le sel est toujours la chaîne littérale "mnemonic" concatenée avec le mot de passe. Un mot de passe vide signifie que le sel est simplement "mnemonic" — il n'y a pas de mode séparé « sans mot de passe ».
• Le mot de passe modifie complètement le résultat de la clé. Les mêmes 12 mots avec mot de passe "A" vs "a" produisent des portefeuilles entièrement différents avec des adresses entièrement différentes. C'est la fonctionnalité du « 25e mot » : un mot de passe vous permet de maintenir une déni plausible (deux portefeuilles à partir d'une même phrase), mais perdre le mot de passe est permanent, même avec les 12 mots en main.

De la clé de départ à la clé maîtresse : BIP32

La clé de 512 bits alimente HMAC-SHA512 avec la chaîne de clé fixe "Bitcoin seed". La sortie de 64 octets se divise en deux moitiés de 256 bits :

import hmac, hashlib

master = hmac.new(b'Bitcoin seed', seed, hashlib.sha512).digest()
master_private_key = master[:32]   # left 256 bits: the actual EC private key
master_chain_code  = master[32:]   # right 256 bits: used for all child derivation

Le code de chaîne est la clé qui explique pourquoi les portefeuilles HD fonctionnent : il empêche les clés dérivées d'être forçées même si la clé parente est connue. Sans cela, connaître une clé parente publique et une clé enfant privée révélerait toutes les clés sœurs. Avec le code de chaîne, la dérivation des clés enfants nécessite à la fois la clé parente et le code de chaîne comme entrées — et pour la dérivation renforcée, la clé parente privée directement.

Ensemble, master_private_key + master_chain_code forment la clé privée étendue maîtresse, encodée sous forme d'une xprv... chaîne Base58Check. La clé étendue publique correspondante est xpub... — utile pour les portefeuilles en lecture seule qui doivent dériver des adresses sans révéler les matériaux de clé privée.

Chemins de dérivation BIP44 : m/44’/60’/0’/0/0 décodé

BIP44 définit une hiérarchie à cinq niveaux. Voici m/44’/60’/0’/0/0 — le chemin standard pour l'adresse Ethereum — décomposé composante par composante :

Niveau	Valeur	Index en hexadécimal	Signification
m	—	—	Racine de la clé maîtresse
44'	usage	0x8000002C	Usage BIP44. Dérivation renforcée (apostrophe = 0x80000000 + index).
60'	type de monnaie	0x8000003C	Ethereum, selon SLIP-0044. Bitcoin = 0′, Solana = 501′, etc.
0'	compte	0x80000000	Premier compte. Incrémenté pour des comptes isolés séparés.
0	changement	0	Chaîne externe (0 = adresses de réception, 1 = adresses de changement). Les portefeuilles utilisent rarement la chaîne de changement sur les chaînes EVM.
0	index	0	Index de l'adresse. Incrémenté pour l'adresse 2e, 3e, etc.

Les apostrophes indiquent dérivation renforcée. Les clés enfants renforcées peuvent être dérivées uniquement à partir de la clé parente privée, pas à partir de la clé parente publique. Cela importe parce que, avec une dérivation normale (non renforcée), une clé enfant privée compromise, combinée à la clé parente publique, révélerait la clé parente privée et toutes les clés sœurs. Pour les niveaux d'usage, de type de monnaie et de compte, la dérivation renforcée est spécifiée.

Pourquoi la même phrase donne des adresses différentes dans différents portefeuilles

La phrase et le chemin par défaut du portefeuille sont des variables indépendantes. Les portefeuilles ont historiquement divergé sur le chemin, et certaines divergences restent encore non résolues.

Pour Ethereum, la principale divergence :

• MetaMask, Ledger Live, la plupart des portefeuilles modernes : m/44'/60'/0'/0/N — chemin standard BIP44.
• MyEtherWallet (par défaut historique) : m/44'/60'/0'/N — un niveau de moins. Un portefeuille restauré à partir de la même phrase dans MEW avec le chemin historique produit un ensemble entièrement différent d'adresses que MetaMask.
• Trezor Suite : Suive le chemin standard BIP44 pour ETH maintenant, mais avait historiquement des particularités avec certains cryptomonnaies.

Pour Bitcoin, la divergence est structurelle : BIP44 (m/44'/0'/0', legacy P2PKH, adresses commencent par 1), BIP49 (m/49'/0'/0', P2SH-P2WPKH, adresses commencent par 3), et BIP84 (m/84'/0'/0', P2WPKH natif segwit, adresses commencent par bc1q) produisent des adresses différentes à partir du même grain. Le format de l'adresse indique quel chemin a été utilisé, ce qui explique pourquoi le format de l'adresse est important lors de la résolution d'un problème de récupération.

Si vous importez une phrase et que « les fonds ne sont pas là », vérifiez le chemin de dérivation avant de supposer que la phrase est erronée. La plupart des portefeuilles vous permettent d'indiquer manuellement le chemin lors de l'importation avancée.

Modes de défaillance de sécurité

La cryptographie ici n'est pas le point faible. Chaque attaque efficace contre les portefeuilles BIP39 vise le côté humain du pipeline.

Phishing : « entrez votre phrase de récupération pour continuer »

L'attaque la plus fréquente par un large écart. Des interfaces de portefeuille fictifs, des extensions de navigateur injectées par des scripts malveillants, des impersonateurs de service client sur Discord — tous demandant aux utilisateurs de taper leurs 12 mots quelque part. Le modèle mental correct : logiciel légitime de portefeuille ne demande jamais votre phrase de récupération après la configuration initiale. Une demande de phrase est une attaque, quelle que soit l'apparence de l'interface.

Surveillance du presse-papiers

Du malware qui surveille le presse-papiers, détecte une séquence de 12 ou 24 mots connus BIP39, et exfiltré. La fenêtre d'exfiltration est de millisecondes. Copier-coller une phrase de récupération n'importe où — même brièvement dans un éditeur de texte — crée une exposition. Les gestionnaires d'historique du presse-papiers (Historique du presse-papiers Windows, gestionnaires de presse-papiers macOS, historique de collage dans les IDE) sont particulièrement à risque.

Écrans et synchronisation des photos en nuage

Prendre une photo d'une phrase de récupération sur un téléphone l'envoie à iCloud Photos ou Google Photos en quelques secondes, avant que la plupart des gens n'aient fini de la lire. Ces sauvegardes ne sont pas chiffrées au niveau client. « J'ai pris une photo pour la garder en sécurité » est un chemin direct d'exfiltration. Une sauvegarde papier dans un lieu physiquement sécurisé n'est pas une recommandation en plaisanterie.

Génération de phrase de récupération côté serveur

Tout site web qui génère une phrase BIP39 côté serveur possède une copie de l'entropie. Le seul endroit sûr pour générer est un appareil que vous contrôlez, hors ligne au moment de la génération. Un portefeuille matériel, une machine isolée, ou un outil client vérifié. Un site web n'est pas l'un de ces éléments — même si le JavaScript semble correct, vous ne pouvez pas vérifier que le serveur n'enregistre pas l'output.

Si vous devez inspecter ou vérifier la structure d'une phrase — vérifier l'entropie, voir la clé dérivée, valider un chemin — le Convertisseur Mnémonique BIP39 s'exécute entièrement dans le navigateur. La phrase ne quitte jamais votre machine, ce qui est la seule architecture sécurisée pour ce cas d'usage.

L'angle du développeur : vous n'avez probablement pas besoin de gérer les phrases de récupération dans votre application

Si vous construisez une application proche du monde cryptographique, l'instinct de « gérer la phrase de récupération » dans votre backend est presque toujours une mauvaise idée. La surface d'attaque :

• Journalisation. Chaque framework web enregistre les corps des requêtes quelque part. Une ligne de débogage, un niveau de journalisation mal configuré, et chaque phrase passant par votre API est sur disque — indéfiniment, sur plusieurs destinations de journalisation que vous n'avez pas auditées.
• Transit. HTTPS protège le canal. Il ne protège pas le pare-feu, le processus backend, la base de données ou l'agregateur de journaux. Chaque élément est une surface de violation séparée.
• Mémoire. Les dumps de processus, les rapports de crash, les fichiers de core et les snapshots de pile capturent des chaînes en mémoire. Une phrase de récupération dans un dictionnaire Python ou un objet JavaScript n'est pas une copie zéro ; elle apparaît probablement dans plusieurs allocations avant qu'elle ne soit « supprimée ».
• Responsabilité. Si votre backend traite les phrases de récupération des utilisateurs et que vous êtes victime d'une attaque, la défaillance est permanente. Contrairement aux mots de passe, il n'existe pas de mécanisme de réinitialisation. Les utilisateurs perdent leurs fonds sans recours.

L'architecture qui fonctionne réellement : dérivez ce que vous avez besoin côté client et transmettez uniquement la sortie — une clé publique, une clé xpub en lecture seule, une transaction signée. Le backend ne voit jamais la phrase. Les bibliothèques qui le font correctement : @scure/bip39 (audité, avec faible dépendance), ethers.jset bitcoinjs-lib. Pour les intégrations avec des portefeuilles matériels, les SDK de Trezor et Ledger retournent une transaction signée — la clé ne quitte jamais l'appareil.

La chaîne complète de dérivation à l'œil

Étape	Saisir	Opération	Sortir
1. Entropie	128 à 256 bits aléatoires	Contrôle de cohérence SHA256 → groupes de 11 bits	Phrase de 12 à 24 mots
2. Clé	Mots de la phrase mnémonique + « mnémonique » + mot de passe	PBKDF2-HMAC-SHA516, 2048 tours	Clé de 512 bits (64 octets)
3. Clé maîtresse	Octets de clé	HMAC-SHA512(« Bitcoin seed », clé)	Clé privée maîtresse (256 bits) + code de chaîne (256 bits)
4. Clé de compte	Clé maîtresse + chemin m/44’/60’/0’	Dérivation renforcée BIP32 × 3	Clé étendue privée du compte
5. Clé d'adresse	Clé de compte + chemin /0/N	Dérivation normale BIP32 × 2	Clé privée enfant → clé publique secp256k1 → keccak256 → adresse

BIP39 a exactement fait ce qu'il était conçu pour faire : rendre l'entropie lisible et récupérable. La surface d'attaque n'est pas dans la cryptographie — PBKDF2 avec 2048 tours, HMAC-SHA512, secp256k1 — tout cela est solide. Les attaques sont entièrement opérationnelles : entrer la phrase ailleurs qu'ailleurs, la stocker numériquement, faire confiance à un outil qui la génère côté serveur. Le calcul est bon. Les humains sont la faiblesse, ce qui est la raison pour laquelle le conseil au développeur est « concevoir votre système de manière à ce que la phrase ne touche jamais votre infrastructure ».

Vous aimerez peut-être aussi