CVE-2022-21449 - implementing cryptography correct requires attention to details

Cryptography can be deceivingly simple when looking in a textbook. Implementing cryptography is much harder to implement properly in real life due edge cases, performance requirements, etc.

A recent example of doing it wrong is CVE-2022-21449. This vulnerability was introduced in Java version 15, where the previous ECDSA implementation written in C++ was replaced by one written in native Java. The rewrite was requested to “remove dependencies to native code”. Now, while a signature is only created once but verified many times, optimizing the validation routine is usually warranted. And in particular with ECDSA, where signature verification is much more expensive than signature creation - the complete opposite of, for instance, RSA.

Back to CVE-2022-21449. The existing C++ implementation seems robust with many comments in the code detailing algorithmic steps and checks (https://github.com/openjdk/jdk/blob/jdk-15-ga/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c#L956). The C++ would none the less have benefited from more test cases. The new Java implementation contains zero comments and references to relevant standards and, maybe therefore, missed critical checks. The actual vulnerability manifests itself in the verification routine by accepting a user provided value of 0 and therefore validating that 0 = 0 * nn which clearly is always true. The vulnerability impacts many authentications protocols like TLS, JWT, etc.

The Java implementation has been corrected (https://github.com/openjdk/jdk15u/commit/f95a3482a4cf403e045ecfdc63b21ff82c513e03) with the comment “8277233: Improve ECDSA signature support”:

I guess this qualifies as an improvement.

This vulnerability could and should have been avoided by 1) reviewing the new Java code by someone with cryptography skills and 2) requiring thorough unit testing of code (there is a an abundance of test data, so this is not a challenge). See also (https://openjdk.java.net/groups/vulnerability/advisories/2022-04-19).