Replay Attack

A replay attack is a form of network attack in which valid data transmission is maliciously or fraudulently repeated or delayed.

Replay Attack: Ocean's 11

Security cameras are monitoring a security-sensitive space. Guards in a remote control room watch video monitors to detect unauthorized access to the door. One can use the replay attack here to fool the guards:

Record and replay the innocent image to the monitors.

This attack was featured in the film Ocean's 11.

Rubber fingerprint attack

One can see that similar types of replay attack can be used to biometric authentication as well. A rubber fingerprint attack is a well-known attack.

Replay Attack on the Password-based Authentication

(source: from Wikipedia)

Suppose Alice wants to prove her identity to Bob. Bob requests her password as proof of identity.

Alice provides (possibly after some transformation like hashing (or even salting) the password).
Meanwhile, Eve is eavesdropping on the conversation and keeps the password (or the hash).
After the interchange is over, Eve (acting as Alice) connects to Bob; when asked for proof of identity, Eve sends Alice's password (or hash) read from the last session which Bob accepts, thus granting Eve access.

Encryption cannot fix this!

Note that the replay attack still works even if an encryption scheme is used instead of a cryptographic hash function (why?)

Other Replay Attacks

Reprocessed transactions. An unscrupulous merchant processes a credit card transfer on behalf of a user. After seeing that the transfer succeeded, the merchant resubmits another transaction on behalf of the user.
Of course, two identical transactions to one merchant would be noticeable and natural for the client to dispute. Nevertheless, possible repetitions of a transaction would be a vulnerability.
Remote keyless-entry system for vehicles. Many vehicles on the road use a remote keyless system, or key fob, for the convenience of the user. There have been replay attacks on this mechanism. For example, see the article about the vulnearability of Honda vehicles in 2022 (here).
Text-dependent speaker verification. Various devices use speaker recognition to verify the identity of a speaker. In text-dependent systems, an attacker can record the target individual’s speech that was correctly verified by the system, then play the recording again to be verified by the system.

See the Wikipedia page for more details.

Power of Replay Attacks

Please observe the following:

With a replay attack, the attacker need not know the content or format of a transmission. This means that replay attacks would even succeed on encrypted data without altering or breaking the encryption.

For example, consider the above scenario of the reprocessed transactions. This time, suppose a merchant has a credit card terminal with built-in encryption such that the user's card number, perhaps a PIN, the transaction amount, and merchant's identifier are encrypted and sent to the credit processing center. Even without breaking the encryption, a merchant who taps the communications line can repeat the same transaction message for a second transfer of the same amount.

When Would a System Be Vulnerable to Replay Attacks?

The vulnerability that the replay attacks exploit is:

The system cannot to detect whether a given data is fresh or stale (i.e., copied and reused).

Consider the case of password-based authentication. Alice sends a hash of the password to Bob. In this case, the credentials are static. Since the same credentials are repeatedly used even by Alice, Bob cannot detect whether the sent credential information is from Alice or from an attacker.

Countermeasure

We can address the vulnerability by enabling the system to tell whether a given data is old or not.

Clock. For the security camera example, if the security sensitive place has a clock, then monitoring guards will be able to notice when videos are replayed, since a replayed video will have old time.

One-time password

Another fix is to use a one-time password.

Hardware token

One-time passwords can be generated easily with a device token. However, there are disadvantages:

The user must have the token for each login.
The token must be synchronized to the access control service.
The tokens must be distributed and managed securely.
Tokens cost money.

Hash chains

Let pwd be the password.

A hash function H is applied repeatedly (for example, 1000 times) to the pwd.
```
hashes[0] = pwd
for i in range(1000): hashes[i+1] = H( hashes[i] )
return hashes[1000]
```
This value store = hashes[1000] is stored on the target system.
The user's first login credential cred is hashes[999].
The target system checks if store = H(cred) holds. The user will pass the check since store is hashes[1000] and hashes[999]. At this moment, the target system sets store := cred.
Next time when the user logs in, the user will use hashes[998] as the credential.
This way, for 1000 times, the credential is always different. The system will require the user to change the password before exhausting 1000 login credentials.

In the above, we had the user store the array hashes, which could be too cumbersome for the user. This can be fixed easily. Instead of storing the entire array contents, the user can always compute the necessary credential, using a simple for-loop, if he knows the pwd.

Challenge and response

Let cred be the credential stored in the target system. Then, the following protocol could also be used to protect against replay attacks:

The target system chooses a random challenge r and send it to the user.
Then, the user sends the following message answer: H(r + cred)
Since the target system also stores cred, it can check the validity of answer by computing the hash on its own.

In the above protocol, the fact that r will be different for each login implies that the answer would also be different. Therefore, the replay attack can be avoided.

Sequence Number and Nonce

Sequence number

Recall that the TCP protocol uses sequence numbers to ensure liveness in a communication session. This idea can be applied to other protocols to avoid replay attacks.

The hash chain protocol in the above implicitly uses a kind of sequence number.
The challenge-response protocol should also work even if a sequence number is used.

However, you need to design a protocol carefully so that it has a strategy to handle missing sequence numbers.

Nonce

A nonce is an arbitrary random number. So, we used a nonce in the challenge-response protocol in the above.

Some tips:

In some cases, simple nonces would be enough to protect against replay attacks.
However, that may not be the case -- you must carefully check the security of the overall protocol. For example, the above challenge-response protocol is slightly changed as follows:
- The random number is chosen by the user instead of the system.
This modified protocol will be broken by the replay attack, unless the system stores all nonces used so far, which would be impractical if there are many users.

Use of Cryptographic Tools

Note that we only considered a single kind of attack. However, the attacker will not be so simplistic --- it will probably use more sophisticated attacks combining many techniques. So, the system may need to use other cryptographic tools to provide the security of the system.