1) Assets to protect (engineer-friendly grouping)

• Identity & keys: private keys, certificates, key slots, derivation seeds, true-random outputs. (Compromise → cloning & impersonation.)
• Boot chain & code: ROM/bootloader stages, OS/app images, signature chains, version metadata. (Compromise → persistent backdoors.)
• Policies & configuration: boot policy, debug policy, recovery policy, protected configuration regions. (Compromise → downgrade & policy bypass.)
• Evidence & logs: signed event trails, monotonic counters, secure timestamps/sequence. (Compromise → “no proof” during audit.)

2) Attack surfaces (bounded by entry points)

• Debug entry: accidental exposure or mismanaged lifecycle states can enable memory reads, patching, or policy bypass.
• Boot entry: image replacement, unauthorized stage insertion, or downgrade to a vulnerable version.
• Non-volatile memory entry: raw reads, offline patching, replay of older but valid content, or metadata tampering.
• Physical entry: enclosure access, probing attempts, environmental anomalies used to force unexpected execution paths.

3) “Provability”: controls must produce evidence

A control is not complete until it yields a verifiable artifact. Reviews typically ask “What is enforced?” and “What is recorded?” The table below shows the minimum mapping that keeps security features from becoming undocumented assumptions.

The rest of this page starts from secure boot because it is the first enforceable control and the earliest point where verifiable evidence can be generated.

1) Chain of trust (who verifies whom)

1. ROM boot (immutable): starts execution and verifies the first stage using a root key (or root key hash) anchored in hardware.
2. 1st-stage bootloader: verifies the next stage and sets security posture (policy locks, debug state, memory protections).
3. OS/runtime stage: verifies application packages or critical components before handing over execution.
4. Application: consumes security posture as read-only inputs (identity, verified version, debug state) and can log security-relevant events.

2) Engineering gates (controls that prevent “almost secure” systems)

Gates are the decision points that must be explicit in the design spec. They also define what must be recorded for compliance evidence.

3) Fail-closed behavior and recovery boundaries

• Fail-closed means a verification failure never transitions to normal run. The system moves to a controlled state with a restricted policy surface.
• Recovery must be authenticated: the recovery image is verified using the same root trust model (or a strictly scoped recovery signer).
• Recovery privileges are minimal: no secret extraction paths, no uncontrolled policy changes, no “silent” debug enablement.
• Every recovery entry is explainable: a reason code is persisted in protected storage and appended to the audit trail.

4) Minimum boot evidence fields (practical checklist)

These fields are small enough to keep, but rich enough to reconstruct “what ran and why”. They also prevent security from being reduced to verbal claims.

With this evidence baseline in place, later sections can extend the model to cover key lifecycle, secure storage, and signed audit logs—without changing the boot trust assumptions.

1) Treat keys as governed objects (not as bytes)

A usable governance model starts with a KeyObject abstraction. The object is stored as non-exportable and is accessed only through controlled operations. The key’s security posture is defined by its policy and lifecycle state.

Purpose tags prevent “one key does everything” drift. Lifecycle state prevents accidental debug/service behaviors from leaking into deployed systems.

2) Provisioning: create / inject / bind (and record it)

Provisioning must answer three audit questions: who created the key, what the key is bound to, and what policy is enforced. A strong design binds keys to device identity and to usage constraints from the first moment. If a key can be created without leaving a record, the lifecycle is already non-auditable.

• Create: generate in a protected boundary or inject under strict authorization; immediately mark as non-exportable.
• Bind: attach usage_policy + purpose_tags + lifecycle_state; optionally bind to counters/sequences for anti-replay.
• Activate: enable the object only after policy is persisted; activation becomes a discrete auditable event.

1) What to optimize: worst-case > average

• Worst-case latency: the maximum time one operation can block a boot gate or a security decision.
• Jitter: how much execution time varies for the same operation across runs.
• CPU blocking time: whether the main core is occupied or can continue other tasks.
• Energy per operation: power cost for verification, hashing, and signing at the required cadence.
• Queueing behavior: whether the engine adds wait time under bursts; timeouts must be recorded.

2) Where accelerators pay off (AES/SHA vs ECC/RSA)

Symmetric and hash operations (AES/SHA) often become “always-on” building blocks for integrity and sealing. Public-key operations (ECC/RSA) typically dominate worst-case latency in verification and signing paths. An engine’s value is highest when it reduces variability and makes the maximum time measurable and schedulable.

3) Engineering checklist: keep acceleration auditable

• Timeouts are events: when the engine is busy or unavailable, record a failure reason and the operation type.
• Queue visibility: record whether an operation waited; queueing changes worst-case latency.
• CPU fallback policy: define when CPU-only is allowed and how it is logged to avoid silent weakening.
• Energy budgeting: treat per-operation energy as a design constraint for sustained security tasks.
• Self-check: record engine health checks as part of the security evidence stream.

1) Identity anchors: where “uniqueness” comes from

