Découvrez RecoverBull : une sauvegarde de portefeuille Bitcoin sécurisée grâce au chiffrement, au cloud et à des serveurs de clés anonymes.

Bull Bitcoin se concentre sur un seul objectif: aider les individus à devenir souverains en créant des outils qui leur facilitent la détention de Bitcoin en propre (ou self-custody).

Notre mission est de rendre l’expérience d’achat, de vente, de réception, de paiements, ainsi que de stockage à long terme de Bitcoin, via un exchange et un wallet self-custodial, aussi fluide que d’utiliser un service custodial type Coinbase.

Nous avons identifié trois principales difficultés à la détention en propre de Bitcoin:

1. Pour acheter du Bitcoin via un échange self-custodial, les utilisateurs doivent d’abord créer un portefeuille self-custodial. Cela nécessite l’utilisation de deux applications différentes : une application d’échange et une application de portefeuille. Lorsqu’ils achètent du Bitcoin, beaucoup ignorent même ce qu’est un portefeuille Bitcoin. La plupart des gens ne voient que « numbers go up » et veulent simplement avoir une exposition à l’augmentation du prix de Bitcoin.
2. Envoyer et recevoir des paiements en Bitcoin peut être cher et lent. Acheter un café on-chain n’a aucun sens. Les portefeuilles Lightning self-custodial résolvent ce problème, mais apportent leurs propres difficultés.
3. Il n’est pas facile de créer une sauvegarde sécurisée d’un portefeuille Bitcoin. Ce qui est le plus frustrant pour un bitcoiner est de voir des utilisateurs perdre leurs portefeuilles faute de sauvegarde ou se faire voler leurs fonds à cause d’une sauvegarde non sécurisée.

Nous avons déjà résolu les deux premiers points en construisant le portefeuille Bull Bitcoin (BULL Wallet) qui estparfaitement intégré à l’exchange, et utilise une technologie d’atomic swaps ultra-moderne pour envoyer et recevoir des paiements Lightning depuis un wallet Liquid.

Alors, comment résoudre le problème de la sauvegarde sécurisée des portefeuilles ?

La philosophie Bull Bitcoin

Avant de présenter notre solution au problème de sauvegarde, voici notre philosophie :

Chez Bull Bitcoin, nous sommes des constructeurs et des solveurs de problèmes. Nous reconnaissons et acceptons pleinement les limites et compromis du protocole Bitcoin. Nous ne pouvons pas, et ne voulons pas, changer la façon dont Bitcoin fonctionne. Mais nous croyons pouvoir créer des outils et des applications pour rendre l’utilisation de Bitcoin plus simple et sûre pour tous.

Il est facile de prendre des raccourcis et de compromettre les valeurs cypherpunk de Bitcoin pour « simplifier » l’expérience utilisateur. C’est pourquoi la plupart des entreprises Bitcoin proposent des services custodiaux : pas besoin de vous soucier de l’expérience de la self-custody si vous ne la pratiquez pas.

Le vrai défi est de fournir une excellente expérience utilisateur tout en minimisant les compromis.

Résoudre le problème de sauvegarde

Beaucoup diront : « créer une sauvegarde est facile, il suffit d’écrire votre phrase de 12 mots ». Nous ne sommes pas en désaccord, mais après avoir aidé des dizaines de milliers d’utilisateurs à utiliser des applications Bitcoin self-custodial, nous avons une perspective plus pragmatique.

Créer une sauvegarde n’est pas si simple. Exemple : si j’initie un chauffeur de taxi à Bitcoin et lui fais télécharger le portefeuille BULL, je dois m’assurer qu’il a une sauvegarde correcte :

• Si vous ne faites pas de sauvegarde et perdez votre téléphone, vous êtes foutu.
• Si vous écrivez votre sauvegarde sur papier et qu’elle se retrouve dans la machine à laver, vous êtes foutu. Achetez donc une plaque métallique.
• Si vous perdez la plaque métallique, vous êtes foutu. Il faut donc en avoir deux et les stocker séparément.
• Si quelqu’un trouve votre plaque métallique, vous êtes foutu. Ajoutez donc une passphrase BIP39.
• Si la passphrase est faible, elle peut être brute‑forcée. Utilisez une passphrase forte et aléatoire.
• Si vous oubliez votre passphrase, vous êtes foutu. Conservez-en une copie séparée de votre backup.
• Et en cas de décès ? Là, c’est un autre problème.

