Trail of Bits : MPC, TEE et la cryptographie des wallets

Au premier semestre 2026, la plus grosse ligne de pertes du secteur crypto n’a pas été provoquée par un bug de Solidity. Selon le rapport Hack3d de CertiK, la compromission de wallets et de clés privées a coûté près de 444 millions de dollars (environ 400 millions d’euros) sur 33 incidents seulement, ce qui en fait le vecteur le plus coûteux de la période. Les deux plus gros événements du semestre, la compromission de l’infrastructure RPC de Kelp DAO (291 millions de dollars) et la brèche de Drift Protocol (285 millions de dollars), toutes deux survenues en avril, ont représenté à elles seules près de 44 % des pertes totales. Ni l’une ni l’autre n’était un bug de contrat intelligent.

Autrement dit, l’argent ne sort plus par le code, mais par la couche qui gère les clés : la cryptographie. En France, Trail of Bits est surtout connu comme l’auteur de Slither et d’Echidna, les outils qui scrutent le Solidity. Mais le cabinet new-yorkais fait tourner une seconde practice, distincte, dédiée à cette couche-là : signatures à seuil (MPC), enclaves matérielles (TEE), génération de nonces, hachage, séparation de domaine. C’est elle qui regarde ce qui casse quand la clé n’existe jamais vraiment en un seul endroit.

Deux publications récentes de ce desk cryptographie, parues à trois semaines d’intervalle, cartographient précisément ces points de rupture : « Don’t let TEEs break your MPC » le 25 septembre 2026, puis « SequenceHash » le 2 octobre. Les deux décrivent, chacune à sa manière, la même famille de bugs : un objet cryptographique réutilisé ou mal rattaché à son contexte. Voici ce que cela veut dire, chiffré en euros et replacé dans le cadre de l’AMF et de MiCA.

L’argent ne sort plus par le Solidity

Le basculement est net dans les données 2026. Les chiffres de CertiK pour le premier semestre totalisent plus de 1,31 milliard de dollars (près de 1,2 milliard d’euros) de pertes sur 344 incidents. Les vulnérabilités de code restent la catégorie la plus fréquente en nombre, avec 204 incidents recensés, mais elles sont loin d’être les plus chères. Ce sont la compromission de clés et le phishing qui raflent le haut du tableau.

Le phishing, deuxième poste le plus coûteux, a pesé environ 366 millions de dollars (près de 325 millions d’euros) sur 63 incidents ; son volume d’incidents a chuté de plus de moitié sur un an, mais les pertes n’ont reculé que d’une dizaine de pour cent, signe d’un hameçonnage devenu chirurgical. Le schéma se répète : on attaque des personnes et des processus, pas des lignes de code. C’est exactement la logique du hack qui n’a plus besoin de pont, car plus la valeur se concentre derrière des clés, moins l’attaquant a besoin de casser un contrat.

Ce glissement a une conséquence directe pour le lecteur : l’étiquette « audité » rassure surtout sur le code, alors que la plupart des gros sinistres de 2026 se jouent ailleurs, sur la façon dont les clés sont générées, réparties et sauvegardées. C’est précisément ce terrain, mal couvert par les audits classiques, qu’occupe la practice cryptographie de Trail of Bits.

La practice cryptographie de Trail of Bits, à ne pas confondre avec l’audit de smart contracts

Fondé en 2012 à New York, Trail of Bits a deux visages. Le premier, le plus visible côté DeFi, est celui de la revue de contrats intelligents : l’analyseur statique Slither, le fuzzer Echidna et son successeur Medusa, tout l’outillage qui traque les bugs de Solidity. Le second est une practice cryptographie à part entière, qui n’audite pas du Solidity mais les primitives elles-mêmes : preuves à divulgation nulle (ZK), calcul multipartite (MPC), post-quantique, et les briques classiques qui soutiennent tout le reste.

