Example sketches - session key to prevent replay attacks

[dewoodruff]

EDIT: The below was my first attempt at session keys, but has since been replaced with an 'extension' library built off of the RFM69 core. See this thread: https://lowpowerlab.com/forum/index.php/topic,966.0.html and my blog: http://www.makethenmakeinstall.com/2015/03/session-key-support-for-arduino-with-rfm69-wireless-module/ for more information.


tl;dr - I've created some proof of concept sketches that implement a session key to prevent replay attacks. They can be found here: https://github.com/dewoodruff/RFM69-session-token-ACKs

The RFM69 library from Felix is wonderful and I've been using it to get my feet wet into Arduino, but it was lacking one critical piece - being able to prevent wireless replay attacks. It is theoretically possible that an attacker could capture packets being sent to or from nodes (like those to open a garage), then replay them at a time of their choosing. Just encrypting the packet is not enough because an encrypted packet would have the same content every time, so the replayed packet would be accepted by the other end as if it were a new, legitimate request.

I've cobbled together a few sketches based on the the Node and Gateway examples that Felix provided in the RFM69 library to 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 the 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 protection. 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. Also, the attacker would have to know what the code was doing to know that this scenario even had a possibility of working.

I'd love some feedback on the sketches. Ultimately I'd like to port them into functions in the RFM69 library directly to simplify the code that has to be written directly in the sketch, however, this proof of concept was the easiest method for me to get it working. I am new to C++/Arduino so there are probably better ways to get this working. Please let me know what you think, and how difficult it might be to build directly into the RFM69 library. Thanks!

[Felix]

Nice work, I wrote an article a while ago about wireless security issues, see the rolling code vulnerabilities section of the article here.

[dewoodruff]

Thanks! I did read your article some time ago. For my attempt I chose to implement a connection handshake kind of like the three way handshake in TCP. It doesn't need to keep some piece of information in sync in perpetuity but rather it negotiates the key for each burst of information that is sent. The downside is the overhead of two non-data packets per piece of information the be transmitted but the positive is that there is no counter or time to keep in sync between the gateway and node.

I'll update the examples soon to pull the connection logic out into functions so that they could be easily copy/pasted into someone else's code without much effort. Hopefully someone else finds this useful!

[TrendSetter]

The way i handled this is just including the lower two bytes of the current millis() into the packet before encryption/sending.  the receiving end doesnt look at those bytes, but it does ensure the payload is different every time, and adds relatively little overhead.
edit: i just realized that this does not prevent replay attacks.  its funny what causes you to think differently about things.

[TomWS]

<...snip>

I've cobbled together a few sketches based on the the Node and Gateway examples that Felix provided in the RFM69 library to 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.

<snip...>

I personally don't have a need for this feature, but I do like that the connection is initiated by the node, which, in my view, spend the bulk of their time sleeping and have the data or need the data from the gateway.  The exceptions to this are control type nodes, (like Garage Door openers, to take a random example).

ISTM that the session key could be returned by the gateway in the Ack response to the connection request.  From what I've seen this is a little used but, IMO, a very valuable feature of the RFM69 library - that Ack can send data.  Also, if you dig into the library code, you will see that the library itself is capable of prepending the session key to the node's data packet within the sendFrame function so that, if the node has a new CTL bit set, enabling session key support, the whole transaction can be totally transparent to the node (other than losing one byte of payload).  The node would only have to call a new method to enable session key support.

There are spare CTL bits, but, as a head's up, I am currently using bit 5 in my own version of the library to control auto transmit level.  My updates will be submitted in the next month or so...

If you're interested, I can include a snippet of code that would handle the session key on the node end...  The gateway side would be somewhat different, of course...

Tom

[dewoodruff]

The way i handled this is just including the lower two bytes of the current millis() into the packet before encryption/sending.  the receiving end doesnt look at those bytes, but it does ensure the payload is different every time, and adds relatively little overhead.
edit: i just realized that this does not prevent replay attacks.  its funny what causes you to think differently about things.

The only issue with this approach is that the receiving end doesn't have anything to verify to say that the incoming data is actually from a legitimate node, rather than being replayed by an attacker. It makes the data look different as it flies over the air, but if it were captured and replayed, the receiver will still process the data.

[dewoodruff]

I personally don't have a need for this feature, but I do like that the connection is initiated by the node, which, in my view, spend the bulk of their time sleeping and have the data or need the data from the gateway.  The exceptions to this are control type nodes, (like Garage Door openers, to take a random example).

