RFM69-session-token-ACKs

NOTE: this method is inefficient as the session logic is being implemented in the sketch. It certainly works, but a better method is to use my RFM69 library extension located here: https://github.com/dewoodruff/RFM69_SessionKey

tl;dr - Proof of concept sketches that implement a session key to prevent replay attacks using the LowPowerLab RFM69 wireless library for Arduino. The library can be found here: https://github.com/LowPowerLab/RFM69

The RFM69 library was lacking one critical piece - being able to prevent wireless replay attacks.

These sketches are based on the the Node and Gateway examples that Felix provided in the RFM69 library and implement a session key. It works as follows:

1. The Node makes a connection request.
2. The Gateway generates a random 1 byte session key, stores it and the node's ID, then sends the key back to the node. Then it waits until a defined timeout for a response.
3. The Node receives the session key and adds it as the first byte in DATA. It appends whatever other data needs to be sent after the key, then sends it all back to the Gateway.
4. The Gateway receives the response. It checks to make sure the first byte of DATA matches the expected key and is from the correct sender, then processes the rest of the payload.

And of course, this is all useless if encryption isn't enabled :)

Pros:

• Provides reasonable protection against replay attacks. Helpful for sensitive transactions such as opening a lock or garage door. Cons:
• While gateway waits for a response to the original connection request it is deadlocked. There is the potential to miss connections from other nodes during this time which could be a problem on busy networks. Can possibly be worked around by tweaking ACK timeout thresholds and counts and keeping the connection timeout low, or some other logic.
• Not perfect. An attacker could theoretically still continuously try to guess the session key by sending a new connection request, then replaying the stored packet, hoping that the session key in the stored packet ends up matching what was just generated by the gateway. However, the gateway only generates a new session key once per timeout period, so the longer the timeout, the less frequently an attacker can guess. This could be made more difficult by using a longer session key, at the expense of payload size.