BIP 39

Alice crée un portefeuille utilisant BIP39 et conserve ses mots de récupération en lieu sûr, en suivant les instructions. Plus tard, son téléphone tombe en panne. Ses bitcoins n'ont pas disparu du réseau : elle a perdu l'appareil qui conservait les clés servant à signer ses paiements. Sur un appareil de remplacement fiable, elle peut utiliser la fonction de restauration d'un portefeuille compatible. Les mêmes mots dans le même ordre, avec la même passphrase si elle en utilisait une, produisent la même graine. Les procédures suivantes recréent les clés privées nécessaires à partir de cette graine, puis le portefeuille retrouve les paiements sur le réseau Bitcoin. Ce n'est pas un compte dont le service d'assistance pourrait réinitialiser le mot de passe. Si Alice utilisait une passphrase, elle en a aussi besoin ; le code PIN de son ancien téléphone ne la remplace pas. Un solde nul après restauration ne signifie pas forcément que les bitcoins sont perdus : outre les mots et la passphrase, il faut vérifier le compte choisi et les paramètres de restauration. D'où l'intérêt de vérifier toute la procédure avant de conserver une somme importante. [1] [5] [13] [14]

Des mots sont plus faciles à recopier et à vérifier qu'une longue représentation de données informatiques. Marek Palatinus, Pavol Rusnak, Aaron Voisine et Sean Bowe ont conçu une méthode pour donner à l’aléa produit par un ordinateur une forme facile à recopier à la main. La proposition est datée du 10 septembre 2013 et porte le statut Deployed dans la spécification. Les mots doivent provenir d’une entrée aléatoire de qualité ; vous ne devez pas les inventer à partir d’une phrase favorite. Cela créerait un Brainwallet reposant sur un secret humain prévisible. Les nœuds Bitcoin ne vérifient pas BIP39 : ils valident les transactions et les blocs, pas la méthode utilisée par le portefeuille pour créer ses clés. [1]

Une bonne transcription ne sert que si elle permet de restaurer le portefeuille. Avant d’y conserver des fonds importants, vérifiez sur un appareil de confiance la procédure de restauration recommandée par le fabricant. Outre l’ordre exact des mots, conservez la passphrase nécessaire, les informations du portefeuille et les éventuels paramètres de dérivation ou de signature. Pour un portefeuille ordinaire à signature unique, le détenteur de la sauvegarde complète et de la passphrase requise peut dériver les clés sans l’appareil d’origine ; avec Multisig, il faut satisfaire les exigences relatives aux autres clés et aux règles de signature. Une photo, une copie dans le cloud, une imprimante ou l’historique du presse-papiers peuvent exposer les secrets à d’autres personnes ou services. Le papier et le métal présentent des limites physiques différentes ; aucun matériau ne suffit à empêcher le vol. [9] [13] [14]

Pour des raisons de compatibilité, BIP39 recommande vivement la liste anglaise : de nombreux portefeuilles ne prennent pas en charge les autres listes. Traduire la sauvegarde ne préserve pas le portefeuille d’origine, car la phrase elle-même intervient dans la dérivation. Il faut aussi tenir compte des autres systèmes. Electrum utilise sa propre procédure de versionnage pour ses sauvegardes natives ; des mots d’apparence similaire n’en font pas automatiquement du BIP39. SLIP39 est un format distinct, avec sa propre liste de 1 024 mots et des règles précisant le nombre de parts nécessaires à la restauration. Il ne s’agit pas simplement de découper une sauvegarde BIP39. Répartir 24 mots dans plusieurs enveloppes ne revient pas à appliquer Shamir Secret Sharing et peut dégrader la protection comme la possibilité de récupération. Il faut toujours connaître le format réel de la sauvegarde. [1] [11] [12]

Tout commence par l’entropie, c’est-à-dire des données aléatoires d’une longueur ENT = 128, 160, 192, 224 ou 256 bits. On y ajoute une somme de contrôle : les premiers CS = ENT/32 bits du résultat de SHA-256 appliqué aux données d’origine. L’ensemble est divisé en groupes de 11 bits, chacun désignant un mot. La relation MS = (ENT+CS)/11 donne donc exactement 12, 15, 18, 21 ou 24 mots. Douze mots représentent 128 bits d’aléa et 4 bits de contrôle ; les 132 bits ne constituent donc pas tous un secret indépendant. Pour 24 mots, la répartition est de 256+8 bits. La confiance dans une sauvegarde commence par le générateur d’aléa, pas par le caractère inhabituel des mots. [1]

Chaque groupe de 11 bits sélectionne une entrée dans une liste ordonnée de 2 048 mots. Le premier mot n’est donc pas la première clé privée : l’ensemble des mots représente les données d’origine et leur somme de contrôle. Dans la liste anglaise, les quatre premières lettres suffisent à distinguer les mots. Ce n’est toutefois ni une règle générale pour toutes les langues ni une invitation à raccourcir arbitrairement la sauvegarde lors de la restauration. Modifier l’ordre, substituer un synonyme ou traduire les mots change les données d’entrée. On obtient parfois une somme de contrôle invalide, parfois une autre sauvegarde valide ; le texte et l’ordre doivent donc être conservés exactement. [1] [2]

