WG: Need for HW-clock independent timestamps

[Axel Neumann]

I really appreciate the resumption.

Whatever mechanisms wireguard introduces to handle non-RTC devices with
limited flash-write cycles (which far most of the openWrt community
uses) would significantly ease the configuration of
every-even-ntp-traffic-secured networks.



Regarding
> Initiation of a wireguard
> tunnel for those devices would be: read last counter to variable X,
> increment last counter, store incremented counter to flash, tell
> wireguard to use X as basetime.

Do you mean update counter to flash for each peer for each handshake?
That may again result in a lot (10..100++ ???) of write cycles per day, no?

Otherwise, if done only once per overall wireguard initialization then
incrementing last counter by one would not be enough to ensure that
already used SQNs are not used again after a reboot.

Incrementing by e.g. 16000 (corresponding 16ms in real time) would allow
16k handshakes before the stored value had to be updated again.
Wireguard could even delay first handshake by 16ms to 100% ensure that
SQNs have never be used before.

Then, by setting system base time to stored counter value on wireguard
init, and
> choose a per-peer base
> time for the first handshake, and then simply increment that on each
> handshake
would be sufficient for our use case.

Just important that the peer base time used for all peers is always
given by the system base time when wireguard initialized (and NOT the
current time when the handshake is made).
Otherwise, an unexpected reboot of the system after >16ms may again lead
to re-used handshake SQNs.




On 04.02.19 15:56, Jason A. Donenfeld wrote:
> An update on this old thread:
> 
> The only requirement for the "timestamp" field is that it's
> monotonically increasing. I've been mulling over some improvements to
> the current situation of just sticking a nanosecond resolution
> timestamp in there raw, after discussing with Jann a few months ago
> and then with Ivan the last two days at FOSDEM.
> 
> First, it's quite trivial to whiten that by only allowing a resolution
> of 16 or so ms, which might mitigate various unrelated sidechannels
> that think they have an oracle in WireGuard.
> 
> Second, both Ivan and Jann have suggested that rather than always
> adding a fresh timestamp, we should instead choose a per-peer base
> time for the first handshake, and then simply increment that on each
> handshake (making sure that the stamp never exceeds the current time).
> While we're holding off on new features and nobs and whatnot until
> post kernel merge, this would then enable us to potentially add a
> specialized option for manually setting the base time. It would by
> default remain the time, as it is now, since that's almost always a
> reasonable decision. But for devices without an RTC and whose flash
> chips prohibit writing out a new timestamp once a second or minute or
> whatever, this would allow, instead, to just write out a counter once
> per boot, which is much more reasonable. Initiation of a wireguard
> tunnel for those devices would be: read last counter to variable X,
> increment last counter, store incremented counter to flash, tell
> wireguard to use X as basetime. I think this dance should handle a lot
> of the issues discussed in this thread.
> 
> Third, Ivan suggested that we actually add a blinding factor to the
> timestamps, simply by adding HASH(label||private||public) or similar
> to the stamp itself. I'll need to think carefully about the crypto
> before committing to anything, but this kind of transformation does
> not seem infeasible and might lessen a potential infoleak. A good
> idea, in other words.
> _______________________________________________
> WireGuard mailing list
> WireGuard at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>