1) Assets (what must remain authentic / secret)

• Boot & firmware: bootloader stages, recovery image, verified manifests, security policy configuration.
• Identity & keys: device identity key/certificate, key-derivation materials, anti-rollback counters.
• Content authenticity: frame/chunk signatures, watermark keys, sequence counters/nonce rules.
• Evidence & traceability: audit logs, tamper events, update history, boot measurements (hash digests).

Engineering note: the most common failure is not “no crypto,” but assets stored or used outside the intended trust boundary (e.g., unsigned configs, read-out-able keys, erase-able logs).

2) Attack surfaces (where compromise usually starts)

• Boot chain: replace/patch early-stage components, modify boot configuration, fault-inject verification checks.
• Update path: deliver modified packages, replay old packages, downgrade to vulnerable versions.
• Debug access: JTAG/SWD/UART pads, insecure RMA unlock flow, over-privileged diagnostic modes.
• External media / interfaces: unsigned parameters/resources, replaceable storage, injection via attachable peripherals.
• Video stream path: replay/insert/drop frames, replace metadata, spoof “trusted” origin without proof.
• Physical access: chip-off attacks, probing buses, component swap, glitching power/clock/reset.

3) Attacker capability levels (use to set priorities)

• L1 Remote: network reachability; no physical contact.
• L2 Close access: can touch ports and enclosure; can trigger resets/power cycles.
• L3 Teardown: can open device and access PCB, flash, test pads.
• L4 Lab: can do voltage/clock glitching, fault injection, side-channel attempts.

Priorities must match the assumed attacker ceiling: many industrial vision deployments must treat L2/L3 as baseline.

4) Business-visible impacts (why it matters)

• Fake evidence: replayed or manipulated video frames that still look “valid” downstream.
• Persistent compromise: modified boot chain or update agent enabling hidden backdoors.
• Device cloning: copied identity keys enabling counterfeit devices and license bypass.
• Downgrade exploitation: forced rollback to a known-vulnerable firmware release.
• Lost traceability: erased or modified logs preventing root-cause analysis and accountability.

1) Root of Trust forms (role boundaries, not platform tutorials)

• SoC Boot ROM RoT: immutable verification logic at the first instruction; strongest “start point” for trust.
• External Secure Element / TPM: isolates private keys and can attest device identity; relies on secure integration and policy.
• FPGA/MCU bridge RoT: can gate boot or enforce policy, but must itself be verified or anchored to a RoT.

The RoT objective is not “more crypto,” but keys cannot be read out, verification cannot be bypassed, and the trust boundary starts before attacker-controlled code executes.

2) Chain of Trust (what must be covered)

• Stages: ROM → BL1 → BL2/UEFI → kernel → core user-space/app.
• Critical configs: boot arguments, device tree, manifest lists, recovery/maintenance policy.
• Coverage rule: a signed manifest must enumerate hashes of all security-relevant components, not only the “main image shell”.

The most common break is unsigned configuration or missing components from the signed manifest, which enables subtle but powerful substitutions.

3) Measured boot vs Verified boot (what each solves)

• Verified boot: prevents untrusted code from running (block execution).
• Measured boot: produces auditable evidence of what ran (prove device state via hashes).

For vision systems that require data authenticity, measured boot helps support device-side proof that the signing/watermarking pipeline is running in an approved state (without describing any cloud architecture here).

4) Fail-closed policy (deterministic state machine)

• Strict stop: verification failure → halt (max security, low availability).
• Recovery-only: verification failure → enter signed-recovery mode (common for field devices).
• Limited mode: verification failure → restricted operation with full audit logging (use with caution).

A correct policy is predictable: the same failure produces the same state and the same evidence trail.

1) Signature mechanisms (engineering tradeoffs)

• RSA: mature tooling; typically larger signatures/certs; verification cost and storage footprint can dominate small boot partitions.
• ECDSA: smaller signatures than RSA; verification time depends on implementation and acceleration; careful constant-time coding required.
• EdDSA: simpler usage patterns and often cleaner implementations; adoption depends on platform/tooling and audit readiness.

Selection should be driven by (a) verification frequency in the chain, (b) signature + cert size, (c) implementation auditability, and (d) update tooling maturity.

2) Certificate chain & key roles (separation of duties)

• Root key (offline): only signs intermediate certificates; never used for daily image signing.
• Intermediate (rotatable): partitions product lines / factories / batches; enables controlled rotation and revocation.
• Image signing key (high-use): signs boot components and manifests; must be replaceable without bricking deployed devices.
• Recovery signing key (optional): signs recovery-only images; prevents the “recovery path” from becoming a backdoor.