L’ordinateur doit savoir quels caractères il a effectivement reçus. BIP39 impose la normalisation Unicode NFKD, puis l’encodage UTF-8, pour la phrase de récupération comme pour la passphrase. NFKD rend équivalents certains caractères écrits différemment, notamment en décomposant certaines lettres accentuées. Deux écritures différentes peuvent ainsi donner le même résultat après normalisation ; leur seule ressemblance visuelle ne le garantit pas. L’ordre des mots, les espaces et les caractères de la passphrase restent importants. Une autre procédure de normalisation peut dériver un seed différent lors de la restauration. L’implémentation de référence et les vecteurs de test publics aident à vérifier que le programme respecte la procédure prescrite. [1] [3] [4]

PBKDF2 reçoit deux entrées distinctes. L’entrée password contient les véritables mots de récupération. La seconde entrée s’appelle le salt : ce sont des données supplémentaires utilisées dans le calcul cryptographique. Elle se compose du texte littéral « mnemonic », auquel la passphrase est ajoutée sans séparateur. Les mots de récupération eux-mêmes ne sont pas insérés une seconde fois dans cette entrée. Les deux entrées sont normalisées avec NFKD et encodées en UTF-8. BIP39 impose HMAC-SHA512, 2 048 itérations et un résultat de 512 bits, soit 64 octets. Sans passphrase, le salt reste « mnemonic » ; seule la passphrase est vide. Le calcul ne déchiffre pas les mots et ne crée pas de nouvel aléa indépendant. En cas de divulgation des mots, les itérations ne suffisent donc pas à protéger une passphrase facile à deviner. [1] [10]

BIP39 s’arrête au seed de 64 octets. Une autre norme, BIP32, en dérive généralement une clé privée maîtresse et un chain code de 32 octets, à l’aide de HMAC-SHA512 et de la clé fixe « Bitcoin seed ». Le chain code contient des données supplémentaires qui, avec une clé, servent à dériver d’autres clés. Ces deux éléments forment le point de départ de l’arbre de clés. Des règles telles que BIP44, BIP49, BIP84 et BIP86 définissent différents chemins de dérivation et types de scripts. Lors d’une restauration, vous pouvez donc saisir les bons mots et la bonne passphrase tout en voyant un solde nul si le programme cherche un autre compte, une autre branche ou un autre type d’adresse. Le gap limit compte aussi : il désigne le nombre d’adresses inutilisées consécutives que le programme accepte de rencontrer pendant sa recherche. Le nom du portefeuille d’origine, les informations sur les comptes, les chemins de dérivation ou un Output Descriptor peuvent apporter des renseignements que les mots seuls ne contiennent pas. [5] [6] [7] [8] [9] [14]

La passphrase est une entrée secrète supplémentaire utilisée pour dériver le seed. Ce n’est pas le code PIN de l’appareil, et BIP39 ne peut pas vous signaler que vous avez saisi la mauvaise : il calcule aussi un résultat pour une autre valeur. Une faute de frappe qui modifie l’entrée normalisée conduit généralement à un autre portefeuille, dans lequel vous ne retrouverez pas vos fonds. À l’inverse, des écritures différentes donnant le même résultat NFKD dérivent le même seed. Quiconque obtient les mots de récupération et les informations permettant de reconnaître le portefeuille recherché peut essayer des passphrases candidates hors ligne. Si vous utilisez une passphrase, elle doit être suffisamment robuste, être saisie de manière fiable et disposer de sa propre sauvegarde sûre. Un stockage séparé doit réduire le risque de vol simultané, sans en faire un secret qui disparaîtrait avec vous. [1] [13]

La somme de contrôle aide à repérer les fautes de frappe, mais ne prouve ni à qui appartient une sauvegarde ni si elle a été créée de manière sûre. Elle comporte 4 bits pour 12 mots et 8 bits pour 24 mots. Une suite de mots tirée uniformément au hasard dans la liste concernée passe donc le contrôle avec une probabilité de 1/16 ou de 1/256, respectivement. Beaucoup d’erreurs sont détectées, mais pas toutes ; la somme de contrôle ne les corrige pas non plus. Un attaquant peut construire une autre sauvegarde avec une somme de contrôle valide. La spécification exige un avertissement lorsque la somme de contrôle ne correspond pas à la valeur attendue et distingue la vérification des mots de la dérivation du seed elle-même. Une somme de contrôle invalide doit donc être examinée à partir du portefeuille d’origine et de son format, plutôt qu’en saisissant une véritable sauvegarde dans un vérificateur en ligne. [1]