123 Main Street, New York, NY 10001

Submit Your BOM

Edge Secure Vault & Tamper-Evident Logs

Edge Secure Vault & Tamper-Evident Logs

← Back to: 5G Edge Telecom Infrastructure

Edge Secure Vault & Logs provides hardware-rooted key custody and tamper-evident audit trails: keys are generated, wrapped, and used under policy without ever exposing plaintext, while security events are appended into a signed, hash-chained evidence log. It is designed to stay verifiable under host compromise, power loss, and physical tamper, so deletion, rollback, or truncation attempts become provable evidence rather than silent failure.

H2-1 · What this page solves: the engineering boundary of Vault & Logs

This page specifies a Secure Vault (key custody) plus Tamper-Evident Logs (forensic integrity) as a deployable edge building block. The vault keeps device secrets non-exportable and policy-governed, while the log subsystem produces an append-only, verifiable audit trail where deletions or edits become provable. It is not a packet security gateway, a traffic inspection engine, or a probe/buffering pipeline.

Vault non-exportable keys Logs hash-chained blocks Freshness counters / anti-rollback Evidence tamper events + signatures

Vault: what it concretely provides (lifecycle, not buzzwords)

  • Generate device secrets from hardware entropy (TRNG → conditioned DRBG) and bind them to device identity.
  • Store secrets as sealed objects (handles / wrapped blobs) so raw key bytes are not exposed to the host.
  • Use secrets via policy-checked operations (sign, unwrap, derive) that return results—not plaintext keys.
  • Rotate keys with versioning (KEK/DEK separation), controlled overlap windows, and anti-rollback guardrails.
  • Revoke / Zeroize specific key tiers based on tamper policy, with irreversible actions recorded as evidence.

Logs: what is different from “normal logs”

  • Append-only storage discipline (WORM-style semantics): writes add new records; history is not overwritten.
  • Tamper evidence: each record links to the previous (prev_hash), then is signed/MACed by a protected key.
  • Order & freshness: monotonic counters and secure timestamps (when available) prevent silent replay or rollback.
  • Exportable proof: exported log packages remain independently verifiable by third parties without trusting the host OS.

Boundary table: choose the right primitive without mixing responsibilities

Component Primary purpose Trust anchor & interface model What it does (and does not)
Secure Vault + Tamper-Evident Logs
(this page)		 Non-exportable key custody + verifiable evidence chain for edge events. Secure element / protected key store; host calls policy-checked ops via handles. Does: wrap/derive/sign, seal storage, append-only signed logs, anti-rollback.
Does not: packet inspection, probe buffering, SIEM analytics.
TPM Measured boot roots, platform integrity, attestation primitives. Standardized commands; PCRs/measurements + attestation key. Does: attest platform state, store limited secrets tied to measurements.
Does not: high-volume evidence-chain logging by design intent.
HSM High-assurance crypto boundary for enterprise/server keys. Dedicated module, strong physical protections; remote clients use crypto services. Does: centralized key custody and crypto policy enforcement.
Does not: device-local power-loss retention workflows by default.
Software keystore Convenient secret storage within OS/app boundary. OS permissions + storage encryption; relies on host integrity. Does: store app secrets if OS is trusted.
Does not: remain safe when host is compromised; cannot guarantee tamper-evident history.
SIEM / log analytics Centralized collection, correlation, detection, reporting. Backend platform; depends on input log authenticity. Does: analyze and alert at scale.
Does not: create cryptographic tamper evidence at the edge source.
Practical decision rule: if the operating assumption is “the host may be compromised,” then secrets must be non-exportable and logs must be tamper-evident at the source before any upload or analytics.
Figure F1 — Boundary map: what Vault & Logs cover vs adjacent primitives
Vault & Tamper-Evident Logs: Key custody + verifiable evidence chain In Scope (This Page) Secure Vault Non-exportable Policy-checked ops KEK/DEK split Key wrapping Tamper-Evident Logs Append-only Hash chain Signed blocks Counters / time Verifiable exports (third-party validation) Adjacent (Different Responsibility) TPM Measured boot roots + platform attestation (PCR-based) HSM Centralized crypto boundary for server/enterprise keys Software keystore Convenience storage relying on host integrity SIEM Backend analytics; depends on authentic source logs Key idea: build tamper evidence at the edge source, then export verifiable proof to any backend.

H2-2 · Threat model & security objectives: what failures must be prevented

A vault-and-evidence design becomes coherent only when all choices map back to a threat model. The baseline assumption here is conservative: the host OS or application may be compromised. Under that assumption, the system must still protect non-exportable secrets, preserve freshness against rollback, and maintain a verifiable evidence chain even across power disturbances.

Threat surfaces (grouped by attack path)

  • Remote compromise: attacker controls host software and tries to misuse key operations or forge audit history.
  • Local interface probing: bus sniffing, debug access attempts, flash dumps, or storage cloning for offline analysis.
  • Power attacks: repeated power cuts to truncate logs, roll back counters/firmware, or replay old wrapped key blobs.
  • Physical tamper: enclosure open, mesh break, light/temperature/voltage manipulation, fault injection (glitch) to bypass policy.

Security objectives (written as measurable acceptance criteria)

  • Key confidentiality: no raw key export paths; operations return signatures/derived outputs, not plaintext key bytes.
  • Integrity: any modification/deletion of a record causes verification failure of the chain and signatures/MACs.
  • Freshness / anti-rollback: counters and version guards prevent replay of older firmware, policies, or key states.
  • Survivability: abrupt power loss cannot silently “make history disappear”; incomplete commits must be detectable.
  • Evidence quality: tamper events and security-relevant decisions are recorded with verifiable linkage and identity.

