Dans le procédé courant BIP39, des données aléatoires deviennent des mots de sauvegarde, ou Seed Phrase. Ces mots et une passphrase facultative, un mot de passe supplémentaire, produisent le seed : des données secrètes dont BIP32 peut dériver un arbre de clés. Données aléatoires, mots, seed et clés sont donc des étapes distinctes d’un même parcours. D’autres formats de sauvegarde peuvent fonctionner autrement.
Imaginez vouloir mémoriser facilement votre sauvegarde et choisir des mots dans votre livre préféré. Ils peuvent vous sembler originaux, mais un attaquant peut justement essayer des citations et des habitudes humaines connues. BIP39 part donc d’un aléa produit par ordinateur, puis le représente sous forme de mots. L’entropie décrit son imprévisibilité. Les mots rendent des données secrètes lisibles ; ils ne vous invitent pas à composer votre propre phrase. [1]
Le portefeuille doit réellement obtenir des données aléatoires, pas seulement appeler une fonction au nom rassurant. Linux propose par exemple getrandom(), qui attend par défaut que la source du système soit prête. Avec GRND_NONBLOCK, la fonction peut plutôt signaler EAGAIN : les données ne sont pas encore disponibles. Le logiciel doit vérifier le résultat et le nombre d’octets, les unités de données reçues. Continuer après un échec comme si l’entrée secrète avait été créée pourrait produire un portefeuille apparemment fonctionnel, mais vulnérable. [2]
Les navigateurs proposent aussi une interface pour obtenir un aléa sûr. Web Crypto getRandomValues() remplit un tableau d’entiers avec des octets cryptographiquement sûrs ; au-delà de 65536 octets, la demande échoue avec QuotaExceededError. Cela décrit toutefois une fonction, pas la sécurité du site entier. Une page pourrait obtenir un bon aléa, puis divulguer les mots de sauvegarde. Il faut donc aussi examiner le code chargé et ce qu’il fait du résultat. [3]
Si vous recopiez mal un mot, le portefeuille peut détecter l’erreur grâce à une somme de contrôle : une courte vérification calculée à partir des données initiales. BIP39 ajoute 4 bits de contrôle à 128 bits d’entrée pour former 12 mots ; 256 bits accompagnés de 8 bits de contrôle donnent 24 mots. Le bit est une unité élémentaire d’information. Les bits de contrôle viennent d’une empreinte des données calculée par SHA256, pas d’une nouvelle entropie indépendante. Une somme valide ne prouve donc ni le secret des mots ni la sûreté de leur génération. [1]
Les mots facilitent la sauvegarde ; le logiciel doit en tirer des données précisément définies. BIP39 utilise la fonction de dérivation PBKDF2-HMAC-SHA512 avec 2048 répétitions pour produire un seed de 512 bits. À la phrase s’ajoute un paramètre appelé salt : ici, le texte littéral mnemonic suivi de la passphrase, ou d’une chaîne vide si elle n’est pas utilisée. La phrase et ce paramètre sont traités en UTF-8 NFKD, qui normalise la représentation des caractères. Une sortie plus longue ne crée pas l’aléa manquant : sa longueur ne prouve pas 512 bits d’entropie initiale. [1]
BIP32 décrit l’étape suivante. Il dérive une clé privée maîtresse et un chain code, des données auxiliaires servant à dériver d’autres clés. Le portefeuille peut ainsi créer de nouvelles adresses depuis une origine commune. Techniquement, il applique HMAC-SHA512 avec le texte fixe Bitcoin seed comme clé de cette fonction, puis partage le résultat. Ce texte public n’est pas votre secret. Une clé privée dérivée nulle ou hors de l’intervalle autorisé est invalide. Le seed n’est donc pas simplement rebaptisé « clé privée ». [4]
Les développeurs doivent savoir si leur programme calcule correctement. Les vecteurs de test fournissent des entrées connues et les résultats attendus. BIP39 publie des ensembles contenant entropie, mots et seed, avec notamment la passphrase de test TREZOR. Un résultat conforme vérifie la conversion de cette entrée ; il ne prouve pas que le générateur réel produit des secrets imprévisibles. Ces données étant publiques, elles ne doivent jamais servir de sauvegarde secrète pour de vrais fonds. [1]
Plusieurs étapes relient la source aléatoire, les mots et la sauvegarde conservée. NIST SP 800-90C décrit comment les sources d’entropie se combinent aux mécanismes de génération de données aléatoires. Évaluer un portefeuille impose aussi d’examiner sa version précise, sa gestion des erreurs et le transfert des données entre étapes. Un composant bien vérifié ne garantit pas qu’un autre ne perdra ni ne divulguera le secret. L’objectif est de suivre tout le processus, pas de chercher une seule appellation rassurante. [5]
Pour une vision complète, lisez aussi Random Number Generator, BIP 39, HD Wallet, Seed Phrase. Cette entrée est également citée par Random Number Generator, CSPRNG, Deterministic RNG, Entropy Mixing.