Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

88

Two zeros bypass Java’s ECDSA signature check

28 April 2022

Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Hanno Böck.

BROUGHT TO YOU BY OUR SPONSOR
Architecture for Machine Identity Management. What will your PKI look like when fast application development triggers an explosion of new machine identities? Read this reference architecture to learn new strategies for orchestrating machine identities in data center, cloud and edge environments. VENAFI

A security vulnerability in Java’s ECDSA implementation allows creating a signature that would always be evaluated as valid. Neil Madden, who discovered the flaw, called it a psychic signature.

ECDSA signatures consist of two values, usually called r and s. The issue is that ECDSA signature validation compares r to the product of the inverse of s multiplied with other values. Depending on how the inverse of s is calculated, the inverse of zero may also be evaluated to zero.

In Java this is the case, so zero gets compared to zero—independent of the message to be validated. Thus a signature where the r and s values are set to zero will always pass.

This is generally a known property of ECDSA. It is therefore required to check that the r and s values are not zero, which is supposed to be the first step of the signature verification algorithm. However, Java failed to implement that check.

Madden noted in a later blog post that two zeros are not the only way to bypass the signature check.

The vulnerability was introduced in Java version 15, where the previous ECDSA implementation written in C++ was replaced by one written in native Java. Oracle fixed the vulnerability in its April update, and the vulnerability was assigned the ID CVE-2022-21449. OpenJDK, the open-source distribution of Java, also published an advisory.

It is noteworthy that this vulnerability was not caught earlier. Neil Madden points out that Project Wycheproof, a cryptographic test suite published by Google, would have caught this vulnerability.

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won't send you anything else.

Short News

Here are some things that caught our attention since the previous newsletter:

  • NSS has released version 3.77 and updates for older version branches. It fixes memory safety violations in multithreaded code that uses PKCS #11 tokens (CVE-2022-1097).
  • A research paper analyzes the deployment and response times of DNS over QUIC (DoQ).
  • Koen Rouwhorst analyzes the handling of the new russian state CA (see last newsletter) in the Yandex browser.
  • Google announces an ACME-based service for certificate management for Google Cloud customers.
  • A security flaw was found in Chrome where in some situations HTTPS connections would be downgraded to HTTP when typing in HTTPS URLs into the URL bar.
  • OpenSSL had announced a security update to be released on April 26, fixing one moderate-severity security flaw, but the release was delayed until May 3.
  • DigiCert started supporting domain locking via CAA. This allows associating a CAA record with a user account.
  • The US Treasury has announced an exemption of Internet services from the sanctions against Russia, which likely also affects CA services.
  • LetsDNS is a new tool to manage DNSSEC DANE/TLSA records in name servers.
  • Lúcás Meier explains potential issues with the random oracle model in a blog post. The random oracle model is an idealized concept of a hash function commonly used in cryptographic proofs.
  • The Real World Cryptography conference 2022 happened as a hybrid event online and in Amsterdam. NCC Group has a blog post covering some of the talks given there.
  • DTLS 1.3 was published as RFC 9147. Robert Merget gives an overview on Twitter.
  • A new service called badkeys.info checks cryptographic keys for known vulnerabilities like the Debian OpenSSL bug, ROCA, common prime factors and others. It has been created by the author of this newsletter. The functionality is also available as an open-source tool.

Interesting jobs

Here are some interesting jobs we've come across in the last month:

  • Security Tools Compiler Engineer - Apple, via @kubamracek
  • Software Engineer III, Open Source Security - Google, via @infernosec
  • Software Engineer, Chrome Permissions - Google, via @mikewest
  • Staff Product Manager - Package Security - GitHub, via @jhutchings0
  • Lecturer in Cyber Security - University of Bristol, UK, via @BristolCyberSec
  • Embedded Systems Software Engineer - wolfSSL, via wolfssl.com
  • Product Security Engineer - Corellium, via @CorelliumHQ

If you know of similar jobs that our readers might be interested in, for example cryptography, TLS, or PKI, let us know and we may add them to future newsletters.

Books and Resources

And here is a free book we think you might find interesting:

  • Concealing for Freedom - The Making of Encryption, Secure Messaging and Digital Liberties, by Ksenia Ermoshina and Francesca Musiani

Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.

Remote and trainer-led, with small classes and a choice of timezones.

Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.

Find out More

@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

  • Newsletter
  • SSL/TLS and PKI History
  • Archived Books
  • Bulletproof TLS Guide

Company

  • Support
  • Website Terms of Use
  • Terms and Conditions
  • Privacy Policy
  • About Us