Werkzeuge, Reproduzierbarkeit und Validierung

Fast jede Krypto-Trace wird mit Software erstellt, und ein Großteil dieser Software ist proprietär, verändert sich schnell und ist meinungsstark. Das Gericht muss dem Werkzeug nicht vertrauen, wohl aber dem Befund. Dieses Vertrauen entsteht dadurch, dass gezeigt wird, wie sich die Fakten aus Rohdaten der Blockchain erneut ableiten lassen, dass das Werkzeug für den jeweiligen Zweck geprüft wurde und dass jede Einstellung und jede Quelle von Labels dokumentiert ist. Diese Lektion behandelt, wie Werkzeuge an ihrem Platz bleiben.

Die Werkzeuglandschaft

Werkzeuge lassen sich in einige allgemeine Kategorien einteilen. Produktnamen sind hier nicht entscheidend; wichtig ist, was die jeweilige Kategorie zur Beweislage beiträgt.

Die meisten Einheiten verwenden mehrere Werkzeuge gleichzeitig: eine Plattform zum Erkunden und Generieren von Ermittlungsansätzen, eine Node und eigene Abfragen zur Feststellung von Fakten sowie einen Bericht, der auf beidem beruht.

Node-Daten im Vergleich zu Werkzeugausgaben

Jede Werkzeugausgabe vereint drei Ebenen. Fakten sind Rohdaten der Blockchain: txids, Outputs, Beträge, Blöcke. Deterministische Transformationen wandeln Rohdaten in eine lesbare Form um: Einheitenumrechnung, Dekodierung von Ereignissen, Traces. Interpretationen fügen eine Beurteilung hinzu: Cluster, Labels, Change-Zuordnungen, Zuweisungsergebnisse.

Auf jeder Ebene kann ein Werkzeug Fehler machen. Es kann Daten falsch parsen (die Dezimalstellen eines Tokens, eine ausgelassene interne Übertragung, eine fehlerhafte Behandlung einer Reorganisation), eine unvollständige Abdeckung haben (ein Token wird nicht indexiert, eine Blockchain nicht unterstützt, Daten hinken dem aktuellen Stand hinterher) oder Standardwerte anwenden, die der Prüfer nie gewählt hat (eine Change-Heuristik ist aktiviert, eine Zuweisungsmethode voreingestellt). Die Arbeitsregel lautet: Jede Tatsache in einem forensischen Bericht muss auf Rohdaten zurückführbar sein, die eine dritte Partei auf ihrer eigenen Node überprüfen kann, und bei jeder Interpretation müssen Methode und Einstellungen angegeben werden. Ein Screenshot einer Graphansicht dient der Veranschaulichung; er beweist nichts. Bewahren Sie die zugrunde liegenden Exporte auf.

Eine Trace aus Rohdaten erneut durchführen

Bevor eine Trace berichtet wird, leiten Sie sie außerhalb des Werkzeugs, mit dem sie erstellt wurde, erneut her:

1. Exportieren Sie den vom Werkzeug ermittelten Pfad als Hop-Tabelle: txid, Output- oder Log-Referenz, Blockhöhe, Betrag in Basiseinheiten;
2. leiten Sie dieselben Felder aus Ihrer eigenen Node oder einem mit einer Node abgeglichenen Data Warehouse erneut her;
3. vergleichen Sie die Felder einzeln;
4. berechnen Sie Zuweisungen mit Ihrem eigenen Skript nach der angegebenen Methode neu;
5. dokumentieren Sie Abweichungen und wie sie jeweils geklärt wurden.

-- Die vom Werkzeug exportierten Hops mit den aus unserer eigenen Node erneut abgeleiteten Werten vergleichen
SELECT t.hop_id, t.txid, t.out_ref,
       t.amount_base  AS tool_amount,   n.amount_base  AS node_amount,
       t.block_height AS tool_height,   n.block_height AS node_height,
       CASE
         WHEN n.txid IS NULL THEN 'NOT FOUND ON NODE'
         WHEN t.amount_base <> n.amount_base
           OR t.block_height <> n.block_height THEN 'MISMATCH'
         ELSE 'OK'
       END AS check_result
