Replay Attack Prevention Animation

See why valid MACs still need freshness checks to stop captured IoT commands

animation
security
authentication
replay-attack
freshness
nonce
timestamp
sequence-counter
iot-security
interactive
A standalone replay attack lab with scenario, defense, replay delay, clock drift, window, and tamper controls; synchronized SVG packet flow; MAC and freshness decision trace; technical accuracy notes; common misreads; practice prompts; and mobile-friendly independent learning support.
Replay attack IoT authentication Freshness checks

A valid MAC does not prove a command is fresh.

Capture a real signed IoT command, send it again later, and compare how no defense, nonces, timestamps, sequence counters, and combined checks change the server decision.

Attack succeeds Replay result
No freshness Selected defense
Open window Replay opportunity
Execute command Server action

Replay Flow Controls

Change one variable at a time. The packet diagram, server checks, command record, and explanation stay synchronized so the failure mode is visible without reading ahead.

Authenticated command leaves the device

The device signs the action, device id, timestamp, nonce, and sequence counter. The command is legitimate on its first trip.

Replay risk high
Replay attack packet flow A signed IoT command travels from device to server while an attacker captures and replays the packet through MAC and freshness checks. IoT device door-sensor-07 adds MAC Attacker stores packet copy Server checks MAC first then freshness MAC valid Freshness missing EXECUTE replay signed command captured copy replayed after 45s Authenticated fields: action=UNLOCK, device=door-sensor-07, nonce=n-8451, ts=10:00:00, seq=418, mac=HMAC(...)
Message Contents

The freshness field must be inside the authenticated data. Otherwise it can be changed without invalidating the replay.

ActionUNLOCK_DOOR
Freshnessnone enforced
MACvalid captured HMAC
Server Verification

Replay prevention is a two-part decision: integrity/authenticity first, then freshness.

1
MAC passesPacket was copied without changing fields.
2
No freshness checkThe server has no state that marks this packet old.
3
Command executesThe replay triggers the same operation again.
Attacker Notebook

Stored packet: action=UNLOCK_DOOR, device=door-sensor-07, timestamp=10:00:00, nonce=n-8451, sequence=418, MAC copied intact.

Delay45 seconds
Payloadunchanged
Outcomereplay accepted
What To Watch
  • No defense: the replayed packet is unchanged, so the MAC passes and the action runs again.
  • Nonce: the server remembers that nonce and rejects the second use.
  • Timestamp: old packets are rejected, but quick replay can fit inside a permissive window.
Technical Accuracy Notes
  • Freshness fields must be authenticated with the command. A timestamp beside the MAC is not enough.
  • Sequence counters need persistent per-device state so reboot or failover does not accept an old counter.
  • Challenge-response nonces avoid long replay caches, but require the verifier to issue an unpredictable challenge.
Practice Prompts
  1. Set Timestamp and 5s. Explain why the replay may still pass.
  2. Switch to Combined. Identify which check stops the same replay.
  3. Turn on tampering. Decide whether the failure is an integrity failure or a freshness failure.
Common Misreads

"The MAC is valid, so the command is safe" is the trap. A MAC only says the message matches the key and fields. It does not say this is the first time the server has seen the message.

"Timestamps solve replay by themselves" is only partly true. They reject old messages, but they can still allow replay inside the accepted clock window unless paired with a nonce, counter, or idempotent command design.

Related Interactive Tools

Compare replay prevention with MITM Attack Animation, Symmetric vs Asymmetric, Diffie-Hellman Exchange, Device Provisioning Flow, and Zero-Trust Simulator.