Ephemeral key lifetime & system sleep

Jason A. Donenfeld Jason at zx2c4.com
Wed Dec 7 22:20:43 CET 2016


Hey guys,

As you know, WireGuard provides perfect forward secrecy, otherwise
known as key erasure, by zeroing out old keys in ram, and constantly
rotating in new keys. It keeps, at most, the current, the previous,
and the next key in ram, and for no more than a handful of minutes for
the oldest possible key. It accomplishes this by using the kernel's
timer_list structure, which is sufficiently lightweight and high
performance.

It does not, however, keep track of time during system suspend. This
means that if you put your computer to sleep for an hour, when you
wake it up, it will still be some amount of time before all old keys
are zeroed.

I could add the book keeping to make the key lifetime work across
suspend. The programming isn't that hard. If I did this, the resultant
behavior would be that when you wake up your computer, all keys will
be zeroed if the clock time has elapsed, and otherwise the the timer
will simply be updated to trigger at the correct suspend-adjusted
time.

But I was thinking that instead of this, maybe it'd be simpler and
even more desirable to simply *always wipe all keys immediately
/before/ system suspend*. This would have the desirable property of
preventing ephemeral key recovery from physical access to the ram or
CPU of a suspended system, or attacks against modified SMM handlers
pilfering data during resume just before handing control back to the
kernel. Is this desirable? Is it absurd?

The downside is that if you put your computer to sleep for just a
couple of seconds, when it comes back up, the [mostly invisible
anyway] 1-RTT handshake must occur again, and you won't be able to
decrypt any packets that were sent to you before going to sleep and
arrived after resuming.

The upside is the tinfoil hat security properties outlined above.

Thoughts on this?

Thanks,
Jason


More information about the WireGuard mailing list