1

On 2022-04-19, Neil Madden published a vulnerability in the ECDSA signature verification code of the library bundled with some editions of Java, including some recent by Oracle and in OpenJDK. That became CVE-2022-21449 (I've yet to understand if CVE-2022-21476, which goes back to Java 7, is related).

In a nutshell, action 1 of the ECDSA signature verification procedure is not performed correctly, and the rest is implemented such that the (0, 0) signature always verify.

I ask related questions

  1. Are there implementations botched such that other signatures determinable from curve parameters always pass? I'm thinking in particular of (u⋅n, v⋅n) for some integers u and v, possibly negative for signatures with ASN.1 decorum.
  2. What are affected applications? I 'm thinking of
    • digital certificates: are there vulnerable PKI and ECDSA certification keys in their chain of trusted public certification keys?
    • code signing: are there vulnerable code verification gear and code signing certificates with ECDSA public key?
    • document validation, e.g. signed PDF: is any end-user application vulnerable? For these, there is profusion of certified ECDSA public key.
fgrieu
  • 1,072
  • 7
  • 19
  • I know of at least one huge IoT deployment in France where the ANSSI KoolAid was drunk and where ECDSA sigs are a cornerstone of the security posture. (email in bio) – Bruno Rohée May 10 '22 at 12:23

0 Answers0