A practical rotation plan defines: how new intermediates are accepted, how old keys are denied, and how attempts are recorded in audit logs.

3) Policy: mutable vs fixed components (scope lock)

• Must be fixed or extremely constrained: trust anchor, early-stage verification policy, and the recovery entry policy.
• May be updated (signed + anti-rollback): later boot stages, OS/kernel, security services, update agent, stream-signing engine.
• Config coverage rule: any boot-critical configuration (boot args / DTB / policy flags) must be bound by the signed manifest.

The common bypass is not a broken signature algorithm—it is unsigned configuration or components missing from the manifest.

4) Boot-time budget (how to estimate without hard numbers)

• Count verifications: number of stages × number of signed objects per stage.
• Measure per-object cost: signature verify + hash compute + manifest parse.
• Total estimate: sum stage-by-stage, then add margin for worst-case storage latency and cold-cache behavior.

Optimization lever: sign a single manifest per stage (hash list + version + policy flags) and verify component hashes, instead of verifying many scattered files repeatedly.

1) Key classes (domain + lifetime)

• Device identity key: long-term; used for attestation and device uniqueness; must be non-exportable.
• Firmware verification keys: trust anchors and certificate chain used to validate boot and updates (public keys + policy).
• Stream-signing / watermark keys: protects frame authenticity; should be isolated from general application code.
• Session keys: short-lived; derived per session/boot; must be erasable and renewable.

Rule of thumb: long-term private keys must be non-readable; short-term keys must be rotatable and erasable.

2) Storage options (where keys live)

• OTP / eFuse: strong anchor storage; good for root public key hash, policy fuses, monotonic counters.
• Secure Element / TPM: hardware boundary for private keys; supports sign/derive without exporting keys.
• PUF-derived keys: keys derived from silicon uniqueness; requires stability strategy and error handling design.
• Encrypted flash: protects at-rest data; must be anchored to a non-exportable root key or it becomes “copyable encryption”.

Common misconfiguration: encrypted flash with the encryption key stored in the same flash. A secure design anchors secrets to a RoT/SE boundary.

3) TRNG vs DRBG (entropy pipeline)

• TRNG: produces raw entropy from a hardware source; must run health tests at startup and continuously.
• DRBG: expands a seed into high-volume cryptographic randomness; must handle reseed policy and reboot state.
• Operational requirement: record TRNG health status and ensure DRBG does not repeat outputs after resets.

“Looks random” is not sufficient. A field-debuggable system needs health-test evidence and a defined reseed strategy.

4) Provisioning (manufacturing vs on-site)

• Factory provisioning: scalable; requires strong manufacturing chain controls and auditable injection records.
• On-site provisioning: reduces supply-chain exposure; increases deployment complexity and process requirements.
• First-boot binding: can generate/lock identity on first boot; depends on a reliable entropy pipeline and immutable policy.

The design should specify what the device can output as proof: certificate chain and a challenge-response signature, verifiable offline.

1) Update threats (what must be engineered out)

• Package substitution: MITM swaps payload or metadata.
• Tamper: payload or manifest altered after signing, or signature coverage is incomplete.
• Replay: a previously valid update package is resent.
• Downgrade: a validly signed but older vulnerable version is installed.
• Power-loss brick: interruption during write/switch/commit leaves both slots non-bootable.

The most common bypass is not cryptography failure—it is unsigned metadata (version/slot/policy) or missing components in the signed manifest.

2) Signed update package + manifest coverage

• Payload: firmware image(s) for the inactive slot.
• Manifest: hash list, rollback_index, human-readable version, device/model constraints, slot policy, and key identifier.
• Signature: signs the manifest (and therefore all payload hashes and policy fields).

Required proof: manifest lists every boot-relevant component hash and policy flag. Signing only a “container file” is insufficient.

3) Anti-rollback logic (monotonic anchor)

• Comparison rule: allow install only if incoming.rollback_index >= stored.rollback_index.
• Anchor options (conceptual): OTP/eFuse, secure element/TPM counter, or secure version store anchored to a RoT boundary.
• Commit rule: update stored.rollback_index only after successful switch + health checks (commit stage).

Separating rollback_index (security monotonic) from “marketing version” avoids ambiguous ordering and prevents downgrade gaps.

4) A/B slots + atomic switch + controlled rollback

• Write to inactive slot: download → verify → install always targets the non-active slot.
• Trial boot: switch selects candidate slot with a bounded retry counter.
• Commit gate: only after health checks pass, mark new slot committed and advance anti-rollback index.
• Rollback condition: repeated boot failures or failed health checks triggers automatic reversion to last known-good slot.

Power-loss safety is a state-machine property: no stage should overwrite the last known-good slot before the new slot is verifiably bootable.

