Relier les identifiants on-chain et off-chain

De nombreuses identifications dans des affaires liées aux cryptomonnaies ont commencé par un seul chevauchement entre la chaîne et le reste d’Internet : une adresse dans la signature d’un forum, un enregistrement de service de nommage, un pseudonyme réutilisé sur une deuxième plateforme, une adresse IP de connexion correspondant à un retrait. Ces chevauchements constituent des pistes puissantes et sont souvent sources d’erreur, car les identifiants peuvent être copiés, usurpés, partagés, revendus et rapprochés par hasard. Cette leçon présente les principaux types de liens entre on-chain et off-chain, leur degré de solidité et la manière de vérifier un lien avant de s’y fier.

Types de liens et degré de solidité

Chaque lien est évalué individuellement, selon l’échelle décrite dans la leçon De l’adresse à l’entité, puis à la personne, et une chaîne de liens reçoit la note de son maillon le plus faible.

Pseudonymes et noms d’utilisateur

Les gens réutilisent leurs pseudonymes. Un pseudonyme utilisé pour promouvoir un service illicite peut aussi apparaître des années auparavant sur un forum de loisir, un dépôt de code ou une place de marché, parfois accompagné d’une adresse e-mail ou d’un autre détail permettant l’identification. Dans l’enquête sur Silk Road, un enquêteur a recherché les premières mentions en ligne de la place de marché et a trouvé des publications datant de janvier 2011, par lesquelles un pseudonyme faisait la promotion du site sur deux forums ; une publication ultérieure du même pseudonyme, visant à recruter un développeur, fournissait une adresse e-mail personnelle pour les réponses. Cette adresse e-mail est devenue une piste suivie au moyen de procédures judiciaires.

Pour évaluer une correspondance de pseudonyme :

• Rareté : quietharbor_77 sur deux forums est plus révélateur que crypto_king. Recherchez le pseudonyme à grande échelle pour voir combien d’utilisateurs sans lien entre eux le partagent.
• Cohérence : sujets qui se recoupent, style d’écriture, fuseaux horaires et dates d’activité.
• Historique du compte : un compte créé le lendemain d’une alerte publique et utilisant le pseudonyme du sujet est plus probablement une imitation qu’une réutilisation.
• Antériorité : qui a utilisé le pseudonyme en premier ? Les imitateurs copient les pseudonymes connus ; c’est généralement la première utilisation qui compte le plus.

Une correspondance de pseudonyme étaye une hypothèse ; elle n’établit pas une identité. Le compte associé est un compte de service dont les données d’abonné peuvent être demandées (voir la leçon Travailler avec les fournisseurs de services).

E-mails, domaines et certificats

Les plateformes frauduleuses, les fausses plateformes d’échange et les kits d’hameçonnage ont besoin de domaines, et les domaines laissent des traces.

• Données d’enregistrement : pour les domaines génériques de premier niveau, le Registration Data Access Protocol (RDAP) est devenu la source faisant autorité pour les données d’enregistrement le 28 janvier 2025, en remplacement de WHOIS. Les réponses publiques sont souvent expurgées pour protéger la vie privée (les règles de publication des données du titulaire varient selon les juridictions) ; les coordonnées du titulaire proviennent donc généralement du bureau d’enregistrement au moyen de procédures judiciaires. Le Deuxième Protocole additionnel à la Convention de Budapest prévoit les demandes directes d’informations sur l’enregistrement des noms de domaine (article 6).
• Archives historiques : les anciennes données d’enregistrement et l’historique de résolution DNS (DNS passif) indiquent quelles adresses IP un domaine a utilisées et quels autres domaines les partageaient.
• Certificate Transparency : les certificats TLS approuvés par le public sont consignés dans des journaux publics en ajout seulement (RFC 6962). Une recherche dans ces journaux à partir du nom d’une marque frauduleuse révèle souvent des domaines apparentés enregistrés pour la même campagne.
• Infrastructure partagée : la même adresse IP d’hébergement, les mêmes serveurs de noms, le même modèle de site, le même identifiant d’analyse ou la même adresse de dépôt sur plusieurs sites suggèrent un opérateur commun.