I was thinking about this situation as well and hope to implement a polling method to handle it. My backend is nodered based and I'm going to add MQTT soon, so I was thinking that when a command is initiated it would be published to a MQTT topic, then when the node checks in and polls for a command, nodered would poll the MQTT topic to see if it needs to send a command. Still working out the details... And that wouldn't be a good solution for when you want an immediate response to that command.

ISTM that the session key could be returned by the gateway in the Ack response to the connection request. From what I've seen this is a little used but, IMO, a very valuable feature of the RFM69 library - that Ack can send data.  Also, if you dig into the library code, you will see that the library itself is capable of prepending the session key to the node's data packet within the sendFrame function so that, if the node has a new CTL bit set, enabling session key support, the whole transaction can be totally transparent to the node (other than losing one byte of payload).  The node would only have to call a new method to enable session key support.

There are spare CTL bits, but, as a head's up, I am currently using bit 5 in my own version of the library to control auto transmit level.  My updates will be submitted in the next month or so...

If you're interested, I can include a snippet of code that would handle the session key on the node end...  The gateway side would be somewhat different, of course...

I would definitely be interested in an example. What you described is ultimately where I hoped to go - integrating it into the library, piggybacking on the ACK, so that all this is handled seamlessly. However I also see a value for "fire and forget" from a node to a gateway such as in reading temperature, so the gateway would have to handle both.

Dan

[TomWS]

I personally don't have a need for this feature, but I do like that the connection is initiated by the node, which, in my view, spend the bulk of their time sleeping and have the data or need the data from the gateway.  The exceptions to this are control type nodes, (like Garage Door openers, to take a random example).

I was thinking about this situation as well and hope to implement a polling method to handle it. My backend is nodered based and I'm going to add MQTT soon, so I was thinking that when a command is initiated it would be published to a MQTT topic, then when the node checks in and polls for a command, nodered would poll the MQTT topic to see if it needs to send a command. Still working out the details... And that wouldn't be a good solution for when you want an immediate response to that command.

That's pretty much how I'm setting up my nodes, practically always sleeping and if the home server has something to deliver to the node, the server sends it to the gateway and the gateway queues it up and keeps track that it's 'gotSomething' for the node.  Then, on the next post from the node, the GW sees that it's got 'something' for the node and signals this (along with the type of 'something') in its Ack to the node's send.  The node can then decide if it wants to wait around for the something or defer it to another time.  If it's willing to accept the 'something', then it sends a request along with the 'something's id, stays awake longer than normal, and the GW passes the 'something' back to it.  This is how I'll do wireless program updates, for example, the 'something' in this case will be individual program update records.  The node can fetch as many as it's willing to grab without draining its battery and then come back for more at a later time.  It will take a long time for an update but I don't much care if it takes even 24 hours to ship out a code update.  Once deployed, nodes shouldn't need updates very often...

A good example of a 'control' type node that I have is my sprinkler valve.  It takes a lot of energy to flip on or off the DC Latching solenoid but it doesn't happen very often so battery operation is entirely plausible.  There are two exceptions to this case, however, first, when you're testing the sprinkler system you want to turn the valves on and off relatively quickly.  In the other case, once a valve is ON then you sure don't want to wait hours to turn it off again     So the polling interval will be variable based on whether the valve is on or off. Or, in the testing case, the server can temporarily override the polling interval.  The neat thing about sprinklers in general is that their operation is generally predictable even up to 24 hours in advance so, with a programmable interval, you can get responsiveness without consuming battery life.

ISTM that the session key could be returned by the gateway in the Ack response to the connection request. From what I've seen this is a little used but, IMO, a very valuable feature of the RFM69 library - that Ack can send data.  Also, if you dig into the library code, you will see that the library itself is capable of prepending the session key to the node's data packet within the sendFrame function so that, if the node has a new CTL bit set, enabling session key support, the whole transaction can be totally transparent to the node (other than losing one byte of payload).  The node would only have to call a new method to enable session key support.

There are spare CTL bits, but, as a head's up, I am currently using bit 5 in my own version of the library to control auto transmit level.  My updates will be submitted in the next month or so...

If you're interested, I can include a snippet of code that would handle the session key on the node end...  The gateway side would be somewhat different, of course...

I would definitely be interested in an example. What you described is ultimately where I hoped to go - integrating it into the library, piggybacking on the ACK, so that all this is handled seamlessly. However I also see a value for "fire and forget" from a node to a gateway such as in reading temperature, so the gateway would have to handle both.