L’équipe est volontairement bicéphale, selon la page du cabinet : « Half the team holds PhDs in cryptography and the other half ships production cryptographic code in Rust, Go, and C », avec les deux profils présents sur chaque mission. Dirigée par Jim Miller, cette practice revendique 63 missions de cryptographie publiques et 345 semaines-personnes d’effort cumulé. Elle publie aussi gratuitement ZKDocs (un manuel sur les systèmes de preuve), l’analyseur de circuits ZK Circomspect, des règles CodeQL dédiées au chiffrement, et surtout un article très cité, « Weak Fiat-Shamir Attacks on Modern Proof Systems », sur lequel nous reviendrons.

La distinction n’est pas cosmétique. Sur le marché de l’audit, détaillé dans notre comparatif des cabinets d’audit crypto, la plupart des acteurs vendent d’abord de la revue de contrats. Faire relire un schéma de signature, la génération d’aléa ou le rattachement d’une preuve à son contexte demande un autre métier, et c’est précisément ce métier qui décide si une clé reste secrète. Un rapport d’audit de Solidity, aussi solide soit-il, ne dit rien sur la façon dont les clés sont fabriquées, réparties et stockées.

Le nonce, ce petit nombre qui vide un wallet

Commençons par la brique la plus simple et la plus traîtresse : le nonce. Chaque signature ECDSA, celle qui autorise une transaction Bitcoin ou Ethereum, consomme un nombre secret à usage unique. S’il est vraiment unique et imprévisible, tout va bien. Mais si deux signatures du même wallet partagent le même nonce, n’importe qui peut récupérer la clé privée par une simple opération algébrique. Pire, il n’est même pas nécessaire de réutiliser le nonce à l’identique : un nonce seulement biaisé suffit, via des attaques par réseaux euclidiens, comme l’a formalisé l’article « Biased Nonce Sense ».

Ce n’est pas théorique. En 2013, un défaut du générateur d’aléa SecureRandom d’Android a produit des nonces répétés et vidé des wallets Bitcoin, parce que plusieurs applications tiraient le même nombre secret pour des signatures différentes. La parade existe depuis longtemps : la RFC 6979 impose un nonce déterministe, dérivé de la clé et du message, qui supprime le besoin d’un bon générateur aléatoire. Sauf qu’il y a un piège : cette recette ne vaut que pour un signataire unique sur une seule machine. Dès qu’on répartit la signature entre plusieurs parties (le MPC) ou qu’on la déplace dans une enclave matérielle (le TEE), le problème du nonce réapparaît, sous une forme bien plus subtile.

MPC : la clé privée qui n’existe jamais

Le calcul multipartite (multi-party computation, MPC) a été adopté massivement par les dépositaires institutionnels parce qu’il supprime le point de défaillance unique. Avec une signature à seuil, selon Fireblocks, « the full private key is never created, never stored, and never assembled at any point » : la clé complète n’est jamais fabriquée, jamais stockée, jamais reconstituée, ni à la création du wallet, ni au moment de signer. Chaque partie détient un fragment, et « an attacker with access to one key share cannot sign a transaction or reconstruct the private key » ; il faut compromettre un quorum de fragments simultanément, dans plusieurs environnements durcis et indépendants.

L’autre atout du MPC est qu’il opère « at the cryptographic layer rather than the blockchain protocol layer », donc de la même façon sur Bitcoin, Ethereum, Solana et plus de 200 réseaux, là où un multisig on-chain dépend du protocole de chaque chaîne. Fireblocks dit avoir traité plus de 16 000 milliards de dollars de transactions et créé plus de 750 millions de wallets sur cette base, et rappelle que les régulateurs ont « explicitly recognized MPC as a valid model for self-custody wallets » dès 2019. Qu’on garde ses fonds chez un dépositaire, sur un perp DEX ou dans un wallet MPC personnel, la vraie question reste la même : qui peut, au bout du compte, faire bouger l’argent.

Dans le détail, un wallet MPC repose sur deux chorégraphies délicates. La génération de clé distribuée (DKG) crée les parts sans jamais assembler la clé, et le rafraîchissement périodique des parts (proactive refresh) change les fragments sans changer l’adresse, de sorte qu’un attaquant qui aurait volé une part hier se retrouve avec un fragment périmé. Ces protocoles sont élégants sur le papier, mais chaque message échangé, chaque reprise après une panne, chaque sauvegarde est une occasion de rejouer un état ou de biaiser une contribution. C’est cette surface d’interaction, invisible dans un simple wallet à clé unique, que la couche cryptographique doit défendre.

