1
$\begingroup$

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

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

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

If the sensor only transmits sensor data samples with timestamps, can one say that it's invulnerable to replay attacks?

And if the "sensor" includes a button to switch something on and off (real-time function), 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. The gateway would then need to keep track of each counter that belongs to each sensor (complications like power cycling retention, flash endurance, etc.) to prevent replay attacks. However, by 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 the 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 were no bit errors). The jammer will continuously jam the sensor for future packets -- to prevent the gateway from updating its counter. 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$

1 Answer 1

3
$\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$
2
  • $\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, 2019 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, 2019 at 12:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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