Retour en arrière

Le premier hardware wallet BitBox01 a été lancé le 25 mars 2016 pour protéger vos fonds contre un ordinateur potentiellement compromis. Avec le BitBox01, nous avons été les premiers à proposer des sauvegardes de portefeuille sur carte microSD et un format portable qui permet d’accrocher l’appareil à votre porte-clés. Au lieu d’intégrer un écran, vous pouviez appairer le BitBox01 avec votre téléphone mobile pour vérifier les adresses de réception et les transactions sur un écran distant. Cette configuration nous a permis de proposer un hardware wallet moins compliqué et moins coûteux à produire. Cependant, l’utilisation d’un écran intégré, comme sur le nouveau BitBox02, réduit la surface d’attaque et rend le produit plus facile à maintenir. À long terme, la sécurité sera mieux assurée en passant au BitBox02.

Regarder vers l’avenir

Nous voulons laisser à chacun suffisamment de temps pour déplacer ses fonds vers une nouvelle configuration. Nous continuerons donc à prendre en charge le BitBox01 dans notre application et via [email protected] dans un avenir prévisible. Néanmoins, nous vous encourageons à déplacer vos coins vers le nouveau BitBox02 et proposons une remise de mise à niveau spéciale dans la BitBoxApp.

Ce que nous avons appris

Pendant la durée de vie du BitBox01, nous avons beaucoup appris. Voici quelques-uns de nos principaux enseignements et la manière dont nous y avons répondu dans le BitBox02.

La complexité est vraiment l’ennemi de la sécurité

Sans écran intégré, vous deviez appairer un téléphone mobile pour savoir ce que vous confirmiez en touchant le BitBox01. Comme le seul moyen pour l’appareil de communiquer avec le téléphone mobile passe par l’ordinateur, potentiellement contrôlé par un attaquant, le canal devait être mis en place de manière sécurisée et résister à la manipulation.

Saleem Rashid a réussi à compromettre l’appairage à plusieurs reprises (voir son article de blog pour le premier exploit). D’abord, l’échange de clés initial servant à établir le canal devait être protégé contre une attaque de l’homme du milieu. Le seul moyen de s’en assurer est de transmettre des informations hors bande d’un point de terminaison à l’autre. Comme nous ne disposions que du toucher et des clignotements de LED, nous avons abouti à une expérience utilisateur sous-optimale. Du point de vue de la sécurité, il était difficile de se protéger contre une attaque par force brute sur la clé échangée avec une entropie hors bande aussi limitée (corrigé dans la version 4.0.0). Mais il s’est aussi avéré qu’il était possible d’utiliser l’interface U2F pour imiter les clignotements de l’appairage sur le BitBox01.

Une fois le canal établi, il faut le protéger contre des attaques telles que le rejeu (corrigé dans la version 6.0.0). C’est la raison pour laquelle nous avons dû exiger une pression de confirmation sur le bouton du téléphone mobile même lorsque la « full 2FA » n’était pas activée. En outre, l’application mobile de vérification constituait une base de code supplémentaire à maintenir et à auditer pour détecter des vulnérabilités. Deux attaques par injection déclenchables par l’ordinateur sont ainsi passées inaperçues jusqu’à ce que Saleem Rashid nous les signale (corrigées dans la version la plus récente). Nous le remercions pour son travail et ses efforts pour améliorer la sécurité du BitBox01.

Solution BitBox02 : Grâce à un écran intégré, sans canal contrôlé par un attaquant entre le firmware et l’écran et sans base de code supplémentaire, le BitBox02 évite tous ces problèmes.

Définir l’architecture de sécurité avant l’implémentation