Bien que faisable pour une personne moyenne, ce n’est pas la méthode idéale pour initier un débutant à Bitcoin. La plupart des gens se contentent alors de télécharger Wallet of Satoshi et d’envoyer quelques sats, en espérant qu’il apprendra la self-custody plus tard. En pratique, il va généralement rester sur une solution custodial pour toujours...

Les solutions existantes

Il existe de nombreuses solutions :

• Ne pas initier les gens et leur dire que Bitcoin n’est pas fait pour eux.
• Acheter des actions ou ETF liés à Bitcoin via un compte de courtage.
• Acheter du Bitcoin sur Coinbase et le laisser là.
• Utiliser un portefeuille custodial.
• Utiliser un service de custody professionnel comme Onramp ou Balance.
• Utiliser un multisig collaboratif avec récupération de clés comme Casa ou Bitkey.
• Utiliser un portefeuille miniscript avec multisig évolutif et chemins de récupération verrouillés dans le temps comme Liania.

Aucune de ces solutions n’atteint le bon équilibre entre compromis et facilité d’utilisation. Notre objectif était de créer une solution facilement utilisable tout en minimisant les compromis.

Construire la solution : objectifs

Voici les objectifs que nous nous sommes fixés (avec notre dev Azad) :

• Les utilisateurs Bitcoin ont le droit d’être non-technique, imprudents ou peu motivés.
• L’anonymat fait partie de la sécurité. Un service manipulant des backups ne doit rien savoir sur les utilisateurs.
• Le processus de sauvegarde doit être réalisable en moins de 2 minutes.
• La sauvegarde doit rester sécurisée et anonyme, où que soit l’utilisateur.
• Il doit rester sécurisé et anonyme quel que soit l'appareil ou le lieu.
• Aucun service ne doit prendre possession des clés privées.
• La récupération doit être gratuite ou très peu coûteuse.
• La récupération doit être portable et sans verrouillage fournisseur.
• Aucune exigence matérielle ou logicielle spéciale.

Construire la solution : les principes

Nous avons travaillé avec les principes suivants :

• Un fichier numérique correctement chiffré est le moyen le plus sûr de protéger un mnémonique Bitcoin.
• Les humains sont mauvais pour générer des mots de passe forts. L’entropie doit être générée aléatoirement.
• Les humains ne retiendront pas une clé aléatoire forte.
• Les humains sont mauvais pour sauvegarder des données.
• Les gestionnaires de mots de passe et le stockage cloud sont des moyens pratiques et répandus.
• Les utilisateurs Bitcoin sont plus susceptibles d’être ciblés par des attaquants ; leur sécurité doit être sérieusement considérée.

En prenant en compte ces éléments, laissez-nous vous présenter notre solution: Recoverbull

Recoverbull: Comment ça marche?

Le modèle de sécurité de Recoverbull repose sur le chiffrement fort d’un wallet backup avec une clé impossible à brute-forcer.
Le backup chiffré peut ensuite être stocké dans un endroit relativement peu sûr (par ex. un cloud provider).

Le problème : une clé de chiffrement à forte entropie ne peut pas être retenue par l’utilisateur. Le risque serait qu’elle soit perdue et donc que le wallet devienne irrécupérable.

Pour résoudre ça, nous introduisons un service gratuit, anonyme, sans compte, dédié uniquement à la gestion de clés : le Key Server.

L’authentification au Key Server se fait via un mot de passe que l’utilisateur doit simplement retenir.
Ce password peut être très faible : nous anticipons qu’il s’agira souvent du PIN à 6 chiffres utilisé pour déverrouiller le smartphone.
Le bruteforce est empêché par un strict rate-limiting au niveau du Key Server.
⁠
En résumé :

• Le backup chiffré est stocké dans le cloud de l’utilisateur.
• La clé de chiffrement est stockée sur un serveur anonyme.
• Pour récupérer la clé, il suffit d'un code PIN.