1) Route A — frame/chunk signing + hash chaining

• Granularity options: sign every frame (strongest, highest overhead) or sign every N frames/chunk (practical).
• Hash chain: link frames by hashing current frame metadata + content hash + previous chain hash.
• Detects: frame insertion/deletion/modification via chain break or signature mismatch.

Freshness is mandatory: without seq/nonce/timestamp, an attacker can replay old but intact signed frames.

2) Route B — watermarking (provenance and tamper evidence)

• Robust watermark: survives common transformations; supports provenance and post-hoc tracing.
• Fragile watermark: breaks under edits; provides a tamper-evidence signal.
• Engineering role: watermark complements signing (deterministic integrity) rather than replacing it.

Output must be machine-readable: wm_detected, wm_score, and a failure reason for audit and field diagnosis.

3) Anti-replay (freshness rules)

• Sequence counter (seq): monotonic increasing; verifier flags reuse, rollback, or abnormal jumps.
• Nonce binding: session challenge binds frames to a specific session to prevent offline recording + later injection.
• Timestamp: supports time-window checks; should be treated as an input to freshness logic, not a stand-alone trust source.

A practical verifier emits separate flags for sequence anomalies and chain breaks to distinguish packet loss from tampering.

4) Key boundary (identity vs session keys)

• Device identity / attestation key (long-term): proves device identity; should not sign every frame.
• Session key (short-term): used for frame/chunk signing or MAC; derived per boot/session and rotated.
• Traceability fields: verifier records key_id / cert_id for forensic linkage.

Keeping long-term keys isolated and using session keys for high-volume operations reduces blast radius and improves rotation agility.

1) Debug port policy as explicit states

Treat debug as a state machine with a strict allowlist. Avoid “blacklist” thinking.

• LOCKED (default): JTAG/SWD disabled or restricted to minimal identification only; no memory read/write.
• LIMITED_DIAG: read-only diagnostics (health counters, temperatures, boot/update reason codes, compact log summaries).
• SERVICE_SESSION: time-bounded session with a command allowlist; still forbids exporting secrets or dumping sensitive regions.
• DENIED: triggered after repeated failures or risk signals; blocks access and increments an immutable failure counter.

This state model keeps the “what is allowed” surface mechanically checkable and prevents accidental escalation in service tooling.

2) Controlled unlock (challenge-response + short TTL)

Unlock should be bound to device, time window, and privilege level.

• Preconditions: device must enter a service posture (e.g., physical action, service pin, or explicit service mode).
• Challenge: device outputs a nonce + device identity + monotonic counter + policy version.
• Response: service tool returns a signed authorization token that encodes level and TTL.
• Enforcement: device verifies token, opens only the approved allowlist, and auto-relocks at TTL expiration.

Freshness is mandatory: include a nonce or monotonic counter to prevent replay of a previously valid unlock token.

3) RMA / service legitimacy (device-side evidence)

• Legitimate service proof: authorization token must be verifiable by the device (trusted service signer identity).
• Context binding: token binds to device ID and may require a physical service posture to reduce remote abuse.
• Minimal exposure: allow diagnostics needed for triage, not a full debug environment.

The design goal is “repair without backdoor”: a service session can observe health and run bounded tests while secrets remain non-exportable.

4) Irreversible vs reversible locks (engineering tradeoff)

• Irreversible (eFuse-style): strongest for disabling high-risk capabilities; cannot be undone if mistakenly fused.
• Reversible (policy-controlled): supports maintainability; must be paired with TTL, allowlist, and immutable audit.
• Hybrid approach: permanently disable secret export paths while keeping a constrained diagnostic gate reversible.

A practical rule: irreversible locking is suited for “never acceptable” capabilities (secret read-out), while reversible sessions cover bounded diagnostics.

1) Typical physical attacks (as observable categories)

• Enclosure intrusion: case open, probing access, connector manipulation.
• Component replacement: external storage swapped or replayed from an older image.
• Fault injection indicators: abnormal voltage/clock/reset patterns intended to bypass checks.

The objective is not to describe attack tooling, but to define which observable signals can be used to trigger policy decisions.

2) Detection signals (choose by reliability, cost, false positives)

• Case open / switch: simple and low cost; bypassable but valuable as a policy input.
• Mesh / intrusion loop: stronger intrusion indicator; must handle contact faults and manufacturing variance.
• Light sensor: effective for enclosure open events; requires false-positive evaluation in real environments.
• Glitch / brownout abuse detect: monitors suspicious voltage patterns and repeated undervoltage edges.
• Clock / reset anomaly detect: flags abnormal frequency or reset patterns that correlate with bypass attempts.