Mais cette élégance a un coût caché. En distribuant le secret, le MPC déplace aussi le risque vers des failles cryptographiques fines, très loin du banal « quelqu’un a volé le fichier de clé ». Le secret ne se vole plus, il se déduit d’un fragment réutilisé, d’une donnée mal validée ou d’un protocole rejoué. Voici où ces failles se logent.

Sept familles de pièges : le catalogue mpcsec.org

Pour cartographier ces failles, une partie de la communauté cryptographique, dont des chercheurs de Trail of Bits aux côtés de zkSecurity, Partisia et Zama, maintient mpcsec.org, un catalogue de bugs MPC réels né lors de l’atelier RWMPC 2025. Il classe les pièges connus en sept familles, du contrôle des entrées aux primitives cryptographiques. Le fil rouge est toujours le même : beaucoup de ces bugs finissent par ramener à une seule faute, un fragment ou un artefact réutilisé hors de son contexte.

Quand le TEE casse le MPC

Première publication-choc de l’automne : le 25 septembre, le cryptographe de Trail of Bits Paul Bottinelli signe « Don’t let TEEs break your MPC ». Le constat de départ est que de plus en plus d’opérateurs font tourner leurs signataires MPC à l’intérieur d’enclaves matérielles (TEE), pour ajouter une protection côté exécution. Le problème, c’est que les deux modèles reposent sur des hypothèses de confiance opposées : le MPC répartit la confiance entre plusieurs parties, tandis qu’un TEE centralise la confiance dans le fabricant du matériel qui contrôle le certificat racine.

Rappelons ce qu’est un TEE. Une enclave matérielle est une zone scellée du processeur, censée exécuter du code à l’abri du système d’exploitation hôte, et prouver à distance, par un mécanisme d’attestation, qu’elle fait bien tourner le bon programme. Sur le papier, c’est l’endroit rêvé pour abriter un signataire, puisque même un serveur compromis ne verrait pas les secrets manipulés à l’intérieur. Le raisonnement tient, à une condition près : que l’attestation et l’environnement soient irréprochables.

Bottinelli décrit quatre modes de défaillance : des mesures d’attestation incomplètes, des vérifications omises dans le processus d’attestation, un durcissement insuffisant de l’environnement, et surtout la disponibilité des données et des sauvegardes. C’est ce dernier point qui fait le lien avec le nonce. Un hôte malveillant qui contrôle le stockage peut rejouer un état passé : « the host could roll back the filesystem state after the signer deletes a pre-signature file. When the TEE later fetches the pre-signature contained in that file, the signer essentially reuses their nonce share, which leads to a disclosure of the private key share. »

Traduit : on revient à la case 2013, mais par la petite porte du système de fichiers. L’enclave n’a rien de cassé en apparence, l’attestation est valide, et pourtant la part de clé fuit parce qu’un fragment a été réutilisé. La recommandation de Trail of Bits est sans ambiguïté : le TEE doit être une couche de défense en profondeur, « a defense-in-depth layer rather than a substitute for a sound protocol », et son attestation doit être liée à l’identité des parties du MPC, jamais un substitut à un protocole sain. Le message dérange parce qu’il vise une parade que beaucoup d’acteurs présentent comme la solution ultime.

SequenceHash : hacher proprement, un problème plus vieux qu’il n’y paraît

Deuxième publication, le 2 octobre : Opal Wright présente SequenceHash, une réponse à un problème que presque tout le monde croit trivial, hacher plusieurs valeurs ensemble. La méthode naïve, concaténer puis hacher, crée une ambiguïté dangereuse : le haché de (« Test 0 », « Test 1 », « Test 2 ») peut être identique à celui de (« Test 0Test 1 », « Test 2 »). Les frontières entre les éléments disparaissent, et ce mélange peut saboter des protocoles entiers, en particulier les transformations de Fiat-Shamir au cœur des preuves à divulgation nulle.

