# Extensions and Enhancements to \"the Secure Remote Update Protocol\"
## 3 Enhancements and Improvements to the Original Protocol
### Vulnerability to Replay Attack
#### 3.1.2 A Sequence ID-Based Approach  
The proposed method to address replay attack within SRUP is to use a sequence ID-based approach: similar in concept to that used within the LoRaWAN protocol [12]. Adopting this method would require an additional value (a sequence ID) within all SRUP messages. A 64-bit (eight byte) sequence ID would be more than sufficient for this purpose (64 bits would permit a system using 1,000,000 messages a second to run for over 580,000 years before overflow). In order to conserve space in the SRUP message, it might appear to be preferable to adopt a smaller size (e.g., a six byte sequence ID, which would still permit 100,000 messages/second for 89 years). However, since a six-byte integer is not a standard size, we would be required to implement our own six-byte integer type to handle this value, and although this could be easily done in most languages, given that for even the smallest message type, the difference would make a \(<\)1% difference to the overall message size, it is felt that there is no value in doing this vs. using a standard 64-bit integer (e.g., uint64_t or unsigned long long) for the sequence ID.  
The implementation would work in the same way for messages sent by the server and messages sent by the devices. In all cases, the sender would simply store the last value it used to communicate with that receiver, in local persistent storage, and increment it by one for each new message.  
A typical device implementation would require that the device stores the last value that it has received from that server, and the protocol would require that any message received from a given server has a sequence ID greater than the last received sequence ID from that server. Any message received where the sequence ID is less than or equal to a previously received sequence ID should be discarded.  
Since under the SRUP paradigm, devices can only accept messages from a server (the protocol does not support peer-to-peer messaging), devices would be required to store (within persistent storage such as a file system or EEPROM) just one such value for each server with which the device is in communication. The relatively small size of the sequence ID means that even devices implemented using tiny microcontroller-based hardware would be unlikely to face storage limitations. For example, just one kilobyte of storage is more than sufficient for 128 sequence IDs at 64 bit (and it is expected that 128 different active C2 servers at any given time is likely significantly in excess of any requirement from any real-world application).  
On the server side, it can be assumed that storage will be much less of an issue. This approach would require that a server keeps the last sequence ID from all devices that they have communicated with (until such a time that the device has been removed from the system). Even a server with 100,000,000 devices would require less than 800 Mb of storage for the current sequence IDs; a relatively trivial amount for any cloud-based server implementation.  
The SRUP protocol has been updated to incorporate an eight-byte (64 bit) sequence ID value for all message types; and to require that all received SRUP messages must be rejected if the sequence ID is not strictly greater than the last received sequence ID from that sender.