OpenSSH's Support for U2F/Fido Security(github.com)
github.com
OpenSSH's Support for U2F/Fido Security
https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.u2f
7 comments
Praise the Maker. I've been waiting 9 years for this.
Wow neat. I've been using yubico-pam module for a while now, to enforce hardware auth for SSH _without clientside config_ (yubikeys can send a OTP by acting as a keyboard).
U2F support would achieve this without the extra server PAM config unique to yubico and remove reliance on a separate auth server - not to mention remove reliance on these particular type of keys that support their OTP which are pricey.
U2F support would achieve this without the extra server PAM config unique to yubico and remove reliance on a separate auth server - not to mention remove reliance on these particular type of keys that support their OTP which are pricey.
Can this be used with a Nitrokey?
I understand OpenSSH is going to support the FIDO U2F standard in which case all standard-conform implementations would work, including Nitrokey FIDO U2F devices.
Does this mean U2F support is coming to OpenSSH (server and client) without the need for custom patches? That would be really awesome.
Current support works as a supplementary form of verification. This _will be_ your keypair, which is cooler
What are the biggest advantages/improvements over generating a "classic" private/public keypair with for example a Yubikey [1]?
[1] https://github.com/drduh/YubiKey-Guide
[1] https://github.com/drduh/YubiKey-Guide
- The administrator can enforce use of hardware-backed keys [1]
- U2F Tokens cost $8-$25 and are significantly cheaper than full-blown Yubikeys
- U2F Tokens do not have a key limit, which enables using a unique public key per server for privacy/anonymity
[1] https://github.com/openssh/openssh-portable/blob/master/PROT...
- U2F Tokens cost $8-$25 and are significantly cheaper than full-blown Yubikeys
- U2F Tokens do not have a key limit, which enables using a unique public key per server for privacy/anonymity
[1] https://github.com/openssh/openssh-portable/blob/master/PROT...
> U2F Tokens do not have a key limit
They must have some limit. EC Keys are roughly 32 (256 bit) or 48 (384 bit) bytes (x2 to store the public half, right?), and most of these devices don't have MB of storage afaik... I think they have security chips with like 64-256kb of secure storage. So once you get into the range of thousands of sites, wouldn't you run out of room?
ETA: thanks akerl, I didn't realize that's what they (or most of them) were doing; I didn't even realize deterministically generating an EC key from a seed was efficient enough to do it quickly on a tiny embedded chip.
They must have some limit. EC Keys are roughly 32 (256 bit) or 48 (384 bit) bytes (x2 to store the public half, right?), and most of these devices don't have MB of storage afaik... I think they have security chips with like 64-256kb of secure storage. So once you get into the range of thousands of sites, wouldn't you run out of room?
ETA: thanks akerl, I didn't realize that's what they (or most of them) were doing; I didn't even realize deterministically generating an EC key from a seed was efficient enough to do it quickly on a tiny embedded chip.
In theory, yes. In practice, the way that most U2F tokens (for example, Yubikeys) work is to storage a single device-specific secret key on the token, which never changes. Then, when “adding” a key for a site, they take the provided details from the server as inputs, along with the secret key, to derive a new, site-specific private key, which is used for U2F. That allows them to “store” an unlimited number of site keys. Note that this method isn’t mandated by the U2F spec, so it’s not guaranteed that any key which implements U2F will do so in this way.
The OpenSSH protocol doc alludes to this requirement when they talk about why U2F needed a custom method for interfacing with SSH: the site’s handle needs to be provided as input to the key, so that it can re-derive the site-specific private key, and that communication channel didn’t already exist in ssh-agent.
The OpenSSH protocol doc alludes to this requirement when they talk about why U2F needed a custom method for interfacing with SSH: the site’s handle needs to be provided as input to the key, so that it can re-derive the site-specific private key, and that communication channel didn’t already exist in ssh-agent.
Critically this isn't quite correct.
The handle (IIRC the FIDO spec calls it a cookie but that doesn't matter) is NOT chosen by the relying party (in this case a SSH server you're logging into). It's chosen by the token itself during the enrollment process and given to the relying party with the other results of enrollment to be stored.
The token will use local random data in addition to random data supplied by the relying party for choosing a private key (and thus in the design you describe, the handle). This is a common design choice in cryptographic systems because it means if either Alice OR Bob really used random numbers the results are truly random, things only go badly if both parties defect.
In WebAuthn this means if you use your token to enroll with Google, and Facebook, and say Twitter, so long as the people who built the token did a good job it won't matter if both Google and Facebook are trying to betray you and deliberately didn't use random data, they can't attack your Twitter account this way.
Edit: refer to the device as a "token" not a key for clarity
The handle (IIRC the FIDO spec calls it a cookie but that doesn't matter) is NOT chosen by the relying party (in this case a SSH server you're logging into). It's chosen by the token itself during the enrollment process and given to the relying party with the other results of enrollment to be stored.
The token will use local random data in addition to random data supplied by the relying party for choosing a private key (and thus in the design you describe, the handle). This is a common design choice in cryptographic systems because it means if either Alice OR Bob really used random numbers the results are truly random, things only go badly if both parties defect.
In WebAuthn this means if you use your token to enroll with Google, and Facebook, and say Twitter, so long as the people who built the token did a good job it won't matter if both Google and Facebook are trying to betray you and deliberately didn't use random data, they can't attack your Twitter account this way.
Edit: refer to the device as a "token" not a key for clarity
I feel like a much simpler correction might have been “you meant application ID instead of key handle”, given that the application ID is based on the individual server (it’s generally partly the URL and a server-provided challenge), and is combined with the token secret key to create the full handle.
Nothing in my comment implied that if google betrayed you, it would leak your facebook token.
Nothing in my comment implied that if google betrayed you, it would leak your facebook token.
Er no? I think you're still not getting it. The essential trick is that the token gets to randomly pick the value for this cookie, it isn't depending on the application ID.
One example way you can do this goes like this:
* Token has a Secret Key S baked inside it
* During enrollment the token makes a random private key P1 and a corresponding public key K1
* It makes a Cookie C1 by encrypting P1 using S
* It signs a message Ma with P1 to produce Za
* It sends C1, K1 and Za
The relying party gets to influence Ma but they do NOT get to pick any of these other values like P1, C1, K1.
The relying party verifies that Za is indeed a signature of Ma with K1 and if so enrollment worked, store C1 and K1
Now, after enrollment the relying party can produce new challenge messages Mb Mc Md and so on for ever, and each time it supplies the token with C1.
Given C1 and Mb, the token can decrypt C1 with S to get back P1, and then it can sign Mb with P1 to produce Zb. It sends that back.
The relying party can confirm that Zb is a signature of Mb with K1 and so this must be the genuine token that was enrolled previously.
One example way you can do this goes like this:
* Token has a Secret Key S baked inside it
* During enrollment the token makes a random private key P1 and a corresponding public key K1
* It makes a Cookie C1 by encrypting P1 using S
* It signs a message Ma with P1 to produce Za
* It sends C1, K1 and Za
The relying party gets to influence Ma but they do NOT get to pick any of these other values like P1, C1, K1.
The relying party verifies that Za is indeed a signature of Ma with K1 and if so enrollment worked, store C1 and K1
Now, after enrollment the relying party can produce new challenge messages Mb Mc Md and so on for ever, and each time it supplies the token with C1.
Given C1 and Mb, the token can decrypt C1 with S to get back P1, and then it can sign Mb with P1 to produce Zb. It sends that back.
The relying party can confirm that Zb is a signature of Mb with K1 and so this must be the genuine token that was enrolled previously.
Does such approach as desribed by you mean that token needs to store P1/K1 for every site?
AFAIK It does not.
And if it does not, your explanation contains bigger errors about enrollment/process.
@akrel described it much better.
AFAIK It does not.
And if it does not, your explanation contains bigger errors about enrollment/process.
@akrel described it much better.
In my description I specifically explain that the token gets P1 back by decrypting C1 with S so that it needn't be stored.
You've become fixated on the part akerl_ (not @akrel) got right, that tokens don't store the private key but missed the _essential_ element they got wrong which is how this key is generated.
One really obvious consequence of things working as I explained rather than as akerl_ (presumably mistakenly not maliciously) explained is what happens if we do enrollment again with the same token for the same Relying Party, for example maybe Alice and Bob are a couple sharing a token.
In reality, as in my explanation, these enrollments produce completely different results, the token will pick a random P1 (thus K1, C1, etc.) when Alice enrolls and a different random P2 (thus K2, C2, etc.) when Bob enrolls, and for the Relying Party everything is different between these two enrollments, just as if the token was different.
In akerl_'s description Alice and Bob would get the same application ID, same results, and now a Relying Party can tell that Alice and Bob are using the same token.
You've become fixated on the part akerl_ (not @akrel) got right, that tokens don't store the private key but missed the _essential_ element they got wrong which is how this key is generated.
One really obvious consequence of things working as I explained rather than as akerl_ (presumably mistakenly not maliciously) explained is what happens if we do enrollment again with the same token for the same Relying Party, for example maybe Alice and Bob are a couple sharing a token.
In reality, as in my explanation, these enrollments produce completely different results, the token will pick a random P1 (thus K1, C1, etc.) when Alice enrolls and a different random P2 (thus K2, C2, etc.) when Bob enrolls, and for the Relying Party everything is different between these two enrollments, just as if the token was different.
In akerl_'s description Alice and Bob would get the same application ID, same results, and now a Relying Party can tell that Alice and Bob are using the same token.
The U2F protocol uses a master secret that signs a KDF. Essentiall you generate a keypair given a certain input and sign the output. You can produce virtually unlimited keys from a single source.
In RSA you need to pick primes, if you pick random numbers RSA doesn't work. But the elliptic curve public key systems work with more or less arbitrary numbers so you can just use any random number as a key. Some magic numbers like zero may not work depending on the algorithm, but
(a) you can exclude those explicitly with a tiny amount of effort
AND
(b) probability of picking any such number for a 128-bit key is insignificant
(a) you can exclude those explicitly with a tiny amount of effort
AND
(b) probability of picking any such number for a 128-bit key is insignificant
Aren't the keys are generated dynamically every time, based on the devices secret and the pub key id.
[deleted]
> - The administrator can enforce use of hardware-backed keys [1]
This is also available on PKCS/OpenPGP for some tokens (and not only for auth keys). See: https://developers.yubico.com/PIV/Introduction/PIV_attestati... and https://developers.yubico.com/PGP/Attestation.html
This is also available on PKCS/OpenPGP for some tokens (and not only for auth keys). See: https://developers.yubico.com/PIV/Introduction/PIV_attestati... and https://developers.yubico.com/PGP/Attestation.html
Importantly, there are fully open source implementations of U2F hardware tokens.
On top of that, U2F tokens have no memory.
This makes them more durable and make the chipset even smaller.
On top of that, U2F tokens have no memory.
This makes them more durable and make the chipset even smaller.
They do have a device counter, incremented on every usage, to help detect cloning. It's up to the server whether to enforce the constraint that the counter increase on every usage. Unfortunately this means that the token does need a little bit of memory.
I don't know whether FIDO2 has the same design.
I don't know whether FIDO2 has the same design.
FIDO2 has, it's an expansion of u2f to allow for more and wider use cases.
Not having to support the OpenSSH / OpenSC / GPG stack is a big one for me. The built-in support shipped on MacOS just works[1], Putty-CAC just works on Windows, but the OpenSC + GPG setup is semi-stable and will randomly fail in ways which require you to stop what you're working on to kill daemons or unplug/replug the device to get it working again. I would not want to support anything involving that stack.
1. The Yubikey docs describe the pre-Sierra process — https://support.apple.com/en-us/HT208372 has what most people will want to use after 2016. See https://github.com/Yubico/developers.yubico.com/issues/197.
1. The Yubikey docs describe the pre-Sierra process — https://support.apple.com/en-us/HT208372 has what most people will want to use after 2016. See https://github.com/Yubico/developers.yubico.com/issues/197.
This!
Setting up a yubikey via gpg to be an agent for ssh was such a pain at least 2 years ago.
Setting up a yubikey via gpg to be an agent for ssh was such a pain at least 2 years ago.
The PIV/OpenSC way work absolutely perfectly for me. Even on Windows.
Interesting. I had so many issues with the SC daemon on Mac that I eventually just gave up and reverted to keeping my local ssh key in ~/.ssh/ with a passphrase on it.
Still is. Just randomly fails.
The principle security improvement is that it’s borderline impossible to mess up provisioning a U2F token, regardless of the technical acumen of the user, in such a way that you can successfully log in but you’ve got an insecure config.
By contrast, GPG is full of footguns. To pick an arbitrary example: many guides walk you through generating the GPG key on your regular computer and then importing it to the the Yubikey, and at best there’s a note suggesting you remove the key afterwards. At worst, there’s not.
By contrast, GPG is full of footguns. To pick an arbitrary example: many guides walk you through generating the GPG key on your regular computer and then importing it to the the Yubikey, and at best there’s a note suggesting you remove the key afterwards. At worst, there’s not.
There was a good reason for creating key material external to the token though, even though it's objectively more secure to let the token generate it. In the past(and possibly this is still the case) most sites had flawed U2F implementations, in the sense that you could only register one U2F key to an account (or rather, you could normally only pick one instance of any supported 2FA method e.g. SMS).
If your U2F token was lost or damaged it would thus permenantly render your accounts inaccessible (depending on whether or not account recovery bypasses U2F), and the best practice to avoid that was to have two tokens initialised with the same key material and to keep one in a safe place at home / bank safe-deposit box / other secure location. Then, if you needed to regain control you still had a valid U2F token.
As U2F gains traction more sites are implementing it properly with multi token support, which renders this method obsolete, but that's the historical reasoning.
If your U2F token was lost or damaged it would thus permenantly render your accounts inaccessible (depending on whether or not account recovery bypasses U2F), and the best practice to avoid that was to have two tokens initialised with the same key material and to keep one in a safe place at home / bank safe-deposit box / other secure location. Then, if you needed to regain control you still had a valid U2F token.
As U2F gains traction more sites are implementing it properly with multi token support, which renders this method obsolete, but that's the historical reasoning.
I’m not sure I understand the case you’re making. The fact that many sites have horrible implementations of MFA, where you can only enroll a single U2F device, couldn’t possibly have been the “good reason for creating key material external to the token”, because creating key material external to the token isn’t a feature of mainstream U2F tokens, it’s something that has been historically supported by GPG hardware devices.
Yes, those sites should implement U2F support better, but the question was about why U2F is more secure than GPG, and ~“because it’s harder to mishandle the private key during setup” is pretty solidly an accurate answer.
Yes, those sites should implement U2F support better, but the question was about why U2F is more secure than GPG, and ~“because it’s harder to mishandle the private key during setup” is pretty solidly an accurate answer.
Being able to use a standard U2F-compliant token means a much simpler setup to get things working. There is no need to setup anything on the key itself, beyond the standard new key registration procedure. Existing U2F keys used to authenticate with web services (WebAuthn) can be reused.
U2F security keys are cheaper too.
U2F security keys are cheaper too.
For starters, the "classic" approach needs a dongle with explicit support for OpenPGP. With the U2F support one could use the cheaper U2F-only ones.
I posted this, because I find this very cool. But before using this in production anywhere, I wanted to find out how secure people think this is and what should be done regarding audits etc before it can be used in a serious system.
Does anyone have insight into the auditing process at openssh?
Does anyone have insight into the auditing process at openssh?
> I wanted to find out how secure people think this is
It depends on what do you compare this with. PKCS/OpenPGP smartcard is protected by a PIN (6 digits min, 3 tries and it locks itself out) and then touch on each use (with Yubikey).
U2F on the other hand it just protected by touch so anyone having the token can authorize themselves. (Sites usually use it in conjunction with username/password that is "something you know").
On the yet another hand I didn't review the implementation and would welcome corrections here.
It depends on what do you compare this with. PKCS/OpenPGP smartcard is protected by a PIN (6 digits min, 3 tries and it locks itself out) and then touch on each use (with Yubikey).
U2F on the other hand it just protected by touch so anyone having the token can authorize themselves. (Sites usually use it in conjunction with username/password that is "something you know").
On the yet another hand I didn't review the implementation and would welcome corrections here.
U2F/FIDO2 supports user verification (UV) in addition to user presence (UP). So you should be able to do the same, but I haven't tested if the current implementation supports it.
Their own documentation suggests these are the same thing and both refer to the need to press a button or close a contact or whatever:
Generically, the term “User Verification” may also refer to this “Test for User Presence”
from e.g.
https://fidoalliance.org/specs/fido-security-requirements-v1...
Generically, the term “User Verification” may also refer to this “Test for User Presence”
from e.g.
https://fidoalliance.org/specs/fido-security-requirements-v1...
Weird, this spec has a little bit of a different terminology. I think it's better to refer to CTAP2 or WebAuthn directly. UV refers to PIN or biometric, it's in addition to UP.
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl...
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-cl...
Note that CTAP and WebAuthn are newer and although they contain U2F for backwards compatibility reasons U2F doesn't contain CTAP2 and WebAuthn. U2F is also surprisingly simple protocol (two specs on FIDO site).
Yes, and exactly because FIDO2 is backward compatible with U2F the definition of UV can't be ambiguous, otherwise you could have older U2F keys that pretend to do FIDO2-UV when in fact they aren't.
Yubikey just announced a key with a fingerprint reader today.
Besides the point that it wouldn't be a secure replacement for a password/PIN, I wonder if it would have support for multiple valid fingerprints. Some time ago, I got cut on my finger and was having some trouble getting my fingerprint recognized. It would suck to get locked out of stuff because of a cut.
Good point.
When I used a Yubikey as a Smartcard it did in fact prompt for a passphrase. But that was via PKCS/SmartCard method, not U2F.
When I used a Yubikey as a Smartcard it did in fact prompt for a passphrase. But that was via PKCS/SmartCard method, not U2F.
There were comments in https://news.ycombinator.com/item?id=21417182
Oh no. I searched for ssh before I posted this and I think I missed that post.
Thanks for pointing that discussion.
Sorry for double posting.
Thanks for pointing that discussion.
Sorry for double posting.
This doc doesn't explain what the enrollment process will look like, there are opportunities here to make this better or worse. Enrollment is crucial to the user experience for WebAuthn/ U2F.
There's also a weird intermediary introduced that I think users may struggle to get their heads around. The FIDO cookie (this doc calls it a "handle" and the WebAuthn spec calls it the "Credential ID") is needed before a client can authenticate, and naturally you'd want to store this on a server, but in SSH the client chooses the authentication method to try not the server, so this cookie has to be stored on the client machine.
Say you enroll on your laptop. The laptop knows a cookie, the FIDO can take that cookie and prove it knows the private key, and that's enough to sign into the server. But without the FIDO key the laptop can't do anything, and without the laptop the FIDO key doesn't know which cookie is needed.
In effect it's two of the same factor. Something you have: The laptop and Something Else that you also have: The FIDO token.
There's also a weird intermediary introduced that I think users may struggle to get their heads around. The FIDO cookie (this doc calls it a "handle" and the WebAuthn spec calls it the "Credential ID") is needed before a client can authenticate, and naturally you'd want to store this on a server, but in SSH the client chooses the authentication method to try not the server, so this cookie has to be stored on the client machine.
Say you enroll on your laptop. The laptop knows a cookie, the FIDO can take that cookie and prove it knows the private key, and that's enough to sign into the server. But without the FIDO key the laptop can't do anything, and without the laptop the FIDO key doesn't know which cookie is needed.
In effect it's two of the same factor. Something you have: The laptop and Something Else that you also have: The FIDO token.
Solution: keep the token on a keyring, don't leave it in your laptop all the time. The point of 2FA is to prevent someone else from logging into the same account via a stolen laptop or stolen username/password.
>so this cookie has to be stored on the client machine.
Not following how you arrived at this. In the U2F, the server holds on to a copy of the key handle. Then during authentication, sends the key handle and challenge (referred to as "message" in this openssh doc) to the client.
Not following how you arrived at this. In the U2F, the server holds on to a copy of the key handle. Then during authentication, sends the key handle and challenge (referred to as "message" in this openssh doc) to the client.
That is exactly how it works for WebAuthn, yes. The server sends over this cookie and then the client uses it.
But SSH is defined with the _Client_ picking how to authenticate first, so they can't do this.
There isn't a step in the SSH Authentication protocol where the server can say "Oh, here's the FIDO cookie you need". The SSH design says that (for public keys) the client starts by proposing "Hi, I can prove I know the private key that goes with this public key K1" and then the server either says "OK prove it" or "No, what else?". You can see this corresponds to the authorized_keys file on the server.
So instead you'll see the document calls this value "key_handle" and you'll see it is in the "private key" stored on the client, not with the "public key" stored on servers.
But SSH is defined with the _Client_ picking how to authenticate first, so they can't do this.
There isn't a step in the SSH Authentication protocol where the server can say "Oh, here's the FIDO cookie you need". The SSH design says that (for public keys) the client starts by proposing "Hi, I can prove I know the private key that goes with this public key K1" and then the server either says "OK prove it" or "No, what else?". You can see this corresponds to the authorized_keys file on the server.
So instead you'll see the document calls this value "key_handle" and you'll see it is in the "private key" stored on the client, not with the "public key" stored on servers.