Replay Protection & Freshness
Overview
Replay protection ensures that a communication endpoint accepts only fresh messages — not old, duplicated, or reordered frames that an attacker could reuse to trigger unintended actions. Freshness is a fundamental property of secure protocols: even if a message is valid and correctly authenticated, it must be rejected if it is not new.
Replay attacks are simple to perform (capture → resend) but can have severe consequences:
- re‑issuing a command
- bypassing rate limits
- undoing a safety action
- injecting stale sensor data
- forcing state machine transitions
Replay protection mechanisms ensure that each message is accepted exactly once, in the correct order, and within a valid time window.
Threat Model
Replay attacks exploit the fact that:
- messages may be valid but old
- sequence numbers may wrap or desynchronize
- nonces may be reused
- endpoints may reboot and lose state
- attackers can capture traffic on the bus or PHY
Typical attacker capabilities:
- recording valid frames
- resending them at arbitrary times
- injecting them in bursts
- mixing replayed frames with fresh ones
- attempting to desynchronize counters
Core Mechanisms for Freshness
1. Sequence Counters
A monotonically increasing counter included in each message.
- Each new message increments the counter.
- The receiver tracks the last accepted value.
- Any value ≤ last accepted is rejected.
Strengths: simple, deterministic. Weaknesses: requires resynchronization after resets.
2. Nonces
Random values used once per session or per message.
- Prevent reuse of previous authentication material.
- Often combined with MAC/HMAC.
Strengths: strong protection against replay. Weaknesses: requires secure generation and distribution.
3. Timestamps
Messages include a time reference.
- Receiver checks if the timestamp is within an acceptable window.
- Requires synchronized clocks.
Strengths: good for distributed systems. Weaknesses: clock drift, synchronization attacks.
4. Sliding Acceptance Windows
Allows limited out‑of‑order delivery while still preventing replay.
- Accepts counters within a window (e.g., N+1 … N+W).
- Rejects anything behind the window.
Strengths: robust to jitter and reordering. Weaknesses: window size must be carefully chosen.
Replay Attack Examples
- Replaying a “start motor” command
- Re‑injecting stale sensor data to mislead control logic
- Replaying authentication tokens
- Re‑sending a “reset” frame to disrupt operation
- Replaying a valid message to force a state machine transition
Mitigation Architecture
Replay protection is typically implemented as a pipeline:
- Extract sequence ID / nonce
- Compare with expected value
- Check acceptance window
- Verify MAC/signature
- Update local state
- Deliver to upper layers
This ensures that even authenticated messages cannot be reused.
Figures
Figure 1 — Replay & Freshness Mechanism
Sequence counters and sliding windows ensure that only fresh messages are accepted, while replayed or stale frames are rejected.
Failure Modes & Edge Cases
Counter Wraparound
When counters reach their maximum value, wraparound must be handled securely.
Endpoint Reset
If one endpoint resets and loses its counter, resynchronization is required.
Message Loss
Sliding windows allow limited tolerance for dropped frames.
Clock Drift (for timestamp‑based systems)
Requires periodic synchronization.
Relationship with Other Security Mechanisms
Replay protection interacts with:
- Integrity protection (MAC/HMAC)
- Authentication (ensures replayed messages are not accepted as valid)
- Session management (counter alignment)
- State machine security (prevents forced transitions)
Replay protection is necessary but not sufficient: it must be combined with integrity and authentication.