SequenceHash corrige cela avec trois idées simples : un suffixe de longueur de 128 bits accolé à chaque élément, qui rend les frontières non ambiguës ; une construction à double hachage, qui neutralise les attaques par extension de longueur sur SHA-256 et SHA-512 ; et l’indépendance vis-à-vis de la fonction de hachage, là où le TupleHash du NIST reste verrouillé sur Keccak. Sa variante à clé, SequenceMAC, exige des clés d’au moins 32 octets. Le tout est désormais versé au C2SP (Community Cryptography Specification Project), avec des implémentations de référence en Rust, Go et Python.

L’intérêt dépasse le simple détail d’ingénierie. En rendant le hachage multiple non ambigu et en offrant des chaînes de personnalisation, SequenceHash fournit un outil propre de séparation de domaine, exactement le manque pointé par la famille « rattachement au contexte » de mpcsec.org. Les deux publications de l’automne se répondent donc : l’une montre comment la couche cryptographique casse, l’autre fournit une brique pour la réparer.

La séparation de domaine, ou pourquoi « ab,c » ne doit pas égaler « a,bc »

La séparation de domaine consiste à garantir qu’un même objet cryptographique ne puisse pas être interprété dans deux contextes différents. Les chaînes de personnalisation de SequenceHash en sont une mise en œuvre directe : pour des entrées identiques, deux chaînes différentes produisent des sorties sans aucun lien, ce qui permet de rattacher un haché, ou une preuve, à un contexte précis (un type de preuve donné, une exécution de protocole donnée). Sans ce rattachement, un attaquant peut rejouer un artefact valide dans un cadre où il ne devrait pas l’être.

Reliez maintenant les points. La réutilisation de nonce, la réutilisation de pré-signature dans un TEE, la séparation de domaine manquante dans un protocole MPC, et les attaques de Fiat-Shamir faibles décrites dans l’article phare de Trail of Bits, sont toutes des variantes d’une seule et même faute : un artefact cryptographique employé dans le mauvais contexte, ou réutilisé là où il devait rester unique. C’est cette grammaire commune, plus que n’importe quelle faille isolée, qui explique pourquoi la couche cryptographique demande des yeux spécialisés.

Revue contre scan : ce qu’un outil automatique ne verra pas

Aucune de ces fautes ne se détecte en lançant un scanner. Elles tiennent à des hypothèses de confiance et à des choix de conception, pas à des motifs de code faciles à repérer. David Schwed, directeur des opérations de SVRN et fondateur du master de cybersécurité de l’université Yeshiva, résume la limite de l’outillage automatique dans une interview à CoinDesk : « ‘Claude, audit my smart contract, make no mistakes’ is not a security program. » Demander à une IA de tout relire sans erreur, autrement dit, n’est pas une démarche de sécurité.

Dans le même article, Alexander Urbelis, directeur de la sécurité des systèmes d’information d’ENS Labs, pointe la nature des bugs qui vident les trésoreries : « The bugs that drain treasuries often turn on intent and adversarial incentives », ils dépendent de l’intention et des incitations de l’adversaire. C’est précisément le terrain d’une revue humaine. Dan Guido, cofondateur de Trail of Bits, formule de son côté la philosophie maison dans un entretien à Decential : « I don’t ever want to find the same bug twice », une obsession qui a justement motivé la création de leurs outils d’analyse statique et de vérification.

Guido est tout aussi tranchant sur les langages de la blockchain, qu’il accuse d’avoir « reinvented every security issue that we eliminated from modern languages like Rust and Go and Swift ». Le message est cohérent : les outils, y compris ceux à base d’IA, accélèrent le travail et balaient le trivial, mais c’est le jugement d’un cryptographe qui décide si un schéma de signature tient réellement face à un adversaire.

Ce partage des rôles a aussi une logique économique. Un scanner tourne en continu pour quelques euros et rattrape les fautes connues ; une revue humaine de cryptographie coûte cher et se réserve aux hypothèses d’adversaire, aux invariants de protocole et aux cas limites que personne n’a encore nommés. Confondre les deux, c’est payer le prix d’un audit pour la seule couverture d’un scan.

Combien part réellement par la couche cryptographique