Evidence fields that make objectives verifiable (what to log, not just what to do)

  • Chain fields: prev_hash, block_hash, block_index
  • Authenticity fields: signature/MAC, signer_id, key_version
  • Freshness fields: monotonic_counter, anti_rollback_version, time_anchor (if available)
  • Power-loss fields: journal_seq, commit_marker, closing_record
  • Tamper fields: tamper_class, response_level (evidence-only/lockdown/zeroize), counter_at_event
Design consequence: if the host is treated as potentially hostile, then (1) secrets must remain non-exportable, (2) log history must be append-only and cryptographically linked at the source, and (3) freshness must be enforced by monotonic state that survives power cycles.
Figure F2 — Threat map (4 quadrants) and the controls that generate verifiable evidence
Threat surfaces → controls → evidence fields Secure Vault & Logs Non-exportable keys Append-only evidence chain Remote compromise Local probing Power attacks Physical tamper Goal: misuse key ops / forge audit history Control: policy checks Evidence: signed blocks Goal: read buses / dump storage / clone media Control: non-exportable Evidence: access records Goal: rollback / truncate chain / replay blobs Control: counters Control: atomic commit Evidence: monotonic_counter + commit_marker + closing_record Goal: open/mesh break/glitch to bypass policy Control: tamper sensors Control: response tiers Evidence: tamper_class + response_level + counter_at_event Acceptance focus: evidence must remain verifiable even if the host is compromised or power is unstable.

H2-3 · Reference architecture: hardware/firmware layers for Edge Secure Vault & Logs

A deployable vault-and-evidence block is defined by clear separation of responsibilities and trust boundaries. The host domain may run critical workflows but is treated as potentially compromised; protected domains must therefore enforce non-exportable key custody and produce tamper-evident audit history at the source.

Untrusted Host domain Trusted Secure Element + TRNG Evidence Append-only storage Tamper Sensors + response Retention Atomic commit

In-scope components and their responsibilities

  • Secure Element (SE): root-of-trust keys, policy engine, wrap/unwrap/sign/derive operations; outputs handles, wrapped blobs, and signatures—never raw key bytes.
  • TRNG + conditioning: entropy source, conditioning, DRBG reseed; produces health status that must be auditable.
  • Host MCU/SoC: API client, workflow orchestration, network uploader; not trusted as a proof source when compromised.
  • Storage (WORM / append-only): write-once semantics for evidence blocks, metadata area for commit markers and chain continuity.
  • Tamper sensors: mesh/light/temp/voltage/accelerometer inputs; events must enter the same evidence chain.
  • Hold-up / retention: ensures atomic commit and sealing completes during power loss (short hold-up window, not long backup power).

Trust boundary and invariants (what must always stay true)

  • Invariant A — Non-exportable custody: secrets remain inside the SE boundary; host receives only results and references.
  • Invariant B — Evidence authenticity: chain linkage and signing originate from protected keys, not from host software.
  • Invariant C — Power-loss detectability: any interrupted write leaves a detectable marker (no silent truncation).

Typical flows (kept minimal but unambiguous)

  • Key use: Host → SE (policy context + operation) → Host (signature / derived output / wrapped blob handle).
  • Evidence write: Host → Storage (append record) with SE-protected chain head and authenticity fields.
  • Tamper event: Sensor → (policy) → evidence record + response tier (evidence-only / lockdown / zeroize).
Common failure to avoid: building the chain in host software and only “storing” it later. If the host can rewrite history, tamper evidence is lost even with strong crypto.
Figure F3 — System block diagram and trust boundary (Host vs Trusted Crypto vs Evidence Domain)
Edge Secure Vault & Logs — Reference Architecture Host Domain (Untrusted) Trusted Crypto Domain Evidence Domain API Client wrap / sign / derive Log Writer append blocks Uploader export verifiable proof Assumption Host may be compromised History must still verify Secure Element Root keys (non-exportable) Policy checks + crypto ops TRNG + DRBG Entropy + health status Chain Head Protector prev_hash + signer_id sign/MAC each block Monotonic State anti-rollback counters Append-only Storage WORM / journal / seals commit_marker Tamper Sensors mesh / light / temp voltage / accel Hold-up / Retention finish atomic commit seal last record op request result / handle append block sign head tamper event Invariants: no raw keys out of SE · signed/linked evidence · power-loss leaves detectable markers

H2-4 · Device identity & root keys: from factory provisioning to online attestation

Vault-and-evidence systems require a stable device identity and a key hierarchy that supports separation of duties, rotation, and anti-rollback guarantees. Identity keys establish “who produced this evidence,” while wrapping and data keys protect “what is stored” without exposing plaintext secrets to the host.

Root non-exportable AK attestation signing KEK wraps keys DEK protects data Counter anti-rollback

Key hierarchy (purpose-driven, with operational implications)

  • Root key: highest trust anchor inside the secure element; used to protect or derive identity keys and critical policy state.
  • Attestation key (AK): signs device statements (identity + measured state + freshness). Leakage enables source impersonation, so protection is critical.
  • KEK (Key-Encryption Key): wraps other keys (key wrapping) and supports controlled rotation with version tracking.
  • DEK (Data-Encryption Key): encrypts payloads (e.g., sealed data, exported log packages). Rotates more frequently and can be scoped by purpose.

