Die Zeit im Telefon ist nicht die Zeit der Wirklichkeit

In einem forensischen Auszug steht eine einzige Zeile, die scheinbar den ganzen Fall entscheidet. Neben einem im Telefon gefundenen Foto steht die Zeit 22:17:08. Das Bild zeigt den Eingang eines Hauses, davor ein geparktes Auto und in der Spiegelung der Scheibe einen Teil jener Person, deren Anwesenheit umstritten ist. Wenige Minuten später geschah dort etwas. Der Besitzer des Telefons behauptet, er sei bereits nicht mehr dort gewesen.

Die Zeitangabe des Fotos wirkt objektiver als eine Aussage. Ein Zeuge kann sich irren. Ein Verdächtiger kann lügen. Erinnerung wird umgeschrieben. Aber ein Telefon hat doch kein Motiv. Es hat 22:17 in die Tabelle geschrieben und scheint damit jeden Zweifel auszuräumen: Das Foto entstand um 22:17, das Telefon war um 22:17 vor Ort, also war auch sein Besitzer dort.

Dann wird eine detailliertere Auswertung derselben Datei geöffnet. Neben DateTimeOriginal: 22:17:08 erscheint ein weiterer Wert: File created: 22:43:51. In der Anwendungsdatenbank steht außerdem 2026-06-14T20:18:14.622Z. Und die Cloud-Historie verzeichnet die Synchronisierung erst am folgenden Tag um 03:12:04.

Vier Angaben. Eine Datei. Welche Zeit ist „richtig“?

Die bequemste Antwort lautet, einer der Werte müsse falsch sein. Die präzisere Antwort ist unangenehmer: Alle können wahr sein. Jeder kann jedoch ein anderes technisches Ereignis beschreiben. Und keiner muss für sich allein genau das beweisen, was wir aus ihm herauslesen wollen.

Eine Zeit braucht ein Verb

„22:17“ allein ist keine Aussage über die Vergangenheit. Es ist ein Wert. Bedeutung erhält er erst, wenn wir ein Verb hinzufügen: Das Foto wurde aufgenommen, die Nachricht wurde gesendet, die Datei wurde angelegt, die Daten wurden empfangen, die Sicherung wurde wiederhergestellt. Genau dieses Verb ist oft der Punkt, an dem sich ein technischer Wert unbemerkt in eine Geschichte verwandelt.

Ein digitales System zeichnet gewöhnlich nicht „den Moment des tatsächlichen Ereignisses“ auf. Es erfasst eine Änderung seines eigenen Zustands: die Entstehung eines Datenbankeintrags, den Eingang einer Anfrage beim Server, das Speichern einer Datei in einem Verzeichnis, eine Inhaltsänderung, Synchronisierung oder Anzeige eines Werts für den Nutzer. Die Fachliteratur unterscheidet deshalb zwischen dem beobachteten Artefakt, dem technischen Ereignis, das es repräsentieren kann, und dem umfassenderen Ereignis in der physischen Welt, das der Analytiker rekonstruiert. Eine Zeitzeile im Werkzeug ist nicht selbst das Ereignis; sie ist die Spur einer Veränderung, deren Bedeutung zuerst bestimmt werden muss.^[1]

Die richtige Frage zu stellen bedeutet daher, einen einfachen Satz in fünf Ebenen zu zerlegen: welches System zeichnete welche Änderung auf, nach welcher Uhr, in welcher Zeitrepräsentation und wie das verwendete Programm sie anschließend anzeigte. Erst danach lässt sich entscheiden, auf welchen Teil des tatsächlichen Geschehens sich der Wert bezieht.

Ein Foto, mindestens vier Vorgänge

Ein Foto ist eine ideale Falle, weil es wie ein einzelner Gegenstand aussieht. Tatsächlich kann es mehrere Zeitschichten tragen, die zu unterschiedlichen Momenten und an unterschiedlichen Orten entstanden sind.

In der Datei kann sich das EXIF-Feld DateTimeOriginal befinden, das für die Entstehungszeit der ursprünglichen Bilddaten bestimmt ist. Bei Digitalkamera oder Telefon stammt es in der Regel von der Geräteuhr im Moment der Aufnahme. Der Text selbst muss jedoch keine Zeitzoneninformation enthalten; der Standard kennt getrennte Angaben für den Zeitversatz, die fehlen können. EXIF kann beim Export entfernt, bei der Bearbeitung verändert oder gar nicht erst erzeugt werden. Seine genaue Bedeutung und Erhaltung hängen deshalb von Gerät, Format, Anwendung und Version ab.^[10]

