# 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
contexts, design changes, such as non-volatile memory may maintain the counter value in between resets. If the attacker cannot reset the counter by resetting the end devices, the only way to accomplish the attack is to wait for a counter overflow [72]. This change essentially decreases the exposure, however requires an adjustment in the LoRaWAN specification. The end device should change its session keys each time when the counter reaches its maximum value. If the device is utilizing OTAA method, it should experience the OTAA activation procedure again to acquire new session keys. If the end device is using a ABP method, it should be re-configured, and session keys should be changed. For this situation, however, the counter values are reused, session keys will prevent the server from accepting malicious messages. With that, this attack will not be possible. It is inconvenient to manually re-activate and configure an end device each time it overflows. Besides, for end devices situated in a remote area, this mitigation will cost an enormous amount of resources since it should be operated manually. According to LoRaWAN specification 1.0.2, after the device activation or the reset, the frame counters on the end-device and the frame counters on the network server for that end-device are reset to zero [69]. One approach to increase the security level is to remain the counter value in the server after resetting. Thereby, each time an ABP activated end device resets, its counter value will restart from zero while the relating counter value in the server will not be changed. At that point when the end device sends messages to the server, the server will not accept the messages until the counter value of the end device becomes larger than the counter value in the server. This strategy prevents all the messages with reused counter value. With that, resetting ABP activated end devices is pointless for an attacker in the replay attack. The attacker can just accomplish this attack by waiting for counter value overflowing [72]. Another technique is to add a function to end devices. Each time it resets or the counter value reaches its maximum value, the end device should be triggered and then be able to re-activate automatically. Regardless, if the end device is activated by OTAA or ABP in the last session, it should utilize OTAA to rejoin the network. This implies that the end device should experience the \"Join request--Join accept\" procedure again. This technique is conceivable to be passed automatically [72]. To protect against replay attacks in Sigfox communications, a 12-bit Sequence Number (SN) is used and transmitted with every uplink frame and protected by a specific Message Authentication Code (MAC). If the actual received Sigfox frame contains a lower SN than the latest received frame, the actual frame will be discarded by the Backend Server. The actual algorithm employed to compute the MAC is proprietary, but it applies Advanced Encryption Standard (AES) in Cipher-based Message Authentication Code (CMAC) mode like in the LoRaWAN protocol, with the secret not acknowledged and the 12-bit SN (for uplink messages), as some of its inputs. For downlink messages, there is no public information related to the SN size, which does not allow us to claim that the same security level is achieved when compared with uplink messages [64].