Provisioning path: three stages, each with distinct risks and required evidence

Stage Primary risks Evidence to record (tamper-evident)
Manufacturing injection Supply-chain exposure, duplicate identity, wrong certificate binding, uncontrolled debug access during provisioning. Provisioning record ID, batch/lot, initial counter baseline, first-boot identity statement hash.
On-site binding Binding to wrong tenant, man-in-the-middle substitution, policy mismatch across fleet. Tenant binding event, policy_version hash, key_version, verifier anchor ID.
RMA / board swap Identity discontinuity, mixing old evidence into new chain, inability to explain gaps to auditors. Explicit chain closure record, new chain genesis record, linkage note (non-secret) for case tracking.

What “attestation output” must contain (a verifiable statement template)

  • Identity: device_id (or certificate subject), signer_id, key_version.
  • Measured state: firmware_measurement hash, critical configuration hash, policy_version hash.
  • Freshness: monotonic_counter, anti_rollback_version, optional time_anchor when available.
  • Evidence linkage (recommended): last_log_head_hash (binds source logs to the identity statement).
  • Signature: statement is signed by AK so verifiers can confirm authenticity independently of the host OS.
Design rule: AK is for signing statements and evidence origin. KEK is for wrapping keys and rotating custody. Keeping these roles separated limits blast radius and enables cleaner rotation policies.
Figure F4 — Key hierarchy and attestation path (Root → AK → KEK/DEK, with freshness and measurements)
Device Identity, Key Hierarchy, and Attestation Statement Key hierarchy (inside Secure Element) Root Key non-exportable Attestation Key Signs device statements KEK Wraps keys DEK Encrypts data Attestation path (verifiable output) Inputs monotonic_counter measurement_hash policy_version log_head_hash Attestation Statement device_id · signer_id · key_version counter · measurement · policy hash signed by AK (inside SE) Verifier checks signature + freshness Policy allow / deny AK signature Separation: Root anchors identity · AK signs statements · KEK wraps keys · DEK protects data · counter prevents rollback

H2-5 · TRNG & entropy health: when “random” is not random

Randomness is a root dependency for device identity, key generation, nonces, and attestation challenges. If entropy quality degrades, the vault can silently produce predictable secrets and the evidence chain can lose credibility. The engineering requirement is therefore not only “having a TRNG,” but also proving ongoing health, defining failure behavior, and logging entropy anomalies into the tamper-evident chain.

Pipeline Noise → Conditioner → DRBG Tests startup + continuous Reseed policy & failure Fail closed where needed Evidence anomaly records

Entropy pipeline (what each stage must guarantee)

  • Noise source: produces unpredictability; vulnerable to bias, correlation, or periodic coupling from clocks and power rails.
  • Conditioner: reduces bias and improves statistical properties; cannot create entropy if the input is compromised.
  • DRBG: expands conditioned entropy into usable random streams; depends on reseed and must enforce reseed policy.
  • Consumers: key material, nonces, challenges, salts; weak randomness here is a systemic failure.

Health tests: what is checked and what field failures look like

Test What it catches Typical field causes
Startup test Bad initial state, stuck outputs, gross bias/correlation before first key/nonce use. Cold/hot startup drift, unstable supply during boot, immediate EMI coupling from nearby switching/clock domains.
Continuous test Runtime degradation, intermittent failures, slow drift of statistics, burst anomalies. Temperature drift and aging, power/clock coupling changes, strong EMI events, brownouts or ripple spikes.
DRBG reseed gate Missing reseed, reseed failure, reseed with unhealthy entropy, policy bypass attempts. Entropy health failure, sensor/rail fault, misconfigured reseed interval, forced low-power modes starving entropy source.

Failure strategy (fail-closed with operational granularity)

  • Hard stop: deny new key generation, deny key-wrapping initialization, deny high-impact attestation statements when entropy health is failing.
  • Soft degrade: allow limited operations using existing protected keys when allowed by policy (no new secrets created).
  • Recovery gate: re-enable critical operations only after a continuous “healthy window” is observed; record the recovery event.
Evidence requirement: entropy anomalies must generate chain records such as entropy_health_fail, reseed_fail, and entropy_recovered with severity, test_id, counter_at_event, and policy_effect.
Figure F5 — Entropy pipeline and test points (startup/continuous) with policy actions and evidence logging
TRNG Entropy Pipeline · Health Tests · Policy Actions Entropy pipeline Noise Source bias / coupling drift / aging Conditioner debias / mix health status DRBG reseed gate output stream Consumers keygen nonce/chal Health tests Startup Test before first use Continuous Test runtime drift/anomaly Reseed Gate deny if unhealthy Actions Hard stop deny keygen Soft degrade limited ops Recovery healthy window Evidence Log entropy events test fail / recover Requirement: health tests drive policy actions and produce verifiable entropy anomaly records in the chain

H2-6 · Key wrapping: what is wrapped, how it rotates, and what “recovery” really means

Key wrapping is the practical mechanism that enables safe storage, rotation, and restoration of sensitive key material without exposing plaintext keys to the host. The wrapped object is a versioned, integrity-protected blob that can be stored in append-only metadata and referenced by handles. Recovery restores only the wrapped state, never raw key bytes.

Objects DEK + key blobs Custody SE generates Versions KEK vN Rotation overlap window Anti-rollback counters

