One side of the equation is r and the other side is multiplied by r and a value derived from s. If the two sides of the equation are equal then the signature is valid, otherwise it is rejected. To verify an ECDSA signature, the verifier checks an equation involving r, s, the signer’s public key, and a hash of the message. Without getting too much into the technical details, an ECDSA signature consists of two values, called r and s. For example, the WebAuthn standard for two-factor authentication allows device manufacturers to choose from a wide range of signature algorithms, but in practice almost all of the devices manufactured to date support ECDSA signatures only (a notable exception being Windows Hello, which uses RSA signatures presumably for compatibility with older TPM hardware). Compared to the older RSA standard, elliptic curve keys and signatures tend to be much smaller for equivalent security, resulting in them being widely used in cases where size is at a premium. Background: ECDSA signaturesĮCDSA stands for the Elliptic Curve Digital Signature Algorithm, and it is a widely used standard for signing all kinds of digital documents. ForgeRock customers can read our advisory about this issue for further guidance. Internally, we at ForgeRock graded this a perfect 10.0 due to the wide range of impacts on different functionality in an access management context. Oracle have given this a CVSS score of 7.5, assigning no impact to Confidentiality or Availability. Note that 15 and 16 are no longer supported, so it will only list 17 and 18 as impacted. Update 2: Oracle have informed me they are in the process of correcting the advisory to state that only versions 15-18 are impacted. The OpenJDK advisory on the other hand lists only versions 15, 17, and 18 as affected by this specific issue (CVE-2022-21449). There are also other security vulnerabilities reported in the same CPU, so (as always) it is worth upgrading even if you are running an older Java version. Although I’m not aware of the bug impacting those older implementations they did fix a similar bug in the (non-EC) DSA implementation at the same time, so it’s possible older versions are also impacted. Update: the official announcement from Oracle also lists older versions of Java, including 7, 8 and 11. If you have deployed Java 15, Java 16, Java 17, or Java 18 in production then you should stop what you are doing and immediately update to install the fixes in the April 2022 Critical Patch Update. For context, almost all WebAuthn/FIDO devices in the real world (including Yubikeys *) use ECDSA signatures and many OIDC providers use ECDSA-signed JWTs. If you are using ECDSA signatures for any of these security mechanisms, then an attacker can trivially and completely bypass them if your server is running any Java 15, 16, 17, or 18 version before the April 2022 Critical Patch Update (CPU). It’s hard to overstate the severity of this bug. All using the digital equivalent of a blank piece of paper. If you are running one of the vulnerable versions then an attacker can easily forge some types of SSL certificates and handshakes (allowing interception and modification of communications), signed JWTs, SAML assertions or OIDC id tokens, and even WebAuthn authentication messages. It turns out that some recent releases of Java were vulnerable to a similar kind of trick, in the implementation of widely-used ECDSA signatures. Of course, this being Doctor Who, the card is really made out of a special “ psychic paper“, which causes the person looking at it to see whatever the Doctor wants them to see: a security pass, a warrant, or whatever. The long-running BBC sci-fi show Doctor Who has a recurring plot device where the Doctor manages to get out of trouble by showing an identity card which is actually completely blank.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |