# Security Vulnerabilities in LPWANs--An Attack Vector Analysis for the IoT Ecosystem
## 3 State-of-the-Art Review
### Attacks and Defense Strategies
#### 3.4.4 Replay Attack  
A replay attack is an attack on security protocol, re-sending or repeating the legitimate data transmission by the malicious actor. The primary motivation behind this attack is tricking the device or module by utilizing handshake messages or old data from the network. To perform this attack in wireless networks, the malicious entity should know the communication frequencies and channels to sniff data from transmission between devices [47]. The attacker receives and transmits data exchange between two trusted parties as an authorized unit, which conducts the participants to accept that the transmission of information has been finished. The malicious actor can capture and store a duplicate genuine request to a service, from a specific device in the system. After that, it can be replayed to get services that are only available to authenticated users [62]. For example in replay attack for Activation by Personalization (ABP) activated devices in LoRaWAN, cf. Figure 9, the objective is to accomplish spoofing and Denial-of-Service (DoS). After the attack execution, the server gets a malicious repeat message from the malicious actor's end device, and the server accepts that the message comes from the working end associated device. For end-user devices, the objective is to perform a DoSattack. After the effectively executed attack, the server will not get a message from the end-user devices. The DoS period relies on selecting a rehashed message [71]. For development devices, which often use ABP activation to join networks, it is necessary to consider that this method has security flaws [47]. For ABP enabled terminal devices are utilized static keys, this way after a reset, the keys continue the same as before, they do not change and may be used in future sessions [81]. Afterward, the network server may receive a malicious message that agrees with: (1) the session keys are the same as one accepted end device; (2) DevAddr is the same as one accepted end device; (3) if the counter value is acceptable. As expressed beforehand, the keys are static and the counter values are not utilized securely. For this situation, an attacker can choose and resend messages before the reset, and the server cannot figure if these messages are from this session or the session before the recovery [71]. The LoRaWAN 1.0 protocol states [82] that after a JoinReq--JoinAccept message exchange or a reset for a personalized end-device, the frame counters on the end-device and the frame counters on the network server for that end-device are reset to zero [69]. For this situation, the attacker can use messages from the last session with the high values counters and repeat them in the current session. Whether or not the end device is activated by ABP or Over The Air Authentication (OTAA), it is possible to perform a replay attack [71]. In addition to manually resetting counters on the two sides, the counter overflow is another method of reset. When the counter value reaches its maximum value, the counter is reset and restarts from 0. With counter values from the last session and with the same session keys, the attacker can also repeat past messages to disconnect communications between the end device and the server [71]. This goes for both ABP and OTAA. However, attacking an ABP-activated end device will take less time as both reset and overflow work if the attacker has the ability and opportunity to reset end devices [69]. **Defense Strategies**: The replay attack depends on the perception that the NwkSSKey and AppSKey are used as the long-term key material that stays unaltered after a counter reset, rather than being restricted to a single session [69]. To prevent this attack from occurring, the following measures could be taken:  
End devices should be physically secured to prevent a malicious entity to start a system reset [43]. While this is hard to achieve in an assortment of IoT deployment  
Figure 9: ABP device exploiting the Replay Attack. Adapted from [79].