Addressing the Delayed Message Attack in Wireless IoT Environments

	Author:	“Sergeant Major” Hare
	Job Title:	Security-Enforcing Developer
	Hobbies:	Disciplining, More Disciplining, Even More Disciplining

While many years have passed while we’re waiting for IoT to take over the world, there are some recent signs that it might indeed eventually happen. With this in mind, issues related to IoT security tend to become more and more important. In this article, we won’t be talking about current IoT security practices, which are, unfortunately, very poor by security community standards. In particular, we won’t talk about ZigBee security, which is atrociously bad, with keys being passed in plain over the wireless channel [Peterson][Lomas]. However, even if your channel encryption and key exchange is reasonably secure (for example, you’re using TLS, which has its own share of problems, but is still light years ahead of passing-key-in-plain, or you’re using protocols such as [SPINS] or [SimpleIoT-SP]/[SimpleIoT-Pairing]), there are still major caveats to be kept in mind.

One such issue which can hit security of your system even if both your key management and channel encryption are perfectly invulnerable, is the delayed-message attack which we will discuss in this article.

The Task at Hand

Let’s consider designing a system which has to implement one very common task: to provide a keycard (or password) entry to your house, with the controller being at home, and communication between the controller and lock being communicated over the wireless channel. For this exercise, we will assume that the TLS we’re using is perfectly unbreakable, and that the necessary keys have already been shared between the controller and the lock in a perfectly secure manner.

Protocol v1 – Building out of Existing Components

With such a simple and obvious task in hand, we can design our system using existing software protocols and libraries. If our lock is powerful enough to support TCP, the most obvious Protocol Specification will look as follows:

• The User enters her credentials
• The Lock establishes a TCP connection with the Controller
• The Lock initiates an Authentication Exchange with the Controller over the TCP connection
• If, as part of the Authentication Exchange, the Lock receives an Authentication-Ok message, it opens.

Here, if the User Credentials is a KeyCard, entering the credentials becomes inserting/swiping the KeyCard, and the Authentication Exchange may look, for example, as (follows):

• The Lock sends a message to the Controller that it wants to authenticate
• The Controller generates crypto-quality Nonce, and sends it to the Lock
• The Lock passes the Nonce to the Keycard, which encrypts it using the keycard’s private key, obtaining Encrypted-Nonce, and passes it (alongside with Keycard-ID) back to the Lock
• The Lock receives the Encrypted-Nonce and Keycard-ID from the Keycard, and sends them as a message to the Controller
• The Controller decrypts the Encrypted-Nonce using public key which corresponds to received Keycard-ID, checks that the decrypted Encrypted-Nonce matches the original Nonce, and sends an Authentication-Ok message back

If passwords are in use rather than keycards, then entering credentials becomes entering a Password (PIN etc.), and the Authentication Exchange may be defined, for example, as follows:

• Establish TLS connection over TCP, with the Controller acting as TLS server (with the Controller certificate already present in the Lock), and the Lock acting as TLS client
• The Lock sends the Password over TLS connection
• The Controller receives the Password, checks it against the (preferably hashed) password DB (database?), and (if the passwords match, the rate limit is not exceeded, etc.) responds to the Lock with an Authentication-Ok message.

As it will be shown below, for our purposes it doesn’t matter if these authentication methods can be attacked; improving them won’t help against the attack we’re considering, so we won’t go into further details about them. The only thing which really matters for our purposes is that the Authentication Exchange contains some kind of Authentication-Ok message which is passed over TCP which in turn is passed over the wireless channel.

Delayed-Message Attack

So, in our protocol design we’re using bulletproof key exchange mechanisms, impregnable cryptography, and foolproof authentication schemas; does it mean that our system is secure? Not exactly.

Let’s consider an Attacker, who has listened to the wireless exchanges when the lock opens, and has found out the frequency where these wireless exchanges happen, and the number of packets exchanged in authentication (i.e. the Attacker knows which message is Authentication-Ok message). Attacker doesn’t need to know exactly what the Authentication-Ok message is, but he needs to be able to guess correctly which of the wireless packets contains Authentication-Ok message).

Then the Attack is mounted as follows:

• The Legitimate User comes in and inserts her KeyCard (or enters Password) into the Lock
• Attacker listens to the wireless exchanges, and when all the packets except for the Authentication-Ok message go through, he starts to jam the wireless exchange frequency
• Our system becomes stuck in the following state:
  • The Controller application (from its perspective) has already sent the Authentication-Ok message, so it is out of the picture
  • However, Authentication-Ok message still sits within the TCP stack Controller-side, and the TCP stack on the Controller side keeps retransmitting the data at regular intervals¹
  • The Lock is still in the middle of Authentication Exchange, waiting for Controller’s decision whether it should open.
  • The Legitimate User is waiting for the Lock to open.
• After some minutes of waiting, the Legitimate User gives up and goes away (goes over the fence, uses another entrance, etc.).
• As soon as the Legitimate User is out of sight, Attacker removes jamming from the wireless exchange frequency
• After some time (with the maximum being the same time which the Legitimate User has waited), TCP makes its next retransmit, which this time reaches the Lock, which opens.
• Attacker can enter

Differences from the Replay Attack

It should be noted that Delayed-Message attack is fundamentally different from the classical Replay Attack. There is no replay in the attack above – Attacker is not replaying an old message, he is just delaying it (until the moment-which-is-convenient-for-him). That’s why none of the replay protection mechanisms (TLS ones or any others) will help to prevent the attack described above.

