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 app 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. Tamper-Evidence Checksum

Every PDF report contains a Tamper-Evidence Checksum, a 64-character hexadecimal value derived from an HMAC-SHA256 keyed message authentication code (RFC 2104) computed over the canonical representation of every numeric field displayed on the report, plus the officer's badge identifier, the device identifier, the report date, the application version, and the administrative case fields (case number, DVR address, DVR identification, officer name, department and unit).

4.1 Inputs

The following fields are serialized, in alphabetical order of key, as a deterministic JSON string. That string is the HMAC message; a fixed application secret is the HMAC key:

• 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)
• Case number (normalized text)
• DVR address / location (normalized text)
• DVR identification (normalized text)
• Officer name (normalized text)
• Department / agency (normalized text)
• Unit / division (normalized text)

Numeric and date/time fields are reduced to their digits (normalized to the ISO 8601 ordering) before hashing, so the code is independent of the device's display language and regional format. The administrative case fields are normalized as text — surrounding whitespace is collapsed and the value is upper-cased — so incidental spacing or capitalization differences do not affect the code while any substantive change does.

4.2 Algorithm

code = HMAC-SHA256( key = application_secret, message = JSON(fields, sorted_keys) )

HMAC-SHA256 is the standard keyed message authentication code defined in RFC 2104 and FIPS 198-1. 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 message authentication code (HMAC), 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 Report 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 Tamper-Evidence Checksum 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, use our secure certificate request page.

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 app clock displayed in the report was correct. That assurance is provided independently by §6.

6. Time Source Attestation

The application uses network-time-corrected time — derived from multiple Internet time sources at startup and refreshed periodically — for all report timestamps and calculations. At report generation, the application additionally performs an independent Time Source Attestation: it queries multiple uncorrelated Internet time sources (via NTP-style HTTP requests), computes a consensus, and records the drift between the app clock (network-time-corrected) and that consensus. This provides contemporaneous, third-party-verifiable evidence of app clock accuracy at the moment of report generation.

If the device is offline at the time of generation, no external time sources can be queried and the attestation is marked UNAVAILABLE — the application falls back to the device clock for calculations and prominently displays a cloud-off icon on the report. In this scenario, the officer is expected to have confirmed the device clock accuracy against an independent external time reference (e.g., radio-controlled watch, second device, dispatch timestamp) before proceeding with generation. The report's offline page explicitly states that the device clock was verified by the officer against an external reference, providing a documented chain of responsibility for clock accuracy even without automated attestation. The attestation 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)
• Microsoft (HTTP Date header on Bing)
• Amazon (HTTP Date header on AWS CloudFront)

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 app 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

The HTTP Date header has whole-second resolution under RFC 7231. A single sample therefore carries on the order of ±1–2 seconds of measurement error (one-second quantization plus network round-trip asymmetry); taking the median across several independent operators removes per-source jitter, while the absolute floor remains roughly ±1 second. This is adequate for the intended use case: confirming that the app 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 Tamper-Evidence Checksum

1. Read all numeric fields from the PDF as displayed.
2. Re-compute the HMAC-SHA256 code 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://verify.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://verify.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.

7.5 Verification portal and retroactive timestamping

SDTech provides a public verification portal at verify.sdtech.app. Any party can paste a token ID (ts_...) or a full verification URL to look up a timestamp record.

For reports generated offline (no trusted timestamp was obtained at generation time), a retroactive timestamping tool is available at verify.sdtech.app/api/v1/timestamp/retroactive. The tool accepts the document’s SHA-256 hash (printed on the offline attestation page) and submits it to the same independent third-party TSA used for online reports. The resulting RFC 3161 token cryptographically binds the document hash to the moment of submission, producing a printable verification certificate identical to the one provided automatically when the device is online. A pre-filled link to this tool is embedded directly in every offline report’s forensic attestation page.

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.
• Tamper-Evidence Checksum is a keyed MAC. HMAC-SHA256 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 be marked UNAVAILABLE. In this case the officer confirms device clock accuracy against an external time reference before proceeding; the report documents this officer-verified state via the cloud-off icon and a dedicated offline attestation page. A retroactive trusted timestamp can be obtained after the fact using the tool at verify.sdtech.app (see §7.5).
• Application secret in binary. The HMAC key 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 Tamper-Evidence Checksum; 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 app clock was right when this was generated?"

The Time Source Attestation block in the PDF records the drift between the app's network-time-corrected 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. Because the app anchors its time to network sources at startup and tracks it via the monotonic clock, the attestation remains accurate even if the device's system clock is changed mid-session.

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?"

No software is "certified" for court use in any general sense; admissibility is decided case by case by the court of competent jurisdiction. What the application provides is a sound technical foundation for that determination: every report carries a Tamper-Evidence Checksum (§4), an independent RFC 3161 trusted timestamp from an outside authority (§5), and a contemporaneous record of clock accuracy (§6) — all verifiable by any third party using standard, publicly available tools. Courts across jurisdictions routinely accept timestamped, tamper-evident digital evidence when it is properly introduced and supported by testimony. This whitepaper and the open verification procedure are intended to support that introduction.

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)
• RFC 2104 — HMAC: Keyed-Hashing for Message Authentication
• FIPS 198-1 — The Keyed-Hash Message Authentication Code (HMAC)
• 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