WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* Re: Support FIDO2/CTAP2 security tokens as keystore
@ 2019-08-30 11:42 Nicolas Stalder
  2019-08-30 18:00 ` Phil Hofer
  0 siblings, 1 reply; 10+ messages in thread
From: Nicolas Stalder @ 2019-08-30 11:42 UTC (permalink / raw)
  To: wireguard

Having something like this has been my dream for a while now, and I
intend to make it
possible with my company's open source FIDO2 product (SoloKeys). No ETA as we're
juggling implementation of other functionality with limited resources.

Note that FIDO2 directly won't work, as it only defines signatures of
certain (not all) payloads
(and with the hmac-extension some HMACs).

The main use cases I see are in a "road warrior" kind of setup:
- can use on other people's computers (or even one's own that are
semi-untrusted and infrequently connect)
- no need to synchronize key out of band - use “donglenet”
- once removed, connections are closed

Use as baby HSM on a server may are may not make sense too, as long as
the microcontroller
can keep up with the number of connections that need (re)keying. To
make this efficient, I'm separately
working on packaging up Bjoern Haase's Cortex-M4 implementation [a] in
an easily usable
form [b].

If my understanding is correct, the bare minimum functionality is:
- store key non-extractably on device (unless you're Colin O'Flynn...)
  (if there is an issue, just rotate the key)
- periodically do Curve25519 Diffie-Hellman to generate sessions keys
  (that are revealed to the client, possibly with some sort of
transport layer security)

Beyond minimal functionality there are questions of how to enroll
keys, how to select if there are multiple...

The threat model would be along the lines of: if the key is in the
port, can connect; if not, cannot.
This does prevent malicious processes in user space (or root) from
stealing the key.

Two layers of security could be added:
- "user presence" check requiring an initial key press on the token.
- "user verification": PIN to unlock key (adding something you know to
something you have)
I assume pressing the key every two minutes (Rekey-After-Time) is
annoying, so perhaps an initial verification
should be good for some time, perhaps per endpoint, perhaps globally.

Regarding implementation I see three basic paths:
- CTAPHID has "vendor" commands [1], use these. Advantage is that raw
CTAPHID is a super simple protocol,
and with FIDO2 maybe becoming more widespread, udev rules will already
be in place [2].
- alternative CTAPHID option: instead of raw vendor commands, use
CTAPHID_CBOR and extend the
Authenticator API with "authenticatorVendor" commands [3]. Disadvantage: CBOR :)
- CCID route: entails supporting the full smartcard stack cruft
someway or other.. ugh, but possible.
Maybe based on PIV? That standard doesn't include the required
cryptography, but it's nicely split in
three parts, where parts 2 + 3 constrain general ISO 7816 into a
protocol, whereas specifics on keys
and their cryptography are constrained to part 1, which could then be
modified [c, page 31].

Personally, I'd prefer options 1 or 2, with the goal of eventually
adding the necessary extensions to
the FIDO CTAP spec. Work towards option 3 is very very experimentally
being explored in [d].

What is completely unclear to me (not being a kernel or Wireguard dev
at all) is how Wireguard as part of the
kernel would connect and interface with the token.

Hence it would be useful if someone with Wireguard and kernel
expertise could define a minimal interface
(mostly: "do DH with your secret key against this public key, give me
the secret") for a small shim process to implement against,
which in turn would speak CTAP2 (or ISO 7816) to the token.
Maybe this minimal interface already exists? Is this where netlink comes in?
Should Noise be used to confidentially mutually authenticate Wireguard
and the token?


Cheers,
Nicolas Stalder


[a] https://github.com/BjoernMHaase/fe25519/tree/master/STM32F407/crypto
[b] https://github.com/nickray/salty
[1] https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#usb-vendor-specific-commands
[2] https://github.com/systemd/systemd/pull/13357
[3] https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html#commands
[c] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-73-4.pdf
[d] https://zissou.dev
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-30 11:42 Support FIDO2/CTAP2 security tokens as keystore Nicolas Stalder
@ 2019-08-30 18:00 ` Phil Hofer
  0 siblings, 0 replies; 10+ messages in thread
From: Phil Hofer @ 2019-08-30 18:00 UTC (permalink / raw)
  To: Nicolas Stalder; +Cc: wireguard