A practical implementation uses debouncing + time windows + counters to avoid one-shot false alarms driving irreversible actions.

3) Response policy (graded and auditable)

• LOG_ONLY: record the event and increase the risk score.
• LIMITED_MODE: degrade functionality (e.g., disable privileged interfaces, reduce features, enable read-only operation).
• LOCK: block sensitive operations until a legitimate service unlock path is used.
• ERASE_KEYS: highest-severity action; should require high confidence and must be backed by strong evidence to avoid self-destruction.

The response must be explainable: which signal(s) triggered it, what thresholds were crossed, and what action was taken.

4) Evidence and recoverability

• Event record: tamper_reason_code, event_counter, policy_action, optional timestamp.
• Persistence: evidence survives reboot and cannot be silently cleared during normal operation.
• Recovery path: limited/locked modes should have a defined service unlock path; irreversible actions must be rare and justified.

“Auditable + recoverable” means incident forensics is possible while still enabling legitimate repair workflows.

1) Event taxonomy (what must be recorded)

Focus on security-critical transitions and denied actions, not verbose debug strings.

• Boot & trust: boot measurement, verified-boot failure, unexpected digest change.
• Update: update verification failure, install failure, commit failure, rollback attempt (rejected).
• Debug: unlock attempt, unlock granted (level/TTL), unauthorized probe blocked.
• Tamper: case open, glitch/brownout abuse flagged, policy escalation taken, key erase event (if any).
• Stream authenticity: sequence gap, hash-chain break, watermark verify fail (flag).

Each event should carry event_typereason_codeseverity and a compact context digest (policy version, firmware version, slot, session level).

2) Minimal record schema (structure over strings)

A log record is a structured object designed for verification and ordering.

• seq (mandatory): monotonically increasing sequence number (primary ordering anchor).
• t_ref (optional): local time reference (RTC time, boot ticks, or a time-quality flag).
• event_type + reason_code: enumerated values (mechanically checkable).
• context_digest: hash of key context fields (fw_version, policy_version, slot_id, level).
• prev_hash + self_hash: hash chain pointers for tamper-evidence.

The design goal is deterministic parsing and verification. Keep records short, stable, and versioned via a schema_version field.

3) Ordering and time base (without external time systems)

• Sequence-first ordering: seq is the canonical timeline; it must never silently decrease.
• Time is auxiliary: RTC can be helpful but should not be the trust anchor; record a time-quality flag if available.
• Cross-reboot continuity: store seq in a protected state so the next boot continues forward or can detect rollback.

Forensics typically needs correct ordering and provenance more than absolute wall-clock accuracy.

4) Integrity protection (hash chain + signed checkpoints)

• Hash chain: each record includes prev_hash; deletion or modification breaks the chain.
• Signed checkpoint (every N records): create a compact checkpoint that signs the current head hash + seq + policy version.
• Append-only policy: normal runtime cannot rewrite history; truncation must be detectable and handled explicitly.

Checkpoints reduce verification cost and provide a trusted “anchor” across power loss, while the chain provides fine-grained tamper evidence.

5) Capacity and cost controls (low-cost, still useful)

• Ring buffer for detail: keep the last N detailed records; older info can be summarized.
• Critical vs informational: critical events should be retained longer; informational events can rotate faster.
• Compression by aggregation: repeated identical failures can increment counters instead of emitting verbose duplicates.

Avoid deep storage algorithms here: the key requirement is predictable retention plus integrity, not high-throughput logging.

Evidence / Acceptance criteria (negative-test driven)

• Integrity test: deleting or modifying a record must be detected (hash-chain break or checkpoint signature fail).
• Monotonicity test: power loss and reboot must not silently decrease seq.
• Truncation test: mid-write power loss must be recovered by rolling back to the last valid checkpoint/record boundary.
• Replay test: replacing storage with an older log image must be detected via seq / checkpoint mismatch.

1) Checklist template (use the same 4 lines everywhere)

• Threat target: the specific action to prevent or detect.
• Minimal test: the smallest tool + steps to reproduce.
• Expected: block/detect behavior (fail-closed or flagged).
• Evidence: required reason codes, counters, and integrity signals (e.g., log chain intact).

This format avoids re-explaining mechanisms and keeps the checklist executable by firmware and validation teams.

2) Automation split (CI vs bench)

• CI-friendly: signature tamper, downgrade package, replay snippets, delete/modify log entries, policy regression tests.
• Bench-friendly: power loss during update stages, case-open/tamper trigger, reset/brownout abuse patterns (trigger category only).

Keep “attack how-to” out of scope. The goal is verifiable outcomes and emitted evidence, not tooling instructions.