Chapter 11 — Clock-offset and record-integrity verification
Lesson map
Lesson 11 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes and connection"]
N1["11.1 Keep four times and a measurement"]
N2["11.2 Reproduce a corrected timeline"]
N3["11.3 Byte integrity is not source truth"]
N4["11.4 A bounded timeline review"]
N5["Subject synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["11.1 Keep four times and a measurement"]
N2["11.2 Reproduce a corrected timeline"]
N3["11.3 Byte integrity is not source truth"]
N4["11.4 A bounded timeline review"]
N5["Subject synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]
[Learning outcomes and connection]
|
v
[11.1 Keep four times and a measurement]
|
v
[11.2 Reproduce a corrected timeline]
|
v
[11.3 Byte integrity is not source truth]
|
v
[11.4 A bounded timeline review]
|
v
[Subject synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes and connection
The learner will normalize three source-reported timestamps to UTC, carry an uncertainty interval instead of a falsely precise order, compare raw and altered record bytes, and explain when a source claim can enter a timeline. Chapter 10 required source-linked evidence before a control. Chapter 11 tests whether that evidence's time and content survived collection and transformation. Chapter 12 will package the records with a manifest and parser report. RFC 3339 supplies the timestamp notation used here; NIST SP 800-86 offers older, high-level forensic source guidance, not this workshop's clock values or a legal custody rule.
11.1 Keep four times and a measurement
For one record, distinguish event time asserted by the producer, ingestion time when a receiving pipeline stored it, collection time when a responder obtained a copy, and analysis time when an analyst ran a query or transformation. A later query cannot retroactively make an earlier event time trustworthy. A receiver can also ingest a late event after the event-time retention window used by a different system. A timeline should preserve all supplied times, their time-zone offsets and the source object. Converting a string to UTC changes its representation, not the producer's clock accuracy.
A clock-offset measurement answers a narrower question: at a measured moment, how far ahead or behind was one producer relative to a trusted reference? The classroom formula is estimated UTC = parsed source time in UTC − measured source offset. A positive offset means the producer clock was ahead; a negative offset means it was behind. Carry measurement time, uncertainty, drift assumptions and the method used to estimate offset. If a host is already offline and no direct measurement exists, do not invent a correction from neighboring events. For two event intervals A and B, a strict A-before-B conclusion requires A's latest plausible time to be earlier than B's earliest plausible time, under validated offsets and coverage. Matching corrected seconds alone do not satisfy that test.
Workshop K11 is an offline timing variant connected to K9–K10's methodological questions. It is not an additional observation in the main LLR case. Three producers report:
| ID | Raw timestamp | Measured source offset | Stated uncertainty | Claim type |
|---|---|---|---|---|
| K11-I | 2026-10-11T13:00:02+01:00 | +3 s | ±1 s | IdP session check. |
| K11-E | 2026-10-11T12:00:03+00:00 | +2 s | ±1 s | Edge access status. |
| K11-H | 2026-10-11T08:00:01-04:00 | −1 s | ±2 s | Host process-status line. |
The offset figures are supplied classroom measurements, not verified device properties. Their measurement times are omitted, so even the stated intervals are exercise assumptions, not production-grade clock confidence. The three text fields are not asserted to share a request or session key. A source-specific ID mapping and completeness check remain necessary.
11.2 Reproduce a corrected timeline
This Python 3 listing parses the explicit offsets, converts each raw value to UTC and subtracts the supplied source offset. It prints a time estimate and the exercise uncertainty. It does not test whether the offset was measured correctly. Run it offline or calculate it by hand. Python's datetime documentation defines the parsing and timezone operations used.
from datetime import datetime, timedelta, timezone
rows = [
("K11-I", "2026-10-11T13:00:02+01:00", 3, 1),
("K11-E", "2026-10-11T12:00:03+00:00", 2, 1),
("K11-H", "2026-10-11T08:00:01-04:00", -1, 2),
]
for name, raw, offset_seconds, uncertainty_seconds in rows:
parsed_utc = datetime.fromisoformat(raw).astimezone(timezone.utc)
estimate = parsed_utc - timedelta(seconds=offset_seconds)
print(name, estimate.strftime("%H:%M:%S"),
"+/-", str(uncertainty_seconds) + "s")
The estimates are K11-I 11:59:59 ±1 s, K11-E 12:00:01 ±1 s, and K11-H 12:00:02 ±2 s. On the stated assumptions, K11-I spans 11:59:58–12:00:00, K11-E spans 12:00:00–12:00:02, and K11-H spans 12:00:00–12:00:04. Their ranges touch or overlap; do not claim a strict causal sequence. Even if one pair had nonoverlapping intervals, time order alone would not establish a common transaction or actor. A separate request/session mapping would still be required.
11.3 Byte integrity is not source truth
Suppose K11-E was supplied as the literal byte line below. Store the exact bytes and any transformed display separately. The program compares its digest with an identical copy and with a variant that changes the status from 503 to 200. This is a local change-detection demonstration; it cannot tell whether 503 was the true gateway result before collection. A digest is meaningful only with a trusted expected value, versioned object identity and provenance.
from hashlib import sha256
raw = b"K11-E,2026-10-11T12:00:03+00:00,status=503\n"
copy = bytes(raw)
variant = raw.replace(b"503", b"200", 1)
print("copy_equal:", sha256(raw).digest() == sha256(copy).digest())
print("variant_equal:", sha256(raw).digest() == sha256(variant).digest())
Expected: copy_equal: True and variant_equal: False. Keep the original and variant objects with separate identifiers. If a derived UTC timeline normalizes time zones, it will have different bytes; that is an expected transformation, not evidence of tampering. A real receipt should also record original source name, authorized collector, method, collection time, copy count, tool version, access and chain of custody appropriate to the organization. A complete integrity story follows a particular object through all transformations; it does not merely paste one hash next to a chart.
11.4 A bounded timeline review
A defensible K11 note would read: “Under supplied, unvalidated offset estimates, three records occupy overlapping UTC intervals near noon. Their raw values have different time-zone offsets. The workshop copy of K11-E matches its local raw bytes; a deliberately altered status copy does not. Event order, source authenticity, same-request mapping and production action status remain unverified.” It then asks the source custodians for clock measurements with measurement times, source object IDs and a bounded producer mapping. If an owner reports that its clock drifted rapidly, widen or withdraw the interval rather than force a preferred order.
An analyst may create a version 2 timeline when better measurements arrive. Version 2 should retain the earlier estimate, state what changed and rerun the overlap test. An irreversible containment decision should not depend on a one-second precedence claim whose uncertainty crosses both events. The next chapter turns the raw/derived distinction into a complete intake manifest.
Common errors and limits
- Using a timestamp parser as evidence that a source clock was correct.
- Sorting corrected point estimates while ignoring overlapping uncertainty intervals.
- Joining rows because their times are close or their principal labels match.
- Calling a changed digest “attacker tampering” when the analyst made the variant.
- Hashing only a normalized display while claiming to verify raw source bytes.
Exercises — subject 11
EX041 — Four-time worksheet. Objective: retain chronology provenance. For K11-I/E/H, list raw event time, parsed UTC, corrected estimate, uncertainty and missing ingestion/collection/analysis times. Explain which fields require custodian confirmation. Evidence: three-row Markdown table. Rubric: 2 = all four time roles and missing measurement context; 1 = correct conversions only; 0 = asserts verified source clocks.
EX042 — Interval proof. Objective: assess a proposed event order. Run §11.2, give the three exact output lines and interval endpoints, then test the assertion “IdP necessarily preceded edge and host.” State one extra fact required to connect the records causally. Evidence: calculation and rebuttal. Rubric: 2 = correct intervals and no strict order at touching boundaries; 1 = point times only; 0 = claims cause from sorting.
EX043 — Integrity variant. Objective: reproduce §11.3. Record both output lines and two object receipts for raw and variant, with the transformation and digest role. State why matching the local copy would not authenticate the producer. Evidence: versioned receipt pair. Rubric: 2 = exact booleans and source limitation; 1 = booleans without provenance; 0 = treats the status edit as observed hostile behavior.
EX044 — Corrected handoff. Objective: communicate uncertainty. Write a 130–180-word version 1 note for a service owner with the bounded timeline, overlapping ranges, missing join, missing authority and next permitted request. Add a version 2 sentence for a hypothetical new offset measurement without rewriting the raw log. Evidence: two-version note. Rubric: 2 = clear uncertainty, owner and version relation; 1 = vague uncertainty; 0 = declares an actor or production intervention.
Subject synthesis
Time conversion and byte comparison are repeatable operations, but they answer only precisely stated questions. K11 does not certify three producer clocks or create a transaction join. Chapter 12 will preserve the raw objects, their validation results and the corrected view in a single inspectable package.
Continue studying — chapter 11 of 18
← Chapter 10 · Course chapter index · Chapter 12 →
Continue to the next authored lesson.