OSCORE Replay State Across Reboots: Preserve Security Context Without Reusing Sender State

Restoring an OSCORE key is not enough to restore a safe connection. Before allowing protected traffic after reset, establish how the endpoint prevents reuse of sender state and how it rejects requests already accepted before the reset. Treat those as two separate recovery gates.

This article is a qualification procedure for pairwise OSCORE under RFC 8613. It does not specify a new nonce algorithm, key-establishment protocol, or universal persistence API. Pin the OSCORE library revision, configuration, cryptographic backend, storage implementation, and recovery mechanism used by both peers. Group OSCORE and implementation-specific context transfer need their own review.

1. Inventory the state by role

RFC 8613 section 7.5 identifies Sender Sequence Number and Replay Window loss as reboot hazards. Reusing a partial stored context must neither reuse a previous Sender Sequence Number nor accept previously received messages. The RFC offers recovery alternatives; it does not make an arbitrary saved counter sufficient. See OSCORE context-loss requirements.

Build a state ownership sheet before changing firmware. For each security context, identify the component that allocates sender sequence values, the component that makes receive replay decisions, and the component that persists recovery information. A device can act as both client and server. Do not assume that protecting its outgoing telemetry also protects its incoming configuration requests.

Evidence item	Question to answer
Context identity and lifecycle.	Which stored record selects this context, and can rollback or cloning select an older instance?
Sender-state recovery.	What proves that post-reset allocation cannot repeat previously used sender state?
Recipient replay recovery.	What prevents a previously accepted protected request from reaching the application again?
Storage completion boundary.	Which completion event means the recovery record survives the stated reset model?
Observe or pending exchanges.	Which registrations and bindings are invalidated or explicitly recovered?
Failure handling.	Does uncertainty block traffic, or does the implementation silently initialize state?

Record opaque context labels and state transitions in test logs. Do not export keys, master secrets, raw credential stores, or production provisioning material to make this sheet.

2. Qualify the sender gate against actual storage failures

RFC 8613 Appendix B.1.1 illustrates reserving sequence space using nonvolatile storage and a forward margin. Its method must not be used if the post-reboot value cannot always exceed the last value used. Storage delay and failure are explicit concerns in the appendix. See the sender recovery example and its limits.

Use that as a review obligation, not a formula to paste into an unrelated flash driver. Ask the library maintainer which persistence contract its recovery path requires. Trace the contract through any work queue, filesystem cache, flash controller, and power-loss boundary. A successful enqueue is not evidence that the recovery record is durable.

The useful invariant is observable: after any supported interruption, no protected message uses sender state already consumed under the same applicable cryptographic context. Establish the comparison in a controlled test harness without logging secret material. Include repeated resets before the first successful post-reset write; one clean reboot is a weak test.

Also inspect exhaustion and storage-error paths. A reserve-ahead design consumes sequence space even when some reserved values are never transmitted. The product must have a documented way to stop and recover before its supported sequence space is exhausted. Resetting the counter to regain capacity is not a recovery strategy.

3. Qualify the receive gate independently

A sender-safe reboot can still reopen the receive side to old requests if the replay window is forgotten. Capture a permitted synthetic request that causes a visible, harmless application event, reset the recipient, and replay that same protected request. The acceptance oracle counts application dispatches, not merely network responses.

RFC 8613 Appendix B.1.2 describes a protected Echo-based replay-window recovery path, including special response processing. Appendix B.1.3 describes forgetting old Observe registrations and registering again. Use the library’s reviewed implementation of the applicable path; a generic unprotected challenge is not a substitute. Echo’s final specification is RFC 9175.

If recovery establishes a new context instead, require evidence that the supported establishment process completes on both peers and meets the uniqueness requirements in RFC 8613 section 3.3. Renaming a local record or toggling a “new session” flag does not establish new cryptographic state.

4. Use a reset acceptance matrix

Injected condition	Required product outcome
Reset after a durable reservation, before transmission.	Resume only through the documented sender recovery path; skipped values are acceptable within its limits.
Reset while recovery storage is delayed or failing.	Demonstrate the proven forward bound, or block protected sending.
Recipient replay information is unavailable.	Keep application delivery gated until the supported receive-recovery procedure succeeds.
Older persistent image is restored.	Detect or otherwise safely handle rollback under the declared threat model; do not assume ordinary reboot coverage proves this case.
Only one peer completes context recovery.	Show a bounded failure and a defined reconciliation path, without silently weakening validation.
Recovery is interrupted repeatedly.	Maintain both safety gates without unbounded writes, allocation, or automatic retries.

These are proposed qualification outcomes, not results from a tested product. Run interruption tests only on an isolated fixture with synthetic credentials and recoverable storage images. Preserve the original production data and provisioning process.

Hypothetical reboot failure

A sensor saves its context keys during commissioning and periodically checkpoints other settings. After a brownout, its OSCORE wrapper reloads the keys and initializes the sender counter and receive window as if commissioning had just happened. Ordinary connectivity tests pass because a new request receives a response.

The reset fixture reveals the missing contract: the new sender state may overlap earlier traffic, and a captured old command may again reach the application. The corrective decision is to select and qualify a supported context-recovery mechanism, not to increase the settings checkpoint frequency and hope the gap is small enough.

Release evidence should include both gate owners, interruption points, application-dispatch observations, storage failure behavior, and the peer compatibility matrix. A passing reboot test covers that implementation and reset model. It does not establish secure boot, physical rollback resistance, credential lifecycle security, or complete product security.