Le 30 juillet, un attaquant a vidé 1 196 adresses Bitcoin en 41 minutes. Un peu plus de 1 082 bitcoins, environ 70 millions de dollars. Aucune des victimes n'avait cliqué sur quoi que ce soit.

Elles avaient acheté un Coldcard, le portefeuille matériel de la société canadienne Coinkite, l'appareil que les puristes du bitcoin recommandent depuis des années précisément parce qu'il ne se connecte jamais à Internet.

Un portefeuille matériel fabrique une seed, la suite de mots dont dérivent toutes vos clés. Toute la sécurité repose sur un seul point : que cette suite soit réellement imprévisible. La puce embarque pour ça un générateur d'aléatoire physique.

En mars 2021, le firmware 4.0.0 a introduit une erreur d'intégration. Coldcard voulait désactiver le générateur intégré de MicroPython pour utiliser le sien, et a donc défini le paramètre MICROPY_HW_ENABLE_RNG à zéro. Sauf que la bibliothèque libngu vérifiait seulement si ce paramètre existait, pas la valeur qu'il portait. Il existait. Le test passait.

Pendant cinq ans, chaque tirage est donc passé par Yasmarang, un générateur pseudo-aléatoire non cryptographique dont l'état de départ venait de trois choses : l'identifiant 32 bits de la puce, un registre de minuterie et l'horloge interne. Rien de secret là-dedans, et plus la moindre entropie fraîche ensuite.

Les Mk3 se retrouvaient avec une quarantaine de bits d'imprévisibilité au lieu des 128 promis, les Mk4, Mk5 et Q avec 72. Pour ces derniers, l'ensemble des clés que l'appareil pouvait produire tombait à quelques milliards de combinaisons.

À ce niveau, il n'y a plus rien à pirater. L'attaquant génère les seeds candidates sur sa propre machine, calcule les adresses que chacune produirait, et les compare à la blockchain, publique par construction. Quand une adresse contient des fonds, il tient la clé. Aucun appareil n'a jamais été touché.

Coinkite a publié un firmware d'urgence le 31 juillet pour tous les modèles concernés. Attention au contresens qui coûte cher : la mise à jour ne répare pas une seed déjà créée. Il faut en générer une nouvelle et y déplacer les fonds. Les configurations multisignature, où le Coldcard n'est qu'une clé parmi plusieurs, sont largement épargnées.

Rodolfo Novak, le patron de Coinkite, a écrit qu'il était désolé et dévasté, et assume. Il avance aussi que l'attaquant a peut-être déniché la faille avec une IA, sans en apporter la preuve, tout en reconnaissant que sa propre revue de code assistée par IA était passée à côté.

Cinq ans qu'un zéro traînait dans un fichier de configuration, sur l'appareil vendu comme le plus sûr du marché. Le pire endroit possible pour ce genre d'oubli.

Source : The Hacker News

Si vous avez déjà envoyé un lien à usage unique qui est arrivé mort chez votre collègue, c'est probablement la prévisualisation de la messagerie qui a ouvert le lien en premier et qui a cramé le secret accompagnant le lien.

La bonne nouvelle c'est que Oğuzhan Karacabay vient de publier une grosse mise à jour d' OTI , son service open source auto-hébergeable qui génère des liens de partage consultables une seule fois, avec chiffrement dans le navigateur.

Vous collez un mot de passe, une clé d'API ou un bout de config dans OTI, le navigateur chiffre, le serveur lui ne stocke que du charabia, et le destinataire reçoit une jolie URL qui ne fonctionnera bien qu'une fois.

Ce qui change, c'est que le lien ne meurt plus tout seul. En chargeant la page, votre destinataire voit un compte à rebours et un bouton "Decrypt Message", rien d'autre. Du coup, tant que personne ne clique, le message continue son roupillon.

Comme ça, un bot qui déroule les URLs pour fabriquer une jolie vignette repart bredouille. Après si c'est un vrai scanner de sécurité qui charge vraiment la page dans un navigateur automatisé, vous ne pourrez pas éviter le problème.

L'autre nouveauté dans OTI c'est à la création d'un nouveau lien. Le service vous génère en fait 2 liens. Il y a celui que vous envoyez et un second que vous gardez pour vous. Ce dernier vous permettra de consulter l'état du message sans jamais afficher son contenu.

Côté crypto, le contenu est chiffré en AES-256-GCM via WebCrypto, et cette clé AES est elle-même emballée dans une paire RSA-2048 générée dans votre navigateur. La clé privée voyage dans le fragment de l'URL, la partie après le #, que les navigateurs n'envoient jamais au serveur.

Le principe zero-knowledge utilisé par OTI est quasi le même que celui de PrivateBin ou d' Enclosed où la clé ne quitte jamais le navigateur.

Par contre, ça donne des liens obèses puisque le mien faisait 1825 caractères, dont 1728 rien que pour le fragment, et c'est déjà compressé en zlib. Bon courage donc pour le dicter au téléphone ^^ (il y a un QR code, heureusement !)

Le reste, c'est du confort... Fichiers .txt jusqu'à 100 Ko validés dans le navigateur avant chiffrement, mot de passe optionnel par-dessus, expiration au choix entre 5 minutes et 7 jours, limitation de débit via Redis et une tâche planifiée qui balaie les secrets périmés toutes les 30 minutes.

Pour l'héberger, c'est de l'AdonisJS 6 en TypeScript avec Dockerfile, docker-compose et migrations fournis, en licence MIT. Redis peut céder sa place au limiteur en mémoire si vous montez juste un petit truc perso.

Notez quand même que pour le moment, le projet n'a pas été audité et est maintenu par un gars tout seul, donc évitez de l'utiliser pour des secrets d'État.

La démo est en ligne si vous voulez essayer avant d'installer.