L’anonymat de l’utilisateur est également un élément crucial du modèle de sécurité. Le serveur de clés ne doit ni collecter ni stocker d’informations pouvant permettre d’identifier l’utilisateur. Dans le cas où la base de données du serveur de clés serait compromise, ou si le serveur de clés était malveillant, toute information personnelle pourrait être utilisée pour des attaques ciblées contre l’utilisateur. Les adresses e-mail et les numéros de téléphone peuvent être retracés jusqu’à l’identité légale d’un utilisateur final, révélant que celui-ci détient des bitcoins.

Processus création de sauvegarde Recoverbull : étape par étape

Étape 1 : génération d’une backup key via dérivation BIP85 (256 bits d’entropie).

Étape 2 : chiffrement du wallet backup avec la backup key créer à l'étape 1

Étape 3 : création du backup file contenant le mnemonic chiffré (ciphertext), le chemin BIP85 utilisé, un backup ID aléatoire, un "sel" aléatoire.

Le résultat de cette opération est que la clé de chiffrement et le fichier de sauvegarde sont créés sur l’appareil de l’utilisateur. Ces deux éléments peuvent être utilisés pour obtenir la phrase mnémotechnique. L’élément important devient alors l’endroit où ces données seront stockées.

Étape 4 : L’utilisateur pourra stocker le fichier de sauvegarde où il le souhaite. Par défaut, nous proposons des services de stockage cloud tels que Google Drive ou iCloud, car ils sont très répandus. Cependant, l’utilisateur peut choisir de sauvegarder ce fichier n’importe où, que ce soit sur un autre appareil ou sur un service de stockage cloud auto-hébergé.

Étape 5 : l’utilisateur est invité à fournir un mot de passe. Le mot de passe peut et doit être à faible entropie, car il doit être facile à mémoriser. L’implémentation de Bull Bitcoin empêche l’utilisation des 1000 codes PIN à 6 chiffres les plus courants comme mot de passe, mais aucune autre exigence n’est nécessaire. Lorsque l’utilisateur saisit son mot de passe, celui-ci est haché avec le sel contenu dans le fichier de sauvegarde afin de produire deux clés : une clé d’authentification et une clé de chiffrement.

Étape 6 : la nouvelle clé de chiffrement dérivée est utilisée pour chiffrer la clé de sauvegarde. Pour que la clé de sauvegarde puisse être déchiffrée, il faudrait donc connaître le mot de passe de l’utilisateur et être en possession du fichier de sauvegarde (qui contient le sel).

Étape 7 : le portefeuille de l’utilisateur lance un client TOR et se connecte à un serveur Recoverbull via TOR. Il envoie au serveur Recoverbull la clé de sauvegarde chiffrée, et fournit l’identifiant (présent dans le fichier de sauvegarde) ainsi que la clé d’authentification (dérivée du mot de passe de l’utilisateur et du sel, également présents dans le fichier de sauvegarde).

Étape 8 : le serveur Recoverbull hache la clé d’authentification et l’identifiant de l’utilisateur pour créer un Key ID. La clé de sauvegarde chiffrée est stockée par le serveur Recoverbull et associée au Key ID correspondant. Il est important de noter que la clé de sauvegarde chiffrée n’est pas associée à l’identifiant ni à la clé d’authentification dans la base de données du serveur, mais uniquement à ce Key ID. La raison est que nous ne voulons pas que le serveur Recoverbull puisse savoir quelle clé de sauvegarde chiffrée permet de déverrouiller un fichier de sauvegarde spécifique à moins que la clé d’authentification de l’utilisateur ne soit fournie. En d’autres termes, ce mécanisme empêche le serveur Recoverbull d’associer un fichier de sauvegarde à une clé chiffrée à moins que le fichier de sauvegarde et le mot de passe de l’utilisateur soient fournis. Cependant, afin de pouvoir appliquer une limitation du nombre de tentatives (voir étape x), le serveur Recoverbull conservera l’identifiant en mémoire pendant la période de limitation de 24 heures.

À ce stade, le processus de sauvegarde est terminé. Le résultat final est que le fichier de sauvegarde de l’utilisateur est stocké dans un emplacement facilement accessible, vraisemblablement chez son fournisseur de stockage cloud hébergé. La clé de sauvegarde chiffrée est conservée par le serveur Recoverbull. Cela crée, en pratique, un schéma de sauvegarde « 2-sur-2 » où deux parties du secret, stockées séparément, doivent être recombinées, en plus du mot de passe de l’utilisateur, pour accéder à la sauvegarde.