FROM tool_hops t
LEFT JOIN node_hops n ON n.txid = t.txid AND n.out_ref = t.out_ref
ORDER BY t.hop_id;

Der Left Join behält jeden vom Werkzeug gemeldeten Hop bei. Ein Hop, der in den Node-Daten fehlt, erscheint daher als „NOT FOUND ON NODE“, statt zu verschwinden. Beträge werden als Ganzzahlen in Basiseinheiten verglichen; ein Fehler bei den Dezimalstellen zeigt sich daher als Abweichung um eine Zehnerpotenz. Die Abfrage prüft nur Fakten; eine Übereinstimmung sagt nichts darüber aus, ob die Labels oder Change-Zuordnungen des Werkzeugs korrekt sind.

Werkzeuge validieren

Laborstandards verlangen, dass Methoden und die Werkzeuge, mit denen sie umgesetzt werden, nachweislich zweckgeeignet sind. ISO/IEC 17025 verpflichtet Labore, nicht standardisierte Methoden, im Labor entwickelte Methoden sowie Standardmethoden zu validieren, wenn diese außerhalb ihres vorgesehenen Anwendungsbereichs eingesetzt oder anderweitig geändert werden (Klausel 7.2.2). ISO/IEC 27041 enthält Leitlinien dazu, wie sichergestellt werden kann, dass Ermittlungsmethoden geeignet und angemessen sind. Das Qualitätsmanagementsystem in diesem Zusammenhang wird in der Lektion Qualitätsmanagement in der forensischen Einheit behandelt; hier liegt der Schwerpunkt auf den Werkzeugen.

Die Minimum Requirements for Testing Tools Used in Digital and Multimedia Forensics der SWGDE (Dokument 18-Q-001, Version 2.1, März 2024) beschreibt drei Prüfstrategien, die alle auf Blockchain-Werkzeuge anwendbar sind:

• Prüfung mit bekannten Datensätzen: Eingaben mit bekanntem Ergebnis bereitstellen und die Ausgabe überprüfen.
• Vergleichsprüfung: Mindestens zwei Werkzeuge ausführen und prüfen, ob die Ergebnisse übereinstimmen.
• Empirische Prüfung: Die Ausgabe anhand anderer Daten überprüfen.

Außerdem fordert die SWGDE Prüfprotokolle, in denen Zweck und Umfang, die prüfende Person, das Datum, das Verfahren, die Datensätze und erwarteten Ergebnisse, die Ergebnisse einschließlich Auffälligkeiten sowie die festgestellten Einschränkungen dokumentiert werden. Sie empfiehlt, interne Werkzeuge bei der ersten Verwendung und nach jeder Überarbeitung erneut zu prüfen sowie Suchwerkzeuge nach größeren Aktualisierungen. Das NIST-Programm Computer Forensics Tool Testing (CFTT) bietet ein Modell für die Strukturierung von Prüfungen: Es orientiert sich an den Funktionen und erstellt für jede Werkzeugfunktion vor der Prüfung eine Spezifikation mit Anforderungen, Assertions und Testfällen.

Für ein Blockchain-Werkzeug listet ein praktischer Prüfplan dessen Funktionen auf und weist jeder ein bekanntes Ergebnis zu:

Kontrollierte Testtransaktionen sind besonders wertvoll, weil die Einheit die tatsächlichen Eigentumsverhältnisse und Change-Ausgaben kennt. Alle festgestellten Punkte werden in ein Register bekannter Einschränkungen aufgenommen, das Prüfer vor dem Einsatz des Werkzeugs lesen und das für eine Offenlegung zur Verfügung steht.

Versionen und Quellen von Labels dokumentieren

Für jeden Analyselauf wird ein Datensatz angelegt und mit der Fallakte aufbewahrt:

