H2-1. Featured Answer + Boundary

What “secure” means on a real video device

• Authenticity: only signed boot stages and signed firmware components are allowed to execute (chain-of-trust gates).
• Anti-rollback: the device rejects older images even if they are validly signed, using a version gate and a monotonic counter or equivalent.
• Confidentiality: streams are encrypted with per-session keys; nonce/IV uniqueness is enforced across reboots and reconnections.
• Integrity: each frame/segment carries an authentication tag; failures are counted and logged as actionable evidence.
• Replay defense: sequence numbers and a replay window drop duplicates/out-of-order beyond policy, with explicit counters.

H2-2. Threat Model for Video Devices (Practical, Not Academic)

Goal: translate real attack paths into control points and evidence that later chapters can verify with event codes and counters.

Five practical threat groups (each maps to controls + evidence)

Evidence-first event code discipline (so field debug is deterministic)

• Event naming is functional, not narrative: codes identify a gate outcome or policy violation (e.g., signature fail, rollback blocked, replay dropped).
• Every control point emits two signals: a one-shot event plus a monotonic counter (e.g., tag-fail count, replay-drop count).
• Events must pin the “first failing gate”: boot verify → manifest → key vault → stream decrypt → tag verify → replay window.

H2-3. Root of Trust & Boot Chain (ROM → BL → OS/App)

Purpose: make the chain-of-trust auditable. Each boot stage must pass a verify gate before the next stage runs, and every failure must emit stage ID + result code + policy context.

Chain-of-trust in practice (what “must be true” at each hop)

• Stage0 (Boot ROM, immutable anchor): holds the root verification material (public key hash / key index / fused digest) and validates the next-stage loader before execution.
• Stage1 (Bootloader, policy enforcer): parses the manifest, verifies signatures and component hashes, checks target HW ID and min-version / rollback policy, selects the active slot (A/B), then hands off only verified components.
• Stage2 (OS/App, trusted runtime): runs only after Stage1 gates pass; runtime should continue to emit security telemetry (verify status, key vault readiness, and stream protection counters).

Evidence contract (minimum fields that make field-debug deterministic)

Gate checklist (what is validated, and what must be logged)

• Gate0 (ROM→BL): validate BL signature or digest; log boot_stage_id and verify_result_code.
• Gate1 (BL→OS/App): validate manifest signature, component hash list, HW ID match, and anti-rollback; log counter + min version + slot selection.
• Failure behavior: prefer “block + fallback to LKG slot” over “continue with partial trust”; log the first failing gate and chosen fallback path.

H2-4. Firmware Signing & Manifest Design (What Must Be Signed)

Purpose: prevent “signed but still compromised.” Signing must cover what runs, how it is assembled, and the policy gates that block downgrade and mismatched hardware.

What must be signed (minimum coverage)

• Manifest / descriptor: schema version, device family, target HW ID, image version, min allowed version, and the full component list.
• Component hash list: hashes for every executable or security-relevant blob (boot stages, kernel/rootfs/app, security policy blob, critical config).
• Policy binding: a policy hash (or policy component hash) so “rules” cannot be swapped while the main firmware stays signed.
• Key identity metadata: signing key ID / algorithm ID so verification knows which trust anchor to apply.

Manifest field checklist (keep it self-describing & auditable)

Evidence contract (fields to log when verification fails)

• manifest_version, image_version, target_hw_id
• failed_component_name + expected_hash vs measured_hash (or a hash ID reference)
• policy_hash (expected vs measured) and min_allowed_version
• verify_result_code (SIG_FAIL / HASH_MISMATCH / HWID_FAIL / POLICY_FAIL)

H2-5. Anti-Rollback & Secure Update (A/B, Counters, Commit Policy)

Goal: updates must behave like a transaction—either commit successfully or return to last-known-good—while blocking downgrade even when signatures are valid.

Two non-negotiable guarantees

• Fail-safe upgrade: an interrupted or unstable update cannot brick the device; it must fall back to a known-good slot.
• Anti-rollback: older images are rejected by policy (min-version + monotonic counter), even if correctly signed.

Update transaction (download → verify → switch → trial → commit)

Evidence contract (minimum fields)

• active_slot, pending_slot, update_state_code, last_failure_step
• monotonic_counter_value + min_allowed_version + image_version
• verify_result_code (SIG_FAIL / HASH_MISMATCH / HWID_FAIL / POLICY_FAIL)

H2-6. TRNG → DRBG → Key Derivation (Where Keys Come From)

Goal: treat randomness and key generation as an auditable supply chain. The device must prove entropy health, maintain DRBG reseed discipline, and derive per-device keys with explicit contexts.

TRNG vs PRNG vs DRBG (engineering meaning)