What is wrapped (and why)

  • DEK (Data Encryption Key): protects encrypted payloads such as sealed data and exported evidence packages; rotates on schedule or incident.
  • Key blobs: session keys or derived materials that must not persist in plaintext; stored only as wrapped blobs with hashes.
  • Metadata binding: key_id, kek_version, and blob_hash are recorded to prevent silent substitution.

End-to-end wrapping lifecycle (engineering-grade, not just a concept)

  1. Generate: SE creates DEK/blob material and returns a handle.
  2. Wrap: SE wraps with KEK vN and produces a versioned wrapped_blob.
  3. Store: Host appends wrapped_blob + metadata into append-only storage.
  4. Use: Host requests unwrap/use; SE enforces policy and returns crypto results (not keys).
  5. Expire: append a “deprecated” record while keeping history verifiable.
  6. Revoke/Destroy: append a “revoked/zeroized” record and enforce denial thereafter.

Rotation and versioning (how KEK changes without breaking history)

  • KEK version numbers: kek_v1, kek_v2… are auditable and must be bound to monotonic state.
  • Overlap window: new blobs are wrapped with v2, but unwrapping v1 remains allowed for a limited period.
  • Rewrap migration: SE rewraps existing blobs to v2 without exporting plaintext (unwrap inside SE → wrap v2).
  • Anti-rollback hook: KEK version must never decrease; any rollback attempt triggers policy action and an evidence record.

Backup and recovery boundary (what can be restored safely)

  • Recoverable: wrapped_blob + non-secret metadata (key_id, kek_version, blob_hash) stored in append-only records.
  • Not recoverable: plaintext keys; no process should export raw key bytes as a “backup.”
  • Audit requirement: every restore attempt becomes a chain event (restore_attempt / restore_success) with counter and policy version.
Verification focus: wrapping is only operationally safe when metadata is append-only and versioned, and when rollback is prevented by monotonic state tied to KEK/key versions.
Figure F6 — Key wrapping sequence: request → generate/wrap in SE → append metadata → evidence event → handle
Key Wrapping Lifecycle (Sequence View) Host Secure Element Append-only Metadata Evidence Chain 1) wrap request 2) generate DEK no raw key out 3) wrap with KEK vN wrapped_blob 4) append record key_id + kek_version blob_hash + seal wrap_created counter_at_event 6) handle returned use via SE ops Rotation (summary) KEK vN → vN+1 overlap window rewrap inside SE (no plaintext export) rollback triggers evidence event Recovery restores wrapped blobs + metadata; plaintext keys are never exported as a backup

H2-7 · Power-loss retention: keep evidence durable and make power-cycling attacks provable

Edge systems face real-world brownouts, jittery supplies, cable pulls, and repetitive power-cycling. A secure vault and tamper-evident log must therefore survive power loss without losing the last critical evidence, and must prevent (or at least prove) attempts to bypass security by rolling back counters or truncating the chain.

Assets counter + critical events Consistency chain tail seal Protocol prepare/commit/seal Storage journal + append-only Hold-up finish one commit

What must be retained (minimum evidence set)

  • Monotonic counter (anti-rollback): binds policy/version evolution and prevents silent reversion to older state.
  • Critical audit events: tamper, entropy anomalies, policy changes, key state changes, and restore attempts.
  • Chain-tail consistency: a verifiable tail seal so truncation or partial writes become detectable.

Engineering pattern: append-only + journal + atomic commit marker

The most robust approach treats every evidence write as a small transaction: first record intent, then append the payload, then finalize with a seal. Each phase leaves distinct artifacts, allowing recovery to prove whether a transaction completed or was interrupted.

Phase What is written If power fails here, what becomes provable
PREPARE Journal intent: prev_hash, record_hash, counter_target, policy_version. Existence of a pending intent record (pending_journal), proving an incomplete write attempt occurred.
COMMIT Append the evidence block into the append-only region (payload + hash link). Partial/uncertain tail without final seal (unsealed_tail) or incomplete block write (incomplete_commit).
SEAL Atomic commit marker + tail seal; advance monotonic counter to match the sealed tail. Block may exist, but tail seal/counter advance is missing; recovery must produce a recovery_record.

Storage choices and their effect on provability

  • FRAM/EEPROM: small-granularity writes and clearer power-loss behavior; ideal for journal and monotonic state.
  • Flash (NOR/NAND/eMMC): page/erase constraints and write amplification; requires strict sealing and recovery records to avoid ambiguity.

Hold-up power: only to finish one atomic commit

  • Trigger: power-fail detect or PG drop initiates “finish-commit mode.”
  • Goal: complete the PREPARE→COMMIT→SEAL chain for the last critical event, not to keep the system running.
  • If the window is insufficient: record a minimal power_loss_incomplete indicator so interruption remains provable.
Attack view: repetitive power cycling often aims to roll back counters or truncate the last chain segment. The engineering goal is to make such attempts either impossible or evidence-producing via tail-seal mismatch and recovery records.
Figure F7 — Power-loss consistency state machine: PREPARE → COMMIT → SEAL, and what each interruption leaves behind
Power-Loss Evidence Consistency · PREPARE → COMMIT → SEAL Transaction states PREPARE Journal intent counter_target COMMIT Append block hash link SEAL Commit marker tail seal Power loss here Power loss here Power loss here Monotonic Counter advance only when SEAL succeeds Evidence outcomes pending_journal incomplete_commit unsealed_tail recovery_record makes attack provable Goal: power loss never silently erases evidence; every interruption yields a verifiable chain outcome