Dan

I'll see if I can cobble together a strawman in a day or two.  To my mind it would be a decision on the node's part to have packets controlled by session keys or not.  This would be completely backward compatible.

[TomWS]

<...snip>
I would definitely be interested in an example. What you described is ultimately where I hoped to go - integrating it into the library, piggybacking on the ACK, so that all this is handled seamlessly. However I also see a value for "fire and forget" from a node to a gateway such as in reading temperature, so the gateway would have to handle both.

Dan

I'll see if I can cobble together a strawman in a day or two.  To my mind it would be a decision on the node's part to have packets controlled by session keys or not.  This would be completely backward compatible.

Dan, I'm going to back off my statement that this is 'easy'.  I do think on the Node side it can be easy and essentially invisible to the Node (other than enabling session key support).  However, as I thought about the gateway end, I had the 'oopsie' revelation that Gateways need to support multiple simultaneous sessions and all of a sudden the gateway side became much more involved than a simple 1:1 implementation would be.  Consequently, as I said, I'm going to awkwardly back out of this for the time being...
 

Tom

[dewoodruff]

Dan, I'm going to back off my statement that this is 'easy'.  I do think on the Node side it can be easy and essentially invisible to the Node (other than enabling session key support).  However, as I thought about the gateway end, I had the 'oopsie' revelation that Gateways need to support multiple simultaneous sessions and all of a sudden the gateway side became much more involved than a simple 1:1 implementation would be.  Consequently, as I said, I'm going to awkwardly back out of this for the time being...
 

Tom

No worries! I still plan to give it an attempt myself. For my purposes I don't have the requirement of multiple simultaneous sessions. I'm good with letting one transaction block another. I'm sure I'll run into other complications along the way but I just need to find the time to sit down and put some serious work into it. Might be a few months until I have something to share... but I will be back!
Dan

[dewoodruff]

Here's what I've come up with to directly integrate session key support into the library. Session keys can be seamlessly enabled by putting useSessionKey(1) in the sketch. I've tested these configurations, both with 'send' and 'sendWithRetry' using the Node and Gateway example sketches:

• both gateway and node with session key disabled
• both gateway and node with session key enabled
• gateway enabled, node disabled - works as expected, allowing "fire and forget" messages from nodes that don't require session keys. However, the gateway cannot initiate a new connection to send data to the node because the gateway will try to initiate a new session, but the node will not be enabled, so it will never handshake a key.
• gateway disabled, node enabled - does not work, as expected, because the nodes can't handshake a key.

I have NOT tested anything with remote firmware uploads or anything more advanced than the example sketches.

The git diff is here: https://github.com/dewoodruff/RFM69/commit/26246e436a2b5b1acc529e04281a128ab282d30a
I'd love some feedback - please tear it apart! After I post this I'm going to start uploading to my production gateway and nodes.

Dan

[Felix]

Dan, thanks for the contributions.
I would consider these extra features and so I would propose including these in a separate library that inherits from RFM69.h.

[TomWS]

Dan, thanks for the contributions.
I would consider these extra features and so I would propose including these in a separate library that inherits from RFM69.h.

So the separate library would extend RFM69 and override the sendFrame method and Interrupt handler? 

Makes sense on the sendFrame method, but it might be better to provide 'hook' that the Interrupt handler escapes to, if enabled.  I need to think about this, but given that I also have 'extensions' that aren't necessarily compatible with this proposal, your suggestion might be the best way to deal with both...

I need to think on this... another scotch, please.

Tom

[kobuki]

Dan, an interesting approach at preventing replay attacks. There are many ways to solve this, and I think it's essentially an algoritmical problem, rather than something specific to microcontrollers. I also think if your communication scheme is similar to what Tom uses, it's probably just fine. You're probably aware that your key is not a "session key"  but rather a "message unique key", since to repel this kind of attack, you need a new key for every message.

I've pondered the same idea several times, though haven't implemented it yet. My approach is simpler, and relies on serial numbers. Sorry if this post becomes long, please feel free to throw it out into a new thread. I don't want to hijack yours, but I thought an exchange of ideas on the subject is the right place here.

