Forensic Methodology Whitepaper

Technical reference for prosecutors, defense counsel, expert witnesses, and agency Information Security Officers evaluating DVR Time Traveler's reports.

1. Scope and intended use

DVR Time Traveler is an investigative aid. It performs deterministic arithmetic on time values supplied by an officer and produces a structured PDF report documenting the calculation, the inputs, the device on which the calculation was performed, and the time at which the calculation was performed.

The application does not ingest video, decode video timestamps, establish chain of custody for media, or assert that the underlying DVR recording is authentic. Those determinations remain the responsibility of the investigator, the seizing agency, and the trier of fact.

This whitepaper describes the controls that allow a third party to independently verify, weeks or years after the fact, that:

1. The PDF in question was produced by DVR Time Traveler.
2. It has not been altered since the moment of generation.
3. The hash of its content existed at or before a specific instant in time, attested by an independent Time-Stamping Authority.
4. The device clock used to perform the calculation was, within a stated margin, accurate at the time of generation.

2. Problem statement

Surveillance Digital Video Recorders (DVRs) commonly run free-running real-time clocks that are not synchronized to authoritative time sources. Drift of seconds per day is normal; drift of hours or days is not unusual for DVRs that have been re-installed without re-configuration, lost power for extended periods, or whose time zone was set incorrectly at installation.

Investigators must therefore translate between two clocks: the inaccurate DVR clock and a reliable "real-world" clock. Errors in this translation propagate into incident reports, statements of probable cause, witness interviews, and ultimately trial exhibits.

DVR Time Traveler eliminates manual arithmetic by computing the translation, formalizing the inputs, and producing a self-describing artifact (the PDF report) that documents both the result and the conditions under which it was produced.

3. The mathematics

The application supports three core calculations, all performed in Coordinated Universal Time (UTC) internally:

3.1 Time difference

Given an actual real-world time T_real and the time displayed by the DVR T_dvr at the same physical instant:

delta = T_real − T_dvr

Where delta may be positive (DVR is behind) or negative (DVR is ahead). The absolute value is decomposed into days, hours, minutes, and seconds for display.

3.2 Target DVR time for an event

Given the calculated delta and the real-world time of an event of interest T_event:

T_dvr_target = T_event − delta

This produces the time the investigator should seek on the DVR in order to view the event.

3.3 Retention horizon

Given a current real-world date T_now and the configured retention period R (in days):

T_retention_end = T_now + R days

and conversely the earliest still-recoverable date is T_now − R days.

3.4 Edge cases handled

• Daylight saving transitions. Calculations are performed on UTC, so spring-forward and fall-back are inherently respected. Display formatting uses the device's locale to render the correct local time.
• Leap years. Day-in-month bounds are validated per month per year (e.g., February 29 only allowed in leap years).
• Cross-day deltas. Differences spanning midnight are handled correctly by operating on absolute timestamps, not on time-of-day strings.
• Cross-year deltas. Same.
• Time-zone differences. The device captures its own time zone offset and includes it in both the computation and the report.

4. Document Authentication Code

Every PDF report contains a Document Authentication Code, a 64-character hexadecimal value derived from a SHA-256 keyed hash over the canonical representation of every numeric field displayed on the report, plus the officer's badge identifier, the device identifier, the report date, and the application version.

4.1 Inputs

The following fields are concatenated, in alphabetical order of key, as a deterministic JSON string and combined with a fixed application secret:

• Device identifier (UUID derived from hardware identifiers)
• Application version
• Officer badge identifier (numeric portion only)
• Report generation date
• Correlation timestamp (the moment delta was captured)
• DVR date and time at correlation
• Event date and time
• Final (target) date and time on the DVR
• Computed time difference (decomposed)
• Retention end date
• Retention period (days)

4.2 Algorithm

code = SHA-256( JSON(fields, sorted_keys) ‖ application_secret )

The first 12 hexadecimal characters of code form the human-readable Document ID, prefixed DVR-TT-. The full 64-character value is displayed in the PDF for byte-level verification.

4.3 Properties and intended assurance

• Tamper-evidence. Modification of any included field will, with overwhelming probability, change the code. A verifier with the same application secret can re-compute the code from the displayed fields and detect any alteration.
• Determinism. Identical inputs always produce identical codes. This makes the code a stable reference across re-prints.
• Honest non-property. The code is a keyed hash, not a public-key digital signature. The application secret is embedded in the application binary. A sufficiently motivated party with a copy of the application can in principle compute valid codes for arbitrary inputs. The code therefore provides tamper-evidence, not non-repudiation.
• Mitigation. Non-repudiation is provided by the independent RFC 3161 Trusted Timestamp described in §5, which does not rely on any application-embedded secret.

4.4 Independent verification service

SDTech offers a professional Document Authentication Verification Service for agencies and legal professionals who require independent, third-party confirmation that a DVR Time Traveler report has not been altered. Upon request, SDTech will re-derive the Document Authentication Code from the fields visible on the report and confirm whether the code matches — providing an independent attestation suitable for court proceedings.

To request verification or learn more about this service, contact [email protected].

5. RFC 3161 Trusted Timestamps

Beginning with version 10.2.5, every PDF report optionally includes a Trusted Timestamp conforming to RFC 3161 (Internet X.509 Public Key Infrastructure Time-Stamp Protocol).

5.1 Privacy-preserving design

The application computes a SHA-256 hash of the canonical content described in §4 and transmits only that hash to the SDTech license server. The server forwards an RFC 3161 TimeStampReq containing the hash to a configured Time-Stamping Authority (TSA). The TSA does not see the original content. The original content never leaves the device.

5.2 Trust chain

1. The TSA issues a TimeStampToken, which is a CMS SignedData structure containing a TSTInfo field that asserts the hash, the policy under which the timestamp was issued, and a trusted time. The token is signed with the TSA's private key.
2. The TSA's signing certificate chains to a publicly trusted root Certificate Authority.
3. The license server stores the token, the original hash, the TSA name, the issued time, and the requesting context in a tamper-evident Cloudflare D1 record. Each record is given a stable, URL-safe Token ID.
4. The PDF embeds the Token ID, the issued time, the TSA name, the content hash, and a public verification URL.
5. Anyone may later fetch the verification URL to retrieve the metadata and (with ?include_raw=1) the original DER-encoded TimeStampToken for cryptographic verification using standard tools (OpenSSL ts -verify, RFC 3161-compliant libraries, etc.).

5.3 Configured Time-Stamping Authorities

5.4 What a Trusted Timestamp proves

• That the document hash existed at or before the asserted issued time.
• That the asserted time was attested by a third party operating outside SDTech's control.
• That the document content has not been altered since the timestamp was issued (because any change to the content would change the hash).

5.5 What a Trusted Timestamp does not prove

• It does not authenticate the identity of the human who produced the report.
• It does not assert that the underlying inputs (the DVR time, the real-world event time) were truthful or accurate. Those determinations remain a question for the trier of fact.
• It does not assert that the device clock displayed in the report was correct. That assurance is provided independently by §6.

6. Time Source Attestation

Whenever a report is generated, the application performs an independent Time Source Attestation: it queries multiple uncorrelated Internet time sources and computes the consensus offset between the device clock and those sources. The result is included verbatim in the PDF.

6.1 Sources queried

The current source list (subject to evolution) is:

• Cloudflare (HTTP Date header on cdn-cgi/trace)
• Google (HTTP Date header on generate_204)
• Apple (HTTP Date header on the test endpoint)
• WorldTimeAPI (JSON utc_datetime)
• TimeAPI.io (JSON dateTime in UTC)

Sources are operated by independent organizations across multiple jurisdictions. A single compromised source cannot mislead the consensus.

6.2 Method

For each source, the application records:

• The local time immediately before the request (t_start);
• The local time immediately after the response (t_end);
• The time reported by the source (t_reported).

It then applies the standard SNTP half-RTT correction:

t_corrected = t_reported − (t_end − t_start) / 2
midpoint    = (t_start + t_end) / 2
drift       = t_corrected − midpoint

The consensus offset is the median of all successful samples; the spread is the sample standard deviation.

6.3 What is reported in the PDF

• The drift between the device clock and the consensus, in milliseconds.
• The number of successful samples and the spread (1σ).
• A per-source table showing each source's reported time and individual drift.
• An overall status: OK (≥ 2 sources), DEGRADED (1 source), UNAVAILABLE (0 sources).

6.4 Resolution and fitness for purpose

HTTP-served time has typical resolution of 50–250 milliseconds. This is adequate for the intended use case: confirming that the device clock used to compute the report's user-facing timestamps was, at the moment of generation, accurate to seconds, not microseconds. Higher-precision NTP-over-UDP is reserved for future native module work and is not required for this purpose.

7. Verification procedure

Any party may independently verify a DVR Time Traveler PDF using only standard, publicly available tools.

7.1 Verify the Document Authentication Code

1. Read all numeric fields from the PDF as displayed.
2. Re-compute the SHA-256 keyed hash per §4. (For independent verification, contact SDTech for the verification harness.)
3. Compare to the value printed on the PDF. Any mismatch indicates alteration.

