What is a replay attack, and why does encrypting a fixed command not prevent it?
The attacker records a valid message and sends it again later. If the same command always produces the same ciphertext, the attacker does not need to read it: resending the encrypted bytes works just as well. Only freshness (a nonce, counter or timestamp the receiver checks) stops replay.
Encryption protects confidentiality: an eavesdropper cannot read the message. A replay attacker does not care what the message says. They only need to know that "this packet opens the door".
Suppose the remote encrypts open with a fixed key and sends it. Every press sends the same ciphertext. The attacker records it and sends it later, the receiver decrypts it to open, and the door opens. An authentication tag (a MAC or HMAC) does not help either: it proves the message came from someone with the key, and the recorded message did.
What is missing is freshness: proof that the message was made now, for this request. The usual mechanisms:
| Mechanism | How it works | Receiver must |
|---|---|---|
| Nonce (challenge-response) | The receiver sends a random number, the sender includes it in the authenticated reply | Remember which nonces it issued and accept each once |
| Counter | Every message carries an increasing number | Store the last counter and reject anything not higher |
| Timestamp | Every message carries the time | Have a synchronised clock and reject old messages |
TLS and DTLS do this automatically: each session uses fresh keys from a handshake with random values, and records carry sequence numbers, so a recorded session cannot be replayed into a new one.
Go deeper:
Wikipedia — Cryptographic nonce — nonces against replay in authentication protocols.- Wikipedia — HMAC — what a message authentication code proves, and what it does not.