Trusted date

A photo's date is not your phone's date

A smartphone clock is set by whoever holds the phone. How to obtain a date that stands up: RFC 3161 timestamps, NTP synchronisation and qualified eIDAS timestamps.

Trusted date 18 July 2026

Of all the challenges a photograph can face, backdating is the most common and the easiest. It requires no expert analysis: it requires pointing out that the date is written by your phone, and your phone is controlled by you.

The problem in one line

Every photograph carries a capture instant, read from the device system clock. And the system clock is an editable setting: three taps take the phone to any date, you shoot, then restore the current time. The resulting file is indistinguishable from one genuinely taken on that date.

A date you gave yourself is not a fact — it is your own statement. Evidential weight begins where the information comes from someone else.

Three levels of «date», not to be confused

1. Phone clock set by whoever holds it no guarantee at all worth nothing 2. NTP synchronisation real time from public servers records the clock drift useful, not conclusive 3. RFC 3161 timestamp signed by a third authority verifiable by anyone this one holds Only the third level answers the question: who else, besides you, can confirm that instant?
The three levels are not alternatives: LOCUS records all three, because they document different things.

The local clock

The time you see on the phone. Useful to you, worthless towards third parties, for the reason above.

NTP synchronisation

The Network Time Protocol lets a device ask public servers for the exact time (LOCUS queries time.cloudflare.com, time.google.com and pool.ntp.org in a fallback cascade). It is not a certification — it is a measurement. The value lies in LOCUS recording both the NTP time and the local clock offset: if the phone was four minutes behind, the manifest says so. That is transparency, not proof.

The RFC 3161 timestamp

Here everything changes. The device computes the file fingerprint and sends only that to a Time-Stamping Authority (TSA). The TSA returns a signed token stating, in essence: «at this time, I saw this fingerprint».

Your device computes the fingerprint only the fingerprint goes out — never the photo a signed token comes back, with date and time Third-party TSA never sees the content A TSA certifies the anteriority of a fingerprint, not the content of the scene.
The RFC 3161 exchange. Because only the fingerprint travels, the authority never sees the photograph: confidentiality is preserved.

Two practical consequences, both important:

  • Confidentiality is preserved. The TSA receives a string, not an image. It does not know what you photographed, and could not say even if it wanted to.
  • A timestamp proves anteriority, not content. It says the file already existed. It does not say it depicts the truth. That is a real limit, worth knowing rather than hiding.

Ordinary versus qualified timestamps

Not all timestamps are equal, and the distinction matters.

An ordinary RFC 3161 timestamp — such as those issued by public authorities like Sectigo, DigiCert or GlobalSign — is technically sound and verifiable by anyone using the issuer's public CA. That is what LOCUS applies by default, querying several authorities across different jurisdictions.

A qualified electronic timestamp under eIDAS Regulation (EU) 910/2014, issued by a qualified trust service provider (QTSP), is a different matter legally: Article 41 grants it a presumption of the accuracy of the date and time it indicates and of the integrity of the data it is bound to. In practice the burden shifts: you do not have to prove the date is right — the challenger has to prove it is not. In LOCUS this is available on request through a qualified provider and consumes additional slots.

Beware a common imprecision: «accredited» is not a synonym for «qualified». A reliable public TSA is not automatically an eIDAS QTSP. If you need the Article 41 presumption, you need a qualified timestamp.

Why LOCUS timestamps twice

Each acquisition receives two distinct timestamps. The first on the media: it fixes the photo, video or audio in time. The second on the signed inventory of all the package's supporting files: it fixes the whole sealed bundle in time, not just the content.

The difference shows when someone tries to rework the package: adding a file, swapping a supporting document, removing an inconvenient attachment. With only the media timestamp, those manipulations would leave no trace. With the second one they do, and they are immediately visible.

How to verify it

An RFC 3161 timestamp is verified with OpenSSL, a standard tool with nothing to do with us:

openssl ts -verify -data data/media.jpg -in data/tsa.tsr -CAfile tsa-ca.pem

A LOCUS bundle ships the issuing authorities' certificates (tsa-ca.pem), so verification works with no connection at all. That is the whole point: whoever checks should depend neither on our site nor on our software. One known caveat on macOS: the system OpenSSL is actually LibreSSL, which does not implement the ts subcommand — you need real OpenSSL.

The limit to keep in mind

Timestamping answers «when?» and answers it well. It does not answer «is it true?». It certifies that a given fingerprint existed at a given instant; whether the corresponding image faithfully depicts reality is a separate question, resting on context and on the operator.

Note too that timestamping requires connectivity: without a network the TSA cannot be queried, which is why LOCUS does not allow offline acquisition. Verification, by contrast, works perfectly on an air-gapped machine.

Continue with what it takes for a photo to hold up, or see how to validate a bundle step by step.

More guides