CVE-2022-21449 breaking WebAuthn with ECDSA

Nitrokeys
#1

A recent vulnerability found in modern Java JDK ECDSA implementations breaks WebAuthn.

Since all Nitrokey Fido2 devices only support ECDSA, there is no alternative algorithm to switch to and users authenticating to affected backend implementations are screwed.

Backends such as Gitlab implement safe curve crypto such as ed25519 and therefore allow the use of an alternative.

As was already requested here [1], it would be good to have an alternative implemention available, as supported (though not required) by the Fido2 standard.

Other Fido2 vendors already provide such alternatives and their users can switch to those to avoid that risk.

I would like to point out that issues like CVE-2022-21449 are very much the reason why many respectable cryptographer recommend the use of safe ecc implementations https://safecurves.cr.yp.to/

Implementing the (NSA developed) ECDSA algorithm is required by the Fido2 standard but Fido2 devices can default to alternatives such as ed25519 and I would think that would make sense for an open source hardware vendor such as Nitrokey.

Thank you

1 Like
#2

[1] Documentation of FIDO2 supported crypto algorithms - #11 by frankm773

#3

Hi @Jeffoh82 !
Just to clear things up a bit:

  1. This is a server-side issue, introduced just recently for ECDSA, within the Java rewrite from C++ (which was not showing this bug); note though apparently other DSAs were broken in the previous versions.
  2. Following the article, we do not know if ed25519 was not affected either (please update me if I am wrong).
  3. Just a couple of notes to clear:
    • see these posts: Documentation of FIDO2 supported crypto algorithms - #8 by szszszsz
    • as a user you cannot select what algorithm you would like to use - this is requested server side. I understand Gitlab has a priority list for the supported algorithms, selecting ed255 first;
    • to switch you need to re-register on the all services you use, so it will not work by itself without any additional work;
    • as a user you do not have control over what signature algorithm will be used (this could be potentially changed with additional configuration steps, like blacklisting some algorithms, however it will result in compatibility issues, as default implementations are ecdsa based as far as I know.
  4. I believe the issue is about not testing the input parameters (specifically checking for 0 values), hence I do not see how ed255 would be more secure against that.
  5. I understand the theory that NSA had mixed constants for its advantage, however it’s almost 10 years, and we still do not have any proofs for that.

Having this said, I would love to see ed25519 curve finally added! I will bring this up on the next internal discussion.

Edit: here is a nice summary on the differences ECDSA vs EdDSA:

#4

I think the biggest issue is that the nitrokey f2 according to the site has a secure element in it, which likely (has been a topic on Pro and storage already) doesnt support 25519.

and while there hasnt been any proof yet of NIST curves having backdoors, having 25519 (or heck, even 448 as well) if possible would be a great advantage. Aside from that the eddsa algo is iirc safer to implement as in that there are iirc less avenues for errors like needing a good random number being a big thing I have read somewhere.