Ephemeral key lifetime & system sleep

Ephemeral key lifetime & system sleep

[Jason A. Donenfeld]

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

Re: Ephemeral key lifetime & system sleep

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Wed 2016-12-07 16:20:43 -0500, Jason A. Donenfeld wrote:
> 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.

I think scrubbing the ephemeral keys prior to suspend is the right thing
to do.  It's simpler to reason about, sounds straightforward to
implement, the usability cost isn't that great, and it's likely to be
the right thing in almost all long-term suspend cases.

    --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Ephemeral key lifetime & system sleep

[Jason A. Donenfeld]

Very much a work in progress, but here's a first stab:
https://git.zx2c4.com/WireGuard/commit/?id=dc89b0ffcb38f668310efdabe7a415ead0742d70

Re: Ephemeral key lifetime & system sleep

[Kalin KOZHUHAROV]

On Thu, Dec 8, 2016 at 7:04 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> I think scrubbing the ephemeral keys prior to suspend is the right thing
> to do.  It's simpler to reason about, sounds straightforward to
> implement, the usability cost isn't that great, and it's likely to be
> the right thing in almost all long-term suspend cases.
>
+1

I never use suspend, except when I need to hack some suspect hardware
(forensics), or ATA SECURITY ERASE a "frozen" drive (anti-forensics).
kill_on_suspend is better, given that it will be auto re-established on resume.

Kalin.