Daneben existieren Zeitangaben des Dateisystems. Erstellungszeit bezeichnet typischerweise, wann dieses konkrete Dateiobjekt in diesem konkreten Speicher angelegt wurde. Wird ein Foto aus der Cloud geladen, in einem Messenger empfangen, aus einer Sicherung wiederhergestellt oder auf ein neues Gerät kopiert, kann es lange nach seiner Aufnahme „erstellt“ werden. Änderungszeit kann den letzten Schreibzugriff auf den Inhalt oder eine andere Änderung nach den Regeln des jeweiligen Systems bezeichnen. Zugriffszeit muss ebenfalls nicht den genauen Moment bezeichnen, in dem ein Mensch das Bild ansah: Manche Systeme verzögern oder begrenzen die Aktualisierung oder arbeiten mit gröberer Auflösung. Microsoft dokumentiert beispielsweise, dass NTFS Zeiten in UTC speichert, FAT dagegen in Ortszeit, und dass die Aktualisierung des letzten Zugriffs verzögert sein kann.^[6]

Dann folgt die Anwendungsebene. Eine Galerie kann ein Vorschaubild erzeugen, ein Medienindex die Datei in einen Katalog aufnehmen, eine Kommunikationsanwendung den Empfang eines Anhangs erfassen und die Cloud einen Upload oder eine Synchronisierung protokollieren. Jeder Vorgang kann einen eigenen Zeitstempel erzeugen. Es sind nicht vier Versionen derselben Zeit. Es sind Zeiten von vier verschiedenen Vorgängen, die sich um denselben Inhalt gruppieren.

Leitete ein Analytiker aus der Dateierstellungszeit den Aufnahmezeitpunkt ab, müsste er keinen gefälschten Wert verwenden. Er könnte mit einem vollkommen authentischen Zeitstempel arbeiten – und ihm lediglich das falsche Verb zuordnen.

Wer trug die Uhr?

Noch komplexer ist die Zeit einer Kommunikation. Eine Nachricht kann eine Erstellungszeit auf dem Clientgerät, eine Einreihungszeit, Sendezeit, Serverempfangszeit, Zustellzeit an das Empfängerkonto, Downloadzeit auf dessen Telefon und eine spätere Synchronisierungszeit haben. Die gewöhnliche Oberfläche zeigt dennoch womöglich nur eine Zahl und ein unbestimmtes Wort: „gesendet“.

Der Unterschied ist nicht akademisch. Das Telefon kann ohne Signal sein. Der Nutzer drückt um 22:17 auf die Schaltfläche, doch die Anwendung sendet den Inhalt erst um 22:26. Die Serverzeit belegt dann zuverlässig, wann der Server die Daten empfing, nicht zwingend, wann der Nutzer die Handlung ausführte. Umgekehrt kann die Clientzeit näher an der menschlichen Aktion liegen, hängt aber von der Geräteuhr ab. Diese kann automatisch aus dem Netz gestellt, manuell verschoben, vorübergehend unsynchronisiert oder während einer Reise zwischen Zeitzonen geändert worden sein.

Zeit des Clientgeräts wird von der Uhr des Telefons oder Computers abgeleitet, auf dem die Nutzerhandlung oder der lokale Schreibvorgang stattfand. Serverzeit stammt von der Uhr eines entfernten Systems und beschreibt gewöhnlich, wann der Server eine Anfrage empfing, verarbeitete oder speicherte. Ein Serverwert ist häufig besser synchronisiert und vom Nutzer des Telefons schwerer zu beeinflussen, doch deshalb ist er nicht automatisch die Zeit der menschlichen Handlung. Ein Clientwert kann dieser Handlung näher sein, trägt aber den Zustand der Geräteuhr mit sich.

Die aktuelle SWGDE-Methodik zur mobilen Forensik weist ausdrücklich darauf hin, dass Datum und Uhrzeit des Telefons aus dem Mobilfunknetz oder aus manueller Einstellung stammen, von tatsächlicher Zeit oder Zeitzone abweichen können und festgestellte Differenzen in der Analyse dokumentiert werden müssen. Dieselbe Methodik erinnert daran, dass konkrete Artefakte und ihre Funktionen von Hardware, Betriebssystem, Firmware, Anwendung, Version und Konfiguration abhängen.^[4]

