[WireGuard] WireGuard key lifetime / keys in smartcard?

Jason A. Donenfeld Jason at zx2c4.com
Wed Jul 13 10:21:43 CEST 2016


What a pleasure it is to see you on this list. Incredible blast from the past.

On Wed, Jul 13, 2016 at 1:14 AM, Nathaniel W Filardo <nwf at cs.jhu.edu> wrote:
> I am sure this is a completely ignorant question, but: I'd love to have a
> wireguard host without direct access to its long-term identity keys to raise
> the difficulty of silently spoofing/cloning a tunnel endpoint after host
> compromise.  I can see two possible ways forward, though I'm sure there are
> others!

Not an ignorant question at all. This would indeed be very interesting.

> 1. Long-lived identity keys giving rise to shorter-lived keys.  Wireguard
>    would, as part of the handshake, include the signature that attested the
>    short-term key as a legitimate product of the long-term key.

This is something for which Noise is well suited. There wouldn't be
signatures, but rather a temporary key would be derived from the long
term one.

What kind of lifetime would be appropriate here, though? Presumably
the main wireguard instance would have to continually fetch new
ephemerals from the box with the longterm keys. If the main wireguard
instance is compromised, it'd then be possible to imitate the main
wireguard instance to the longterm key server, which presents again
the same issue. Or did you have in mind a kind of manual intervention?

> 2. Long-lived keys not in host memory (e.g. in a smartcard).  I don't know
>    if the kernel has an existing mechanism for upcalling to userland to
>    request a cryptographic transform, but it seems like a plausible thing to
>    want.  (I'm aware of the request-key mechanism, but that doesn't seem
>    like what'd be wanted here.)  Handshakes would be slow (limited by crypto
>    processor and upcall overhead) but otherwise the WireGuard protocol would
>    not change.

The kernel's crypto API has all sorts of async methods of getting
things done, and I'm pretty sure this was built with smartcards and
HSMs in mind. In our case, we wouldn't be asking for a signature but
rather an X25519 multiplication from the device. I assume there's some
ugly code out there for javacard, but I'm not sure if there's any real
HSM for 25519. Something to look into... Using hardware to prevent key
heists strikes me as generally the most robust solution.

A third option is to hide private keys between network namespaces. For
example, a particular container might receive a wg0 interface as its
sole link to the network, but would be unable to read out key material
from it. This is an easy sort of thing to support. Unfortunately, the
Linux kernel is a disaster from a security perspective and container
escapes are a dime a dozen...


More information about the WireGuard mailing list