H2-8 · Tamper detection: sensors are the start—policy and evidence make it real

Tamper inputs are only signals. Real security comes from a closed loop: detection → decision → tiered response → evidence record in the tamper-evident chain → controlled reporting. This prevents “it was a false alarm” disputes and preserves auditability even when the host is untrusted.

Inputs mesh / light / temp Decision debounce + correlate Tiers evidence/lockdown/zeroize Evidence chain record Mitigation false tamper

Tamper inputs (grouped by practical attack surface)

  • Physical open/mesh/light: cover switch, conductive mesh integrity, light exposure triggers.
  • Environmental abuse: temperature extremes, vibration/acceleration outliers.
  • Fault injection signals: voltage/clock glitch indicators and abnormal rail behavior.
  • Interface probing indicators: abnormal access counters or unexpected debug paths (treated as signals, not as network security).

Decision pipeline (reduce false tamper without losing true positives)

  • Signal hygiene: filtering, debounce, sampling windows, and latching when required.
  • Threshold + hysteresis: avoid rapid toggling under noisy conditions or marginal states.
  • Multi-sensor correlation: require combined conditions (e.g., cover + light + accel) before escalating.

Tiered response (three operational levels)

Tier What it does When it fits
Evidence-only Record event and context, report status, continue operations under monitoring. Low confidence, service/maintenance cases, or benign environment anomalies.
Lockdown Stop high-risk operations: deny sensitive unwrap, deny critical attestation outputs, keep evidence logging enabled. Medium/high confidence tamper or correlated indicators.
Zeroize Irreversibly erase selected key tiers; must append a verifiable “zeroize” record before/while executing. High confidence physical compromise requiring irreversible containment.
Non-negotiable: every tamper decision must append a chain record with short fields like tamper_type, confidence, response_tier, counter_at_event, and policy_version. False-tamper mitigation improves operability, but evidence-first design preserves auditability.
Figure F8 — Tamper closed loop: inputs → decision → tiered action → evidence record → report
Tamper Policy Loop · Detect → Decide → Act → Record → Report Inputs Mesh integrity Light / cover switch Temp extremes Voltage / clock glitch Accel / vibration Access counters Decision pipeline Filter / Debounce Correlate signals Classify confidence Tiered actions Evidence-only Lockdown Zeroize Append record Report Rule: every tier must append a verifiable tamper record; sensors alone are not auditability

H2-9 · Secure logs: append-only blocks, hash chains, and signatures that make edits provable

A “secure log” is not a text file. It is a verifiable data structure designed so that deletion, truncation, or modification becomes detectable by an external verifier. The design hinges on three primitives: append-only storage, cryptographic linkage (hash chaining or Merkle-style aggregation), and authentication (signature or MAC) over the fields that define order and meaning.

Block payload + prev_hash Order monotonic counter Time timestamp or anchor Auth signature / MAC WORM closing record

Event classes (keep scope tight, keep evidence consistent)

  • Security events: tamper tier changes, policy updates, attestation failures, rollback detection.
  • Operations events: KEK rotation, certificate updates, wrap/rewrap outcomes, restore attempts.
  • Health events: TRNG health failures/recovery, reseed failures, power-loss incomplete commits.

Minimum log block format (the fields that make tampering detectable)

Field group What it contains Why it matters
Link prev_hash of the prior block (genesis for the first block) Edits and truncation break linkage and become provable.
Order counter (monotonic) and optional seq Preserves ordering even without a trusted clock; blocks rollback attempts.
Time timestamp + time_quality (untrusted/anchored) Allows correlation without making time a single point of trust.
Payload event_type + short context (reason codes, policy version, tamper tier) Enables audits while avoiding verbose, hard-to-verify text.
Auth Signature or MAC over prev_hash + counter + payload (and time fields if used) Prevents undetected replacement; binds meaning to ordering.

Hash chain vs Merkle-style aggregation (engineering tradeoffs)

Hash chain (default for append-only)

Simple to implement and naturally append-friendly. Verification typically walks from a known anchor (or checkpoint) through the chain to the target range. Adding periodic anchors improves verification speed.

Merkle / segmented Merkle (for frequent partial proofs)

Faster partial-range proofs, but higher implementation complexity and more careful power-loss consistency requirements. Best used only when exporting small proofs is frequent and performance-critical.

WORM / append-only partitions and truncation handling

  • No overwrite: “delete” becomes an appended record (e.g., a tombstone or closure record).
  • Truncation is not silent: a missing tail seal or missing closure becomes a verifiable failure.
  • Closing record: a final appended block that states closing_reason, last_counter, last_hash, and is authenticated.

No trusted time? Use counters and anchors

  • Counter preserves order: blocks remain auditable by strict monotonic progression.
  • Time anchors: when a verified time source exists, append an anchor block binding anchor_time to anchor_counter and anchor_hash.
  • Practical outcome: sequence is provable; time is correlated when anchored, not assumed.
Export principle: exporting a secure log means exporting a verifiable evidence package (blocks + anchors/checkpoints + closing record), not a user-editable text file.
Figure F8 — Secure log block format and linkage: block fields, hash chain, time anchor, and closing record
Secure Log Structure · Append-only Blocks with Verifiable Linkage Log block format Header: version · type · length prev_hash counter · seq timestamp · time_quality payload: event_type reason codes · policy ver signature / MAC Hash-chained blocks Block N-1 Block N Block N+1 prev_hash links blocks Anchors and closure Time anchor anchor_time anchor_counter + sig Closing record closing_reason last_counter + last_hash Export as evidence: blocks + anchors/checkpoints + closing record (verifiable package, not editable text)

