-
Notifications
You must be signed in to change notification settings - Fork 333
Enable support for FIDO2/U2F security keys #541
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
requested by akshayku@
only prompt for a FIDO PIN if sshsk_enroll() fails with SSH_ERR_KEY_WRONG_PASSPHRASE, which never happens when sk-usbhid uses webauthn.dll and means we are communicating directly with a security key.
only prompt for a FIDO PIN if sshsk_sign() fails with SSH_ERR_KEY_WRONG_PASSPHRASE, which never happens when sk-usbhid uses webauthn.dll and means we are communicating directly with a security key.
only prompt for a FIDO PIN if sshsig_wrap_sign() fails with SSH_ERR_KEY_WRONG_PASSPHRASE, which never happens when sk-usbhid uses webauthn.dll and means we are communicating directly with a security key.
only prompt for a FIDO PIN if sshkey_certify() fails with SSH_ERR_KEY_WRONG_PASSPHRASE, which never happens when sk-usbhid uses webauthn.dll and means we are communicating directly with a security key.
I have pushed two commits to add support for git commit signatures using FIDO2/U2F security keys. In addition to the two commits, you will need a version of git built with git-for-windows/git#3561. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Appreciate your time for adding this functionality.
<LibreSSL-Path>$(SolutionDir)\LibreSSL\sdk\</LibreSSL-Path> | ||
<LibreSSL-x86-Path>$(SolutionDir)\LibreSSL\bin\desktop\x86\</LibreSSL-x86-Path> | ||
<LibreSSL-x64-Path>$(SolutionDir)\LibreSSL\bin\desktop\x64\</LibreSSL-x64-Path> | ||
<LibreSSL-arm64-Path>$(SolutionDir)\LibreSSL\bin\desktop\arm64\</LibreSSL-arm64-Path> | ||
<LibreSSL-arm-Path>$(SolutionDir)\LibreSSL\bin\desktop\arm\</LibreSSL-arm-Path> | ||
<fido2-Path>$(SolutionDir)\libfido2\</fido2-Path> | ||
<fido2-x86-Path>$(SolutionDir)\libfido2\Win32\Release\v143\static\</fido2-x86-Path> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
v143 -> I'm guessing it's compiled with visual studio 2022.
Win32-openssh is compiled with visual studio 2015, windows SDK v8.1.
Does it have any compatibility issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can FIDO be compiled with visual studio 2015, windows SDK v10?
We might switch to windows SDK v10 from windows SDK v8.1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not aware of any incompatibility. I had to disable a warning (C4201; nonstandard extension used: nameless struct/union
) to build libfido2 with Windows SDK 8.1 (using Visual Studio 2022). I don't have Visual Studio 2015 on my laptop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Building with Windows SDK 8.1 using Visual Studio 2015 works as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please remove the v143 here. Having this makes us change this as we move to different version of visual studio
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can change it once the vendoring process is complete, as it needs to match the SDK version used to build libfido2. CC @anmenaga
Have you implemented |
@tavrez |
webauthn.dll inside Windows 11 is version 3, I think it supports FIDO 2.1(according to this commit). |
these are needed by sk-usbhid.c when operating in environments with multiple authenticators attached.
unless explicitly specified, don't consider a sk_provider a key constraint, allowing ssh-sk keys using the default internal provider to be added with SSH2_AGENTC_ADD_IDENTITY instead of SSH2_AGENTC_ADD_ID_CONSTRAINED.
a sk_provider is required by ssh-sk-helper. as such, treat ssh-sk keys without a provider as belonging to the "internal" provider.
@@ -721,12 +733,31 @@ sk_enroll(uint32_t alg, const uint8_t *challenge, size_t challenge_len, | |||
skdebug(__func__, "fido_cred_set_type: %s", fido_strerr(r)); | |||
goto out; | |||
} | |||
if ((r = fido_cred_set_clientdata_hash(cred, challenge, | |||
challenge_len)) != FIDO_OK) { | |||
#ifndef WINDOWS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason why you are adding line 737 to 741 as it's new code for Unix?
https://github.com/openssh/openssh-portable/blob/V_8_6/sk-usbhid.c#L724
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used V_8_8 as reference: https://github.com/openssh/openssh-portable/blob/V_8_8/sk-usbhid.c#L724. I could trim that chunk to reduce the difference against V_8_6, but we would have to revisit it in V_8_8 or later. Let me know if you prefer that approach.
CI is failing with:
Successful runs seem to take ~54 minutes, so we are very close to the limit. I could keep pushing empty commits until we are lucky and CI passes again, but perhaps it would make sense to bump the limit. |
I've sent them a request to increase it to 90 minutes. Hopefully it gets approved. |
This PR enables client-side support for FIDO2/U2F security keys, allowing the generation and use of
ecdsa-sk
anded25519-sk
SSH keys on cross-platform and platform authenticators, from PowerShell and WSL.Build and test instructions can be found at here. I have uploaded Win64 and ARM64 symbols. (GitHub wouldn't let me attach them to the PR.)
Thank you,
-p.
CC @akshayku