Une infrastructure partagée relie les sites entre eux de façon plus fiable qu’elle ne les relie à une personne. Les fournisseurs d’hébergement et les bureaux d’enregistrement servent des milliers de clients sans lien entre eux ; une adresse IP partagée sur un grand service d’hébergement constitue donc un indice faible, tandis qu’un identifiant d’analyse ou une adresse de dépôt partagés et inhabituels constituent un indice fort.

Services de nommage, NFT et profils sociaux

L’Ethereum Name Service (ENS) associe des noms lisibles par l’humain à des adresses. Deux directions sont importantes et n’ont pas le même poids :

• La résolution directe (nom vers adresse) est définie par le propriétaire du nom et peut pointer vers n’importe quelle adresse, sans le consentement du titulaire de celle-ci. Elle montre ce que le propriétaire du nom a choisi d’afficher, pas qui contrôle l’adresse.
• La résolution inversée (adresse vers nom principal) est définie par une transaction provenant de l’adresse elle-même. Il s’agit donc d’une déclaration faite par la personne qui contrôlait l’adresse au moment où elle a été définie, ce qui constitue un élément plus solide établissant un lien, surtout lorsque les enregistrements directs et inversés concordent.

Les noms peuvent également contenir des enregistrements textuels tels que url, email, com.twitter et avatar. Ils expirent : après la période de grâce et une période de 21 jours durant laquelle le prix de lancement diminue, n’importe qui peut enregistrer un nom expiré. Consignez l’historique des enregistrements et le bloc auquel chaque enregistrement a été défini ; un nom dont le propriétaire a changé en 2025 ne révèle rien sur une activité en 2023.

Les photos de profil NFT, les badges de portefeuille vérifié et les fonctions « connecter le portefeuille » des plateformes sociales et des places de marché créent d’autres chevauchements. Les enregistrements de la plateforme, qui indiquent quel compte a associé quelle adresse et comment elle l’a vérifiée, peuvent être obtenus auprès de la plateforme ; le badge public, à lui seul, n’est que la déclaration de la plateforme.

Le chevauchement le plus solide est un message signé. Selon BIP-322 (Bitcoin) ou EIP-191 (Ethereum), le détenteur d’une clé signe un texte avec celle-ci, et chacun peut vérifier la signature. Une signature valide montre que le signataire pouvait signer pour l’adresse à ce moment-là. BIP-322 précise également ce qu’elle ne prouve pas : que le signataire contrôle toujours les fonds ou qu’il a envoyé une transaction antérieure. Traitez avec prudence les signatures publiées par des tiers et vérifiez chacune d’elles vous-même à l’aide d’une implémentation ouverte, en consignant l’outil et sa version.

Publications sur les forums, adresses et copie

Une adresse figurant dans une publication datée d’un compte établi constitue un lien utile, mais les adresses sont parmi les chaînes de caractères les plus copiées sur Internet :

• Les adresses de dons et de paiement sont republiées par des fans, des escrocs et des agrégateurs.
• Empoisonnement d’adresse : des attaquants créent des adresses ressemblantes qui partagent les premiers et les derniers caractères de l’adresse d’un interlocuteur de la victime, puis envoient des transferts de faible valeur ou de valeur nulle pour que l’adresse ressemblante apparaisse dans l’historique de la victime. Une adresse ressemblante dans l’historique n’est pas un interlocuteur, et une adresse tronquée dans une capture d’écran peut correspondre à l’une ou l’autre.
• Publications modifiées : certaines plateformes permettent les modifications sans historique visible. Comparez avec les captures des archives du Web.
• Chronologie : une publication qui affiche une adresse avant sa première activité on-chain est beaucoup plus probante qu’une publication parue après une alerte publique.

Comparez toujours l’adresse complète, caractère par caractère ou à l’aide d’un hachage, et jamais la forme tronquée affichée.

Corrélation des adresses IP et des horaires

