0
$\begingroup$

My wireless sensor nodes and gateway application use timestamps as nonce and will guaranty that different messages use different nonces so security is not compromised.

If for some reason the gateway does not include logic to discard packets with old timestamps relative to its own clock, a replay attack can be sent to it. Beneficially, the sensor would then also be able to re-transmit the exact same packet later if the gateway was down. Let's say the sensor was not able to deliver the packet to the gateway, but it was picked up by an eavesdropper.

If for some reason the eavesdropper would like to replay this message, it would actually do the system a favor, as I can see it.

So, if the sensor only transmits sensor data samples with timestamps, can one say that it's not vulnerable to replay attacks?

And if the "sensor" includes a button to switch something on and off (real-time function), then one could discard packets with old timestamps.

Let's say a counter was used as the nonce rather than timestamps and there are hundreds of sensors connected to the gateway. Then the gateway would need to keep track of each individual counter that belongs to each sensor (complications like power cycling retention, flash endurance and etc) in order to prevent replay attacks. But using timestamps (and sharing the current time to the sensors initially) no such counters need to be monitored - wouldn't this be right?

Let's go back to the button example, and say that a counter nonce was used. The man in middle could then listen in to a button event packet and simultaneously do jamming at the end of the data packet (during CRC). This way the gateway did not receive the packet and it has not incremented its counter value (for this sensor). The jammer however did receive the packet (hoping that there was no bit errors). The jammer will continuously jam the sensor for future packets - to prevent the gateway to update its counter. Then later, it would transmit the packet it copied earlier - and the packet would be accepted(!) Using timestamps this would not happen, as I can see it. Or am I missing something here...?

$\endgroup$
2
$\begingroup$

It seems you're worried about two distinct attacks: replay attack (attacker reads a packet and re-sends it later), and a "delay attack" (attacker intercepts a packet, blocks it, and sends it later).

The replay attack can be avoided with counters or timestamps; as you mentioned, timestamps can be easier. The hard part is keeping clocks synchronized.

The delay attack can be detected with a timestamp (you need to authenticate the timestamp, e.g. in CCM mode you can include it in the additional data field).

Of course, you need to think about your application to see if you really need to protect against these attacks.

$\endgroup$
  • $\begingroup$ Thanks for clarifying the correct terms. During "pairing/commissioning" each party sends a certificate which verifies the public keys and corresponding sensor/gateway ID. Then ECDH is used to make the symmetric AES key. Clock synchronization is working, but not including current time yet (it's FHSS). Yes, I include the whole header (ADF), timestamp and everything. But, I guess that delay attacks still can happen during a short time frame - but then it's really not a problem as it can be considered as a "re-transmission". $\endgroup$ – hcglitte Sep 25 at 12:40
  • $\begingroup$ But I see one critical aspect here. If the sensor is reset (due to watchdog reset etc) it will have lost its "clock time". It will need to ask the gateway what the current time is. The sensor will not be able to know if this is a replay attack since its own clock is not ticking yet. So an attacker can set an incorrect time into a sensor. The only gained effect here is that the sensor becomes dysfunctional - but it should detect this (from gateway ACK) so that it can ask again for the time and hope its correct this time. Could the sensor include a challenge in the request perhaps? $\endgroup$ – hcglitte Sep 25 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.