So, my approach would be: similar to your session key, each and every packet contains a serial number, which is stored and consequently transmitted encoded before or after the payload, together with an additional encoded, fixed node ID. The serial number is strictly monotonic increasing, this must be ensured by the sender, however the difference between subsequent serial numbers is not important. It can be practically incremented by one every time a new packet is sent. There is one problem to solve: what about reboots? We assume for now that the serial is 32 bits. We have EEPROM of course, so we can store a 16-bit prefix (high 16 bits) in nonvolatile storage. At every reboot of the node, the prefix must be incremented by one. The lower 16 bits are simply incremented on the fly and stored in a static variable. Should it overflow, we increment the stored prefix. This simple algoritm ensures we always have a node-local independent serial number.

There are 3 main attack vectors: first is the AES encryption key which is a shared secret between the nodes and the gateway. In practice its impossible to guess, let alone compute the correct one in a timely manner. The second is the serial. It can easily be guessed but without the key it's irrelevant. The 3rd is jamming/modifying the radio comms, but its usefullness is only equal to DOS (denial of service) or to delaying certain packets.

The gateway only needs to verify the node ID, the monotonicity criterion and of course the CRC, but this latter is done by the module itself, and from security and data integrity perspective it's far from ideal but let's just skip it for now. The node ID + serial number together forms a globally unique ID (GID) for every packet sent in a given system, so it's not possible to simply replay any of them. Naturally the GW needs to keep track of the serial for every node. Other benefits are that it can be used in one-way communication scenarios because the GID is independent of the gateway. This enables less frequent wake-ups, less radio comms and more sleep for a mote.

[TomWS]

Kobuki, I'm not sure how your proposal is immune from the inevitable missed connection.  Further, I don't see how Dan's proposal is weak WRT to the stated goal, which is to eliminate the possibility of replay attacks, which, I believe, is the main exposure with the current encryption scheme. 

The advantage of Dan's scheme is that it requires an interchange, which, by its very nature, is unique and, under the covers of encryption, totally immune from replay.  Any single exchange method requires an implied synchronization that would be very hard, if not impossible, to maintain in a Moteino environment.  The one aspect of Dan's implementation that might be considered weak is the fact that it uses Arduino's non-random random function.  But that could be easily addressed and probably isn't too serious as each session is still sufficiently unique in the context of someone monitoring 'garage door' openings - it probably wouldn't be acceptable for Fort Knox, however 

What am I missing from your suggestion?

Tom

[kobuki]

Tom, I don't exactly get what you refer to by missed connections. Please elaborate a bit more. OTOH, my post is not meant to point out weaknesses in Dan's solution.

What my solution provides is a unique, unrepeated identifier for every single packet. There's no need to sync anything, you only need to verify what I have already written of, and that's a node ID and the monotonicity of the serial number. It's easy to check even in a Moteino-based gateway, however I'd do the verification in the server code. No problem if you miss one or many packets.

[TomWS]

Tom, I don't exactly get what you refer to by missed connections. Please elaborate a bit more. OTOH, my post is not meant to point out weaknesses in Dan's solution.

What my solution provides is a unique, unrepeated identifier for every single packet. There's no need to sync anything, you only need to verify what I have already written of, and that's a node ID and the monotonicity of the serial number. It's easy to check even in a Moteino-based gateway, however I'd do the verification in the server code. No problem if you miss one or many packets.

I guess I don't understand your proposal then.  As I read your proposal, when a mote wants to send a packet to the gateway, it adds some information that is uniquely generated for that packet and sends the packet to the gateway.  The gateway receives it and 'somehow' knows that the unique information is correct.  If this is a correct interpretation, then I don't understand HOW the gateway knows that the unique information is correct. 

I had interpreted your proposal that the unqiue information was some monotonically increasing value and, if this was the case, then how do you deal with lost packets (since the earlier incremental value had been lost)?

Please help me understand your proposal better.
Tom

[kobuki]

The point is that the monotonicity criterion does not specify an increment. What is important is that subsequent serial numbers arriving from the same node are bigger than the previous one. I have mentioned this in my original post, 3. paragraph, 2. sentence There can be an arbitrary difference between 2 subsequent serial numbers received by the GW. This still ensures replay attacks are unfeasible.

There is however the possibility of an attacker jamming the receiver and at the same time capturing a packet of a node, and later repeating it. It can delay a certain packet to cause an event and subsequent action in the GW at a later point in time than originally intended, but the usefulness of this attack is rather limited and similarly to Dan's proposal, easy to negate using carefully chosen timeouts. Additionally, jamming the GW inadvertently causes awareness of the operator and the attack is easily detected.

[TomWS]