Les adresses IP proviennent principalement des dossiers des services : journaux de connexion aux plateformes d’échange, serveurs dorsaux de portefeuilles, fournisseurs de nœuds ou d’API, tous obtenus au moyen de procédures judiciaires (voir la leçon Les comptes de plateformes d’échange et de services cloud comme éléments de preuve). Des recherches publiées, notamment celle de Biryukov, Khovratovich et Pustogarov (2014), ont montré que les observateurs du réseau pair à pair de Bitcoin peuvent parfois relier des transactions à l’adresse IP qui les a relayées en premier, mais il ne s’agit pas d’un élément de preuve courant, et Tor ainsi que d’autres mesures permettent de le déjouer. Une correspondance d’adresse IP n’a de valeur qu’en contexte : les nœuds de sortie VPN, Tor, le NAT des opérateurs mobiles et les bureaux partagés placent de nombreuses personnes derrière une même adresse, et les journaux consignent les heures dans des fuseaux horaires différents.

Les profils temporels de l’activité ne sont au mieux que des éléments d’appui. La requête ci-dessous établit un profil par heure de la journée pour les transactions envoyées par un cluster sur une chaîne à modèle de compte :

-- Profil par heure de la journée (UTC) des transactions envoyées par le cluster C-4
SELECT EXTRACT(HOUR FROM t.block_timestamp) AS hour_utc,
       COUNT(*) AS tx_count
FROM transactions AS t
JOIN cluster_members AS c
  ON c.address = t.from_address
WHERE c.cluster_id = 'C-4'
  AND t.block_timestamp >= TIMESTAMP '2025-01-01 00:00:00'
  AND t.block_timestamp <  TIMESTAMP '2026-01-01 00:00:00'
GROUP BY EXTRACT(HOUR FROM t.block_timestamp)
ORDER BY hour_utc;

Elle joint la table des transactions aux adresses membres du cluster, limite les données à une année et compte les transactions par heure UTC. EXTRACT est une fonction SQL standard ; certains moteurs utilisent plutôt HOUR() ou date_part('hour', …). Le résultat peut être comparé aux heures de publication d’un pseudonyme suspect. N’oubliez pas les limites : l’heure du bloc n’est pas l’heure de diffusion (sur Bitcoin, les horodatages des blocs peuvent différer de plus d’une heure de l’heure réelle), les bots fonctionnent à toute heure et de nombreuses personnes partagent le même fuseau horaire.

Faux liens et coïncidences

Avant de vous fier à un lien, demandez-vous à quelle fréquence il pourrait se produire par hasard. Si un suspect a retiré 0,5 ETH de la plateforme d’échange K dix minutes après un dépôt de 0,5 ETH effectué ailleurs, comptez le nombre de retraits de 0,5 ETH effectués par les portefeuilles chauds de la plateforme d’échange K pendant cette période ; s’il y en a eu quarante, la correspondance est faible. Puis suivez cette courte liste de vérification :

1. L’identifiant est-il rare et avez-vous vérifié combien d’autres personnes le partagent ?
2. A-t-il été observé avant que l’affaire ne devienne publique ?
3. A-t-il pu être copié, imité ou empoisonné ?
4. L’heure de l’enregistrement off-chain correspond-elle à l’activité on-chain ?
5. Existe-t-il un deuxième lien indépendant, idéalement d’un autre type ?
6. Les explications concurrentes ont-elles été consignées et vérifiées ?

Consignez également les liens qui n’ont pas passé la liste de vérification. Les liens impliquant des personnes privées restent dans une annexe à accès restreint jusqu’à leur confirmation au moyen de procédures judiciaires (voir la leçon IDFE-BA Protection des données, éthique et divulgation responsable).

Points clés pour l’examen : principaux types de liens entre on-chain et off-chain et leur solidité typique ; évaluation des correspondances de pseudonymes (rareté, cohérence, historique du compte, première utilisation) ; RDAP comme source faisant autorité pour l’enregistrement des domaines gTLD depuis le 28 janvier 2025, expurgation des données et obtention des dossiers auprès du bureau d’enregistrement au moyen de procédures judiciaires (article 6 du Deuxième Protocole additionnel) ; DNS passif, Certificate Transparency (RFC 6962) et infrastructure partagée ; résolution directe et inversée ENS, enregistrements textuels et expiration ; ce qu’un message signé (BIP-322, EIP-191) prouve et ne prouve pas ; adresses copiées, empoisonnement d’adresse et comparaison des adresses complètes ; limites de la corrélation des adresses IP et des horaires d’activité ; raisonnement fondé sur les taux de base et liste de vérification contre les liens fortuits.