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 [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
