Technische Beweisfragen
Digitale Zeitangaben wirken präzise, können aber unterschiedliche Ereignisse beschreiben: Dateisystemzeit, Commitzeit, Serverlog, Datenbankzeit oder signierter Zeitstempel. Eine belastbare Versionszuordnung entsteht erst, wenn Quelle, Zeitzone, Uhrenbasis und technische Entstehung der Metadaten geklärt sind.
Kurzantwort
Zeitstempel werden nicht isoliert gelesen, sondern mit ihrem Erzeugungssystem und weiteren Ereignissen korreliert. Für eine Versionszuordnung werden Hashes, Builds, Releases, Commit-IDs, Deployments und Laufzeitmerkmale zusammengeführt. Ein kryptografischer Zeitstempel kann das Vorhandensein bestimmter Daten zu einem Zeitpunkt stützen, ersetzt aber keine vollständige Herkunftsrekonstruktion.
Vom Untersuchungsstand zur nachvollziehbaren technischen Schlussfolgerung
1. Metadatenquelle und semantische Bedeutung klären
Ein mtime-Feld im Dateisystem, ein Git-Commitdatum und ein HTTP-Date-Header besitzen unterschiedliche Entstehungsbedingungen. Vor jeder Chronologie wird deshalb geklärt, welches technische Ereignis die jeweilige Zeitangabe tatsächlich repräsentiert.
Metadaten können beim Kopieren, Exportieren oder Konvertieren verändert werden. Eine sichtbare Zeitangabe ist daher nicht automatisch ein unveränderlicher Entstehungszeitpunkt.
2. Zeitzonen, Uhren und Synchronisation berücksichtigen
UTC, lokale Zeitzonen, Sommerzeit und nicht synchronisierte Systemuhren können scheinbare Widersprüche erzeugen. Die Prüfung dokumentiert Rohwert, interpretierte Zeitzone und bekannte Offset- oder Synchronisationsinformationen.
Bei verteilten Systemen können wenige Sekunden Abweichung die Reihenfolge eng aufeinanderfolgender Ereignisse beeinflussen. Deshalb werden keine überpräzisen Schlussfolgerungen gezogen, wenn die Uhrenqualität nicht belegt ist.
3. Kryptografische Zeitstempel korrekt abgrenzen
RFC 3161 beschreibt einen Time-Stamping-Dienst, der stützen kann, dass ein Datum zu einem bestimmten Zeitpunkt vorlag. Für die technische Bewertung werden Token, Hashbezug und Vertrauenskette geprüft.
Ein solcher Zeitstempel belegt nicht automatisch, wer den Inhalt erzeugt hat oder ob er fachlich korrekt ist. Er bezieht sich auf den eingebrachten Datenhash und die Eigenschaften des verwendeten Zeitstempeldienstes.
4. Mehrere unabhängige Ereignisquellen korrelieren
Stärkere Chronologien entstehen, wenn unterschiedliche Systeme dasselbe Ereignis aus eigener Perspektive erfassen: beispielsweise CI-Build, Artefakt-Repository, Deploymentplattform und Applikationslog.
Abweichungen werden nicht stillschweigend geglättet. Sie können auf Zeitzonenfehler, verzögerte Verarbeitung oder tatsächlich unterschiedliche Zustände hinweisen und sind damit selbst Teil des technischen Befunds.
5. Versionszuordnung über identifizierbare Artefakte absichern
Commit-ID, Buildnummer, Container-Digest und veröffentlichte Releaseversion können eine Kette zwischen Quelle und Laufzeit bilden. Je mehr Glieder technisch belegt sind, desto enger kann der untersuchte Zustand einer Version zugeordnet werden.
Fehlt diese Kette, sollte eine Oberfläche mit Versionsnummer nicht als alleiniger Beweis eines bestimmten Quellstands verwendet werden. Buildparameter oder nachträgliche Änderungen können denselben sichtbaren Versionsstring erzeugen.
6. Zeitfenster und Unsicherheit statt Scheingenauigkeit berichten
Wenn Metadaten nur ein Intervall stützen, wird ein Zeitfenster angegeben. Eine exakte Sekunde ist methodisch nicht besser, wenn die zugrunde liegende Uhr oder Quelle diese Genauigkeit nicht trägt.
Die Schlussfolgerung trennt direkt beobachtete Metadaten von daraus abgeleiteten zeitlichen Hypothesen. Dadurch bleibt erkennbar, welche Zuordnung reproduzierbar und welche nur plausibel ist.
Bei E-Mail-, Cloud- oder SaaS-Exporten können mehrere Zeitfelder existieren, die Client-, Server- und Verarbeitungsperspektiven abbilden. Die Feldsemantik sollte anhand des konkreten Formats oder Systems geklärt werden, bevor Ereignisse sortiert werden.
Für Git ist zwischen Author Date und Committer Date zu unterscheiden; für Builds können wiederum separate CI-Zeitpunkte relevant sein. Solche Systemeigenschaften werden nicht vereinheitlicht, sondern bewusst als unterschiedliche Ereignistypen modelliert.
Ist der Dateizeitstempel der sichere Entstehungszeitpunkt einer Datei?
Nein. Dateisystemzeitstempel können je nach System Kopier-, Änderungs- oder Metadatenoperationen abbilden und teilweise verändert werden.
Ihre Bedeutung muss im Kontext des konkreten Dateisystems und Erhebungswegs interpretiert werden.
Belastbarer wird die Einordnung durch unabhängige Ereignisquellen und nachvollziehbare Provenienz.
Ist die Untersuchung für diesen Themenbereich technisch nachvollziehbar?
- Ist für jede verwendete Zeitangabe bekannt, welches System und welches Ereignis sie erzeugt hat?
- Sind Zeitzone, Format und mögliche Uhrenabweichungen dokumentiert?
- Wurden Metadaten vor unnötigen Transformationen gesichert?
- Sind kryptografische Zeitstempel in Bezug auf Hash und Token separat geprüft?
- Werden unabhängige Log-, Build- oder Deploymentquellen zur Korrelation genutzt?
- Ist die Versionszuordnung über Commit, Build oder Artefakt nachvollziehbar belegt?
- Wird Unsicherheit als Zeitfenster oder Alternativhypothese sichtbar gemacht?
Konstruiertes Beispiel
Ein Deploymentlog meldet 10:03 UTC, während ein lokales Administrationsprotokoll 12:04 Uhr ausweist. Nach Prüfung der Zeitzonen und einer dokumentierten Uhrabweichung von rund einer Minute lassen sich beide Einträge demselben Rollout zuordnen; der Bericht gibt dennoch ein Zeitfenster statt einer sekundengenauen Behauptung an.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- Internetstandard RFC 3161 Time-Stamp Protocol zur technischen Einordnung kryptografischer Zeitstempel. Quelle öffnen.
- W3C-Empfehlung W3C PROV-DM als Datenmodell zur Beschreibung von Entitäten, Aktivitäten und Provenienzbeziehungen. Quelle öffnen.
- NIST-Leitlinie NIST SP 800-86 zur technischen Erhebung und Analyse digitaler Datenquellen. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Hashwerte, Integrität & Nachweiskette
- Git-Historie & Software-Provenienz
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zum Themenbereich Technische Beweisfragen
Die konkrete Aussagekraft hängt vom Untersuchungsgegenstand, der verfügbaren Evidenz und der dokumentierten Prüfmethode ab.
Gerichte & Rechtsanwälte