{"id":788,"date":"2026-10-13T22:32:28","date_gmt":"2026-10-13T22:32:28","guid":{"rendered":"https:\/\/hoge.gg\/fr\/trail-of-bits-mpc-tee-cryptographie-wallets-2026\/"},"modified":"2026-10-13T22:32:28","modified_gmt":"2026-10-13T22:32:28","slug":"trail-of-bits-mpc-tee-cryptographie-wallets-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/fr\/trail-of-bits-mpc-tee-cryptographie-wallets-2026\/","title":{"rendered":"Trail of Bits : MPC, TEE et la cryptographie des wallets"},"content":{"rendered":"

Au premier semestre 2026, la plus grosse ligne de pertes du secteur crypto n’a pas \u00e9t\u00e9 provoqu\u00e9e par un bug de Solidity. Selon le rapport Hack3d de CertiK, la compromission de wallets et de cl\u00e9s priv\u00e9es a co\u00fbt\u00e9 pr\u00e8s de 444 millions de dollars (environ 400 millions d’euros) sur 33 incidents seulement, ce qui en fait le vecteur le plus co\u00fbteux de la p\u00e9riode. Les deux plus gros \u00e9v\u00e9nements du semestre, la compromission de l’infrastructure RPC de Kelp DAO (291 millions de dollars) et la br\u00e8che de Drift Protocol (285 millions de dollars), toutes deux survenues en avril, ont repr\u00e9sent\u00e9 \u00e0 elles seules pr\u00e8s de 44 % des pertes totales. Ni l’une ni l’autre n’\u00e9tait un bug de contrat intelligent.<\/p>

Autrement dit, l’argent ne sort plus par le code, mais par la couche qui g\u00e8re les cl\u00e9s : 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\u00e9di\u00e9e \u00e0 cette couche-l\u00e0 : signatures \u00e0 seuil (MPC), enclaves mat\u00e9rielles (TEE), g\u00e9n\u00e9ration de nonces, hachage, s\u00e9paration de domaine. C’est elle qui regarde ce qui casse quand la cl\u00e9 n’existe jamais vraiment en un seul endroit.<\/p>

Deux publications r\u00e9centes de ce desk cryptographie, parues \u00e0 trois semaines d’intervalle, cartographient pr\u00e9cis\u00e9ment ces points de rupture : \u00ab Don’t let TEEs break your MPC \u00bb le 25 septembre 2026, puis \u00ab SequenceHash \u00bb le 2 octobre. Les deux d\u00e9crivent, chacune \u00e0 sa mani\u00e8re, la m\u00eame famille de bugs : un objet cryptographique r\u00e9utilis\u00e9 ou mal rattach\u00e9 \u00e0 son contexte. Voici ce que cela veut dire, chiffr\u00e9 en euros et replac\u00e9 dans le cadre de l’AMF et de MiCA.<\/p>

L’argent ne sort plus par le Solidity<\/h2>

Le basculement est net dans les donn\u00e9es 2026. Les chiffres de CertiK<\/a> pour le premier semestre totalisent plus de 1,31 milliard de dollars (pr\u00e8s de 1,2 milliard d’euros) de pertes sur 344 incidents. Les vuln\u00e9rabilit\u00e9s de code restent la cat\u00e9gorie la plus fr\u00e9quente en nombre, avec 204 incidents recens\u00e9s, mais elles sont loin d’\u00eatre les plus ch\u00e8res. Ce sont la compromission de cl\u00e9s et le phishing qui raflent le haut du tableau.<\/p>

Le phishing, deuxi\u00e8me poste le plus co\u00fbteux, a pes\u00e9 environ 366 millions de dollars (pr\u00e8s de 325 millions d’euros) sur 63 incidents ; son volume d’incidents a chut\u00e9 de plus de moiti\u00e9 sur un an, mais les pertes n’ont recul\u00e9 que d’une dizaine de pour cent, signe d’un hame\u00e7onnage devenu chirurgical. Le sch\u00e9ma se r\u00e9p\u00e8te : 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<\/a>, car plus la valeur se concentre derri\u00e8re des cl\u00e9s, moins l’attaquant a besoin de casser un contrat.<\/p>

Vecteur<\/th>Pertes H1 2026<\/th>Incidents<\/th>Nature<\/th><\/tr><\/thead>
Compromission de wallet \/ cl\u00e9 priv\u00e9e<\/td>~444 M$ (~400 M\u20ac)<\/td>33<\/td>Cl\u00e9s et back-ends, pas le code<\/td><\/tr>
Phishing<\/td>~366 M$ (~325 M\u20ac)<\/td>63<\/td>Ing\u00e9nierie sociale cibl\u00e9e<\/td><\/tr>
Vuln\u00e9rabilit\u00e9s de code<\/td>Co\u00fbt total bien moindre<\/td>204<\/td>Le plus grand nombre d’incidents<\/td><\/tr>
Total semestre<\/td>~1,31 Md$ (~1,17 Md\u20ac)<\/td>344<\/td>Dont Kelp DAO + Drift ~44 %<\/td><\/tr><\/tbody><\/table>
Source : CertiK Hack3d H1 2026. Conversions en euros au cours du 13 octobre 2026.<\/figcaption><\/figure>

Ce glissement a une cons\u00e9quence directe pour le lecteur : l’\u00e9tiquette \u00ab audit\u00e9 \u00bb rassure surtout sur le code, alors que la plupart des gros sinistres de 2026 se jouent ailleurs, sur la fa\u00e7on dont les cl\u00e9s sont g\u00e9n\u00e9r\u00e9es, r\u00e9parties et sauvegard\u00e9es. C’est pr\u00e9cis\u00e9ment ce terrain, mal couvert par les audits classiques, qu’occupe la practice cryptographie de Trail of Bits.<\/p>

La practice cryptographie de Trail of Bits, \u00e0 ne pas confondre avec l’audit de smart contracts<\/h2>

Fond\u00e9 en 2012 \u00e0 New York, Trail of Bits a deux visages. Le premier, le plus visible c\u00f4t\u00e9 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<\/a> \u00e0 part enti\u00e8re, qui n’audite pas du Solidity mais les primitives elles-m\u00eames : preuves \u00e0 divulgation nulle (ZK), calcul multipartite (MPC), post-quantique, et les briques classiques qui soutiennent tout le reste.<\/p>

L’\u00e9quipe est volontairement bic\u00e9phale, selon la page du cabinet : \u00ab Half the team holds PhDs in cryptography and the other half ships production cryptographic code in Rust, Go, and C \u00bb, avec les deux profils pr\u00e9sents sur chaque mission. Dirig\u00e9e par Jim Miller, cette practice revendique 63 missions de cryptographie publiques et 345 semaines-personnes d’effort cumul\u00e9. Elle publie aussi gratuitement ZKDocs (un manuel sur les syst\u00e8mes de preuve), l’analyseur de circuits ZK Circomspect, des r\u00e8gles CodeQL d\u00e9di\u00e9es au chiffrement, et surtout un article tr\u00e8s cit\u00e9, \u00ab Weak Fiat-Shamir Attacks on Modern Proof Systems \u00bb, sur lequel nous reviendrons.<\/p>

La distinction n’est pas cosm\u00e9tique. Sur le march\u00e9 de l’audit, d\u00e9taill\u00e9 dans notre comparatif des cabinets d’audit crypto<\/a>, la plupart des acteurs vendent d’abord de la revue de contrats. Faire relire un sch\u00e9ma de signature, la g\u00e9n\u00e9ration d’al\u00e9a ou le rattachement d’une preuve \u00e0 son contexte demande un autre m\u00e9tier, et c’est pr\u00e9cis\u00e9ment ce m\u00e9tier qui d\u00e9cide si une cl\u00e9 reste secr\u00e8te. Un rapport d’audit de Solidity, aussi solide soit-il, ne dit rien sur la fa\u00e7on dont les cl\u00e9s sont fabriqu\u00e9es, r\u00e9parties et stock\u00e9es.<\/p>

Le nonce, ce petit nombre qui vide un wallet<\/h2>

Commen\u00e7ons par la brique la plus simple et la plus tra\u00eetresse : le nonce. Chaque signature ECDSA, celle qui autorise une transaction Bitcoin ou Ethereum, consomme un nombre secret \u00e0 usage unique. S’il est vraiment unique et impr\u00e9visible, tout va bien. Mais si deux signatures du m\u00eame wallet partagent le m\u00eame nonce, n’importe qui peut r\u00e9cup\u00e9rer la cl\u00e9 priv\u00e9e par une simple op\u00e9ration alg\u00e9brique. Pire, il n’est m\u00eame pas n\u00e9cessaire de r\u00e9utiliser le nonce \u00e0 l’identique : un nonce seulement biais\u00e9 suffit, via des attaques par r\u00e9seaux euclidiens, comme l’a formalis\u00e9 l’article \u00ab Biased Nonce Sense \u00bb<\/a>.<\/p>

Ce n’est pas th\u00e9orique. En 2013, un d\u00e9faut du g\u00e9n\u00e9rateur d’al\u00e9a SecureRandom d’Android a produit des nonces r\u00e9p\u00e9t\u00e9s et vid\u00e9 des wallets Bitcoin, parce que plusieurs applications tiraient le m\u00eame nombre secret pour des signatures diff\u00e9rentes. La parade existe depuis longtemps : la RFC 6979<\/a> impose un nonce d\u00e9terministe, d\u00e9riv\u00e9 de la cl\u00e9 et du message, qui supprime le besoin d’un bon g\u00e9n\u00e9rateur al\u00e9atoire. Sauf qu’il y a un pi\u00e8ge : cette recette ne vaut que pour un signataire unique sur une seule machine. D\u00e8s qu’on r\u00e9partit la signature entre plusieurs parties (le MPC) ou qu’on la d\u00e9place dans une enclave mat\u00e9rielle (le TEE), le probl\u00e8me du nonce r\u00e9appara\u00eet, sous une forme bien plus subtile.<\/p>

MPC : la cl\u00e9 priv\u00e9e qui n’existe jamais<\/h2>

Le calcul multipartite (multi-party computation, MPC) a \u00e9t\u00e9 adopt\u00e9 massivement par les d\u00e9positaires institutionnels parce qu’il supprime le point de d\u00e9faillance unique. Avec une signature \u00e0 seuil, selon Fireblocks<\/a>, \u00ab the full private key is never created, never stored, and never assembled at any point \u00bb : la cl\u00e9 compl\u00e8te n’est jamais fabriqu\u00e9e, jamais stock\u00e9e, jamais reconstitu\u00e9e, ni \u00e0 la cr\u00e9ation du wallet, ni au moment de signer. Chaque partie d\u00e9tient un fragment, et \u00ab an attacker with access to one key share cannot sign a transaction or reconstruct the private key \u00bb ; il faut compromettre un quorum de fragments simultan\u00e9ment, dans plusieurs environnements durcis et ind\u00e9pendants.<\/p>

L’autre atout du MPC est qu’il op\u00e8re \u00ab at the cryptographic layer rather than the blockchain protocol layer \u00bb, donc de la m\u00eame fa\u00e7on sur Bitcoin, Ethereum, Solana et plus de 200 r\u00e9seaux, l\u00e0 o\u00f9 un multisig on-chain d\u00e9pend du protocole de chaque cha\u00eene. Fireblocks dit avoir trait\u00e9 plus de 16 000 milliards de dollars de transactions et cr\u00e9\u00e9 plus de 750 millions de wallets sur cette base, et rappelle que les r\u00e9gulateurs ont \u00ab explicitly recognized MPC as a valid model for self-custody wallets \u00bb d\u00e8s 2019. Qu’on garde ses fonds chez un d\u00e9positaire, sur un perp DEX<\/a> ou dans un wallet MPC personnel, la vraie question reste la m\u00eame : qui peut, au bout du compte, faire bouger l’argent.<\/p>

Dans le d\u00e9tail, un wallet MPC repose sur deux chor\u00e9graphies d\u00e9licates. La g\u00e9n\u00e9ration de cl\u00e9 distribu\u00e9e (DKG) cr\u00e9e les parts sans jamais assembler la cl\u00e9, et le rafra\u00eechissement p\u00e9riodique des parts (proactive refresh) change les fragments sans changer l’adresse, de sorte qu’un attaquant qui aurait vol\u00e9 une part hier se retrouve avec un fragment p\u00e9rim\u00e9. Ces protocoles sont \u00e9l\u00e9gants sur le papier, mais chaque message \u00e9chang\u00e9, chaque reprise apr\u00e8s une panne, chaque sauvegarde est une occasion de rejouer un \u00e9tat ou de biaiser une contribution. C’est cette surface d’interaction, invisible dans un simple wallet \u00e0 cl\u00e9 unique, que la couche cryptographique doit d\u00e9fendre.<\/p>

Mais cette \u00e9l\u00e9gance a un co\u00fbt cach\u00e9. En distribuant le secret, le MPC d\u00e9place aussi le risque vers des failles cryptographiques fines, tr\u00e8s loin du banal \u00ab quelqu’un a vol\u00e9 le fichier de cl\u00e9 \u00bb. Le secret ne se vole plus, il se d\u00e9duit d’un fragment r\u00e9utilis\u00e9, d’une donn\u00e9e mal valid\u00e9e ou d’un protocole rejou\u00e9. Voici o\u00f9 ces failles se logent.<\/p>

Mod\u00e8le<\/th>O\u00f9 vit la cl\u00e9<\/th>Ce qu’il faut compromettre<\/th>Couche<\/th><\/tr><\/thead>
Cl\u00e9 unique<\/td>Un seul fichier ou appareil<\/td>Ce fichier<\/td>Application<\/td><\/tr>
Multisig<\/td>N cl\u00e9s inscrites on-chain<\/td>M cl\u00e9s sur N<\/td>Protocole de chaque cha\u00eene<\/td><\/tr>
MPC (signature \u00e0 seuil)<\/td>Jamais reconstitu\u00e9e ; parts r\u00e9parties<\/td>Un quorum de parts<\/td>Couche cryptographique, toutes cha\u00eenes<\/td><\/tr><\/tbody><\/table>
Source : Fireblocks, \u00ab MPC vs Multi-Sig \u00bb.<\/figcaption><\/figure>

Sept familles de pi\u00e8ges : le catalogue mpcsec.org<\/h2>

Pour cartographier ces failles, une partie de la communaut\u00e9 cryptographique, dont des chercheurs de Trail of Bits aux c\u00f4t\u00e9s de zkSecurity, Partisia et Zama, maintient mpcsec.org<\/a>, un catalogue de bugs MPC r\u00e9els n\u00e9 lors de l’atelier RWMPC 2025. Il classe les pi\u00e8ges connus en sept familles, du contr\u00f4le des entr\u00e9es aux primitives cryptographiques. Le fil rouge est toujours le m\u00eame : beaucoup de ces bugs finissent par ramener \u00e0 une seule faute, un fragment ou un artefact r\u00e9utilis\u00e9 hors de son contexte.<\/p>

Famille<\/th>Ce qu’elle couvre<\/th><\/tr><\/thead>
Validation des entr\u00e9es<\/td>V\u00e9rifier qu’une donn\u00e9e re\u00e7ue d\u00e9code bien vers un objet alg\u00e9brique valide (points de courbe non valid\u00e9s, modules de Paillier accept\u00e9s sans preuve)<\/td><\/tr>
Rattachement au contexte<\/td>Emp\u00eacher qu’un artefact cryptographique soit rejou\u00e9 ou transplant\u00e9 d’une ex\u00e9cution \u00e0 l’autre (s\u00e9paration de domaine manquante)<\/td><\/tr>
Concurrence et \u00e9tat<\/td>G\u00e9rer les \u00e9carts par rapport au mod\u00e8le d’ex\u00e9cution prouv\u00e9<\/td><\/tr>
Sous-protocoles non s\u00fbrs<\/td>Garantir une diffusion et un transport authentifi\u00e9s corrects<\/td><\/tr>
Reprise et abandons<\/td>Traiter les \u00e9checs de protocole sans fuite (r\u00e9utilisation de pr\u00e9-signature)<\/td><\/tr>
Entr\u00e9es adaptatives<\/td>Emp\u00eacher une partie de biaiser sa contribution apr\u00e8s avoir vu celle des autres<\/td><\/tr>
Primitives cryptographiques<\/td>Corriger les failles des briques de base, ind\u00e9pendamment du protocole<\/td><\/tr><\/tbody><\/table>
Source : mpcsec.org, \u00ab Common MPC Pitfalls \u00bb.<\/figcaption><\/figure>

Quand le TEE casse le MPC<\/h2>

Premi\u00e8re publication-choc de l’automne : le 25 septembre, le cryptographe de Trail of Bits Paul Bottinelli signe \u00ab Don’t let TEEs break your MPC \u00bb<\/a>. Le constat de d\u00e9part est que de plus en plus d’op\u00e9rateurs font tourner leurs signataires MPC \u00e0 l’int\u00e9rieur d’enclaves mat\u00e9rielles (TEE), pour ajouter une protection c\u00f4t\u00e9 ex\u00e9cution. Le probl\u00e8me, c’est que les deux mod\u00e8les reposent sur des hypoth\u00e8ses de confiance oppos\u00e9es : le MPC r\u00e9partit la confiance entre plusieurs parties, tandis qu’un TEE centralise la confiance dans le fabricant du mat\u00e9riel qui contr\u00f4le le certificat racine.<\/p>

Rappelons ce qu’est un TEE. Une enclave mat\u00e9rielle est une zone scell\u00e9e du processeur, cens\u00e9e ex\u00e9cuter du code \u00e0 l’abri du syst\u00e8me d’exploitation h\u00f4te, et prouver \u00e0 distance, par un m\u00e9canisme d’attestation, qu’elle fait bien tourner le bon programme. Sur le papier, c’est l’endroit r\u00eav\u00e9 pour abriter un signataire, puisque m\u00eame un serveur compromis ne verrait pas les secrets manipul\u00e9s \u00e0 l’int\u00e9rieur. Le raisonnement tient, \u00e0 une condition pr\u00e8s : que l’attestation et l’environnement soient irr\u00e9prochables.<\/p>

Bottinelli d\u00e9crit quatre modes de d\u00e9faillance : des mesures d’attestation incompl\u00e8tes, des v\u00e9rifications omises dans le processus d’attestation, un durcissement insuffisant de l’environnement, et surtout la disponibilit\u00e9 des donn\u00e9es et des sauvegardes. C’est ce dernier point qui fait le lien avec le nonce. Un h\u00f4te malveillant qui contr\u00f4le le stockage peut rejouer un \u00e9tat pass\u00e9 : \u00ab 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. \u00bb<\/p>

Traduit : on revient \u00e0 la case 2013, mais par la petite porte du syst\u00e8me de fichiers. L’enclave n’a rien de cass\u00e9 en apparence, l’attestation est valide, et pourtant la part de cl\u00e9 fuit parce qu’un fragment a \u00e9t\u00e9 r\u00e9utilis\u00e9. La recommandation de Trail of Bits est sans ambigu\u00eft\u00e9 : le TEE doit \u00eatre une couche de d\u00e9fense en profondeur, \u00ab a defense-in-depth layer rather than a substitute for a sound protocol \u00bb, et son attestation doit \u00eatre li\u00e9e \u00e0 l’identit\u00e9 des parties du MPC, jamais un substitut \u00e0 un protocole sain. Le message d\u00e9range parce qu’il vise une parade que beaucoup d’acteurs pr\u00e9sentent comme la solution ultime.<\/p>

SequenceHash : hacher proprement, un probl\u00e8me plus vieux qu’il n’y para\u00eet<\/h2>

Deuxi\u00e8me publication, le 2 octobre : Opal Wright pr\u00e9sente SequenceHash<\/a>, une r\u00e9ponse \u00e0 un probl\u00e8me que presque tout le monde croit trivial, hacher plusieurs valeurs ensemble. La m\u00e9thode na\u00efve, concat\u00e9ner puis hacher, cr\u00e9e une ambigu\u00eft\u00e9 dangereuse : le hach\u00e9 de (\u00ab Test 0 \u00bb, \u00ab Test 1 \u00bb, \u00ab Test 2 \u00bb) peut \u00eatre identique \u00e0 celui de (\u00ab Test 0Test 1 \u00bb, \u00ab Test 2 \u00bb). Les fronti\u00e8res entre les \u00e9l\u00e9ments disparaissent, et ce m\u00e9lange peut saboter des protocoles entiers, en particulier les transformations de Fiat-Shamir au c\u0153ur des preuves \u00e0 divulgation nulle.<\/p>

SequenceHash corrige cela avec trois id\u00e9es simples : un suffixe de longueur de 128 bits accol\u00e9 \u00e0 chaque \u00e9l\u00e9ment, qui rend les fronti\u00e8res non ambigu\u00ebs ; une construction \u00e0 double hachage, qui neutralise les attaques par extension de longueur sur SHA-256 et SHA-512 ; et l’ind\u00e9pendance vis-\u00e0-vis de la fonction de hachage, l\u00e0 o\u00f9 le TupleHash du NIST reste verrouill\u00e9 sur Keccak. Sa variante \u00e0 cl\u00e9, SequenceMAC, exige des cl\u00e9s d’au moins 32 octets. Le tout est d\u00e9sormais vers\u00e9 au C2SP (Community Cryptography Specification Project), avec des impl\u00e9mentations de r\u00e9f\u00e9rence en Rust, Go et Python.<\/p>

L’int\u00e9r\u00eat d\u00e9passe le simple d\u00e9tail d’ing\u00e9nierie. En rendant le hachage multiple non ambigu et en offrant des cha\u00eenes de personnalisation, SequenceHash fournit un outil propre de s\u00e9paration de domaine, exactement le manque point\u00e9 par la famille \u00ab rattachement au contexte \u00bb de mpcsec.org. Les deux publications de l’automne se r\u00e9pondent donc : l’une montre comment la couche cryptographique casse, l’autre fournit une brique pour la r\u00e9parer.<\/p>

La s\u00e9paration de domaine, ou pourquoi \u00ab ab,c \u00bb ne doit pas \u00e9galer \u00ab a,bc \u00bb<\/h2>

La s\u00e9paration de domaine consiste \u00e0 garantir qu’un m\u00eame objet cryptographique ne puisse pas \u00eatre interpr\u00e9t\u00e9 dans deux contextes diff\u00e9rents. Les cha\u00eenes de personnalisation de SequenceHash en sont une mise en \u0153uvre directe : pour des entr\u00e9es identiques, deux cha\u00eenes diff\u00e9rentes produisent des sorties sans aucun lien, ce qui permet de rattacher un hach\u00e9, ou une preuve, \u00e0 un contexte pr\u00e9cis (un type de preuve donn\u00e9, une ex\u00e9cution de protocole donn\u00e9e). Sans ce rattachement, un attaquant peut rejouer un artefact valide dans un cadre o\u00f9 il ne devrait pas l’\u00eatre.<\/p>

Reliez maintenant les points. La r\u00e9utilisation de nonce, la r\u00e9utilisation de pr\u00e9-signature dans un TEE, la s\u00e9paration de domaine manquante dans un protocole MPC, et les attaques de Fiat-Shamir faibles d\u00e9crites dans l’article phare de Trail of Bits, sont toutes des variantes d’une seule et m\u00eame faute : un artefact cryptographique employ\u00e9 dans le mauvais contexte, ou r\u00e9utilis\u00e9 l\u00e0 o\u00f9 il devait rester unique. C’est cette grammaire commune, plus que n’importe quelle faille isol\u00e9e, qui explique pourquoi la couche cryptographique demande des yeux sp\u00e9cialis\u00e9s.<\/p>

Revue contre scan : ce qu’un outil automatique ne verra pas<\/h2>

Aucune de ces fautes ne se d\u00e9tecte en lan\u00e7ant un scanner. Elles tiennent \u00e0 des hypoth\u00e8ses de confiance et \u00e0 des choix de conception, pas \u00e0 des motifs de code faciles \u00e0 rep\u00e9rer. David Schwed, directeur des op\u00e9rations de SVRN et fondateur du master de cybers\u00e9curit\u00e9 de l’universit\u00e9 Yeshiva, r\u00e9sume la limite de l’outillage automatique dans une interview \u00e0 CoinDesk<\/a> : \u00ab ‘Claude, audit my smart contract, make no mistakes’ is not a security program. \u00bb Demander \u00e0 une IA de tout relire sans erreur, autrement dit, n’est pas une d\u00e9marche de s\u00e9curit\u00e9.<\/p>

Dans le m\u00eame article, Alexander Urbelis, directeur de la s\u00e9curit\u00e9 des syst\u00e8mes d’information d’ENS Labs, pointe la nature des bugs qui vident les tr\u00e9soreries : \u00ab The bugs that drain treasuries often turn on intent and adversarial incentives \u00bb, ils d\u00e9pendent de l’intention et des incitations de l’adversaire. C’est pr\u00e9cis\u00e9ment le terrain d’une revue humaine. Dan Guido, cofondateur de Trail of Bits, formule de son c\u00f4t\u00e9 la philosophie maison dans un entretien \u00e0 Decential<\/a> : \u00ab I don’t ever want to find the same bug twice \u00bb, une obsession qui a justement motiv\u00e9 la cr\u00e9ation de leurs outils d’analyse statique et de v\u00e9rification.<\/p>

Guido est tout aussi tranchant sur les langages de la blockchain, qu’il accuse d’avoir \u00ab reinvented every security issue that we eliminated from modern languages like Rust and Go and Swift \u00bb. Le message est coh\u00e9rent : les outils, y compris ceux \u00e0 base d’IA, acc\u00e9l\u00e8rent le travail et balaient le trivial, mais c’est le jugement d’un cryptographe qui d\u00e9cide si un sch\u00e9ma de signature tient r\u00e9ellement face \u00e0 un adversaire.<\/p>

Ce partage des r\u00f4les a aussi une logique \u00e9conomique. Un scanner tourne en continu pour quelques euros et rattrape les fautes connues ; une revue humaine de cryptographie co\u00fbte cher et se r\u00e9serve aux hypoth\u00e8ses d’adversaire, aux invariants de protocole et aux cas limites que personne n’a encore nomm\u00e9s. Confondre les deux, c’est payer le prix d’un audit pour la seule couverture d’un scan.<\/p>

Combien part r\u00e9ellement par la couche cryptographique<\/h2>

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

Et l’enjeu grandit avec le march\u00e9. Au 13 octobre 2026, la capitalisation totale des cryptomonnaies tourne autour de 2 600 milliards d’euros, avec un Bitcoin \u00e0 pr\u00e8s de 74 400 euros<\/a> et un Ether autour de 2 258 euros, selon CoinGecko. \u00c0 mesure que le march\u00e9 dig\u00e8re les d\u00e9cisions de la Fed, un sujet que nous suivons dans notre analyse de la r\u00e9action du march\u00e9 \u00e0 la banque centrale<\/a>, la valeur stock\u00e9e derri\u00e8re ces cl\u00e9s remonte, et avec elle le gain potentiel d’une seule part de cl\u00e9 qui fuit. Plus la capitalisation monte, plus la couche cryptographique devient une cible rentable.<\/p>

ZK et post-quantique : la prochaine surface<\/h2>

La m\u00eame grammaire de bugs s’\u00e9tend aux deux chantiers les plus actifs de la cryptographie appliqu\u00e9e. Les preuves \u00e0 divulgation nulle, d\u00e9sormais au c\u0153ur des rollups et des protocoles de confidentialit\u00e9, reposent sur des transformations de Fiat-Shamir : mal rattach\u00e9es \u00e0 leur contexte, elles deviennent falsifiables, ce que l’article \u00ab Weak Fiat-Shamir Attacks on Modern Proof Systems \u00bb de Trail of Bits a document\u00e9 en d\u00e9tail. C’est, \u00e0 l’\u00e9chelle d’un syst\u00e8me de preuve, la m\u00eame faute que le nonce r\u00e9utilis\u00e9.<\/p>

La migration post-quantique ajoute, elle, de nouvelles primitives (les standards ML-KEM et ML-DSA du NIST) et donc de nouvelles impl\u00e9mentations \u00e0 relire, chacune avec ses propres pi\u00e8ges de nonce, de hachage et de s\u00e9paration de domaine. La surface d’attaque ne se r\u00e9duit pas, elle se d\u00e9place. C’est pourquoi la practice cryptographie de Trail of Bits couvre d’un m\u00eame tenant ZK, MPC et post-quantique : ce sont trois dialectes d’un m\u00eame langage, et un sp\u00e9cialiste de l’un rep\u00e8re souvent la faute de l’autre.<\/p>

Ce que l’AMF et MiCA encadrent (et surtout pas)<\/h2>

C\u00f4t\u00e9 r\u00e9glementaire, il faut \u00eatre clair : aucune autorit\u00e9, ni l’AMF, ni l’ESMA via MiCA, n’impose ni n’accr\u00e9dite un audit de cryptographie. MiCA encadre les prestataires de services sur crypto-actifs (PSCA) et les \u00e9metteurs ; son article 75 fixe un r\u00e9gime de responsabilit\u00e9 pour la conservation, et le r\u00e8glement DORA impose une r\u00e9silience op\u00e9rationnelle informatique. Mais aucun texte n’exige qu’un sch\u00e9ma de signature \u00e0 seuil ou une enclave mat\u00e9rielle soit relu par un cryptographe, et un protocole pleinement d\u00e9centralis\u00e9 \u00e9chappe largement au p\u00e9rim\u00e8tre.<\/p>

La qualit\u00e9 de cette couche reste donc polic\u00e9e par la seule r\u00e9putation. Le calendrier fran\u00e7ais ajoute une pression de conformit\u00e9 : la p\u00e9riode transitoire des PSAN sous l’ancien r\u00e9gime PACTE s’est achev\u00e9e au 1er juillet 2026, et l’AMF<\/a> a pr\u00e9venu que les acteurs non conformes doivent organiser une sortie ordonn\u00e9e. Rien de tout cela, cependant, ne garantit qu’un wallet MPC a \u00e9t\u00e9 audit\u00e9 l\u00e0 o\u00f9 il compte vraiment, au niveau du protocole cryptographique. Le tampon r\u00e9glementaire couvre l’enregistrement du prestataire, pas la solidit\u00e9 de ses maths.<\/p>

Faute d’accr\u00e9ditation officielle, le march\u00e9 s’en remet \u00e0 des signaux indirects : la r\u00e9putation du cabinet, la publication int\u00e9grale du rapport d’audit, la pr\u00e9sence de cryptographes nomm\u00e9s dans l’\u00e9quipe, ou encore le recours \u00e0 plusieurs relectures ind\u00e9pendantes. 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 \u00e9t\u00e9 regard\u00e9e s\u00e9rieusement.<\/p>

Pour les builders : construire la couche cryptographique<\/h2>

Pour une \u00e9quipe qui construit un d\u00e9positaire, un wallet \u00e0 seuil ou un protocole \u00e0 base de preuves, les le\u00e7ons de l’automne se r\u00e9sument en quelques principes concrets. D’abord, documenter les invariants de nonce, de pr\u00e9cision et de s\u00e9paration de domaine comme des propri\u00e9t\u00e9s formelles, pas comme de simples commentaires dans le code. Ensuite, traiter tout TEE comme une d\u00e9fense en profondeur, jamais comme un remplacement du protocole, et lier son attestation \u00e0 l’identit\u00e9 des parties.<\/p>