146 / 736SLIP39

SLIP-39

Sauvegarde de portefeuille répartie en parts de récupération

Comment retrouver un portefeuille avec suffisamment de parts, et pourquoi ce n’est ni une Seed Phrase découpée ni du Multisig.

SLIP-39 est un standard de sauvegarde utilisant plusieurs listes de mots, appelées parts de récupération. On choisit à l’avance combien de parts différentes seront nécessaires. Avec une organisation deux sur trois, on peut par exemple en perdre une et retrouver quand même son portefeuille. Une seule ne suffit pas. Créé par SatoshiLabs, ce standard utilise Shamir’s Secret Sharing, une méthode mathématique de partage d’un secret. Ses parts ne sont pas une simple réécriture d’une Seed Phrase BIP 39.

Anna choisit une sauvegarde deux sur trois. Un portefeuille est une application ou un appareil permettant de recevoir et d’envoyer des bitcoins. Le portefeuille produit trois parts distinctes, dont deux quelconques permettent la récupération. Ce minimum s’appelle le seuil. Deux photos de la même part ne comptent toujours que pour une part. L’organisation simple utilise un seul groupe. SLIP-39 permet aussi des règles plus complexes : par exemple 2 groupes sur 3, chacun exigeant 2 parts sur 3. Deux parts du groupe A et deux de B suffisent. Trois de A et une de B ne suffisent pas, car seul A est complet. C’est donc la répartition qui compte, pas seulement le nombre de feuilles. [1] [6]

Chaque liste contient des données différentes et les renseignements nécessaires à leur assemblage. SLIP-39 utilise une liste fixe de 1024 mots anglais ; les mots de sauvegarde ne sont pas traduits, même si l’interface est en français. Un secret de 128 bits donne des parts de 20 mots ; un secret de 256 bits, de 33 mots. Le bit est une unité élémentaire de données, pas un mot supplémentaire à noter. La part indique aussi son ensemble, son groupe, sa position, les seuils requis et les paramètres de chiffrement. La récupération vérifie leur cohérence et que les parts sont distinctes. Des listes quelconques de même longueur ne peuvent donc pas être mélangées. [1]

Anna peut également employer une passphrase, un mot de passe supplémentaire choisi par elle. Réunir assez de parts ne le remplace pas. Une bonne combinaison ne détecte pas non plus une faute de frappe dans cette passphrase : une autre entrée produit un autre secret maître, donc un autre portefeuille. Il faut comparer le résultat à des adresses connues, sans se contenter d’un message de sauvegarde valide. Sans passphrase, l’entrée est vide. SLIP-39 autorise les caractères ASCII imprimables 32–126, les caractères latins de base sans accents, espace compris. Cette règle appartient à ce standard, pas à tous les portefeuilles. La passphrase n’est pas le code PIN qui déverrouille l’appareil. [1]

Une Seed Phrase BIP 39 est produite autrement, avec une autre liste de mots. Répartir ses mots sur des feuilles n’en fait pas des parts SLIP-39. Pour conserver le même portefeuille, une conversion devrait préserver le seed, les données secrètes à l’origine de l’arbre de clés BIP 32, ainsi que la bonne Derivation Path, le chemin menant aux clés utilisées. Recoder l’entropie initiale, les données aléatoires antérieures aux mots, ne suffit pas. BIP 39 tire des mots et de la passphrase un seed de 512 bits ; sa sauvegarde directe avec SLIP-39 produit des parts de 59 mots. Convertir un portefeuille ne transfère pas automatiquement les autres, accessibles avec d’autres passphrases. Il faut vérifier au préalable la procédure effectivement prise en charge. [1] [3] [2]

Une sauvegarde compatible portant l’indicateur extendable peut changer de répartition tout en conservant les mêmes portefeuilles. Trezor décrit ainsi le passage d’une sauvegarde à une part vers plusieurs parts. Mais en remplaçant les feuilles, Anna n’a pas changé son secret : une combinaison ancienne suffisante fonctionne encore. Les anciennes et les nouvelles parts ne doivent pas être mélangées. Techniquement, la valeur 1 de l’indicateur exclut l’identifiant d’ensemble de l’entrée auxiliaire du chiffrement, appelée salt. Le même encrypted master secret (EMS), le secret maître chiffré, peut alors être repartagé sous un nouvel identifiant sans connaître la passphrase. Cela ne répare pas la divulgation d’une ancienne sauvegarde utilisable. [1] [4]

Une clé privée est une valeur numérique secrète dont le portefeuille se sert pour créer une signature numérique autorisant une dépense. Une fois restauré, le portefeuille d’Anna peut signer normalement. Les détenteurs des parts n’ont pas à approuver chaque paiement : SLIP-39 reconstitue un secret, tandis que Multisig exige plusieurs signatures selon les conditions de dépense. Un seul incendie peut détruire trois parts conservées dans le même logement. La répartition doit compliquer à la fois leur perte commune et la collecte d’assez de parts par un attaquant ; un montage plus complexe rend aussi la récupération plus exigeante. Le test doit suivre une procédure prise en charge sur un appareil fiable. La bibliothèque de référence python-shamir-mnemonic sert aux développeurs à contrôler la compatibilité avec des exemples publics de test, pas à traiter votre véritable sauvegarde. Elle prévient explicitement qu’elle ne protège pas suffisamment les secrets. [1] [4] [5] [6]

Pour un portefeuille BIP 32, le secret maître est le seed d’entrée, pas la racine privée étendue déjà calculée de l’arbre de clés. On chiffre d’abord le seed, puis on partage l’EMS obtenu. Le chiffrement utilise quatre tours d’une construction Feistel, chacun contenant PBKDF2-HMAC-SHA256 avec 2500×2^e itérations. L’exposant e enregistré fixe le coût de calcul. C’est un traitement précisément défini du mot de passe, pas un ajout de mots aléatoires. Le partage s’effectue octet par octet dans GF(256), un cadre mathématique comportant 256 valeurs. Le polynôme place le secret en f(255) ; à partir d’un seuil de 2, f(254) contient une valeur de vérification appelée digest. [1] [2]

Les trois derniers mots d’une part forment la somme de contrôle RS1024. Elle détecte avec certitude les erreurs touchant au plus trois mots, mais ne constitue ni la signature du créateur ni une preuve de propriété. Le standard déconseille la correction automatique : le logiciel pourrait produire des mots valides mais différents. À l’assemblage, un autre digest de 32 bits aide à détecter un ensemble incorrect. Il a aussi une conséquence théorique : une personne ayant une part de moins que le seuil peut éliminer certains secrets candidats lors d’une recherche exhaustive. L’affirmation mathématique d’absence absolue de fuite sous le seuil doit donc être nuancée. Cela ne signifie pas que la protection est facile à casser ; cela explique l’exigence d’un secret initial suffisamment fort. [1]

Pour une vision complète, lisez aussi Shamir Secret Sharing, BIP 39, Trezor, Multisig, HD Wallet, Seed Phrase. Cette entrée est également citée par BIP 39, Trezor, Pavol « Stick » Rusnák, Shamir Secret Sharing.

DOC · 001SLIP-0039 — Shamir Secret-Sharing for Mnemonic CodesSpécification DOC · 002BIP 32 — Hierarchical Deterministic WalletsSpécification DOC · 003BIP 39 — Mnemonic code for generating deterministic keysSpécification DOC · 004Trezor — Multi-share BackupDocumentation DOC · 005Trezor — python-shamir-mnemonic reference implementationSource primaire DOC · 006Bitcoin Developer Guide — WalletsDocumentation
Révisé le: Sources d’abord · Pas un conseil financier