Netzzeitsynchronisierung verringert diese Unsicherheit erheblich, beseitigt sie aber nicht. NTP ist kein Stempel absoluter Wahrheit; es schätzt die Abweichung einer Uhr gegenüber Zeitquellen und arbeitet zugleich mit Verzögerung, Streuung und erwarteter Fehlergröße. Je nach Implementierung kann ein System die Uhr schrittweise oder sprunghaft korrigieren. Für die Analyse ist deshalb nicht nur wichtig, ob das Gerät „automatische Zeit“ verwendete, sondern ob im relevanten Zeitraum Aufzeichnungen über Synchronisierung, Zeitzonenwechsel oder Uhrkorrekturen existieren.^[9]

UTC ist nicht der Ort, an dem das Ereignis geschah

Die Zeitzone ist eine weitere Schicht, die beim gewöhnlichen Lesen verloren geht. Die Angabe 2026-06-14T20:18:14Z bezeichnet einen Zeitpunkt in UTC. In Prag wird derselbe Moment während der Sommerzeit als 22:18:14 angezeigt. Es handelt sich weder um zwei verschiedene Ereignisse noch um einen Fehler von zwei Stunden, sondern um zwei Darstellungen desselben Zeitpunkts.

Ein Unix-Zeitstempel geht noch weiter: Er speichert typischerweise die Zahl der Sekunden seit der Epoche vom 1. Januar 1970 in UTC. Der Wert 1781468294 enthält weder „Prager Zeit“ noch Informationen darüber, wo sich das Telefon befand. Erst Software übersetzt ihn in Datum und Uhrzeit für die gewählte Zone. Manche Systeme verwenden zudem Millisekunden, Mikrosekunden oder andere Epochen. Die Verwechslung von Sekunden und Millisekunden erzeugt keinen Versatz um eine Stunde; sie kann ein absurd wirkendes Datum hervorbringen – und dennoch lediglich die Folge einer falsch gedeuteten Einheit sein.

Außerdem besteht ein Unterschied zwischen UTC-Versatz und Zeitzone. Der Wert +02:00 beschreibt die Beziehung zu UTC in einem bestimmten Moment. Die Bezeichnung Europe/Prague trägt ein Regelwerk, nach dem sich der Versatz historisch und beim Wechsel zwischen Normal- und Sommerzeit verändert. Moderne Internetstandards unterscheiden deshalb einen festen Zeitstempel mit UTC-Versatz von ergänzenden Angaben zu einer benannten Zeitzone.^[8]

Bei der herbstlichen Zeitumstellung kann dieselbe Ortszeit zweimal vorkommen. „02:30“ ohne Datum, Zone und Versatz bezeichnet dann womöglich keinen eindeutigen Moment. Beim Sprung im Frühjahr treten manche lokalen Uhrzeiten dagegen überhaupt nicht auf. Wendet ein Programm heutige Zonenregeln auf einen älteren lokalen Wert an, kann sein Ergebnis von dem eines Programms abweichen, das historische Regeln oder nur einen festen Versatz nutzt.

Deshalb muss der gespeicherte Wert von seiner Anzeige unterschieden werden. Zwei Werkzeuge können über denselben Bytes 20:18 und 22:18 zeigen, ohne einen Zeitstempel verändert zu haben. Der Unterschied entstand durch die Umrechnung.

Die Cloud gibt Daten ein zweites Leben

Ein Telefon ist längst keine geschlossene Schachtel mehr. Ein Foto kann auf einem Gerät entstehen, über einen Server gesendet, automatisch in der Cloud gespeichert, auf einen Laptop geladen, bearbeitet, erneut synchronisiert und schließlich auf einem neuen Telefon wiederhergestellt werden. Bei jedem Schritt entstehen legitime Zeitspuren.

Ein Cloud-Dienst kann die Erstellung eines Objekts in seinem Speicher, die letzte Änderung der Cloud-Kopie, Upload, Vorschaubilderzeugung, Freigabe, Download oder Synchronisierung erfassen. Was seine Oberfläche „created“ nennt, muss nicht der Entstehungszeitpunkt des ursprünglichen Inhalts sein. Die SWGDE-Methodik warnt, dass die Erstellungszeit eines Cloud-Objekts einem Download oder einer Verschiebung entsprechen, die Änderungszeit eine Synchronisierung statt einer Nutzeränderung widerspiegeln und die Zeitzone des Eintrags nicht auf den ersten Blick erkennbar sein kann.^[5]