H2-10 · Integration: how edge devices call vault/log services without exposing keys

Integration must assume the host can be compromised. The secure element (or vault core) should therefore expose an interface that returns cryptographic results (signatures, wrapped blobs, derived outputs) rather than exporting secret material. Logs are appended as verifiable evidence blocks, not as editable text.

Channel SPI/I²C/mailbox Session integrity + replay API handle + policy Limits least privilege Logs same evidence chain

Host ↔ vault core channel (transport is not the security boundary)

  • Transports: SPI, I²C, mailbox, or similar host-device links.
  • Session protection: message integrity and (when needed) confidentiality via a session key.
  • Replay protection: per-session counters/sequence numbers so captured traffic cannot be replayed.

API mental model: handle + policy, not key export

❌ Wrong model

Read out secrets to host memory and perform crypto on the host.

✅ Correct model

Use handles and policies: request operations and receive cryptographic results.

Call pattern What returns What remains protected
sign(handle, msg_digest) Signature + metadata (counter/time quality) Private key never leaves the vault core
unwrap(handle, wrapped_blob) Decryption/unwrap result or a new protected handle Plaintext key material is not exported
derive(handle, context) Derived output or derived-handle Root secrets stay internal; policy limits apply

Logging calls: write, seal/rotate, export evidence

  • Write: append an evidence block (event type + short context + linkage fields).
  • Seal/rotate: append a closing record stating reason and last hash/counter.
  • Export: export a verifiable package (blocks + anchors/checkpoints + closing record).

Two common pitfalls and how to bound damage

  • Compromised host: apply least privilege per key/role, separate high-risk operations, and enforce usage limits.
  • Log growth: apply quotas by event class, aggregate low-value events into summaries, and force closure records—never silent overwrite.
Design rule: sensitive operations and tamper responses must be policy-gated inside the vault core, and every critical decision must append an evidence block into the same tamper-evident chain.
Figure F9 — Integration sequence: handle-based crypto calls and evidence logging on the same append-only chain
Handle-based Calls · Policy Check · Evidence Append · Verifiable Export Host Secure element Append-only logs Evidence export Sign request handle + digest Policy check Signature result sig + meta append event Log block prev_hash + counter Use / unwrap handle + blob Policy check Crypto result no key export append event Log block signature/MAC Export package blocks + anchors Principle: return crypto results, not secret keys; log every critical decision into the same verifiable chain
Edge Secure Vault & Logs

H2-11 · Validation & Production Checklist: proving it is secure and operable

This chapter turns “secure vault + tamper-evident logs” into verifiable pass/fail criteria: what must be tested, what evidence must be recorded, and what artifacts must be exportable for third-party verification.

1) Acceptance goals (what “done” means)

Define measurable outcomes before any test plan is written. Each goal must map to an evidence field in the secure log chain.

  • Key confidentiality: plaintext keys are non-exportable; host compromise cannot dump secrets.
  • Policy enforcement: signing/unwrapping is gated by policy (role, counter, state, tamper level).
  • Tamper-evidence: deletion, truncation, and rollback attempts leave cryptographically verifiable traces.
  • Power-loss safety: atomic commit prevents “half-written” records from being mistaken as valid.
  • Operability: operators can export a verifiable evidence bundle without exposing secrets.
Counter / anti-rollback Prev-hash / chain link Signature/MAC Commit stage Tamper level TRNG health flags

2) Figure F10 — Validation matrix at a glance (R&D → production → field)

Use this to ensure every “security claim” has a test and every test produces a durable evidence record.

Validation Matrix Map Areas × Phases → Evidence in the same append-only chain Phases DVT (Lab) PVT (Line/Sample) Field (Ops) Areas TRNG Health Key Wrapping Power Retention Tamper Policy Forensics Export DVT Stress & fault-inject PVT Process repeatability Field Self-check + evidence export Rule: every failure mode must produce a signed record + counter + previous hash link (no “silent failures”).
Figure F10 — Coverage map: DVT stress, PVT repeatability, field self-check & export, all producing chain-verifiable evidence.

3) Test matrix (recommended minimum for DVT/PVT/field)

Each row defines setup, pass criteria, and the evidence fields that must appear in the append-only log chain.