Remettons des euros sur tout cela. Les deux incidents d’avril, Kelp DAO et Drift, cumulent à eux seuls 576 millions de dollars, soit plus de 515 millions d’euros, pour deux compromissions qui n’ont touché ni un contrat ni une preuve, mais la gestion des clés et de l’infrastructure. Sur l’ensemble du semestre, la compromission de wallets a coûté en moyenne plus de 13 millions de dollars (environ 12 millions d’euros) par incident, très au-dessus du coût moyen d’un bug de code. Le petit nombre de ces incidents (33) masque donc leur poids réel : ce sont les plus rares et les plus chers.

Et l’enjeu grandit avec le marché. Au 13 octobre 2026, la capitalisation totale des cryptomonnaies tourne autour de 2 600 milliards d’euros, avec un Bitcoin à près de 74 400 euros et un Ether autour de 2 258 euros, selon CoinGecko. À mesure que le marché digère les décisions de la Fed, un sujet que nous suivons dans notre analyse de la réaction du marché à la banque centrale, la valeur stockée derrière ces clés remonte, et avec elle le gain potentiel d’une seule part de clé qui fuit. Plus la capitalisation monte, plus la couche cryptographique devient une cible rentable.

ZK et post-quantique : la prochaine surface

La même grammaire de bugs s’étend aux deux chantiers les plus actifs de la cryptographie appliquée. Les preuves à divulgation nulle, désormais au cœur des rollups et des protocoles de confidentialité, reposent sur des transformations de Fiat-Shamir : mal rattachées à leur contexte, elles deviennent falsifiables, ce que l’article « Weak Fiat-Shamir Attacks on Modern Proof Systems » de Trail of Bits a documenté en détail. C’est, à l’échelle d’un système de preuve, la même faute que le nonce réutilisé.

La migration post-quantique ajoute, elle, de nouvelles primitives (les standards ML-KEM et ML-DSA du NIST) et donc de nouvelles implémentations à relire, chacune avec ses propres pièges de nonce, de hachage et de séparation de domaine. La surface d’attaque ne se réduit pas, elle se déplace. C’est pourquoi la practice cryptographie de Trail of Bits couvre d’un même tenant ZK, MPC et post-quantique : ce sont trois dialectes d’un même langage, et un spécialiste de l’un repère souvent la faute de l’autre.

Ce que l’AMF et MiCA encadrent (et surtout pas)

Côté réglementaire, il faut être clair : aucune autorité, ni l’AMF, ni l’ESMA via MiCA, n’impose ni n’accrédite un audit de cryptographie. MiCA encadre les prestataires de services sur crypto-actifs (PSCA) et les émetteurs ; son article 75 fixe un régime de responsabilité pour la conservation, et le règlement DORA impose une résilience opérationnelle informatique. Mais aucun texte n’exige qu’un schéma de signature à seuil ou une enclave matérielle soit relu par un cryptographe, et un protocole pleinement décentralisé échappe largement au périmètre.

La qualité de cette couche reste donc policée par la seule réputation. Le calendrier français ajoute une pression de conformité : la période transitoire des PSAN sous l’ancien régime PACTE s’est achevée au 1er juillet 2026, et l’AMF a prévenu que les acteurs non conformes doivent organiser une sortie ordonnée. Rien de tout cela, cependant, ne garantit qu’un wallet MPC a été audité là où il compte vraiment, au niveau du protocole cryptographique. Le tampon réglementaire couvre l’enregistrement du prestataire, pas la solidité de ses maths.

Faute d’accréditation officielle, le marché s’en remet à des signaux indirects : la réputation du cabinet, la publication intégrale du rapport d’audit, la présence de cryptographes nommés dans l’équipe, ou encore le recours à plusieurs relectures indépendantes. Aucun de ces signaux n’a de valeur juridique, mais leur accumulation reste, en 2026, la meilleure approximation d’une garantie que la couche cryptographique a été regardée sérieusement.

Pour les builders : construire la couche cryptographique