Attack Variations

In general, the attack described above, will work in any environment where (a) there is an automated retransmit of packets; and (b) there are no measures to prevent the attack. It means that replacing TCP with, say, reliable UDP library, won’t help. However, non-reliable UDP may help if the attack is performed exactly as described above – that is, if the underlying protocols don’t retransmit on their own²

Moreover, more generally, any protocol which has Authentication-Ok message is vulnerable to this attack (unless prevention/mitigation is in place as described below), regardless of packets being retransmitted, with only a minor complication to the Attacker. For example, if we use unreliable UDP, Attacker could modify his attack to add sniffering of the Authentication-Ok message (while preventing the Lock from receiving it), and replaying this Authentication-Ok message later³; while admittedly somewhat more complicated to mount in practice, it is still perfectly feasible in most environments.

Practical Implementations

There is at least one known practical implementation of the Delayed-Message Attack. As described in [Wired], RollJam device by Samy Kamkar, improving on the work of [SpencerWhyte], manages to catch the message sent by your electronic key to the car, while blocking the car from receiving the message⁴. As soon as it is achieved (which looks as a simple “it didn’t work” for the victim), RollJam manages to keep one of “rolling codes” for itself, while using an old code to keep the system working (car opening etc.) for the victim.

Protection from RollJam would require cars (and garage door openers) to use real request-response protocol (then the attack won’t work as described), with further protections described below.

Note that while RollJam has caused quite a lot of discussions in the community, the problem with Delayed-Message Attacks is much wider than car locks, and (as discussed above) it can be applied in many scenarios other than simple rolling codes, including request-response scenarios.

Protocol v2a – Preventing the Attack

As we have seen, it is not TCP who’s guilty here. Neither is TLS or nonces – even if these models are perfectly solid, the Attack still applies. The whole Attack is related to a subtle interplay of timings and Legitimate User expectations, which are beyond classical channel protection (including replay protection). We’re sure that the Attack should be addresses at application level (more precisely – within the authentication routine), not at the transport level.

Fortunately, preventing the Attack at the application level is not too difficult. In theory, the best way would be to make sure that the User is still in front of the Lock when Authentication-Ok message arrives. In one example, if KeyCard is in use, the Lock may generate Nonce2, ask the KeyCard to encrypt it (just as what was done for Nonce), and to check that Encrypted-Nonce2, after decrypting with public key of the KeyCard, matches the original Nonce2. Note that for this to work, the Controller will need to pass KeyCard’s public key to the Lock (in Authentication-Ok message or before), and the Lock should be powerful enough to perform the public cryptography; also Nonce2 may be passed by the Controller too (to avoid random generation Lock-side).

In this case, our Protocol may become the following:

• The User enters her credentials (inserts KeyCard)
• The Lock establishes a TCP connection with the Controller
• The Lock initiates an Authentication Exchange with the Controller over TCP connection
• If, as a part of the Authentication Exchange, the Lock receives an Authentication-Ok message (which contains Nonce2 and Public-Key of the KeyCard), it:
  • passes Nonce2 to the KeyCard, which encrypts it, and passes Encrypted-Nonce2 back to the Lock
  • decrypts the Encrypted-Nonce2 with a Public-Key
  • checks that the decrypted Encrypted-Nonce2 matches Nonce2
  • if everything is ok – the Lock opens, otherwise it treats authentication as failed, and becomes ready to accept new credentials

Protocol v2b – Mitigating the Attack

As a mitigation measure (which in practice can be as good as prevention), one can go a much simpler route: by restricting the time the whole Authentication Exchange (from the moment when the Legitimate User has presented her credentials, to the moment of receiving Authentication-Ok message) is allowed to take, on Lock-side. If we’re talking about real-world Locks, we can realistically expect that in 0.1 seconds after the Legitimate User has presented her credentials, she will still be in front of the Lock. Increasing the time to 1 second probably won’t hurt either in most cases, but going above 10 seconds might be risky in some environments.

It is important to note that if timeout has expired, it is not sufficient to initiate a new exchange with the Controller; it is necessary to ask the Legitimate User to enter her credentials once again.

Therefore, our modified Protocol may look as follows:

• The User enters her credentials, the Lock remembers time t0
• The Lock establishes a TCP connection with the Controller
• The Lock initiates an Authentication Exchange with the Controller over the TCP connection
• If, as a part of the Authentication Exchange, the Lock receives an Authentication-Ok message, it:
  • checks that the elapsed time between now (the moment of receiving Authentication-Ok message) and t0 is below the predefined threshold (such as 0.1 seconds)
  • if the time is below the threshold – the Lock opens, otherwise it treats authentication as having failed, and becomes ready to accept new credentia

Conclusion

We have presented a Delayed-Message Attack which can apply to a wide class of IoT devices, including locks. The Attack can be mounted in practice with fairly minimal efforts on the Attacker’s side. While the attack borderlines on being trivial, it is still one more thing to keep in mind when designing secure systems.

Prevention/mitigation of the Attack is easy, but it needs to be taken into account at the application level.

Don't like this post? Comment↯ below. You do?! Please share:

Acknowledgement

Cartoons by Sergey Gordeev from Gordeev Animation Graphics, Prague.