Area Test Setup Pass criteria Evidence recorded (in-chain)
TRNG Startup health test Cold boot across temperature corners; multiple boots; capture health flags before any key generation. No health failure; if failure occurs → fail-closed for key generation/signing classes. boot_idrng_healthpolicy_statecounter
TRNG Continuous health under stress Supply ripple / EMI injection / thermal ramp; run periodic reseed; correlate with sensor telemetry. Alert triggers at threshold; degraded mode blocks new keys; log chain stays continuous. rng_alarmdegrade_reasonprev_hashsig
Wrapping KEK rotation drill Rotate KEK with dual-write window; verify both KEK versions can unwrap during migration; then retire old KEK. All active blobs unwrap; retired KEK cannot unwrap after cutoff; version is monotonic. kek_verblob_verrotate_eventcounter
Wrapping Rollback attempt Restore older firmware/config or older wrapped blob; attempt unwrapping/signing. Operation denied or flagged; a “rollback detected” record is produced. anti_rb_ctrmeasured_hashdeny_codesig
Power-loss Random power-cut across commit stages Inject power loss during PREPARE/COMMIT/SEAL; repeat thousands of cycles; vary load and temperature. After reboot: chain verifies; partial records are detectable; no “valid-looking” truncation. commit_stageseal_flagrecovery_pathprev_hash
Power-loss Counter monotonicity Repeated brownouts; attempt to freeze/rewind counters by toggling rails; validate counter increments. Counter never decreases; detected anomalies are logged and block sensitive ops if configured. anti_rb_ctrbrownout_evttamper_lvlsig
Tamper Sensor injection + debounce Trigger mesh/light/temp/accel/glitch inputs with controlled pulses; verify debounce and correlation rules. False positives remain below target; real tamper triggers correct tier. tamper_srcdebounce_msdecisioncounter
Tamper Response tier validation Run Evidence-only → Lockdown → Zeroize scenarios; verify policy gates: signing/unwrapping/export. Expected functions blocked/allowed per tier; irreversible actions require explicit policy state. tamper_lvlpolicy_statezeroize_idsig
Logs Truncation & deletion attempt Erase tail blocks; remove “latest” pages; attempt to continue logging and produce a clean chain. Verifier detects gap; system emits a closing/repair record; “gap detected” is preserved. gap_indexclosing_recprev_hashsig
Logs Time absence & time anchor Run without trusted RTC/network time; then later introduce a trusted time anchor; verify continuity. Evidence remains verifiable using counter + anchor records; no ambiguous ordering. time_anchorctr_rangeanchor_sigprev_hash
Forensics Third-party verification replay Export an evidence bundle; verify on a clean machine using a separate verifier toolchain. Independent verifier reproduces chain integrity, signatures, and counters; mismatches are explainable. bundle_idroot_pubverify_okerror_code
Production tip: PVT must validate repeatability (same inputs → same evidence fields), while field mode must validate operability (export + verify without privileged secrets).

4) Example reference BOM (specific part numbers)

These are representative material numbers to speed up sourcing and prototyping. Final selection must follow datasheets, package/temperature grade, lifecycle, and certification needs.

Function Example material numbers Why it fits this page (vault/log evidence)
Secure element (vault core) Microchip ATECC608B Infineon OPTIGA™ Trust M SLS32AIA NXP EdgeLock SE050 ST STSAFE-A110 Analog Devices DS28C36 Microchip TA100 Non-exportable keys, secure storage, on-chip RNG/TRNG (device-dependent), counters, and policy-like gating primitives used to anchor wrapping + log signing.
TPM (boundary option) Infineon SLB9670VQ2.0 SLB9670VQ20FW786XTMA1 Useful when a TPM2.0 stack is required; still needs an append-only evidence design (TPM ≠ tamper-evident log by itself).
Append-only log storage (SPI NOR) Winbond W25Q128JVSIQ Winbond W25Q128JVPIQ TR Macronix MX25L12835FMI-10G Supports large, cheap append regions; the “tamper-evident” property comes from block format + chaining + closing records, not from flash alone.
Journal / atomic metadata (FRAM) Fujitsu MB85RS256TY Fujitsu MB85RS256 (family) High endurance metadata/journal storage helps implement PREPARE/COMMIT markers robustly across power cuts.
Power-loss window control TI TPS3899 TPS3899DL01DSER Supervisor + timed reset can enforce “commit-or-fail” behavior during brownouts, preventing ambiguous log state.
Hold-up energy (supercap) Eaton KVR-5R0H105-R Provides a short ride-through window to finish a single atomic commit (not for long runtime).
Tamper sensors (examples) ST LIS2DW12 (3-axis accel) Vishay VEML7700-TT (ambient light) TI TMP117 TMP117MAIDRVR Enable multi-sensor correlation and tiered response; the key requirement is that tamper events are logged in-chain with counter + signature.
Procurement rule of thumb: prefer components with stable lifecycle and clear ordering codes; avoid “NRND” variants for new designs.

5) Production-ready evidence package (what must be exportable)

Security claims become credible only when evidence is easy to export and independently verify.

  • Signed log bundle: contiguous log blocks + the device public identity (or certificate chain) needed for verification.
  • Closing records: explicit “seal/close” entries used for partition boundaries and controlled truncation policies.
  • Counter snapshots: anti-rollback counter values + last verified time anchor (if available) to reconstruct ordering.
  • Tamper summary: last tamper level, last tamper source, and the response tier applied (evidence-only/lockdown/zeroize).
  • Verifier output: a deterministic report: chain OK/FAIL, first failing block index, failing signature/hash reason code.

Request a Quote

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

H2-12 · FAQs (Edge Secure Vault & Logs)

These FAQs target long-tail engineering questions about key custody, tamper-evident evidence chains, power-loss safety, and operationally safe tamper response—without expanding into network security appliances or traffic inspection.