7.2 Verify the Trusted Timestamp metadata

curl https://license.sdtech.app/api/v1/timestamp/verify/<TOKEN_ID>

The response includes the original hash, the TSA, the issued time, and the request context. Compare the hash to the one printed on the PDF.

7.3 Cryptographically verify the Trusted Timestamp token

# 1. Fetch the raw RFC 3161 token (base64)
curl 'https://license.sdtech.app/api/v1/timestamp/verify/<TOKEN_ID>?include_raw=1' \
  | jq -r .tokenB64 | base64 -d > token.tsr

# 2. Verify against the document hash (TSA root cert from FreeTSA / DigiCert as applicable)
openssl ts -verify -in token.tsr -digest <HASH_HEX> \
  -CAfile tsa-ca.pem

An OK result confirms that the asserted hash existed at or before the timestamp issued time and that the token was issued by the named TSA.

7.4 Verify the Time Source Attestation

The attestation is reproducible in principle but not in fact (the queried sources do not retain historical responses). The attestation block in the PDF is therefore evaluated as contemporaneous evidence of clock accuracy at the time of report generation, not as a re-runnable test.

8. Limitations and honest caveats

• Investigative aid, not original evidence. The PDF is a derived artifact. The original evidence remains the surveillance recording itself.
• Garbage in, garbage out. The mathematics is exact; the inputs are not. If the officer enters the wrong DVR time at correlation, the result will be precisely wrong.
• Document Authentication Code is a keyed hash. It provides tamper-evidence but not non-repudiation. Non-repudiation comes from the RFC 3161 timestamp.
• RFC 3161 timestamps depend on the TSA. If the issuing TSA's signing key is later revoked or its operations called into question, the assurance value of timestamps issued during the affected period must be re-evaluated. SDTech monitors TSA status and may issue advisories.
• Time Source Attestation is one-shot. The attestation reflects the moment of report generation, not continuous clock health.
• Network dependence. If the device is offline at the time of generation, the Trusted Timestamp will be omitted (the PDF clearly states this) and the Time Source Attestation will fall back to the device clock alone (status: UNAVAILABLE).
• Application secret in binary. The keyed-hash secret is recoverable from the application binary. This is documented; the design relies on RFC 3161 for trust beyond tamper-evidence.

9. Anticipated cross-examination Q&A

Q. "Could the officer have manipulated this report?"

An officer who modifies the displayed fields without re-generating the report will invalidate the Document Authentication Code; the modification will be detectable by re-computation. An officer who re-generates the report after modification will produce a new RFC 3161 timestamp with a later issued time, which will be evident on the face of the document.

Q. "How do we know the device clock was right when this was generated?"

The Time Source Attestation block in the PDF records the drift between the device clock and the median of multiple independent Internet time sources at the moment of generation. A drift value within seconds of zero is contemporaneous evidence of an accurate clock.

Q. "How do we know SDTech didn't fabricate this timestamp?"

The Trusted Timestamp is signed by an external Time-Stamping Authority — FreeTSA, DigiCert, or Sectigo, depending on configuration — using a key SDTech does not possess. SDTech cannot forge a valid token. The token is independently verifiable using OpenSSL or any RFC 3161 library.

Q. "What if the TSA was compromised?"

A compromise of a public TSA would be a major incident affecting the entire industry. SDTech monitors public TSA security advisories and would issue a corresponding advisory affecting reports generated during any affected window. Reports may be re-anchored against an alternative TSA on request.

Q. "Is this app certified for court use?"

The application is a tool. Admissibility is determined by the court, with reference to the foundation laid by the proffering party. This whitepaper, the source-available verification procedure, and the use of standard cryptographic primitives are intended to support such foundation.

Q. "Could the officer have fabricated the entire scenario?"

The application does not, and cannot, defend against an officer who knowingly enters false inputs. That scenario is identical to a hand-written calculation containing knowingly false figures. The application's role is to ensure that, given the inputs as recorded, the arithmetic is correct, the result is preserved unaltered, and the generation event is independently anchored in time.

10. Standards and references

• RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)
• RFC 5816 — ESSCertIDv2 update for RFC 3161
• FIPS 180-4 — Secure Hash Standard (SHA-256)
• FIPS 197 — Advanced Encryption Standard (AES)
• NIST SP 800-171 r2 — Protecting Controlled Unclassified Information
• NIST SP 800-88 r1 — Guidelines for Media Sanitization
• FBI CJIS Security Policy v6.0 (mapped in the SDTech compliance package, available on request)
• RFC 8446 — TLS 1.3