A good design separates “unique” from “secret.” The anchor must be stable and non-colliding, while secrecy is enforced by non-exportable keys and policy.

The anchor is allowed to be readable; anti-cloning comes from a private key that cannot be exported.

2) Certificate chain: how a verifier trusts the device

A certificate chain turns a device signature into trusted evidence. The device presents a device certificate, and the chain links it to an issuer hierarchy that a verifier can validate. The device identity is meaningful only if the private key used for signing is policy-restricted (for example: sign-only) and non-exportable.

• Device cert: identifies the device public key and issuer reference.
• Issuer hierarchy: allows validation without trusting the device itself.
• Key policy: restricts what the private key can do (sign only, purpose-bound).

3) Identity binding: proving “this device + this state”

Identity becomes compliance-grade evidence when it signs a compact “evidence package” that includes a freshness challenge (nonce) and a state summary (measurement/policy snapshot). This binds the device identity to what is running, instead of proving only “a key exists somewhere.”

• Nonce: prevents replay of old evidence.
• State summary: binds identity to measured/policy-relevant state.
• Signature: produced by a non-exportable private key under purpose-bound rules.

4) Anti-cloning pitfalls to avoid

• UID used as a secret: a readable UID cannot prevent cloning.
• Exportable private key: once a key can be extracted, the identity can be copied.
• Chain not validated: checking “a certificate exists” is not verification.
• No nonce binding: evidence can be replayed and still look valid.
• No policy context: identity claims that omit policy/debug/rollback context are incomplete for audits.

1) Partition by protection goal (public vs secret)

Treat storage regions as different security domains. Public configuration needs integrity and controlled writes; secret material needs non-exportability and strict policy. Counters and logs must preserve monotonicity and ordering even under power loss.

• Public config: readable; writes are authorized and integrity-protected.
• Secret vault: certificates/keys/counters; access through controlled operations only.
• Counters: monotonic updates with atomic commit.
• Logs: append-only records for audit traceability.

2) Anti-rollback: monotonic counters + atomic commits

Rollback protection fails when counters can be reverted by restoring old storage images or by interrupted updates. A robust design uses a monotonic counter (or equivalent non-decreasing sequence) and updates it through an atomic commit pattern: write the new value, write a commit record, then switch the active pointer.

• Monotonicity: the counter must never decrease.
• Power-fail safety: incomplete writes must be detectable and recoverable to a consistent state.
• Auditability: counter updates must have reason codes and sequence ordering.

3) Secure erase and consistency under wear and power loss

Secure erase must be defined in engineering terms. For secret material, the most reliable erase outcome is often key destruction (rendering data unrecoverable by eliminating the wrapping key or the key object) rather than relying on physical overwrite. Wear leveling and interrupted writes can otherwise leave remnants and inconsistent metadata.

• Key destruction: remove the ability to decrypt or validate sealed data.
• Two-copy metadata: keep critical pointers/counters with a recoverable structure.
• Commit records: a small durable marker that indicates “new state is valid.”

4) Audit cues: what must be explainable after incidents

• Which region changed: config vs secrets vs counters vs logs.
• Why it changed: reason codes for counter increments, erase events, and policy transitions.
• What remained monotonic: counter and sequence ordering never went backward.
• What was rejected: integrity failures and rollback attempts must produce visible, durable records.

1) Event taxonomy: log what can be audited

Events should be recorded by category and by outcome. Each record must include enough context to answer what happened, why it happened, and what policy applied—without leaking secrets.

Use digests (hashes) for sensitive material. Evidence should be provable without exposing secrets.

2) Normalize records: make audits deterministic

Normalization is what makes logs comparable across devices and software revisions. A canonical record format avoids “free-form” log lines that cannot be consistently verified or correlated.

• Canonical fields: fixed field set for every record (type, result, reason, actor, object, policy, time, sequence).
• Stable IDs: policy_id and object_id are stable tokens that survive software changes.
• Redaction: log digests and identifiers, not plaintext secrets.

3) Non-repudiation: hash chain + signed checkpoints

Integrity must survive deletion and rewriting attempts. A strong pattern is a hash chain for every record, plus signed checkpoints so attackers cannot “recompute the chain” after tampering.

• prev_hash links records to detect insertion/removal.
• checkpoint seal signs the chain state at defined moments (periodic or on critical events).
• failure is evidence: verify failures and seal failures must generate durable events.

4) Trusted time: sequence first, time second

Time must be explainable. A trusted design pairs a secure time source with a monotonic sequence. If time jumps or moves backward, it should be recorded as an auditable event; the sequence still preserves ordering for investigations.

• Monotonic sequence: cannot decrease; defines event order.
• Secure time: used to interpret “when,” not to define order alone.
• Time anomaly events: make clock changes visible and reviewable.

1) Sensor evidence: strength and false-trigger risk

Sensors do not “prove tamper” by themselves. They provide evidence with different strengths and false-trigger sources. A controller should treat them as inputs to a confidence decision.

