AES-CCM replay attack and nonce 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 &quot;sensor&quot; 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?
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.