1) How do secure elements, TPMs, and HSMs split roles in edge devices?
A practical split is: a secure element anchors non-exportable root keys and policy-gated cryptographic operations; a TPM provides standardized attestation interfaces where TPM2.0 ecosystems are required; an HSM is typically chosen for higher assurance or higher throughput key services. The vault/log focus is “keys never leave + signed evidence,” not general platform security.
Mapped to: H2-1 / H2-3 · Example parts: ATECC608B, NXP SE050, OPTIGA Trust M; TPM: Infineon SLB9670VQ2.0
2) If data is “encrypted at rest,” why is that still not enough?
“Encrypted storage” only protects ciphertext on media; it does not solve key custody, key rotation, or host compromise. Key wrapping introduces a KEK/DEK boundary: DEKs are stored only as wrapped blobs bound to a KEK version and policy, so recovery restores wrapped state—not plaintext. This also enables controlled rotation and anti-rollback checks tied to counters and evidence logs.
Mapped to: H2-6
3) What are common field symptoms when a TRNG becomes unhealthy, and how should it degrade?
Unhealthy entropy often shows up as repeated or low-diversity challenges, key-generation refusals, or attestation/signing being blocked by policy—even when the rest of the device “looks normal.” A robust design runs startup and continuous health tests along the noise→conditioner→DRBG chain. On failure, the safest default is fail-closed for sensitive operations and a signed “entropy health” event appended into the same evidence chain.
Mapped to: H2-5
4) During KEK rotation, how can “old keys still work” or rollback bypass be prevented?
Rotation must be versioned and evidence-backed: every wrapped blob carries a KEK version and policy version; the secure element enforces allowed versions and rejects older blobs after a defined migration window. Rollback is blocked by monotonic counters and by logging “version mismatch/rollback detected” events. The key point is that rotation is an enforced policy state, not merely replacing a key file.
Mapped to: H2-6 / H2-7
5) In power-unstable edge sites, how is log continuity preserved and the “last record” protected?
Use an append-only format plus an atomic commit journal with explicit stages (e.g., PREPARE→COMMIT→SEAL). A short hold-up window (supercap/FRAM journaling) is used only to finish one atomic commit, not to power the system. If power fails mid-write, recovery emits a signed record describing the interrupted stage, so truncation is detectable and the chain never silently “looks clean.”
Mapped to: H2-7 / H2-9
6) Without a trusted RTC/time source, how can logs prove ordering and freshness?
Ordering is proven by a monotonic counter plus a previous-hash link (and signature/MAC) per block; this provides an unambiguous sequence even with no wall clock. Freshness is established later via time anchors: when a trusted time becomes available, the device appends a signed anchor record binding “counter range → time.” Verifiers then check continuity across anchors without assuming the host clock is honest.
Mapped to: H2-9
7) Tamper false positives are common—how should debounce and correlation be designed?
Treat sensors as noisy inputs and make policy decisions using debounce windows and correlation rules (e.g., 2-out-of-N within a time window, or threshold + persistence). The operational goal is to funnel uncertain events into “evidence-only” logging rather than destructive actions. Every tamper decision should be recorded with sensor source, confidence, and decision tier, so repeated nuisance triggers become diagnosable instead of mysterious.
Mapped to: H2-8
8) Must tamper always trigger zeroization? What tiered response is more operable?
Zeroization is not always the most operable first response because it is irreversible and complicates RMA. A practical tier model is: (1) Evidence-only—record and report; (2) Lockdown—block unwrapping/signing/attestation outputs while preserving evidence; (3) Zeroize—erase selected key tiers only under high-confidence conditions. The critical invariant is that the tamper decision itself is appended to the signed evidence chain.
Mapped to: H2-8
9) If the host is compromised, what is the worst it can do, and how does the vault limit damage?
A compromised host can spam requests, try policy edge-cases, and attempt rollback/truncation games—but it should not be able to extract plaintext keys. Damage radius is limited by handle-based APIs, least privilege, usage counters, and policy-gated operations (e.g., deny signing when tamper level is elevated or when anti-rollback counters mismatch). Every denied attempt should be a signed event, turning attacks into evidence rather than silent risk.
Mapped to: H2-10 / H2-2
10) What happens when append-only/WORM log storage is full? How can truncation/archival stay evidentiary?
Storage-full must not force silent overwrite. Instead, create boundaries with explicit closing records and export evidence bundles (blocks + anchors/checkpoints + closing record) for offline retention. Controlled truncation is performed only after a closing record is appended, so verifiers can prove where the chain ended and why. Quotas and event severity filtering keep the log useful while preserving security-critical events at highest priority.
Mapped to: H2-9 / H2-10
11) How can audits prove logs were not deleted or modified, and how can third parties verify independently?
Independent verification checks three invariants: (1) hash links are continuous (prev_hash matches), (2) signatures/MACs validate under the device identity, and (3) counters are monotonic with consistent closing records. Negative tests—delete a block, edit a field, truncate the tail—must fail deterministically and identify the first invalid block. This makes “tampering” a provable event rather than a suspicion.
Mapped to: H2-9 / H2-11
12) In RMA/repair, after replacing a board or storage, how should identity and evidence continuity be handled?
Board replacement often implies a new root identity, so continuity should be handled via sealed evidence packages rather than pretending it is the same chain. Before repair, export and seal the existing evidence bundle with closing records and identity references. After repair, the new device starts a new chain but can attach a signed “RMA linkage record” referencing the sealed prior bundle. This preserves forensic clarity without weakening key custody.
Mapped to: H2-4 / H2-11
Implementation note: keep each FAQ answer short and “verifiable.” Avoid platform-level topics (traffic inspection / SIEM workflows) to prevent cross-page overlap.
icnavigator

ICNavigator helps engineers find verified ICs, alternatives, and fast quotes.

Explore
Categories
  • Power Management
  • MCU
  • Automotive ICs
  • Sensors
  • Interface & Transceivers
  • Analog Front-End
Get in Touch
  • Email: hello@icnavigator.com
  • WeChat/WhatsApp: +86-xxxx

© 2025 ICNavigator. All rights reserved.