OSINT et mise en relation des identifiants sur chaîne et hors chaîne

La recherche en sources ouvertes fournit souvent le lien que l’analyse sur chaîne ne peut pas établir : une publication dans laquelle un suspect a diffusé une adresse, l’historique d’enregistrement d’un site web frauduleux, un pseudonyme réutilisé sur une deuxième plateforme. De tels recoupements ont été à l’origine de nombreuses identifications. Ils constituent aussi des sources fréquentes d’erreurs, car les identifiants peuvent être copiés, usurpés, revendus ou correspondre par hasard, et une capture d’écran sans URL, sans indication temporelle et sans trace de la manière dont elle a été trouvée est facilement contestable devant un tribunal. Cette leçon explique comment planifier les travaux en sources ouvertes, collecter des éléments en documentant leur provenance, évaluer chaque type de lien entre chaîne et hors chaîne, et mettre un lien à l’épreuve avant de s’y fier.

Information, renseignement et preuve

Le Protocole de Berkeley sur l’utilisation de sources ouvertes numériques dans les enquêtes, publié en décembre 2020 par le Human Rights Center de l’UC Berkeley School of Law avec le Haut-Commissariat des Nations Unies aux droits de l’homme, constitue la principale référence internationale pour les travaux en sources ouvertes destinés à des procédures judiciaires. Il distingue trois notions :

• Information de source ouverte : information que tout membre du public peut observer, acheter ou demander, sans statut juridique particulier ni accès non autorisé.
• Renseignement de source ouverte (OSINT) : information de source ouverte utilisée principalement pour éclairer des décisions, par exemple sur les points à approfondir ou les éléments à demander.
• Preuve de source ouverte : information de source ouverte ayant une valeur probante, sur laquelle il est possible de s’appuyer pour établir des faits dans le cadre d’une procédure.

Dans une affaire liée aux cryptoactifs, la plupart des éléments issus de l’OSINT restent du renseignement, qui indique le service à solliciter. Seuls les éléments collectés et conservés selon des exigences probatoires peuvent devenir des preuves ; prévoyez donc cette possibilité dès la première recherche : une page qui disparaît ne peut plus être collectée. Concernant l’emplacement des données, la Convention de Budapest permet à une Partie d’accéder à des données informatiques stockées accessibles au public, quel que soit leur emplacement géographique (article 32(a)) ; les règles nationales relatives aux recherches en ligne des enquêteurs restent applicables et sont définies par les conseillers juridiques de l’unité.

Planification et posture

Les travaux en sources ouvertes suivent le cycle du renseignement : orientation (que devons-nous savoir ?), collecte, traitement, analyse, diffusion et retour d’information. Le Protocole de Berkeley décrit les étapes de l’enquête comme suit : recherches en ligne, évaluation préliminaire, collecte, conservation, vérification et analyse aux fins de l’enquête. Avant de lancer vos recherches, consignez un bref plan de collecte dans le dossier de l’affaire :

Le plan limite les recherches à ce que la question exige (la minimisation des données figure parmi les principes du Protocole de Berkeley, avec l’exactitude, la conservation et la sécurité dès la conception) et permet de répondre ultérieurement à la question de savoir pourquoi une source a été consultée ou non.

La manière dont l’enquêteur apparaît en ligne compte pour sa sécurité et pour l’affaire. Une recherche attribuable permet d’identifier l’organisme ou l’entreprise et peut alerter les personnes visées. Une recherche non attribuable utilise une infrastructure qui ne révèle pas l’organisation et se limite à une consultation passive ; elle convient à la plupart des recherches OSINT sur des personnes visées. Un travail sous couverture, impliquant des interactions avec les personnes visées sous une identité d’emprunt, ne relève pas de l’OSINT passif et nécessite une autorisation juridique spécifique ; le Protocole de Berkeley avertit que les fausses déclarations, comme le fait de rejoindre des groupes fermés sous de faux prétextes, peuvent porter atteinte au droit au respect de la vie privée et compromettre une enquête. Même la consultation d’une adresse suspecte sur un explorateur public indique à son opérateur que quelqu’un s’y intéresse ; les requêtes sensibles doivent être effectuées sur votre propre nœud (leçon 1.5).

Recherche, capture et provenance

Les opérateurs de recherche ("…" pour une chaîne exacte, site:, -term, OR, intitle:, filetype:, et, sur certains moteurs, before: et after:) diffèrent selon les moteurs et évoluent ; consignez donc la chaîne de requête exacte avec chaque résultat. Pour les affaires liées aux cryptoactifs :