Pour une équipe qui construit un dépositaire, un wallet à seuil ou un protocole à base de preuves, les leçons de l’automne se résument en quelques principes concrets. D’abord, documenter les invariants de nonce, de précision et de séparation de domaine comme des propriétés formelles, pas comme de simples commentaires dans le code. Ensuite, traiter tout TEE comme une défense en profondeur, jamais comme un remplacement du protocole, et lier son attestation à l’identité des parties.

• Utiliser un hachage multiple non ambigu (longueur explicite, double hachage, chaînes de personnalisation) plutôt qu’une simple concaténation.
• Dériver les nonces de façon déterministe pour un signataire unique, et vérifier l’absence de réutilisation de part dès qu’on passe au MPC.
• Maintenir des campagnes de fuzzing continues et une couverture de tests proche de 100 % sur les chemins cryptographiques.
• Faire relire la cryptographie par des cryptographes, séparément de la revue du Solidity.

Ces gestes ne sont pas gratuits. Une mission de cryptographie sérieuse se compte en semaines-personnes et en dizaines de milliers d’euros, mais c’est le prix de l’assurance qu’une part de clé ne fuira pas par le système de fichiers, un soir de sauvegarde mal gérée.

Pour les détenteurs : la bonne question à poser

Pour un particulier ou une trésorerie d’entreprise, le réflexe utile est de déplacer la question. Un badge « audité » ou une certification SOC 2 renseignent rarement sur ce qui a réellement été relu. La vraie interrogation n’est pas « le contrat a-t-il été audité », mais « qui a relu la gestion des clés, le schéma MPC, la génération de nonces et l’attestation du TEE ».

Le MPC et les enclaves ne sont pas des baguettes magiques : ils déplacent le risque vers une couche que peu de monde sait auditer. Que vous laissiez vos fonds sur une plateforme, dont nous avons décortiqué le prix caché derrière le volume, ou dans un wallet à seuil, la constante de 2026 est que l’argent sort par la clé, pas par le code. Lire au-delà du badge, c’est se demander qui a regardé les maths.

Foire aux questions

Qu’est-ce que la practice cryptographie de Trail of Bits ?

C’est l’équipe de Trail of Bits dédiée aux primitives cryptographiques (preuves à divulgation nulle, MPC, post-quantique, briques classiques), distincte de la revue de contrats intelligents. Dirigée par Jim Miller, elle revendique 63 missions publiques et 345 semaines-personnes, et publie des ressources gratuites comme ZKDocs et Circomspect.

Pourquoi un TEE peut-il compromettre un wallet MPC ?

Parce que le MPC répartit la confiance tandis qu’un TEE la centralise dans le fabricant du matériel. Selon Trail of Bits, un hôte malveillant peut rejouer l’état du système de fichiers (rollback) pour forcer un signataire à réutiliser sa part de nonce, ce qui révèle sa part de clé privée. Le TEE doit donc rester une défense en profondeur, pas un substitut au protocole.

Qu’est-ce que la réutilisation de nonce et pourquoi est-elle dangereuse ?

Une signature ECDSA utilise un nombre secret à usage unique, le nonce. Si deux signatures partagent le même nonce, ou même un nonce biaisé, la clé privée se récupère par calcul. Le bug Android de 2013 a vidé des wallets Bitcoin de cette façon ; la RFC 6979 impose des nonces déterministes, mais cette parade ne suffit plus dès qu’on répartit la signature en MPC ou dans un TEE.

Qu’apporte SequenceHash ?

SequenceHash, publié par Trail of Bits le 2 octobre 2026, rend le hachage de plusieurs valeurs non ambigu grâce à un encodage de longueur et un double hachage, indépendamment de la fonction de hachage utilisée. Il fournit aussi des chaînes de personnalisation pour la séparation de domaine, et est versé au projet de spécification C2SP.

L’AMF ou MiCA imposent-ils un audit de cryptographie ?

Non. Ni l’AMF ni l’ESMA via MiCA n’exigent ou n’accréditent un audit de cryptographie. MiCA encadre les prestataires et les émetteurs, son article 75 traite de la responsabilité de conservation et DORA de la résilience informatique, mais aucun texte n’impose la relecture d’un schéma MPC ou d’une enclave par un cryptographe. La qualité reste policée par la réputation.

Par la rédaction de HOGE Wire, desk sécurité.