• TRNG: a physical entropy source. It is where “unpredictability” enters the system.
• PRNG: an algorithmic generator. Useful for simulation or non-security uses, but not a trust anchor.
• DRBG: a deterministic generator seeded from entropy with defined reseed rules and observable counters—what production systems typically use for consistent security-grade output.

Per-device key derivation (KDF with device binding)

• Device binding: derive keys using a stable device UID (concept) so two devices cannot generate the same keys from identical firmware.
• Context separation: each purpose uses a distinct kdf_context_id (boot verify, stream session, storage sealing) to prevent cross-use of keys.
• Epoch/rotation: session keys should be derived with an epoch (or session ID) so rotation is explicit and auditable.

Evidence contract (minimum fields)

H2-7. Key Storage & Access Control (Vault Abstraction)

Goal: make key storage auditable and enforceable. Treat SE/TPM/TEE as a key vault that exposes operations (sign/decrypt/derive) via handles—never exporting private keys.

Key vault rules (minimum, enforceable)

• Never-export private keys: apps and firmware receive handles, not raw key material.
• Policy-gated usage: each key has explicit usage flags (encrypt-only / sign-only / attest-only).
• Lifecycle states: factory → provisioned → field → decommission; secure erase must produce auditable events.

Evidence contract (minimum fields)

Access control model (who can request what)

• Boot chain: verification-only operations; no general-purpose decrypt/sign outside boot policy.
• Crypto engine: AEAD encrypt/decrypt and signing strictly by usage flags and context.
• Video pipeline app: receives only key handles/session handles; cannot export long-term keys.

H2-8. Stream Confidentiality (Session Keys, Nonce/IV Discipline)

Goal: protect the video stream’s confidentiality without a protocol deep dive. The real risk is not “choice of cipher,” but session key rotation and nonce/IV uniqueness across frames, reconnects, and reboots.

Encryption approach (concept-first)

• Prefer AEAD: a single pass provides confidentiality and integrity tags (conceptually reducing mismatch between encrypt and authenticate paths).
• Session-based keys: derive a session key for a session ID, then rotate by key epoch.
• Rotation triggers: by time, by frame count, or on reconnect; rotation must be explicit and logged.

Evidence contract (minimum fields)

Session behavior checklist (field-auditable)

• On session start: log session_id and initialize key_epoch=0 with a fresh base nonce counter.
• Per frame: increment nonce_counter monotonically; include it in the protected metadata (concept).
• On rotation: increment key_epoch, reset nonce counter safely for the new epoch, and log EPOCH_ROTATE.
• On reboot: restore nonce counter or force a new epoch; never resume with reused nonces under the same epoch.

H2-9. Stream Integrity (Auth Tags, Watermark, Replay Defense)

Goal: detect and stop insertion, deletion, tampering, and replay so modified content cannot “still play” without leaving evidence. Integrity must be measurable by counters and event codes, not assumptions.

Integrity scope (what must be caught)

• Tamper: frame payload or protected metadata changed.
• Splice: frames from another stream/session inserted.
• Drop/Insert: missing frames or injected frames (sequence gaps/duplicates).
• Replay: valid old frames resent to appear current.

Replay defense (sequence number + window)

• Sequence number: every authenticated unit (frame or segment) carries a strictly increasing seq_number.
• Sliding accept window: allow limited reordering while rejecting duplicates and overly old seq values.
• On reject: drop content and log REPLAY_DROP with the offending seq.

Optional watermark / signing (forensics-lite)

• Watermark: a trace marker (ON/OFF/FAIL) to support later attribution; it does not replace auth tags.
• Forensics signal: record watermark status changes and failures as events, not UI states.

Evidence contract (minimum fields)

H2-10. Secure Time, Timestamps & Ordering Proof (Non-Repudiation Lite)

Goal: integrity needs more than tags—it needs ordering proof. Within page scope, “secure-ish time” means a trustworthy ordering signal built from time source state plus monotonic counters, not a full compliance/WORM system.

Secure-ish time sources (within scope)

• RTC with hold-up: useful when valid; must expose rtc_valid_flag.
• Monotonic counter fallback: preserves ordering even when RTC is invalid or stepped.
• Time state matters: every timestamp must be interpreted through time_source_state.

Ordering proof (what to log)

• Sequence + monotonic time: seq_number proves frame order; monotonic time proves time order.
• Clock step detection: record any backward/large jump events as clock_step_events.
• Source switching: if RTC becomes invalid, log a source switch and continue with monotonic fallback.

Evidence contract (minimum fields)

H2-11. Security Telemetry & Field Debug Playbook (Symptom → Evidence → Fix)

This chapter turns security failures into a field-runnable SOP. Every path starts from two objective signals (counters / event codes), uses a discriminator to separate root causes (key vs time vs nonce vs signature/policy), then applies a minimal first fix (LKG rollback, session rebuild, epoch rotate, reprovision).