Les produits de sécurité doivent être conçus avec soin plutôt que de croître de manière organique. Même si cela semble évident, ce n’est souvent pas ce qui se passe en pratique. Différents ingénieurs ajoutent différentes fonctionnalités au fil du temps. Une autre faille conceptuelle, en plus du problème d’appairage, concerne la manière dont le BitBox01 utilise la puce sécurisée ATAES132A. Initialement ajoutée pour disposer d’une bonne source d’entropie afin de générer la seed, elle a ensuite aussi été utilisée pour stocker la seed chiffrée avec une clé stockée dans le MCU. Cependant, aucune protection de sécurité n’a été activée pour la puce sécurisée, ce qui signifie que n’importe qui pouvait demander la seed chiffrée à la puce sécurisée. À l’origine, nous présentions cet aspect comme suit : « tous les secrets (clés et mots de passe) sont stockés de manière isolée sur une puce séparée hautement sécurisée, conçue spécifiquement pour garder vos secrets secrets ». Même si c’est techniquement vrai — tant que nous ne parlons, pour les clés, que de la seed — cette affirmation est trompeuse et nous l’avons donc supprimée. Saleem Rashid fournit des explications détaillées dans son article de blog. Une autre leçon est qu’il faut être très prudent lorsque l’on traduit des propriétés techniques en messages marketing. Les affirmations marketing à caractère technique doivent toujours être validées par des ingénieurs.

Solution BitBox02 : Tout ce que nous avons appris avec le BitBox01 a été intégré dans la conception du matériel et du firmware du BitBox02. Tous les vecteurs d’attaque que nous avons pris en compte et les contre-mesures que nous avons mises en œuvre sont expliqués dans notre modèle de menace récemment publié.

Il faut maintenir ce que l’on construit

Il y a deux aspects clés. D’abord, de nombreuses fonctionnalités des débuts, comme le portefeuille caché pour le déni plausible ou la full second-factor authorization, étaient difficiles à corriger ou à maintenir de manière rétrocompatible, c’est-à-dire de sorte que les effets négatifs sur les utilisateurs existants soient aussi faibles que possible. Ensuite, nous avons réorienté en interne notre attention vers le développement du BitBox02, ce qui signifiait moins d’ingénieurs et moins de regards sur le BitBox01. En conséquence, des problèmes de sécurité, comme l’absence de validation du keypath, peuvent passer inaperçus trop longtemps.

Solution BitBox02 : Concentrer nos ressources d’ingénierie sur l’amélioration et la maintenance d’un hardware wallet central dont nous pensons qu’il présente un potentiel de sécurité supérieur à long terme.

Les programmes de bug bounty fonctionnent

Les logiciels open source assortis d’incitations financières pour les chercheurs en sécurité ont profité à nos utilisateurs. Au cours des deux dernières années, nous avons reçu de nombreux signalements via notre programme de bug bounty. Beaucoup étaient mineurs, mais certains étaient critiques. Nous remercions vivement toutes les personnes qui ont contribué à notre programme de bug bounty.

Nous mettons fin, avec effet immédiat, au versement de récompenses pour les nouveaux signalements de chercheurs en sécurité concernant le BitBox01.

Solution BitBox02 : Notre programme de bug bounty et votre aide sont importants pour rendre le BitBox02 aussi sûr que possible. C’est pourquoi nous continuons à développer ouvertement dans nos dépôts GitHub du firmware BitBox02 et de la BitBoxApp.

Vous n’avez pas encore de BitBox02 ?

Le BitBox02 est disponible en deux éditions : la Multi edition, qui prend en charge plusieurs crypto-actifs et peut être utilisée comme authentificateur de second facteur. Et la Bitcoin-only edition, qui intègre un firmware radicalement ciblé : moins de code signifie moins de surface d’attaque, ce qui renforce encore votre sécurité si vous stockez uniquement du Bitcoin.

Procurez-vous-en un dans notre boutique !

Shift Crypto est une entreprise privée basée à Zurich, en Suisse. Notre équipe internationale de spécialistes en ingénierie, cryptosécurité et développement Bitcoin Core conçoit les produits BitBox et fournit des services de conseil. Le BitBox02, hardware wallet de deuxième génération, permet aux particuliers de stocker, protéger et utiliser facilement des cryptomonnaies. Son compagnon, la BitBoxApp, offre une solution tout-en-un pour gérer vos actifs numériques en toute sécurité et simplement.

This post was translated with the help of AI