Les comptes de plateformes d'échange et les comptes cloud comme éléments de preuve

La plupart des enquêtes qui commencent sur la blockchain aboutissent à un service : une plateforme d'échange qui sait qui a retiré les fonds, un compte cloud qui contient la sauvegarde, une boîte de messagerie pleine de confirmations de dépôt. Les données de ces prestataires apportent souvent les éléments relatifs à l'identité et à l'intention que la blockchain ne peut pas révéler. Mais une feuille de calcul provenant d'une plateforme d'échange ne fait pas preuve par elle-même : l'examinateur doit savoir d'où elle provient, si elle est complète, ce que signifie chaque colonne et si elle concorde avec la blockchain. Cette leçon présente le contenu des données des prestataires, la manière de les authentifier, les précautions à prendre lors d'un accès direct à un compte et la manière de rapprocher les données des prestataires de celles de la blockchain.

Contenu des données des plateformes d'échange et des dépositaires

La manière de demander des données est abordée dans la leçon Travailler avec les prestataires de services ; la présente leçon commence à la réception de la réponse. Une transmission typique d'une plateforme d'échange ou d'un dépositaire contient :

Les données peuvent parvenir de trois manières, avec une force probante différente. Les transmissions du prestataire répondent à une procédure légale et sont accompagnées d'éléments de provenance fournis par le prestataire. Les exports utilisateur, tels que les relevés téléchargés par un suspect ou fournis par une victime, sont trouvés sur des appareils ou remis aux enquêteurs et doivent être vérifiés auprès du prestataire. Les captures en direct sont des données qu'un enquêteur recueille en se connectant en vertu d'une autorisation ou d'un consentement. Toute constatation doit préciser sur quel type de source elle repose.

Authentifier les données des prestataires

L'authentification consiste à démontrer qu'un document ou un enregistrement est bien ce qu'il prétend être et qu'il n'a pas changé depuis sa production.

1. Provenance. Consignez qui a demandé les données, en vertu de quelle autorisation, par quel canal (portail destiné aux forces de l'ordre, transfert sécurisé, support physique), qui les a reçues et à quel moment.
2. Intégrité à la réception. Calculez immédiatement l'empreinte de chaque fichier livré, conservez l'original sans modification et travaillez sur des copies. Si le prestataire fournit ses propres empreintes, comparez-les.
3. Attestation. De nombreux prestataires peuvent fournir une déclaration d'un responsable de la conservation des données décrivant comment les données sont créées et conservées dans le cadre habituel de leurs activités. La nécessité d'une telle déclaration et la forme qu'elle doit prendre dépendent de la juridiction ; la demander ne coûte guère.
4. Signification. Obtenez un dictionnaire de données : quel fuseau horaire est utilisé pour les horodatages, si les montants sont bruts ou nets de frais, ce que signifie chaque code de statut et comment les transferts internes sont représentés.
5. Exhaustivité. Vérifiez que la période, les comptes, les actifs et les types de données demandés ont tous été fournis, et que le solde d'ouverture augmenté des mouvements correspond au solde de clôture.

Les tableurs provoquent des erreurs évitables. Les longs identifiants numériques peuvent être convertis en notation scientifique, les zéros initiaux supprimés, les montants arrondis et les dates réinterprétées selon des formats locaux. Importez les fichiers du prestataire dans un outil d'analyse ou une base de données sous forme de texte, effectuez les conversions de manière contrôlée et conservez les étapes de conversion.

Accès direct aux comptes et données obtenues par API

Les enquêteurs accèdent parfois directement à un compte : avec le consentement d'une victime, avec des identifiants trouvés lors d'une perquisition légale ou par l'intermédiaire de l'API d'une plateforme d'échange. Les données ainsi accessibles peuvent être stockées à l'étranger. L'article 32 de la Convention de Budapest permet à une partie d'accéder à des données stockées situées sur le territoire d'une autre partie avec le consentement légal et volontaire de la personne légalement autorisée à les divulguer, ainsi que d'accéder à des données accessibles au public ; au-delà de ces cas, les voies présentées dans la leçon Autorisation légale et coopération internationale s'appliquent. Lorsqu'une injonction de produire est possible, elle offre généralement des garanties de provenance plus solides qu'une connexion au compte.

Si vous recourez à un accès direct, documentez-le comme une intervention en direct : enregistrement vidéo de l'écran pendant la session, heure, compte, chaque export téléchargé avec son empreinte et, pour les appels API, point de terminaison, paramètres et réponse brute conservée sans modification. Veillez à ne pas modifier le compte : aucune opération de négociation, aucune modification des paramètres, aucune réinitialisation du mot de passe qui alerterait le titulaire et aucune action qui contreviendrait aux dispositions de non-divulgation du prestataire.

Rapprocher les données des prestataires de celles de la blockchain

Les données d'un prestataire et la blockchain sont deux sources indépendantes concernant les mêmes événements. Leur rapprochement permet de vérifier les deux, et un enregistrement rapproché est bien plus difficile à contester que chaque source prise isolément. Le contrôle principal des retraits consiste à joindre les lignes du prestataire aux données de blockchain propres au service d'enquête :

-- Rapprocher les retraits du prestataire des sorties sur la blockchain (tables de type UTXO)
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount_sat,  -- montant du relevé, converti en satoshis à l'importation
       o.value AS value_sat, t.block_timestamp,
       CASE
         WHEN w.txid IS NULL THEN 'NO_TXID'
         WHEN t.hash IS NULL THEN 'TXID_NOT_ON_CHAIN'
         WHEN o.transaction_hash IS NULL THEN 'ADDRESS_NOT_IN_TX'
         WHEN o.value <> w.amount_sat THEN 'AMOUNT_DIFFERS'
         ELSE 'MATCHED'
       END AS status
FROM provider_withdrawals w
LEFT JOIN transactions t ON t.hash = w.txid
LEFT JOIN outputs o ON o.transaction_hash = t.hash AND o.address = w.to_address
ORDER BY w.requested_utc;

Chaque ligne de retrait est d'abord rapprochée de la transaction au moyen du txid, puis de la sortie qui verse les fonds à l'adresse indiquée, puis de l'horodatage confirmé de son bloc. Les jointures gauches conservent les lignes du prestataire qui ne correspondent pas, et l'expression CASE les classe dans des catégories explicables au lieu de les écarter. La sortie porte le montant net des frais de retrait du prestataire, tandis que la requête compare le montant tel qu'il figure sur le relevé ; savoir si ce montant est brut ou net relève du dictionnaire de données, et un écart égal aux frais constitue une différence expliquée, non une discordance (W-102 ci-dessous). Sur les blockchains à modèle de comptes, la jointure avec les sorties devient une jointure avec les transferts ou les journaux de transfert de jetons, avec un index de journal à la place de la sortie.

Exemple détaillé de rapprochement de cinq retraits d'un même compte :

Chaque ligne aboutit soit à une correspondance, soit à une explication. W-103 est un cas typique : les transferts internes entre clients d'un même service sont des écritures dans le grand livre du prestataire ; les données du prestataire en constituent donc la seule preuve (voir la leçon Traçage à travers les plateformes d'échange et les services de conservation). W-104 montre pourquoi une transaction par lots ne doit pas être attribuée dans son intégralité à un seul client. Les dépôts sont rapprochés de la même manière, en gardant à l'esprit que les prestataires regroupent ensuite les dépôts dans des portefeuilles chauds. Les différences de temps doivent être expliquées par le fuseau horaire du prestataire et les délais entre la demande, la diffusion et la confirmation.