Migration und Wiederherstellung aus einer Sicherung erzeugen eine besondere Zeitillusion. Ein neues Telefon kann eine drei Jahre alte Nachricht enthalten, obwohl die Datenbankdatei erst gestern auf diesem Gerät angelegt wurde. Ein Bild kann sein ursprüngliches EXIF bewahren, während seine Dateierstellungszeit die Wiederherstellung bezeichnet. Eine Anwendung kann alte Anwendungszeitstempel in eine neu erzeugte Datenbank importieren. Keiner dieser Werte muss fehlerhaft sein. Jeder verfolgt nur eine andere Kontinuität: Inhalt, Datenbankeintrag, Datei oder Gerät.

Ein Gerätewechsel kehrt daher die gewöhnliche Intuition um. Ein Fund „im Telefon“ bedeutet nicht zwingend, dass die Daten dort entstanden. Er kann belegen, dass sie auf das Telefon synchronisiert, importiert oder wiederhergestellt wurden. Und das Fehlen einer alten Dateizeit bedeutet nicht, dass der Inhalt zuvor nicht existierte; sie kann beim Kopieren zwischen Systemen verloren gegangen sein, die unterschiedliche Metadaten bewahren.

Die Cloud ist dabei nicht nur eine Quelle der Verwirrung. Sie liefert oft eine unabhängiger geführte Serverzeit, Versionshistorie oder Einträge, die das lokale Gerät nicht mehr enthält. Ihre Stärke entsteht jedoch erst, wenn der Analytiker weiß, welchen Prozess ein Feld beschreibt und ob tatsächlich unabhängige Quellen verglichen werden. Drei Werte, die aus demselben Cloud-Ereignis abgeleitet sind, sind nicht automatisch drei unabhängige Bestätigungen.

Eine Datenbank speichert nicht „Zeit“. Sie speichert eine Vereinbarung über Zeit

In einer Datenbank kann ein Zeitstempel besonders überzeugend wirken: Eine lange Zahl mit Millisekunden sieht wissenschaftlich aus. Doch die Datenbank weiß häufig nicht, was die Zahl bedeutet. Sie weiß nur, dass in einer bestimmten Spalte eine Ganzzahl, ein Dezimalwert oder Text liegt.

SQLite, das in mobilen und Desktop-Anwendungen weit verbreitet ist, besitzt keinen eigenen Datentyp für Datum und Uhrzeit. Zeitwerte können als ISO-8601-Text, julianische Tageszahl oder Unix-Zeitstempel gespeichert werden. Bedeutung liefern das Anwendungsschema und der Code, der den Wert schreibt und liest.^[7] Eine Spalte namens created_at kann Sekunden seit 1970, Millisekunden seit derselben Epoche, lokalen Text ohne Zone oder Serverzeit enthalten. Der Feldname ist ein Hinweis, kein Beweis seiner genauen Semantik.

Noch wichtiger ist die Frage, wer den Wert erzeugt hat. Schrieb ihn der Client nach der Uhr des Telefons? Ergänzte ihn der Server beim Eingang der Anfrage? Wurde er aus einem importierten Eintrag übernommen? Aktualisierte ihn eine Synchronisierung? Eine Datenbank kann gleichzeitig die Entstehungszeit des Inhalts, die letzte Änderung des Datensatzes und die letzte Synchronisierungszeit speichern. Werden alle drei Spalten ohne Kenntnis ihrer Bedeutung in eine einzige Zeitleiste übernommen, entsteht eine schön geordnete, aber sachlich falsche Geschichte.

Deshalb braucht fachliche Interpretation Dokumentation und Prüfung an einem vergleichbaren System. Das genaue Verhalten kann sich zwischen Anwendungsversionen ändern. Ein Update kann die Zeit vom Client auf den Server verlagern, die Einheit ändern oder ein neues Feld einführen. Fehlt Dokumentation, ist Unsicherheit ein legitimer Schluss – nicht die selbstsichere Zuweisung der wahrscheinlichsten Bedeutung.

Wenn ein Werkzeug Zeit übersetzt