Restauration de portefeuille avec Recoverbull: etape par etape

Étape 1 : l’utilisateur doit d’abord récupérer son fichier de sauvegarde et l’importer dans l’application compatible Recoverbull (probablement son portefeuille Bull Bitcoin).

Étape 2 : maintenant que l’application cliente possède le fichier de sauvegarde, l’utilisateur saisit son mot de passe. À partir du sel contenu dans le fichier de sauvegarde et du mot de passe de l’utilisateur, l’application recréera la clé de chiffrement et la clé d’authentification qui avaient été initialement générées à l’étape 5 du processus de sauvegarde.

Étape 3 : l’application cliente initie la connexion TOR vers le serveur Recoverbull, fournit l’Identifiant et la clé d’authentification, et demande la clé de sauvegarde chiffrée associée. Le serveur Recoverbull applique strictement une limitation de 3 tentatives par jour pour un même identifiant. C’est pourquoi le serveur Recoverbull doit conserver l’identifiant en mémoire pendant la période de limitation (dans notre implémentation, 24 heures). Un attaquant en possession d’un fichier de sauvegarde qui tenterait d’accéder par force brute au serveur pour obtenir la clé de sauvegarde le ferait en générant plusieurs clés d’authentification à partir du sel du fichier de sauvegarde. La limitation des tentatives rend ce type d’attaque par force brute extrêmement improbable.

Étape 4 : le serveur Recoverbull, ayant reçu la clé d’authentification et l’identifiant, en déduit le Key ID. Si un Key ID est trouvé, le serveur Recoverbull sait qu’il peut retourner en toute sécurité la clé de sauvegarde chiffrée au client, car la seule manière d’avoir généré ce Key ID est que le client soit en possession à la fois du fichier de sauvegarde et du mot de passe.

Étape 5 : l’application cliente possède maintenant le fichier de sauvegarde, la clé de sauvegarde chiffrée et la clé de chiffrement. Elle déchiffre la clé de sauvegarde chiffrée à l’aide de la clé de chiffrement, puis elle déchiffre la phrase mnémotechnique chiffrée contenue dans le fichier de sauvegarde à l’aide de la clé de sauvegarde.

Le résultat de cette opération est que l’application cliente possède désormais la sauvegarde mnémotechnique du portefeuille de l’utilisateur, et peut restaurer le portefeuille Bitcoin de l’utilisateur.

Revue du modèle de sécurité:

Maintenant que nous avons une compréhension claire du processus Recoverbull, passons en revue les éléments clés du modèle de sécurité.

1. Sur le plan technique, il s’agit d’un schéma de sauvegarde « 2-sur-2 » où deux éléments de données sont nécessaires pour récupérer un portefeuille : le fichier de sauvegarde et la clé de sauvegarde. Comme la clé de sauvegarde est vraisemblablement stockée sur le serveur de clés, et que ce serveur exige une clé d’authentification dérivée du mot de passe de l’utilisateur, il s’agit en réalité d’un schéma « 3-sur-3 » : à moins que l’utilisateur n’ait lui-même conservé une copie de la clé de sauvegarde, son mot de passe sera nécessaire pour effectuer la récupération. Cela vise à prévenir le vol ou l’accès non autorisé à la sauvegarde.
2. L’utilisateur s’appuie sur des services de stockage cloud omniprésents pour stocker le fichier de sauvegarde et sur un serveur Recoverbull dédié pour stocker la clé de sauvegarde. Cela permet d’éviter toute perte accidentelle d’accès à la sauvegarde.
3. Le modèle de sécurité repose sur le fait que l’utilisateur ne doit se préoccuper que de mémoriser son mot de passe. Pour cette raison, le protocole est conçu pour des mots de passe à entropie très faible. La responsabilité de stocker les autres parties de la sauvegarde (le fichier et la clé) est confiée à des prestataires externes.
4. Le modèle de sécurité du serveur de clés repose sur la limitation du nombre de requêtes effectuées par les clients pour obtenir une clé de sauvegarde chiffrée. Cela empêche les attaquants d’accéder illégalement au fichier de sauvegarde d’un utilisateur, puis d’obtenir la clé de sauvegarde.
5. L’utilisateur reste à tout moment absolument anonyme vis-à-vis du serveur Recoverbull. Non seulement le serveur Recoverbull ne dispose d’aucune information permettant d’identifier l’utilisateur (pas même une adresse IP !), mais il ne possède aucune information permettant de relier une clé de sauvegarde à un fichier de sauvegarde, sauf si le mot de passe de l’utilisateur est fourni. Cela vise à réduire et empêcher les demandes légales contraignant le serveur Recoverbull à remettre la clé de sauvegarde d’un utilisateur. Ce qu’il ignore, il ne peut le partager.
6. Enfin, le serveur Recoverbull lui-même est également anonyme. Une partie de la raison pour laquelle le serveur Recoverbull fonctionne exclusivement via TOR est que ses opérateurs ne puissent pas être identifiés. Dans l’implémentation du portefeuille Bull Bitcoin, nous fournissons un serveur Recoverbull par défaut. Ce serveur est géré par des bénévoles anonymes. N’importe qui peut exploiter un serveur Recoverbull. Le serveur Recoverbull doit être digne de confiance pour rester fiable et accessible en permanence, et ne pas collaborer avec les prestataires de stockage cloud. Bull Bitcoin croit fermement que les bénévoles anonymes gérant le serveur Recoverbull actuellement suggéré par défaut dans le portefeuille Bull Bitcoin peuvent être dignes de confiance pour ces deux objectifs.

