Home Books Training Newsletter Resources
Sign up Log in

Bulletproof TLS Newsletter

88

Two zeros bypass Java’s ECDSA signature check

28 April 2022

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Maintained by Hanno Böck.

BROUGHT TO YOU BY OUR SPONSOR
Application Security Across Top 1 Million Sites Curious about the state of application security across the top 1 million web sites? Read this report for cybersecurity analysis outlining trends in HTTPS, Certificate Authority, Permissions Policy and more. 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 Bulletproof TLS 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 1,500 students who have benefited from more than a decade of deep TLS and PKI expertise.

Find out More

THE FINEST IN TLS
AND PKI EDUCATION
@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

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

Company

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