Zwischen rohem Artefakt und Mensch steht gewöhnlich ein Programm. Ein forensisches Werkzeug liest Bytes, erkennt ein Format, entscheidet, ob eine Zahl Sekunden oder Millisekunden darstellt, weist ihr eine Epoche zu, rechnet sie in UTC oder eine konfigurierte Zone um und fügt eine Bezeichnung hinzu. Jeder Schritt kann richtig sein – und jeder fügt Interpretation hinzu.

Deshalb kann eine grafische Oberfläche Ortszeit anzeigen, während ein CSV-Export UTC enthält. Ein Analytiker kann das Projekt auf die Zone des Beweisgeräts einstellen, ein anderer auf seine eigene Ortszeit. Eine ältere Parser-Version kann dasselbe Feld anders benennen als eine neue. Und ein Programm kann lokalen Text ohne Zeitzone nach den Einstellungen des Computers umrechnen, obwohl das Gerät zum Ereigniszeitpunkt anderswo war.

Eine solide Zeitanalyse bewahrt deshalb drei Formen des Werts: den Rohwert, die decodierte Bedeutung und den angezeigten Wert in einer angegebenen Zeitzone. Dazu gehören Werkzeugversion, Projekteinstellungen und Extraktionsmethode. Nicht weil Werkzeugen grundsätzlich nicht zu trauen wäre, sondern weil sie Übersetzer sind. Nach einer Prüfung der wissenschaftlichen Grundlagen digitaler Ermittlungen fasst NIST zusammen, dass die verwendeten Techniken auf etablierten Methoden der Informatik beruhen und bei sachgerechter Anwendung als zuverlässig gelten.^[3] Die Worte „bei sachgerechter Anwendung“ sind hier wichtiger als die Marke der Software.

Authentizität, Richtigkeit der Uhr und Beweisbedeutung sind drei verschiedene Fragen. Ein Wert kann authentisch in der ursprünglichen Datenbank gespeichert sein und dennoch aus einer falsch eingestellten Uhr stammen. Er kann zeitlich präzise sein, aber den Serverempfang statt der Bildaufnahme bezeichnen. Und er kann eine Datenübertragung korrekt belegen, ohne zu beweisen, wer das Telefon hielt.

Stärke entsteht im Schnittpunkt

Kehren wir zum Foto aus der Einleitung zurück. EXIF nennt 22:17:08, enthält jedoch keine sichere Zeitzoneninformation. Der Server registriert den Empfang um 20:18:14.622 UTC, also 22:18:14 lokaler Sommerzeit. Eine Netzwerkspur zeigt die Übertragung zwischen 22:18:12 und 22:18:16. Das Telefon des Empfängers speichert die Datei um 22:43:51, die Cloud synchronisiert sie in der Nacht.

Aus diesen Angaben lässt sich nicht redlich behaupten, der Auslöser sei exakt um 22:17:08 gedrückt worden. Man kann aber etwas anderes sagen: Ist nachgewiesen, dass der Server genau diesen Inhalt empfing, musste er spätestens um 22:18:14 existiert haben. Die Netzwerkspur stützt dieselbe Abfolge. EXIF ist mit einer Aufnahme etwa eine Minute vor der Übertragung vereinbar, doch sein Gewicht hängt von der Richtigkeit der Geräteuhr und der Integrität der Metadaten ab. Die Dateierstellungszeit 22:43 beschreibt nicht die Aufnahme; sie passt zur späteren Speicherung einer Kopie.

Eine solide Zeitleiste entsteht deshalb nicht durch mechanisches Sortieren sämtlicher Zeitstempel. Sie entsteht, indem jedem Wert Herkunft, Uhr, Format, mögliche Abweichungen und technisches Ereignis zugeordnet werden. Danach sucht man nach übereinstimmenden Abfolgen, Widersprüchen und Zeitankern: Serverprotokollen, Synchronisierungseinträgen, Netzwerkereignissen, Daten eines weiteren Geräts oder anderen Spuren, deren Beziehung zur externen Zeit besser bekannt ist.

Das Ergebnis muss kein Punkt sein. Oft ist es ein Intervall und eine Reihenfolge: Der Inhalt existierte bereits; dann wurde er übertragen; später erschien er in diesem Telefon; schließlich wurde er synchronisiert. Ein solcher Schluss ist vielleicht weniger dramatisch als ein fett gesetztes „22:17“, aber meist erheblich genauer.