Modèle de menaces et scénarios catastrophiques:

Les scénarios suivants peuvent entraîner la perte complète d’accès au portefeuille d’un utilisateur :

• Perte : l’utilisateur perd l’accès à son appareil et à son fichier de sauvegarde, et n’a pas de sauvegarde physique.
• Perte : l’utilisateur perd l’accès à son appareil, le serveur de clés est inaccessible, il ne possède pas de copie de la clé de sauvegarde et n’a pas de sauvegarde physique.
• Perte : l’utilisateur perd l’accès à son appareil et à son mot de passe, il ne possède pas de copie de la clé de sauvegarde et n’a pas de sauvegarde physique.
• Vol : le fichier de sauvegarde de l’utilisateur est accédé par un attaquant malveillant qui connaît également le mot de passe.
• Vol : un attaquant malveillant obtient un fichier de sauvegarde et la base de données du serveur Recoverbull est divulguée publiquement.
• Vol : le prestataire de stockage cloud collabore activement avec l’opérateur du serveur Recoverbull (ou exploite un serveur Recoverbull piège).
• Vol : le serveur Recoverbull et les prestataires de stockage cloud sont tous deux contraints par la même autorité légale à remettre l’intégralité de leurs bases de données et choisissent de se conformer.

Cas d’usage de Recoverbull:

Ce n’est pas une solution de stockage à froid.

• Ce n’est pas une alternative aux portefeuilles matériels avec sauvegarde physique appropriée.
• Ce n’est pas une solution sécurisée de stockage Bitcoin à long terme.
• Ce n’est pas une alternative à la garde collaborative ou aux portefeuilles multisignatures basés sur miniscript.

C'est une solution de sauvegarde de portefeuille « chaud ».

• Une alternative aux portefeuilles Bitcoin custodiaux ou aux comptes d’échange.
• Une alternative aux sauvegardes physiques pour les hot wallets.
• Une alternative aux phrases BIP39 pour les sauvegardes physiques.

Recoverbull doit être considéré comme une solution temporaire. En effet, si le serveur Recoverbull qui stocke les clés disparaît, l’utilisateur ne pourra pas récupérer sa sauvegarde Recoverbull à moins de posséder une copie séparée de la clé de sauvegarde. En règle générale, une sauvegarde Recoverbull doit être utilisée pour les montants que l’on serait à l’aise d’utiliser avec un portefeuille custodial ou pour un portefeuille chaud sur son téléphone.

Pour les développeurs:

Les codes sources du client et du serveur Recoverbull sont bien entendu open-source. Pour une implémentation de référence, vous pouvez consulter le code source du portefeuille Bull Bitcoin.

• Whitepaper : https://recoverbull.com/whitepaper
• Client : https://github.com/SatoshiPortal/recoverbull-client-dart
• Serveur : https://github.com/SatoshiPortal/recoverbull-server
• Portefeuille Bull Bitcoin : https://github.com/SatoshiPortal/bullbitcoin-mobile/tree/develop
• Site Recoverbull : https://recoverbull.com/