Les comptes cloud comme éléments de preuve

Les services cloud contiennent ce que les utilisateurs souhaitent mettre à l'abri ou synchroniser : photos de phrases de récupération, sauvegardes de portefeuilles, feuilles de calcul d'adresses, coffres de gestionnaires de mots de passe, notes et courriels contenant des notifications de plateformes d'échange concernant les dépôts, les retraits, les connexions et les étapes KYC. Ces données sont obtenues et authentifiées comme celles des plateformes d'échange : préservées rapidement, produites en vertu d'une autorisation, soumises à un calcul d'empreinte à la réception et vérifiées quant à leur exhaustivité.

Le piratage de Bitfinex en 2016 montre l'intérêt de les combiner avec les données de la blockchain. En vertu d'un mandat de perquisition, les enquêteurs ont obtenu un fichier depuis un compte de stockage cloud et l'ont déchiffré. Il répertoriait environ 2 000 adresses de monnaie virtuelle avec leurs clés privées. L'analyse de la blockchain a relié presque toutes ces adresses au vol et, les 31 janvier et 1er février 2022, les autorités y ont saisi environ 94 636 BTC. Le fichier cloud apportait la preuve du contrôle et un lien avec son détenteur ; la blockchain confirmait que les adresses correspondaient aux fonds volés. Aucune de ces sources, prise isolément, n'aurait eu la même force probante.

Points clés pour l'examen : le contenu des données des plateformes d'échange (KYC, grand livre, dépôts, retraits, opérations de négociation, journaux d'accès, circuits de monnaie fiduciaire) et l'utilisation de chaque catégorie en investigation numérique ; les transmissions des prestataires, les exports utilisateur et les captures en direct ; les cinq étapes d'authentification (provenance, intégrité à la réception, attestation, signification, exhaustivité) et les pièges des tableurs ; la documentation des accès directs et par API et la voie du consentement prévue à l'article 32 de la Convention de Budapest ; le rapprochement des retraits par txid, adresse, montant net et heure ; l'explication des transferts internes, des frais, des lots et des demandes annulées ; les comptes cloud comme sources de clés, de sauvegardes et de notifications ; l'affaire Bitfinex comme exemple de combinaison des preuves issues du cloud et de la blockchain.