• Enclosure open: strong indicator; must be policy-aware for authorized service scenarios.
• Light / magnet: sensitive to opening and proximity; needs thresholds and debounce.
• Accelerometer: movement and shocks; separate transient impacts from sustained anomalies.
• Temperature anomaly: can indicate probing/abuse; often needs correlation with other evidence.
• Probe detect: high-value signal; commonly escalates response level when confirmed.

2) Tamper controller: debounce, score, latch

The controller turns noisy sensor signals into an auditable decision. The key is to make decision rules explicit and stable so the response can be reproduced in testing and defended in audits.

• Debounce / hold time: prevents instantaneous noise from becoming incidents.
• Confidence scoring: combines sensor evidence into low/medium/high confidence.
• Latching: critical events may remain latched until an authorized clear condition is met.
• Policy snapshot: record the active policy_id and lifecycle state at decision time.

3) Response levels: controlled, not chaotic

Responses should be tiered so that evidence strength maps to a predictable action. Extreme actions should require high confidence and must be fully recorded as evidence.

4) Compliance points: explainable, auditable, reproducible

• Explainable: every action maps to a policy rule and a confidence outcome.
• Auditable: record sensor evidence, decision, action level, duration, and clear condition.
• Reproducible: the same evidence and policy must produce the same response in tests.

1) Debug port lifecycle: open → controlled → off

Define explicit lifecycle states and attach debug rules to each state. This prevents “forgotten factory settings” and blocks accidental re-enablement after deployment.

“Controlled” means debug is never a permanent switch; it is a time-bounded, policy-scoped session that leaves evidence.

2) Controlled unlock: challenge/response + scoped sessions

A secure unlock scheme makes debug access verifiable and bounded. The device issues a fresh challenge (nonce); an authorized signer returns a proof; the device validates it and opens a limited session.

• Time-bounded: sessions auto-expire and return to locked state.
• Capability scope: allow only what is required (read-only vs limited write), and forbid key-region reads.
• Attempt accounting: failed unlock attempts increment counters and generate security events.
• Fail-closed: any verification failure keeps debug locked and produces durable evidence.

3) Manufacturing vs service privileges: isolate the domains

Avoid using one “master” credential for factory, deployment, and service. Domain separation prevents a single leakage event from turning into full fleet compromise.

4) RMA key policy: recover without exposing production secrets

An RMA workflow must not “hand back everything.” If device identity keys are ever suspected of exposure, the safer approach is to zeroize key objects and re-provision under controlled rules, producing an auditable record of the transition.

1. Enter Service/RMA state: record policy_id and reason_code (durable event).
2. Open a controlled debug session: time-bounded, scoped; log session_id and scope.
3. Repair / diagnose: keep secret regions non-readable; prefer “sign-only” operations.
4. Zeroize or revoke if required: destroy/disable affected key objects; record irreversible markers.
5. Re-provision: establish a new certificate/identity binding; generate provisioning record (no secrets).
6. Exit Service/RMA state: return to Deployed rules; log state transition.

Example parts: secure identity & controlled debug building blocks

The following part numbers are common starting points for designs that need non-exportable keys, device signing, and controlled authorization flows. Capabilities vary by variant; always confirm features and certifications in the datasheet.

1) Control points that auditors can verify

• Secure boot & policy gates: fail-closed behavior and recorded outcomes.
• Key lifecycle: provisioning, rotation, revocation/zeroize events with durable records.
• Secure logging: normalization + hash chain + signed checkpoints + trusted ordering.
• Tamper response: sensor evidence → confidence → policy → tiered actions (auditable).
• Secure debug lifecycle: controlled unlock sessions with scope, time bounds, and audit trails.

2) Tests: prove controls, not intentions

Tests should include negative cases. Evidence is stronger when a design demonstrates that unauthorized actions are rejected and that rejections generate durable audit events.

3) Artifacts: what to hand over (without leaking secrets)

• Signed log excerpts: boot/auth/tamper/debug/config events with chain and checkpoint proof.
• Provisioning record: batch_id, device identifiers, certificate serial ranges, and policy_id (no private keys).
• Configuration snapshot: hashes of critical security settings (debug policy, tamper policy, log policy).
• Test report: test IDs, expected vs observed results, firmware/policy versions, and dates.
• Lifecycle transition evidence: Service/RMA entry/exit records, zeroize/re-provision markers where applicable.

If a reviewer cannot independently validate integrity and ordering, the artifact is informational, not evidentiary.

4) A practical packaging checklist

1. Freeze the control list and policy_id for the release under review.
2. Run functional + negative tests that exercise fail-closed paths and evidence creation.
3. Extract signed log excerpts (with checkpoint proofs) for key scenarios.
4. Export configuration snapshot hashes and provisioning records (no secrets).
5. Bundle artifacts with firmware/policy version identifiers and verification notes.

Example parts: linking controls to evidence

Evidence quality improves when key operations (signing checkpoints, unlock proofs, monotonic ordering) are bound to non-exportable key objects. These example part numbers are commonly used as secure key anchors.