The REPLAY attack is a well known attack in the world of radio transmission, and unfortunately the LoRaWAN 1
protocol is no exception. 2
We could find it quite strange because the LoRaWAN is done with keys, so it's supposed to be encrypted 3
and really secured. 4
Don't worry, that's the case. 5
But what about the security level? 6
We can't prevent anyone to listen to a LoRa transmission because listening to a LoRa transmission 7
is really easy. 8
And the best tool to do it is probably a gateway. 9
Indeed, the gateway can listen on all channels with all spreading factor at the same time. 10
But even if we can listen to a LoRa modulation, is it serious ? Because the communication is encrypted, 11
so that shouldn't be a problem. 12
Actually, encryption is good for confidentiality, but that doesn't help for authenticity. 13
We can explain that with the following example. 14
We can imagine that a lower transmitter sends an encrypted frame to open a door. 15
A hacker listens to the radio transmission, but obviously we can consider that he does not understand 16
the content. 17
However, he can steal the payload. And he notices that when his frame is sent, the garage door opens. 18
Why is it dangerous? 19
Because if the hacker comes back a few months later and we play the same frame 20
Even if he doesn't understand anything about it, then there is a good chance that the garage door would 21
open again. 22
The hacker has simply replayed a frame, nothing more. 23
There is, of course, a simple way to prevent this REPLAY attack. 24
The trick is to make sure that we never transmit twice the same frame. 25
Even if we have the same command to send, the content of the LoRaWAN frame must be different. 26
For that we use a simple counter called frame counter and this counter starts from zero, but increases 27
by one each time the end-device sends a new frame. 28
On the other side, the server takes the frame counter. 29
It simply checks that the frame counter received is greater than the one received previously. 30
Otherwise the server should drop it. 31
So let's make a little demonstration with an end-device that has just started after registration. 32
We suppose that all frames use the right Network Session Key so that they are all authenticated. 33
So at the beginning, when the first frame is sent with a frame counter one then the server ask itself is 34
the frame counter received higher than the previous one? 35
Of course this case is yes. 36
So the server accept it. Then, the end-device send frame counter two. Again the server accept it. 37
Even if for some reason the end-device frame don't reach the server. 38
It doesn't matter. 39
Let's say the frame 3 to 9 are lost. 40
If the server received a frame counter ten, then it accepts it. 41
And finally, what happens if a hacker has thought of frame number five and tries to reply nothing because 42
it detects a replay attack and drop it silently? 43
Great. 44
We are now protect it from replay attack. 45
And that's a good news. 46
So now we'll take two end devices, one in ABP and one in OTAA and will see what happened on the network 47
server.