• Recherchez les adresses complètes, avec et sans guillemets, sur plusieurs moteurs, dans les dépôts de code et sur les sites de partage de texte ; une correspondance sur une longue chaîne unique est rarement une coïncidence, même s’il peut s’agir d’une copie. Recherchez les pseudonymes avec leurs variantes (traits de soulignement, chiffres, substitutions).
• Consultez les archives web, comme la Wayback Machine d’Internet Archive, pour trouver des versions antérieures au retrait des adresses de dépôt d’un site frauduleux ou à la modification d’une publication par un utilisateur ; citez l’URL de l’archive et l’heure de capture telles qu’elles sont enregistrées par l’archive.
• Capturez d’abord, analysez ensuite. Les pages en ligne changent et disparaissent, parfois parce que la personne visée a remarqué l’intérêt qu’elle suscite.

Chaque élément doit être accompagné d’informations suffisantes pour montrer ultérieurement ce qu’il était, d’où il provenait, quand et comment il a été capturé, et qu’il n’a pas été modifié. Les Bonnes pratiques pour l’acquisition de contenus en ligne du SWGDE (document 21-F-001) recommandent de capturer la séquence complète des URL, de consigner les dates, les heures et le fuseau horaire des accès, de préserver les métadonnées, de calculer l’empreinte de chaque fichier acquis avec des algorithmes approuvés par le NIST, et de documenter l’examinateur, le navigateur et l’adresse IP d’accès ; le Protocole de Berkeley y ajoute les outils et logiciels utilisés. Voici une entrée de journal de collecte :

{
  "item_id": "OS-0007",
  "case_id": "CF-2026-0142",
  "url": "https://forum.example/t/48213?page=3#post-912",
  "query": "\"bc1q…7k3f\" site:forum.example",
  "captured_utc": "2026-03-06T10:41:12Z",
  "method": "full-page capture + HTML source + WARC",
  "tool": "open-source capture tool v3.2, browser 128",
  "files": [
    {"name": "OS-0007.warc.gz", "sha256": "5b0e…11d4"},
    {"name": "OS-0007.png", "sha256": "c3a9…7e20"}
  ],
  "archive_copy": "web archive capture requested 2026-03-06T10:44Z",
  "posture": "non-attributable, research host RH-2",
  "collector": "EX-07",
  "note": "post dated 2023-11-14 shows address in user signature"
}

L’entrée conserve un fichier WARC (le format d’archive web normalisé par ISO 28500), qui préserve l’échange HTTP ; une capture d’écran lisible ; et le code source HTML, chacun faisant l’objet d’un calcul d’empreinte lors de la capture, ainsi qu’une copie d’archive indépendante servant de trace fournie par un tiers. La note distingue la date affichée sur la publication, qui constitue une affirmation de la plateforme, de l’heure de capture, qui relève de l’observation propre de l’examinateur.

Types de liens et force probante

Chaque lien est évalué individuellement selon l’échelle de la leçon 4.5, et une chaîne de liens reçoit la cote de son maillon le plus faible. La colonne de force probante constitue un point de départ habituel, pas une cote : une signature que vous avez vérifiée vous-même est une preuve directe du contrôle au moment de la signature (A sur cette échelle), une publication ou un enregistrement isolé constitue un indicateur présentant des modes de défaillance connus (C), une correspondance de pseudonyme ou d’horaire d’activité prise isolément est généralement une piste (D), et chacun de ces éléments passe à B lorsqu’un indicateur indépendant d’un autre type concorde.

Messages signés et services de noms

Le recoupement le plus solide est un message signé. Selon BIP-322 (Bitcoin) ou EIP-191 (Ethereum), le détenteur d’une clé signe un texte, et n’importe qui peut vérifier la signature. Une signature valide montre que le signataire pouvait signer pour l’adresse à cet instant. BIP-322 précise lui-même ce qu’il ne prouve pas : que le signataire contrôle toujours les fonds ou qu’il a envoyé une quelconque transaction antérieure. Vérifiez vous-même chaque signature à l’aide d’une implémentation ouverte, en consignant l’outil et sa version.

