Author Topic: Example sketches - session key to prevent replay attacks  (Read 10990 times)

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Example sketches - session key to prevent replay attacks
« Reply #15 on: March 02, 2015, 05:38:50 AM »
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

  • Hero Member
  • *****
  • Posts: 1930
Re: Example sketches - session key to prevent replay attacks
« Reply #16 on: March 02, 2015, 08:33:31 AM »
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

  • Sr. Member
  • ****
  • Posts: 289
Re: Example sketches - session key to prevent replay attacks
« Reply #17 on: March 02, 2015, 08:45:21 AM »
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

  • Hero Member
  • *****
  • Posts: 1930
Re: Example sketches - session key to prevent replay attacks
« Reply #18 on: March 02, 2015, 01:38:45 PM »
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

  • Sr. Member
  • ****
  • Posts: 289
Re: Example sketches - session key to prevent replay attacks
« Reply #19 on: March 02, 2015, 02:07:32 PM »
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

  • NewMember
  • *
  • Posts: 17
Re: Example sketches - session key to prevent replay attacks
« Reply #20 on: March 02, 2015, 09:42:08 PM »
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

  • Hero Member
  • *****
  • Posts: 1930
Re: Example sketches - session key to prevent replay attacks
« Reply #21 on: March 02, 2015, 09:50:15 PM »
... 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

  • Sr. Member
  • ****
  • Posts: 289
Re: Example sketches - session key to prevent replay attacks
« Reply #22 on: March 02, 2015, 09:58:09 PM »
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

  • Sr. Member
  • ****
  • Posts: 289
Re: Example sketches - session key to prevent replay attacks
« Reply #23 on: March 02, 2015, 10:11:33 PM »
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.