{
  "run_id": "CF-2026-0142-R07",
  "started_utc": "2026-03-05T08:40:12Z",
  "tool": {"category": "investigation platform", "version": "8.4.1", "data_through_block": 939910},
  "node": {"client": "Bitcoin Core", "version": "29.0", "tip_height": 939962},
  "settings": {"allocation": "haircut", "hop_limit": 6, "change_heuristic": "on",
               "stop_at": "labeled custodial services"},
  "labels_used": [
    {"address": "bc1q…dx7e", "label": "Exchange K deposit", "source": "platform cluster 4471",
     "basis": "co-swept with known deposits", "retrieved_utc": "2026-03-05T08:52:40Z"}
  ],
  "exports": [{"file": "R07_hops.csv",
               "sha256": "3b1f…9e02"}],
  "examiner": "EX-07"
}

Der Datensatz fixiert die Werkzeugversion und die Blockhöhe, bis zu der die Daten reichen; diese kann hinter dem aktuellen Stand der Node zurückliegen. Er führt alle Einstellungen auf, die Ergebnisse verändern. Jedes Label wird mit seiner Quelle, der angegebenen Grundlage und dem Zeitpunkt seines Abrufs dokumentiert, weil sich Labels ändern; dieselbe Adresse kann im nächsten Monat anders gelabelt sein. Für jeden Export wird ein Hash erzeugt, damit spätere Kopien damit abgeglichen werden können. Im echten Datensatz wird der tatsächliche Name des Werkzeugs eingetragen; in diesem Kurs bleibt er allgemein gehalten. Die Aufbewahrung dieser Dateien wird in den Lektionen On-Chain-Beweise sichern und Hashing, Protokollierung und Beweismittelkette behandelt.

Wenn Werkzeuge unterschiedliche Ergebnisse liefern

Unstimmigkeiten zwischen Werkzeugen sind normal und nützlich: Sie zeigen, wo die Interpretation beginnt. Betrachten Sie den Pfad aus der Lektion Tracing nach Beweisstandard. Werkzeug A gibt an, dass 0,90909091 BTC des Lösegelds bei bc1q…dx7e angekommen sind, und labelt die Adresse als Einzahlung bei Exchange K. Werkzeug B gibt 1,20000000 BTC an und lässt die Adresse ungelabelt.

Gehen Sie vom ersten Punkt der Abweichung aus zurück zu den Rohdaten:

Häufige Ursachen sind unterschiedliches Clustering (ein Werkzeug hat zwei Cluster zusammengeführt), unterschiedliche Change-Zuordnungen, unterschiedliche Quellen oder Abrufdaten von Labels, unterschiedliche Zuweisungsstandards, fehlende interne Übertragungen oder Tokens sowie unterschiedliche Blockhöhen als Stichtag. Dokumentieren Sie die Abweichung, ihre Ursache und die Lösung in der Fallakte und entscheiden Sie niemals einfach zugunsten des bequemeren Ergebnisses. Sachverständige der Verteidigung hinterfragen oft die Intransparenz von Werkzeugen und die Herkunft von Labels; siehe die Lektion Offenlegung und Prüfung durch die Verteidigung.

Prüfungsschwerpunkt: die Kategorien von Werkzeugen und ihr jeweiliger Beitrag zur Beweislage; Fakten, deterministische Transformationen und Interpretationen sowie mögliche Fehler von Werkzeugen auf jeder Ebene; warum berichtete Fakten erneut aus Rohdaten ableitbar sein müssen und Screenshots nur der Veranschaulichung dienen; eine Trace erneut durchführen und Werkzeugexporte mit Node-Daten vergleichen; Methodenvalidierung nach ISO/IEC 17025 und ISO/IEC 27041; die drei Prüfstrategien der SWGDE, Prüfprotokolle und erneute Prüfungen; das funktionsorientierte Modell des NIST CFTT; Prüfungen mit bekannten Ergebnissen, einschließlich kontrollierter Transaktionen; das Register bekannter Einschränkungen; die Felder eines Datensatzes für einen Analyselauf (Version, Datenhöhe, Einstellungen, Quelle und Abrufzeitpunkt von Labels, Export-Hashes); Abweichungen zwischen Werkzeugen diagnostizieren und dokumentieren.