L’Ethereum Name Service (ENS) associe les noms aux adresses dans deux sens dont la valeur probante diffère. La résolution directe (du nom vers l’adresse) est définie par le propriétaire du nom et peut pointer vers n’importe quelle adresse sans le consentement de celle-ci ; elle montre ce que le propriétaire du nom a choisi d’afficher. La résolution inverse (de l’adresse vers le nom principal) est définie par une transaction provenant de l’adresse elle-même ; il s’agit donc d’une déclaration de la personne qui contrôlait l’adresse au moment du paramétrage, ce qui est plus probant, surtout lorsque les enregistrements directs et inverses concordent. Les noms portent également des enregistrements textuels tels que url, email, com.twitter et avatar. Ils expirent : après le délai de grâce et une période de 21 jours durant laquelle le supplément de prix diminue, n’importe qui peut enregistrer un nom expiré ; consignez donc l’historique d’enregistrement et le bloc auquel chaque enregistrement a été défini. Les badges de portefeuille vérifié et les fonctionnalités « connecter un portefeuille » des plateformes constituent des affirmations de la plateforme ; ses données indiquant quel compte a lié quelle adresse peuvent être demandées.

Pseudonymes, adresses e-mail et domaines

Les personnes réutilisent leurs pseudonymes. Dans l’enquête Silk Road, un enquêteur qui recherchait les premières mentions en ligne du marché a découvert des publications de janvier 2011, sous un même pseudonyme, faisant la promotion du site sur deux forums ; une publication ultérieure sous ce même pseudonyme, visant à recruter un développeur, indiquait une adresse e-mail personnelle pour les réponses, ce qui est devenu une piste poursuivie par voie légale. Évaluez une correspondance de pseudonyme selon sa rareté (quietharbor_77 sur deux forums signifie davantage que crypto_king ; recherchez combien d’utilisateurs sans lien entre eux le partagent), la cohérence des sujets, du style, des fuseaux horaires et des dates, l’historique du compte (un compte créé le lendemain d’une alerte publique relève plus probablement de l’imitation que de la réutilisation) et la chronologie (la première utilisation est généralement la plus importante). Une correspondance étaye une hypothèse ; le compte qui se trouve derrière est un compte de service dont les données d’abonné peuvent être demandées (leçon 1.4).

Les plateformes frauduleuses, les fausses plateformes d’échange et les kits d’hameçonnage ont besoin de domaines, et les domaines laissent des traces. Pour les domaines génériques de premier niveau, le protocole d’accès aux données d’enregistrement (RDAP) est devenu la source de référence des 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 coordonnées du titulaire proviennent donc généralement du bureau d’enregistrement par voie légale ; le Deuxième Protocole additionnel à la Convention de Budapest prévoit des demandes directes d’informations relatives à l’enregistrement de noms de domaine (article 6). Les données historiques d’enregistrement et le DNS passif montrent quelles adresses IP un domaine a utilisées et quels autres domaines les partageaient. Les journaux de Certificate Transparency (RFC 6962) consignent les certificats TLS publiquement reconnus dans des journaux publics à ajout uniquement, et une recherche portant sur une marque frauduleuse y révèle souvent des domaines apparentés. Une infrastructure partagée relie des sites entre eux de manière plus fiable qu’elle ne les relie à une personne : une adresse IP partagée sur un grand service d’hébergement constitue un lien faible, tandis qu’un identifiant inhabituel d’outil d’analyse ou une adresse de dépôt partagés constituent un lien fort.

Copie, chronologie et preuves liées aux adresses IP

Les adresses figurent parmi les chaînes de caractères les plus copiées sur Internet. Les adresses de don et de paiement sont republiées par des sympathisants, des escrocs et des agrégateurs. Dans l’empoisonnement d’adresse, les attaquants créent des adresses ressemblantes qui partagent les premiers et les derniers caractères de l’adresse d’une contrepartie de la victime, puis envoient des transferts de très faible valeur ou de valeur nulle pour que l’adresse ressemblante apparaisse dans l’historique de la victime ; une adresse tronquée sur une capture d’écran peut correspondre à l’une comme à l’autre. Certaines plateformes autorisent des modifications sans historique visible ; comparez donc avec les captures d’archives. Comparez toujours l’adresse complète, caractère par caractère ou par empreinte de hachage. La chronologie est le test le plus probant : une publication qui montre une adresse avant sa première activité sur chaîne est bien plus solide qu’une publication apparue après une alerte publique, alors que n’importe qui pouvait la copier. Dans l’exemple, la publication OS-0007 est datée du 2023-11-14 et l’adresse a reçu ses premiers fonds en décembre 2023.

