[WireGuard] WireGuard key lifetime / keys in smartcard?

[WireGuard] WireGuard key lifetime / keys in smartcard?

[Nathaniel W Filardo]

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

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!

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.

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.

Thanks for a lovely piece of technology!
--nwf;

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

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[Jason A. Donenfeld]

Hey!

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@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...

Jason

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[Daniel Kahn Gillmor]

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

On Wed 2016-07-13 10:21:43 +0200, Jason A. Donenfeld wrote:
> 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.

it's not labeled officially an "HSM", but Gnuk is a USB hardware token
capable of X25519 and guarded storage of secret key material:

  http://www.fsij.org/doc-gnuk/
  https://anonscm.debian.org/git/gnuk/gnuk/gnuk.git/tree/README
  https://lists.alioth.debian.org/mailman/listinfo/gnuk-users

It has an open hardware design (the small FST-01 [0]) and also targets
the low-cost Olimex STM32-H103 [1].  It has a fully-free software stack
for those who might want to hack it to be more wireguard-friendly.

Access to the gnuk is usually routed through GnuPG, but it's clearly not
limited to that.

The author, Gniibe (cc'ed here), is helpful and responsive.  I'm sure if
anyone tried to get the gnuk working with wireguard he would be happy to
give pointers.

    --dkg

[0] http://www.seeedstudio.com/wiki/FST-01
    https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator
    https://www.seeedstudio.com/item_detail.html?p_id=1277
    https://www.seeedstudio.com/item_detail.html?p_id=1276

[1] https://www.olimex.com/Products/ARM/ST/STM32-H103/

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

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[Jason A. Donenfeld]

Hey Daniel,

Thanks for the pointer.

Gniibe -- pleased to meet you. What's programming these things like?
How much effort do you suppose it would take me to produce a very
stripped-down firmware for one of these that has these simple USB
operations:

- load key from host input
- multiply loaded key by host input
- erase key

What's the X25519 implementation in general like? Any architecture
specific tricks required to avoid sidechannel attacks and such?

Regards,
Jason

On Wed, Jul 13, 2016 at 11:01 AM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> On Wed 2016-07-13 10:21:43 +0200, Jason A. Donenfeld wrote:
>> 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.
>
> it's not labeled officially an "HSM", but Gnuk is a USB hardware token
> capable of X25519 and guarded storage of secret key material:
>
>   http://www.fsij.org/doc-gnuk/
>   https://anonscm.debian.org/git/gnuk/gnuk/gnuk.git/tree/README
>   https://lists.alioth.debian.org/mailman/listinfo/gnuk-users
>
> It has an open hardware design (the small FST-01 [0]) and also targets
> the low-cost Olimex STM32-H103 [1].  It has a fully-free software stack
> for those who might want to hack it to be more wireguard-friendly.
>
> Access to the gnuk is usually routed through GnuPG, but it's clearly not
> limited to that.
>
> The author, Gniibe (cc'ed here), is helpful and responsive.  I'm sure if
> anyone tried to get the gnuk working with wireguard he would be happy to
> give pointers.
>
>     --dkg
>
> [0] http://www.seeedstudio.com/wiki/FST-01
>     https://shop.fsf.org/storage-devices/neug-usb-true-random-number-generator
>     https://www.seeedstudio.com/item_detail.html?p_id=1277
>     https://www.seeedstudio.com/item_detail.html?p_id=1276
>
> [1] https://www.olimex.com/Products/ARM/ST/STM32-H103/

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[gric]

> What's programming these things like?

They are Cortex-M3 ARM microcontrollers (STM32F103). So pretty standard.
No java involved. As said earlier, they have free toolchains.

> How much effort do you suppose it would take me to produce a very
> stripped-down firmware for one of these that has these simple USB
> operations:
>
> - load key from host input
> - multiply loaded key by host input
> - erase key
>
> What's the X25519 implementation in general like? Any architecture
> specific tricks required to avoid sidechannel attacks and such?

Keys should be generated on the card if possible.

I suppose this stripped down firmware will not conform to the OpenPGP
Card specification, especially considering that there is no need for
user-space to ever touch the keys.

The operations themselves are not harder than usual to implement,
however it should be noted that the MCU provides:

- No crypto facilities of any kind.
- No anti-tampering mecanisms.
- No side-channel and fault injection mitigation.
- No features designed for random-number generation. Gnuk/NeuG uses the
STM32 ADCs.
- No dedicated area to store the keys. They seem to be stored in NOR.
- No code signature verification.

The list goes on. It is not officially labeled as a HSM because it is
not one. It could possibly help to protect the keys a bit from a
compromise of the host, but it will not hold for more than a few minutes
if you loose physical control of the dongle. I wonder what kind of
non-invasive attacks have been attempted, especially against the EC modes.

For personal use when a host compromise is detected, key rotation is
often a small effort compared to decontamination. The main benefit is to
require the attacker to connect to the host in order to capture
temporary keys or directly inject traffic in the tunnel, and to deny him
the ability to do so when the dongle is removed.

For servers, the maximum number of connected peers will be limited by
the MCU performance. Unfortunately a very large number of peers with
difficulties to update the server public key would be the only case
where reusing a key after a host compromise looks excusable.

It might feel better than to store keys in ~, however the security
benefits in the case of the STM32 do not seem sufficient to justify a
lot of added complexity.

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[Jason A. Donenfeld]

On Fri, Jul 15, 2016 at 8:44 PM, gric <gric@izri.org> wrote:
> They are Cortex-M3 ARM microcontrollers (STM32F103).

Cool, so shouldn't be too hard.

>
> Keys should be generated on the card if possible.

Right, of course.

>
> I suppose this stripped down firmware will not conform to the OpenPGP
> Card specification, especially considering that there is no need for
> user-space to ever touch the keys.

Right. Generate key. Multiply. Erase. Anything more complex risks
leaking the key due to implementation flaws, especially considering
the key is just stored in NOR as you explained below.

>
> The operations themselves are not harder than usual to implement,
> however it should be noted that the MCU provides:
>
> - No crypto facilities of any kind.
> - No anti-tampering mecanisms.
> - No side-channel and fault injection mitigation.
> - No features designed for random-number generation. Gnuk/NeuG uses the
> STM32 ADCs.
> - No dedicated area to store the keys. They seem to be stored in NOR.
> - No code signature verification.
>
> The list goes on. It is not officially labeled as a HSM because it is
> not one. It could possibly help to protect the keys a bit from a
> compromise of the host, but it will not hold for more than a few minutes
> if you loose physical control of the dongle. I wonder what kind of
> non-invasive attacks have been attempted, especially against the EC modes.

Not good. The poor RNG is especially worrying. So this isn't very
interesting in fact...

Do you know any dedicated chips that do X25519 that have a safe place
for storing them and a good RNG?

>
> For personal use when a host compromise is detected, key rotation is
> often a small effort compared to decontamination. The main benefit is to
> require the attacker to connect to the host in order to capture
> temporary keys or directly inject traffic in the tunnel, and to deny him
> the ability to do so when the dongle is removed.

Right. The idea is when inevitably the Linux box gets popped.
Preventing software-side cloning seems somewhat worthwhile.

> For servers, the maximum number of connected peers will be limited by
> the MCU performance. Unfortunately a very large number of peers with
> difficulties to update the server public key would be the only case
> where reusing a key after a host compromise looks excusable.

Curve25519 is pretty fast, but you're right -- maybe an M.3 would wind
up being intolerably slow.

>
> It might feel better than to store keys in ~, however the security
> benefits in the case of the STM32 do not seem sufficient to justify a
> lot of added complexity.

:(

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[Jonathan Rudenberg]

FWIW, the STM32F415 claims to have a hardware RNG and some capabilities =
to protect secrets stored in the onboard flash. The SC4-HSM apparently =
has TweetNaCl running on it: https://sc4.us/hsm/

No information on the performance of Curve25519 that I=E2=80=99m aware =
of.=

Re: [WireGuard] WireGuard key lifetime / keys in smartcard?

[NIIBE Yutaka]

Hello,

I'm not in the WireGuard mailing list.  So, my message will
be possibly bounced.  Please forward it if needed.

On 07/15/2016 09:12 PM, Jason A. Donenfeld wrote:
> Gniibe -- pleased to meet you. What's programming these things like?

Nice to meet you, too.

For Gnuk, it's a C programming with no useful library.  I only use
limited functions from C library (like memcpy), but avoid to use
complex one like malloc.  For Gnuk 1.0, I use ChibiOS/RT for threads.
For Gnuk 1.2, I switched to my own thread library, named Chopstx
(because I only need threads).

I use my own USB routine to implement USB functionality.

RSA is based on PolarSSL 1.2.10 (now, mbedSSL), heavily modified,
without blinding.

EdDSA and X25519 are my own implementation.

While I don't have an attitude of "not invented here" in general,
however, for the particular purpose of controlling our own crypto
computation by minimizing features, Gnuk has such a shape, currently.

> How much effort do you suppose it would take me to produce a very
> stripped-down firmware for one of these that has these simple USB
> operations:
> 
> - load key from host input
> - multiply loaded key by host input
> - erase key

Well, it highly depends on the methodology and the goal.  I show two
approaches below.

(1) Bigger is easier.  Please consider to get some SDK with full of
features from a vendor, which may include some feature-ful RTOS.  If
the SDK allows programming interface like POSIX, the barrier is lower.
Even you can use crypto library written for POSIX.  If you can use
vendor supplied USB stack and you can use template and generator for
USB device, it is easier.  Once you will get the functionality, please
consider improving by removing dependencies.

While I didn't started a big one with SDK, I also took an approach
like this, started by using ChibiOS/RT, and stripped down to Chipstx.
In other words, for Gnuk 1.2, I did my best to stripped down things,
so that I can control/see/explain how computation is done.


(2) You can start from Chopstx 1.1.  For a Cortex-M0plus 48MHz board,
which I designed (and I plan to manufacture now), I wrote an example
application where I can connect to /dev/ttyACM0:


http://git.gniibe.org/gitweb/?p=chopstx/chopstx.git;a=tree;f=example-fs-bb48

I am going to add EdDSA and X25519 to this application to see how it's
fast/slow enough.

Once you will get things working in this approach, you can change USB
device implementation to your own vendor specific protocol (or any
others).


> What's the X25519 implementation in general like? Any architecture
> specific tricks required to avoid sidechannel attacks and such?

In general, we use Montgomery ladder (against timing attacks).  I also
use Montgomery ladder in Gnuk.  Choice of radix would be architecture
specific.

Implementations for PC have to care about cache and/or branch target
prediction, because of sidechannel attacks.  I don't care about these
because my target architecture doesn't have cache and branch prediction.

Cortex-M3 architecture has a multiplier with an optimization.  So,
it's timing differs.  32-bit x 32-bit -> 64-bit multiplication takes
less clocks when higher 32-bit will be zero.  I believe that this is
OK for Gnuk (attacker cannot mount this for some timing attack, in
practice).  But, since it is true that timing differs, I am going to
use Cortex-M0plus because of constant time for multiplication (and
it's slower).  Slowness is important to mitigate brute force attack
in the worse case where a control is stolen.
--