[-- Attachment #1.1.1: Type: text/plain, Size: 890 bytes --]

>     If my understanding is correct, the bare minimum functionality is:
>     

> -   store key non-extractably on device (unless you're Colin O'Flynn...)
>     (if there is an issue, just rotate the key)
>     

> -   periodically do Curve25519 Diffie-Hellman to generate sessions keys
>     (that are revealed to the client, possibly with some sort of
>     transport layer security)

Are there HSMs out there that performs ECDHE fast enough
to make this reasonably DoS-proof?

The last HSM I worked with was a ("cheap," $650) YubiHSM that still
took a pretty long time (~250ms) to do ECDHE. Fine for cert
management, but no good for pointing at the internet.

An alternative that would tolerate slow HSMs would be to
periodically rotate the Wireguard host key with an attestation
from the HSM, but then you'd need an out-of-band key distribution
solution.

- Phil

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 477 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-25 19:30         ` Derrick Lyndon Pallas
@ 2019-08-26 14:34           ` Andreas Karlsson
  0 siblings, 0 replies; 10+ messages in thread
From: Andreas Karlsson @ 2019-08-26 14:34 UTC (permalink / raw)
  To: Derrick Lyndon Pallas; +Cc: wireguard

On 8/25/19 9:30 PM, Derrick Lyndon Pallas wrote:
> The private key is in kernel memory and is available via netlink and cli.

Obviously, but my assumption was that the reason Rene wanted FIDO 
support was to move the private key out from the kernel memory and into 
an external device. Otherwise there would not be any real benefit from 
using FIDO.

Personally I doubt the benefit you get from moving the private key out 
to an external device would be worth to effort, but then I have no 
interest in FIDO support myself.

Andreas
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-24 19:01       ` Andreas Karlsson
@ 2019-08-25 19:30         ` Derrick Lyndon Pallas
  2019-08-26 14:34           ` Andreas Karlsson
  0 siblings, 1 reply; 10+ messages in thread
From: Derrick Lyndon Pallas @ 2019-08-25 19:30 UTC (permalink / raw)
  To: Andreas Karlsson; +Cc: wireguard

The private key is in kernel memory and is available via netlink and cli.

~Derrick • iPhone

> On Aug 24, 2019, at 12:01 PM, Andreas Karlsson <andreas@proxel.se> wrote:
> 
>> On 8/24/19 4:08 PM, Matthias Urlichs wrote:
>> Anyone with *root* access to the running machine can do that. They also
>> can trivially read the kernel memory (if nothing else, by installing a
>> module) and walk the kernel data structures to find the private and/or
>> shared key.
> 
> No, anyone with root access can only get the shared key used for encrypting data, not the actual private key. The private key does never leave the device.
> 
> Does this add enough extra security to be worth it? No idea. I haven't worked much with systems like this, only a little bit with SSL and SmartCards.
> 
> Andreas
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-24 14:08     ` Matthias Urlichs
@ 2019-08-24 19:01       ` Andreas Karlsson
  2019-08-25 19:30         ` Derrick Lyndon Pallas
  0 siblings, 1 reply; 10+ messages in thread
From: Andreas Karlsson @ 2019-08-24 19:01 UTC (permalink / raw)
  To: Matthias Urlichs, wireguard

On 8/24/19 4:08 PM, Matthias Urlichs wrote:
> Anyone with *root* access to the running machine can do that. They also
> can trivially read the kernel memory (if nothing else, by installing a
> module) and walk the kernel data structures to find the private and/or
> shared key.

No, anyone with root access can only get the shared key used for 
encrypting data, not the actual private key. The private key does never 
leave the device.

Does this add enough extra security to be worth it? No idea. I haven't 
worked much with systems like this, only a little bit with SSL and 
SmartCards.

Andreas
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-22  8:54   ` Rene 'Renne' Bartsch, B.Sc. Informatics
  2019-08-23  6:19     ` Reto
@ 2019-08-24 14:08     ` Matthias Urlichs
  2019-08-24 19:01       ` Andreas Karlsson
  1 sibling, 1 reply; 10+ messages in thread
From: Matthias Urlichs @ 2019-08-24 14:08 UTC (permalink / raw)
  To: wireguard

On 22.08.19 10:54, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> Anyone with access to the running machine or malicious software can
> read the keys on hard-disk. 

Anyone with *root* access to the running machine can do that. They also
can trivially read the kernel memory (if nothing else, by installing a
module) and walk the kernel data structures to find the private and/or
shared key.

IMHO: if your threat model includes randomly subverted systems in your
network, you have problems that wireguard cannot fix.

-- 
-- Matthias Urlichs

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-22  8:54   ` Rene 'Renne' Bartsch, B.Sc. Informatics
@ 2019-08-23  6:19     ` Reto
  2019-08-24 14:08     ` Matthias Urlichs
  1 sibling, 0 replies; 10+ messages in thread
From: Reto @ 2019-08-23  6:19 UTC (permalink / raw)
  To: wireguard

On Thu, Aug 22, 2019 at 10:54:56AM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> Anyone with access to the running machine or malicious software can read the
> keys on hard-disk.

No. That depends entirely on how you set it up. Permissions are a thing and you
don't need to constantly keep the corresponding storage unlocked either.

> How do you de-crypt the encrypted disk on a headless machine which has to
> reboot autonomously on error conditions?

How do you do that with a security token? It's the same issue really.
Either allow ssh access without the tunnel or use a serial connection or
vitalization thereof to unlock the secret and bring up the vpn.

> The point of security-tokens is you never get access to the private key.

Yes, my point is wg already allows you to do that, so what more do you need?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-18 17:09 ` Reto
@ 2019-08-22  8:54   ` Rene 'Renne' Bartsch, B.Sc. Informatics
  2019-08-23  6:19     ` Reto
  2019-08-24 14:08     ` Matthias Urlichs
  0 siblings, 2 replies; 10+ messages in thread
From: Rene 'Renne' Bartsch, B.Sc. Informatics @ 2019-08-22  8:54 UTC (permalink / raw)
  To: wireguard


Am 18.08.19 um 19:09 schrieb Reto:
> For starters, storing stuff on a hard disc is certainly not "quite 
> insecure".
> Are you aware that you can encrypt discs / partions / files?

Anyone with access to the running machine or malicious software can read 
the keys on hard-disk.

How do you de-crypt the encrypted disk on a headless machine which has 
to reboot autonomously on error conditions?

> Wireguard also allows you to set the private key on the fly, so you can feed it
> for example secrets stored in pass (gpg encrypted), which you *can* decrypt with
> a yubikey already.
>
> Are you speaking specifically about wg-quick?
> In that case the manpage already shows you how to feed wg encrypted secrets
>
>> Or, perhaps it is desirable to store private keys in encrypted form, such as  through
>> use of pass(1):
>> 	PostUp = wg set %i private-key <(pass WireGuard/private-keys/%i

The point of security-tokens is you never get access to the private key.

Instead you pass the stream-cipher encrypted with the public key to the 
security token

to be de-crypted by the security token.

Regards,

Renne

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Support FIDO2/CTAP2 security tokens as keystore
  2019-08-18 14:22 Rene 'Renne' Bartsch, B.Sc. Informatics
@ 2019-08-18 17:09 ` Reto
  2019-08-22  8:54   ` Rene 'Renne' Bartsch, B.Sc. Informatics
  0 siblings, 1 reply; 10+ messages in thread
From: Reto @ 2019-08-18 17:09 UTC (permalink / raw)
  To: wireguard

On Sun, Aug 18, 2019 at 04:22:49PM +0200, Rene 'Renne' Bartsch, B.Sc. Informatics wrote:
> currently the private key ist stored on HDD which is quite insecure.

What are you referring to?
Why do you consider a HDD insecure?

For starters, storing stuff on a hard disc is certainly not "quite insecure".
Are you aware that you can encrypt discs / partions / files?

Wireguard also allows you to set the private key on the fly, so you can feed it
for example secrets stored in pass (gpg encrypted), which you *can* decrypt with
a yubikey already.

Are you speaking specifically about wg-quick?
In that case the manpage already shows you how to feed wg encrypted secrets

> Or, perhaps it is desirable to store private keys in encrypted form, such as  through
> use of pass(1):
>	PostUp = wg set %i private-key <(pass WireGuard/private-keys/%i)

Of course pass is only an exapmple, use any way of decrypting the secret as you
see fit.
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Support FIDO2/CTAP2 security tokens as keystore
@ 2019-08-18 14:22 Rene 'Renne' Bartsch, B.Sc. Informatics
  2019-08-18 17:09 ` Reto
  0 siblings, 1 reply; 10+ messages in thread
From: Rene 'Renne' Bartsch, B.Sc. Informatics @ 2019-08-18 14:22 UTC (permalink / raw)
  To: WireGuard mailing list

Hi,

currently the private key ist stored on HDD which is quite insecure.
I suggest to support FIDO2/CTAP2 security tokens as keystore (see 
https://en.wikipedia.org/wiki/Client_to_Authenticator_Protocol).

Have Phun,

Renne
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-30 11:42 Support FIDO2/CTAP2 security tokens as keystore Nicolas Stalder
2019-08-30 18:00 ` Phil Hofer
  -- strict thread matches above, loose matches on Subject: below --
2019-08-18 14:22 Rene 'Renne' Bartsch, B.Sc. Informatics
2019-08-18 17:09 ` Reto
2019-08-22  8:54   ` Rene 'Renne' Bartsch, B.Sc. Informatics
2019-08-23  6:19     ` Reto
2019-08-24 14:08     ` Matthias Urlichs
2019-08-24 19:01       ` Andreas Karlsson
2019-08-25 19:30         ` Derrick Lyndon Pallas
2019-08-26 14:34           ` Andreas Karlsson

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git