Les adresses IP proviennent principalement de données de services (journaux de connexion des plateformes d’échange, systèmes dorsaux de portefeuilles, fournisseurs de nœuds ou d’API) obtenues par voie légale (leçon 7.5). Biryukov, Khovratovich et Pustogarov (2014) ont montré que des observateurs du réseau pair à pair peuvent parfois relier des transactions Bitcoin à l’adresse IP qui les a relayées en premier, mais il ne s’agit pas d’une preuve courante et Tor déjoue cette méthode. Une correspondance d’adresse IP doit être contextualisée : les sorties VPN, Tor, le NAT opérateur et les bureaux partagés placent de nombreuses personnes derrière une même adresse, et les journaux utilisent des fuseaux horaires différents.

Les profils horaires d’activité ne sont, au mieux, que des éléments d’appui. Compter les transactions d’un cluster par heure UTC (en SQL, EXTRACT(HOUR FROM block_timestamp), ou HOUR() ou date_part('hour', …) dans certains moteurs) fournit un profil à comparer aux heures de publication d’un pseudonyme. Gardez les limites à l’esprit : l’heure du bloc n’est pas l’heure de diffusion (sur Bitcoin, les horodatages des blocs peuvent différer de l’heure réelle de plus d’une heure), les robots fonctionnent en permanence, et de nombreuses personnes partagent un même fuseau horaire.

Vérifier et mettre un lien à l’épreuve

Les éléments collectés restent des affirmations tant que leur authenticité, leur fiabilité, leur pertinence et leur valeur probante n’ont pas été vérifiées. Examinez la source (qui l’a publié ; le compte est-il authentique et établi ?), le contenu (est-il cohérent en lui-même et avec les autres informations ?) et les traces techniques (métadonnées, structure de la page, historique des archives). La chaîne offre un contrôle indépendant solide des affirmations datées. Consignez ensuite les explications concurrentes (l’auteur de la publication contrôle l’adresse ; il l’a copiée ; son identité a été usurpée ou son compte compromis) ainsi que les éléments favorables et défavorables à chacune.

Demandez-vous à quelle fréquence un lien pourrait survenir 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 ailleurs, comptez le nombre de retraits de 0,5 ETH effectués par les portefeuilles chauds de la plateforme d’échange K durant cet intervalle ; s’il y en a eu quarante, la correspondance est faible. Parcourez ensuite une liste de contrôle :

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 faire l’objet d’un empoisonnement ?
4. La date et l’heure de l’enregistrement hors chaîne concordent-elles avec l’activité sur chaîne ?
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 mises à l’épreuve ?

Consignez également les liens qui n’ont pas satisfait aux critères de la liste de contrôle.

Documentation destinée au tribunal

Une pièce de source ouverte est défendable lorsqu’un autre examinateur pourrait suivre le même cheminement et vérifier chaque élément. Le dossier de l’affaire contient le plan de collecte et ses modifications ; le journal de collecte et les captures, avec leurs empreintes de hachage et sous chaîne de conservation (leçons 8.2 et 8.3) ; les notes prises au moment des faits, y compris les recherches infructueuses ; la vérification de chaque élément sur lequel vous vous appuyez ; et une déclaration de posture confirmant l’absence d’accès non autorisé ou de fausse déclaration. Dans le rapport, citez les éléments par leur identifiant, ne reproduisez que ce qui est nécessaire et occultez les informations relatives aux personnes non impliquées ; les liens avec des particuliers restent dans une annexe à accès restreint jusqu’à leur confirmation par voie légale.

Points clés pour l’examen : les informations, les renseignements et les preuves de source ouverte dans le Protocole de Berkeley (2020), ainsi que ses étapes d’enquête ; l’article 32(a) de la Convention de Budapest ; un plan de collecte assorti d’une règle d’arrêt ; les postures attribuable, non attribuable et sous couverture, et les raisons pour lesquelles le travail sous couverture exige une autorisation spécifique ; la consignation de la requête exacte et la capture avant l’analyse ; les enregistrements de collecte avec URL complète, heure UTC, méthode, version de l’outil, empreintes SHA-256 et WARC (ISO 28500), conformément au document SWGDE 21-F-001 ; les types de liens et leur force probante habituelle ; ce qu’un message signé (BIP-322, EIP-191) prouve et ne prouve pas ; la résolution directe et la résolution inverse ENS, ainsi que l’expiration ; l’évaluation des correspondances de pseudonymes (rareté, cohérence, historique du compte, première utilisation) ; RDAP depuis le 28 janvier 2025, le DNS passif, Certificate Transparency (RFC 6962) et l’infrastructure partagée ; les adresses copiées, l’empoisonnement d’adresse et la comparaison des adresses complètes ; les limites de la corrélation des adresses IP et des horaires d’activité ; le raisonnement fondé sur les taux de base et la liste de contrôle contre les liens fortuits.