How does replay cache prevent replay attacks in BLE Mesh?

[Mitch996]

Hi, can someone explain in simple terms how it works?

I don't really have a clear concept of what a replay attack is, but I suppose it has something to do with recording a message, and then spams it through out the mesh network, overloads all the nodes thus achieving a DDoS style attack result?

Anyhow I don't know the particulars. What role does the replay cache play? How does it distinguish from a genuine piece of repeated message that should be repeated under certain circumstances or an actual attack? Time stamp? A counter?

[ovrebekk]

Hi

Most wireless encryption schemes use AES encryption at the core. The simplest way to encrypt your data with AES is simply to use a fixed AES key, and run an AES encryption operation on all your data.

The problem with this method is that every time you encrypt the same data you get the same encrypted 'cipher text', and this leaves you vulnerable to replay attacks.

Say you make a wireless door opener, and every time you open the door you send the same command, then it is really easy for a hacker to figure out how to open the door, even if he is unable to decrypt the message, as illustrated by this chart.

The normal method to avoid replay attacks is to append a rolling counter (also called sequence number) to your data before encryption. As long as the counter is unique for every packet then the encrypted cipher text will always change. Then it is up to the receiver to verify the counter after decryption to ensure that it receives a counter value that has never been sent before, and discard any packet that uses an old counter value. The easiest way to do this is simply to increment the counter for each packet, then the receiver can just store the previous counter value and make sure any new packet has a higher counter.

In a peer to peer connection this is quite easy, but the mesh makes it a bit more complicated. Essentially each node needs to keep track of the current sequence number for each node it is receiving from, since they all have unique sequence numbers, and this is where the replay cache come in. By default the replay cache has room for 32 elements, which means you can not receive data from more than 32 different devices.

Best regards
Torbjørn

[Mitch996]

Hah! That's very thorough, thank you!

[jqualie]

It nrf5_SDK_for_Mesh_v0.9.2-Alpha, the replay cache is initialized on startup (blank/empty). If a packet is received, the sender's source address and packet sequence number are added to the cache. Any future packet sequence numbers from this sender are checked against the most recent sequence number stored in the replay cache.

See transport_pkt_in() in transport.c

1. Doesn't this make the device vulnerable to replay attacks after restart (when the replay cache is empty)? Basically, it will accept any received packet and source address and if the sender isn't already in the cache, it adds it, without checking.
2. Are there plans to save the replay cache to NVM and restore on startup?

[ovrebekk]

1. I checked with the team, and they confirmed that this is a weakness in the current implementation.
2. Yes, we are looking into ways to handle this without having to continuously write to the flash (since that would quickly wear it out). Most likely we are going to base it off of the brownout detection mechanism, and try to store the replay cache when a drop in supply is detected.

Best regards

[PopradiArpad]

Hi!

Is this feature implemented in SDK Mesh 1.0.1?
Can the the SDK alone decide when to do the saving or should
be triggered by the application or a GPIO?

Thanks