The point is that the monotonicity criterion does not specify an increment. What is important is that subsequent serial numbers arriving from the same node are bigger than the previous one. I have mentioned this in my original post, 3. paragraph, 2. sentence There can be an arbitrary difference between 2 subsequent serial numbers received by the GW. This still ensures replay attacks are unfeasible.

Ah, I missed this distinction.  I apologize and agree that this would work to a point and would be simpler to implement.  However, did you also explain how to deal with the problem that occurs when the number rolls over?  I suppose some sort of exchange could take place at that point to reset both endpoints.  Your scheme does, however, require that receivers keep track of the 'state' of each transmitter.

There is however the possibility of an attacker jamming the receiver and at the same time capturing a packet of a node, and later repeating it. It can delay a certain packet to cause an event and subsequent action in the GW at a later point in time than originally intended, but the usefulness of this attack is rather limited and similarly to Dan's proposal, easy to negate using carefully chosen timeouts. Additionally, jamming the GW inadvertently causes awareness of the operator and the attack is easily detected.

Jamming the receiver while at the same time capturing the transmitted packet is an interesting academic discussion but would require such sophistication to achieve reliably that it seems extremely unlikely in this context.  Further, Dan's proposal is immune from this type of attack since his scheme requires an interchange.  I take that back, it is not totally immune if the jamming/capture occurred precisely at the second phase of the interchange, but, as you say that is trivially addressed with timing constraints. 

Finally,  short of millimeter wave radio, I'm not aware of ANY consumer grade wireless technology that is immune from outright jamming.

Tom

[kobuki]

Yes, I mentioned the rollover and proposed a simple solution. I've also proposed the serial number to be 32 bits which should be enough for 8000+ years worth of transmissions if they're occurring every minute Even if the TX delay is shorter, you can just let it roll over. This is the lesser of the problems. OTOH, to make things a little simpler, you can auto-initialise the system and you don't need to store any state in the gateway nor in the motes. When you first hear a node, you drop the first packet (to avoid sucking in a replay attack) and apply the algorithm to all subsequent ones.

You're right, jamming is a problem with any radio system in practical use. While it might sound academic or theoretical, we're discussing replay attacks with very cheap solutions, right? It's not impossible to build a suitable jammer and a recorder with directional antennas. It only takes a little more than just Arduino knowledge, off the shelf components are easily available... Designing a robust mesh of motes is a significantly larger and more complicated task, yet they seem to become ubiquitous nowadays.

[dewoodruff]

Great discussion, guys! kobuki, I had not heard of the concept of monotonic functions before. With your proposal in the last post to not store state on either end, that could be a very simple solution for sensor nodes that just spit out data, other than the gateway needing to keep track of the value for each node. It seems like it would work for bidirectional communication too, where the gateway initiates a command to the node. The node would just discard the first command after a reboot and then keep track of the gateway's value. However, if you didn't save the gateway's value between reboots, you'd have to power cycle every node after a gateway reboot to reset the counter.

I was coming at the problem thinking about a handshake where neither side needs to keep track of anything between transmissions. It is at the expense of power though, because now instead of one or two packets (data packet and an ACK), we're up to three or four (request key, send key, send data, ACK).

Regarding Arduino's random not being random - in an earlier test I did use randomSeed(analogRead(0)), however I left that out of the library because not everybody will have their analog pin 0 disconnected. That could be added to the sketch during setup if desired. And even then I know the arduino can't generate a true random value, and having only one byte of random key might not be sufficient enough for military grade applications, but for me, it's good enough!

[TomWS]

... but for me, it's good enough!

If there is a phrase that every 'techie' should learn (in their life and their career), it's 'good enough'!!!!
I spent too many years pushing on 'better and better' and it was only when I found this phrase I found not only saleable products, but satisfaction as well!

To take a random example, 'Moteino' is even better than 'good enough'.

T

[kobuki]

The algorithm can be used in both directions, but yes, it needs some refinement. For instance, in the case when it's not storing persistent states for reboots, a reset of the serial back to zero can signal a restart of the other end and after dropping the first out of order packet, the sequence verification can run as usual. Assuming the key is still only known to our nodes, a replay attack is very impractical in cases of 2-way communication.

Regarding random numbers, I have an idea: set the radio to receive with its highest sensitivity in either continuous or in packet mode and record the incoming noise Doing it when randomisation is needed would produce fairly good random numbers, or it simply can be used as seed once.

[kobuki]

For making the lives of casual attackers a little harder, the original solution is certainly good enough If that was the set goal, I guess it has been reached.