Security-Coupled Supervisor for Reset-Lock, Key Window, and Tamper/Zeroize
← Back to: Supervisors & Reset
What It Solves
Map attack surfaces → risks → capability hooks so the supervisor is security-coupled (not generic). Attack surfaces: brown-out glitch, reset-storm, replay/rollback, physical tamper, and power-fail evidence loss. Required conclusion: Reset-Lock + Key Window + Tamper→Zeroize + Power-Fail Evidence.
Early reset release → unauthorized code runs.
Key-load window hijacked or delayed.
No zeroize after tamper; secrets persist.
Power-fail evidence missing; no forensic trail.
Cold boots occasionally “run wild”.
Auth_OK arrives late vs PG threshold.
Tamper false positives or missed events.
Random outages leave logs empty.
Reset-Lock: PG → SE_OK → MCU release chain.
Key Window: enforce t_key[min,max] with over/under-window policy.
Tamper → Zeroize: one-shot or latch-off with controlled recovery.
PG/FAULT as Signal: storm counting, debounce, min pulse width.
Power-Fail Evidence: minimal forensic log + monotonic counter.
KPI targets — FPRrelease ≤ 1e-6/boot · Log success ≥ 99% at typical dV/dt · Tamper→Zeroize latency ≤ target ms · Counters strictly monotonic.
| Risk | Symptom | Primary Hook | Secondary Hook | Acceptance |
|---|---|---|---|---|
| Early release | Code runs before auth | Reset-Lock | Key Window | FPRrelease ≤ 1e-6/boot |
| Key-window hijack | Auth_OK late/spoof | Key Window | PG/FAULT gating | t_key[min,max] enforced |
| No zeroize after tamper | Secrets persist | Tamper→Zeroize | Latch-off | ttz ≤ target ms |
| Power-fail evidence loss | No log on outage | Power-Fail Evidence | Reset-storm counter | Log success ≥ 99% |
| Replay/rollback | Non-monotonic events | Monotonic counter | Signature chain | Counter strictly increasing |
Threat-Driven Requirements
Convert threats into measurable engineering requirements and output semantics (OD/PP, PG/FAULT, latch/one-shot). Use parameters and acceptance criteria that are copy-ready for bench validation.
Set dVdt_max, t_min_glitch, and hysteresis; prefer OD for cross-domain safety.
Acceptance: no early release at ns injection; FPRrelease ≤ 1e-6.
Separate trip vs release (Schmitt), add debounce and min PG pulse.
Acceptance: t_release ≥ t_pg + t_auth across slow ramps/ringing.
Gate N/s, count, backoff or latch; write minimal event log during storms.
Acceptance: maintains secure state; logs complete.
Use monotonic counter + signature chain; size power-fail write budget.
Acceptance: counters strictly increase after power cycles.
Multi-source arbitration; one-shot zeroize or latch-off with controlled recovery.
Acceptance: t_tz ≤ target ms; audited recovery path.
Starting points — Entry: t_min_glitch=80–120 ns, Hyst=30–60 mV, PG_min_pulse=5–10 µs, N_reset/s≤4, Backoff=200–500 ms.
Automotive-Q: t_min_glitch=150–250 ns, Hyst=60–120 mV, PG_min_pulse=20–40 µs, N_reset/s≤2, Backoff=1–2 s, storm latch=Y.
High-Security: dynamic t_key, Zeroize=full, Monotonic≥32b.
Reset-Lock Order & Key Windowing
Define an auditable release sequence VIN → PWRGOOD → Auth_OK → MCU_RST_RELEASE. Authentication must complete within the window
[t_key_min, t_key_max]; outside the window, the system stays locked or enters a degraded / zeroize path. Handle slow ramps with
PG debounce, hysteresis and a minimum pulse width to avoid “pre-authorized” releases.
Run power ramp and authentication in parallel. Supervisor releases MCU_RST only when Sys_PG is valid and Auth_OK arrives within t_key.
Budget guideline: t_release ≥ t_pg + t_auth, with overlap to approach “zero added delay”.
Aggregate multi-rail PG into Sys_PG with hysteresis, debounce, and PG_min_pulse.
Avoid half-release under slow ramps, ringing and coupled noise.
A short-lived cache (monotonic counter + signature) may accelerate success, but is ignored until the key window opens.
Under-window/over-window policy dictates degrade or zeroize actions.
t_key_min, t_key_max, t_key_policy(over/under) ·
PG quality: Hyst_mV, Debounce_us, PG_min_pulse · Reset: PW_reset_min ·
Security: FPR_release ≤ 1e-6/boot, KeyFail_N → Degraded/Zeroize.
Verification — Inject 50–200 ns glitches during t_key; measure mis-release probability and latch paths. Sweep slow ramps (0.1–5 V/ms) with 5–10% ringing; confirm no half-release.
Replay reset-storm (1–5 Hz for 60 s); gating and window logic must hold. Pre-Auth replay must be ignored before window, and monotonic counters must pass.
Tamper & Zeroize Triggers
Define sources → arbitration → actions. Sources: enclosure open, RTC loss, probe/address conflict, authentication fail N times, PG/FAULT storms. Actions balance availability and evidence: one-shot zeroize (self-recover) vs latch-off (manual/signed recovery).
Chassis open / intrusion; RTC lost; probe / I²C address conflict.
Auth failure N times; PG/FAULT storm (rate exceed).
Multi-source OR with weight/grade. Enter Suspicious with debounce and K-of-M concurrence, then decide Tampered.
Keep an auditable path: event ID, monotonic counter, signed chain.
One-shot zeroize: wipe keys, allow automatic reboot.
Latch-off: set latch bit, require manual or signed recovery.
Tamper_Debounce_ms · Concurrence: MultiSource_K ·
Modes: Zeroize_Mode(partial/full), Latch_Release(manual/signed) · Timing: t_tz, t_recover_min ·
Evidence set: Event_ID, Monotonic++, Cause_Code, Sig_chain.
Experiments — Repeat tamper with forced power loss; counters must remain strictly monotonic and signatures chained.
Evaluate false positives across noise/vibration/thermal shocks; tune Tamper_Debounce_ms and MultiSource_K.
Under PG/FAULT storms, confirm transition through Suspicious to Tampered with the selected zeroize/latch policy.
Verify both one-shot and latch-off recovery flows are auditable.
Security-Aware Reset Tree
Build the reset tree with security semantics: choose OD for cross-domain safety and wired-AND, use PP only in single-domain paths with verified no back-power; define a latch branch for audit; aggregate SE_OK → Latch → MCU → Peripherals; and keep deterministic behavior under EM/ESD/surge (no chatter, no early release).
OD: avoids back-power; simple level adaption via pull-up to {1.2/1.8/3.3/5V}; supports wired-AND.
PP: same-domain only; use level shifters/isolators across domains.
Respect Fanout_N_max, C_bus_max, R_pull_range; insert reset buffers/fanout gates when limits are exceeded.
Edge quality = f(R_pull, C_bus, temperature, voltage).
A high-priority latch line (OD) gates the tree. Release requires manual or signed process.
Record Event_ID, Monotonic++, Cause_Code for compliance.
Back-Power_max(µA), Level_xfer(type) ·
Fanout: Fanout_N_max, C_bus_max(nF), R_pull_range(kΩ), Slew_min(V/µs), PW_min(µs) ·
Latch: Latch_assert_time(µs), Latch_release(manual/signed) · Determinism: Err_release_rate ≤ 1e-6/boot, Glitch_reject(ns).
Measurements — Back-power current; edge slew vs R_pull/C_bus; fanout limit; cross-domain coupling under ESD/EFT/Surge; verify latch asserts and requires manual/signed release.
Event Logging & Power-Fail Evidence
Before power is lost, write a minimal auditable set with high success: Event_Type, Counter, Time_Base (monotonic tick if no RTC), and Signature/Hash. Trigger on PG falling, buffer to a ring, and commit with a short idempotent write (mirror slots). Prefer FRAM; use EEPROM with wear leveling; add hold-up capacitance if needed.
Fields: Event_Type, Counter++, Time_Base, Sig.
Chain signature: Sig = H(Prev_Sig || Record).
Dual-slot mirror: prepare → payload+sig → atomic flip.
Ring buffer with CRC on Head/Tail; priority drop oldest/low-priority when full.
Verify signature chain and monotonic counter on boot.
Reject stale mirrors; enter controlled recovery with Cause_Code.
Log_Success ≥ 99% (FRAM ≥ 99.9%) · t_commit(µs) within hold-up budget ·
Counter strictly increasing across boots · Sig_chain_valid under replay attempts · EEPROM_Wearout_life ≥ lifetime×SF.
Experiments — Random pull power at varying dV/dt/temperature/load; measure Log_Success and Sig_chain_valid.
Simulate page-tear at each phase; ensure idempotent recovery. Under PG chatter, confirm debounce/merge does not drop key events. Replay old mirrors → expect rejection and controlled recovery.
Selection & Cross-Brand Mapping
Select supervisors by security-coupling capability: accurate window trips, programmable delay/window/latch, open-drain (OD) reset for cross-domain fanout, auditable PG/FAULT semantics (counter, debounce, minimum pulse), explicit Security Hooks (Tamper_In, Zeroize_Out, SE_OK/Auth_Fail), EMC hardening, AEC-Q100 grade, and healthy lifecycle.
| Capability Tier | Trip Model | Programmability | Reset Output | PG/FAULT Semantics | Security Hooks | Hardening | Grade & Package | Lifecycle |
|---|---|---|---|---|---|---|---|---|
| Baseline | Fixed UV/OV; accuracy (±%); hysteresis (mV) | Fixed delay (OTP bins) | OD preferred; PP same-domain only; fanout within spec | Minimum pulse; basic debounce | — | IEC/ISO basic; dV/dt tolerance noted | AEC-Q100 grade; temperature; package | Not NRND/EOL; alternative PN exists |
| Programmable | Window UV/OV; tighter accuracy; settable hysteresis | I²C/PMBus or fine OTP; delay/window; latch/one-shot | OD; verified cross-domain; buffered fanout | Counter; debounce (µs); min pulse (µs) | Optional Tamper_In / Zeroize_Out | IEC 61000-4-2/-4-4; surge notes | AEC-Q100; multiple packages | Multi-source family |
| Security-Coupled | Tight window; authenticated release gating | PMBus/I²C policy bits; audit latch | OD tree + latched gate; cross-domains verified | Counters; debounce/merge; evidence hooks | Tamper_In, Zeroize_Out, SE_OK/Auth_Fail, irreversible latch | Automotive EMC set; dV/dt budgeted | AEC-Q100 Grade 0/1; −40~125/150 °C; robust packages | Healthy roadmap; second-source mapping |
TPS3702-Q1 — high-accuracy window detector, OD outputs (good for cross-domain tree); TPS3890-Q1 — 1% precision with programmable delay (helps slow ramps).
Rationale: clear accuracy/hysteresis, low Iq, strong automotive coverage; easy to gate Reset-Lock with Auth_OK.
FS6500 (SBC with multi-rail PG/Reset IO); FS6500/FS4500 Datasheet; A5000 EdgeLock (Auth_OK/Auth_Fail source).
Rationale: system PMIC + security device combo enables Reset-Lock and Key Window policies.
NCV809 (3-pin reset monitor, OD output).
Rationale: simple and robust; good as trunk/branch monitor in the reset tree.
MLX92251 (Hall dual-latch; usable as Tamper_In trigger).
Rationale: automotive-grade sensing with strong EMI immunity; ideal for cover/open detection.
Bring-Up & Validation
Convert the threat model into bench scripts and pass/fail criteria: brown-out sweep (dV/dt vs PG hysteresis), ns-glitch injection within t_key, reset-storm throttling with counters/alarms, and anti-replay monotonicity on the evidence chain. Capture time, configuration, signature, and waveforms.
- Scan dV/dt and steps; measure PG hysteresis and minimum pulse
- Verify “no early release”; log threshold drift vs temperature/load
- Inject 50–200 ns pulses on PG/RESET/Auth within t_key
- Observe latch/zeroize hit rate and false-release rate
- 1–5 Hz for 60 s; throttle/counter/alarm threshold (N/s)
- No early release after threshold; produce auditable record
- Power cycles; counter and signature only increase
- Old mirror rejected; controlled recovery with cause code
FPR_release ≤ 1e-6/boot · Log_Success ≥ 99% (FRAM ≥ 99.9%) ·
Auth_OK ∈ [t_key_min, t_key_max] ≥ 99.5% · N/s throttle active with audit record · Sig_chain_valid under replay.
Evidence Log Template — TimeBase/RTC: ____ ; Rail: ____ ; Trip/Window: ____ ; Delay: ____ ; Latch: ____ ; t_key: [__, __] ; Stimulus: ____ ; KPIs: FPR=____ ; Log_Success=____ ; Counter→____ ; Sig=____ ; Waveform link: ____
BOM & Procurement Notes
Use this copy-ready structure to request small-batch quotes while keeping reset semantics and security hooks intact. Fill one row per rail or per supervisor device. Prefer open-drain outputs for cross-domain trees, and specify audit/latch policies explicitly to avoid ambiguous substitutions.
| V_rail | n_rails | Threshold Tolerance | Policy (Latch/One-shot) | Output (OD/PP) | AEC-Q100 Grade | Package Height | Second-source (Y/N) |
|---|---|---|---|---|---|---|---|
| 3.3 V | 1 | ±1% window; 50 mV hysteresis | Latch-off | OD; fanout ≤ 5; cross-domain = Yes | G1 (−40~125 °C) | ≤ 1.0 mm | Y |
| VBAT 12 V | Multi-rail (PG aggregated) | ±1.5% window; 80 mV hysteresis | One-shot zeroize | OD; buffered; cross-domain = Yes | G0 (−40~150 °C) | ≤ 1.2 mm | Y |
- I²C/PMBus (Y/N; address; write-protect)
- PG/FAULT semantics (counter; debounce µs; min pulse µs)
- Security hooks (Tamper_In; Zeroize_Out; SE_OK/Auth_Fail)
- dV/dt requirement; surge/ESD notes
- Pin/semantic mismatch → verify polarity; prefer OD; add level shifting/buffer
- EOL/NRND → lock current rev; prepare second-source mapping
- Samples/MOQ → allow cut-tape or split shipments
- Key-window drift → validate −40~+85 °C; document t_key budget
- Back-power via PP → series resistor/diode clamp; isolate domains
- PG/FAULT storms → debounce, min-pulse, rate gate (N/s)
- Log monotonicity → FRAM/EEPROM short-write; counter+signature chain
Have a mixed-brand requirement or tight ramp schedule? Send your BOM and we will map cross-brand supervisors while preserving reset semantics and security hooks.
Submit your BOM (48h cross-brand mapping)Request a Quote
Frequently Asked Questions
How do I lock reset until the key is validated without adding boot latency?
Use a parallel handshake: aggregate PG signals, pre-authenticate in a side channel, and gate reset release with Auth_OK through an open-drain tree. Enforce debounce and minimum-pulse on reset so brief glitches do not free the CPU early. Preload configuration in OTP/I²C to avoid extra firmware delay.
What’s a safe power-up key window to resist brown-out glitch attacks?
Define a bounded window long enough for authentication yet short enough to limit attack surface. Typical designs reserve tens of milliseconds with dV/dt limits and window hysteresis. Validate by injecting 50–200 ns glitches inside the window and prove zero early-release events under temperature and load corners.
When should latch-off be preferred over one-shot zeroize after tamper?
Choose latch-off when evidence preservation or human inspection is required before re-enable. Use one-shot zeroize when availability is critical but secrets must be cleared immediately. In both cases, log the event and require a signed or physical recovery path to prevent silent re-arming after tamper.
How do I route Auth_OK/Fail into a mixed-voltage reset tree safely?
Use open-drain signaling with per-domain pull-ups and, where needed, level shifters or buffers. Avoid push-pull across domains to prevent back-power. Define polarity and minimum-pulse constraints, and verify fanout limits so Auth_Fail cannot be masked by capacitance or simultaneous transitions.
What minimal power-fail log is still forensically useful without a secure RTC?
Record an event code, a monotonic counter, a coarse timebase tick, and a cryptographic digest over the previous state. Use FRAM or EEPROM with a short-write, idempotent update. On boot, verify the counter increases and the digest chain is valid before trusting stored state or keys.
Can PG/FAULT storms serve as tamper signals, and how do I debounce them?
Yes. Treat repeated PG/FAULT edges as a rate-based tamper source. Add a debounce filter, a minimum-pulse constraint, and a sliding-window counter with a threshold in events per second. When exceeded, enter a controlled state, record the cause, and, if required, trigger zeroize or restricted boot mode.
How do I prove monotonicity of logs with only a coarse timebase?
Rely on a strictly increasing counter stored with each entry and protect it with a rolling message digest that commits to the prior state. Reject any record where the counter does not advance or the digest mismatch occurs, and annotate recovery so auditors can trace gaps or rollbacks.
Which OD vs PP choice minimizes back-power on multi-domain resets?
Use open-drain with per-domain pull-ups and buffering at boundaries. Avoid push-pull across domains because its high state can feed a powered-down rail. Where legacy PP exists, insert series resistance or a unidirectional clamp to block parasitic current and verify leakage over temperature extremes.
How tight must key-window thresholds be across −40~+85 °C?
Budget the window using trip accuracy, hysteresis, oscillator tolerance, and authentication worst-case time. Many designs target a guard-band of 20–30% beyond typical latency. Validate by temperature sweeps while applying supply ramps and injected glitches; release must never occur before successful authentication.
How to specify surge/ESD so security hooks remain deterministic?
State IEC 61000-4-2 and -4-5 levels, the allowed residual at the supervisor pins, and the minimum-pulse guarantee for reset and tamper lines. Add dV/dt limits during brown-out tests. Confirm filtering or TVS placement does not stretch pulses below detectability or create false release conditions.
What makes a supervisor “security-coupled” vs a standard programmable one?
It exposes explicit security hooks—Tamper_In, Zeroize_Out, and Auth_OK/Auth_Fail—plus audit latches and programmable semantics for debounce, minimum pulse, and release. It integrates with mixed-voltage reset trees without back-power and supports evidentiary logging so decisions are reconstructable after power loss.
How do I plan cross-brand migration while keeping reset semantics stable?
Normalize polarity and open-drain routing, match minimum-pulse and debounce parameters, and keep window and hysteresis definitions equivalent. Where features differ, add small glue logic or buffers. Re-validate key-window behavior, fanout limits, and tamper semantics across temperature and ramp profiles before releasing to production.
