OpenSSH support for FIDO RSA keys

[Jan Schermer]

Hello,
thank you all for comments.

I am testing on a Dell E5410 laptop equipped with TPM 2.0.
I am using this piece of software to use Windows Hello in SSH:
https://github.com/tavrez/openssh-sk-winhello <https://github.com/tavrez/openssh-sk-winhello>

When trying to generate key like this:
SSH_SK_PROVIDER=winhello.dll ssh-keygen -t  ecdsa-sk

^ I am prompted to insert a Security Key (and if I do everything works)

I opened an issue in that project here:
https://github.com/tavrez/openssh-sk-winhello/issues/9 <https://github.com/tavrez/openssh-sk-winhello/issues/9>

Which led me to believe it was a winhello.dll limitation, but it doesn’t seem to be.

When testing “real” FIDO (webauthn) on webauthn.io <http://webauthn.io/>, it seems to be using RSA keys only as well.

I also tried webauthn.me <http://webauthn.me/> and there I had to use the debugging mode and set the key to RSASSA instead of ECDSA to make it work with the TPM.

So maybe Windows Hello really doesn’t support anything but RSA? I don’t have any other (TPM 2.0) Windows device on hand (and even if I did, this it the hardware we use), so I’m not able to really test it.

I think support for RSA would be great, even if only to get around possible Windows Hello limitations. For me, the main reasons for using Windows Hello are
1) Price. It’s hard to convince your corporation to buy thousands of FIDO keys _and_ to create supporting processes for lost keys and stuff, but Windows Hello is already present on all corporate devices and just needs to be enabled. The hardware itself and user accounts tied to the keys are already secured (and disabled in case of theft etc.).  
2) FIDO itself is great because of attestation, otherwise we are stuck using ISO format smartcards with X509 certificates (and using those to infer SSH keys). Not nice or usable

So getting FIDO adopted (in any form) is a way to get your foot into door of corporate vendor-locked PKI. Security Key market is not yet infested with hot water peddlers and even vendors seem to understand (or are forced to fake) why it should be standard and open. Being able to use Windows Hello just makes it so much easier to adopt and it’s hard for vendors to dispute integral technology behind today’s Window security...

I am not going to argue for/against RSA vs ECDSA, but AFAIK RSA is not a “bad” algorithm in any way (implementations might have many flaws, but that’s just because RSA is ubiquitous and old), and even if it gets broken or weak one day, disabling it in OpenSSH will be the least of IT world problems :-)

Jan


> On 27. 8. 2021, at 19:27, Peter Stuge <peter at stuge.se> wrote:
> 
> Damien Miller wrote:
>> I'm expecting a big fight when I eventually push to remove ssh-dss,
> 
> FWIW I think that's long overdue, and understand your worry.
> 
> 
>> In the case of RSA/FIDO, it's really to support a single vendor
>> (admittedly an important one), but using an algorithm (RSA) which
>> almost everyone is moving away from in favour of elliptic-curve crypto,
> 
> Many are indeed moving, but popularity in itself doesn't really mean much.
> I for one like RSA in spite of the many caveats now known, because the math
> is simple (to me). But I by no means hate or reject ECC, it's just different.
> (Yes, ECC code can be simpler than RSA code.)
> 
> 
>> and that seems was chosen to support a legacy hardware standard (TPM 1.x)
>> that is already superseded.
> 
> I think the reason to add RSA/FIDO should be less to support TPM 1.x
> and more to create opportunity and/or a use-case for future RSA tokens.
> 
> I understand the code coverage concern, but since RSA is already
> quite heavily used in OpenSSH, would the overhead actually be large?
> 
> The FIDO code would of course grow, were you refering to that all along?
> 
> 
> Thanks and kind regards
> 
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://www.google.com/url?q=https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev&source=gmail-imap&ust=1630690230000000&usg=AOvVaw0g2hTB10t4n7Km8FrD--nL