Good key management for financial services: protecting your digital assets from the inside out

Johannes Lintzen, Managing Director at Cryptomathic

Java’s recent Elliptic Curve Digital Signature Algorithm (ECDSA) vulnerability underscores the fact that organizations cannot rely solely on outside vendors for effective cybersecurity. Jo Lintzen, Managing Director at Cryptomathic, routinely helps enterprise CISOs in the financial services industry evolve their encryption and key management strategies in line with their changing infrastructure models, advocating an inside-out approach that has proven itself over time.

On April 19, 2022, information came to light about a severe vulnerability in recent versions of Java: in short, a serious implementation flaw of the Elliptic Curve Digital Signature Algorithm (ECDSA) would allow a malicious actor to achieve successful signature validation without access to the private signing key.

The news sent shock waves through the security community. And rightly so. ECDSA is the elliptic curve analogue of the Digital Signature Algorithm (DSA) and is widely used in a variety of authentication processes used in financial institutions, such as SSL/TLS handshakes, JSON Web Tokens, SAML assertions, and OIDC tokens. It is the signature algorithm of choice, especially in resource-constrained environments where key size and power consumption matter. Being able to pass the ECDSA signature verification algorithm without knowledge of a user’s private signing key means that an attacker can assume a user’s identity and act on their behalf. This vulnerability, formally labelled CVE-2022-21449 and popularly known as “Psychic Signatures,” could be easily exploited to forge authorization tokens or TLS handshakes. Or worse still, it could be used to declare an electronic signature as valid and legally binding even though it is not. A compromised cryptographic key can be catastrophic for a financial institution, as South Africa’s Postbank learned a few years ago.

This revelation comes at a time when concern within the financial services industry about cybersecurity vulnerability is already at an all-time high. According to a report from The Anti-Phishing Working Group (APWG), the financial services industry experienced a 35% increase in ransomware attacks in Q1 2022. Across the industry, CISOs are recognizing the need to prioritize the evolution of their encryption strategies to ensure that digital assets are secure.

So, if attacks are increasing in frequency and sophistication, and tried and trusted cryptographic tools are vulnerable to trivial attacks, where does that leave us?

For starters, it must be noted that there was nothing actually wrong with ECDSA. The vulnerability was introduced through an implementation flaw when ECDSA code was translated from native C++ code to Java for the Java 15 release. That this bug went undetected suggests that insufficient testing and oversight of the code was applied.

In fact, without getting too technical, all that needs to be done for an ECDSA implementation to meet its security claims is to implement the parameter generation, signature generation, and signature verification algorithms exactly as described in the standards, such as ANSI X9.62, FIPS 186-2, IEEE 1363-2000, or ISO/IEC 15946-2. Indeed, each of these standards states in the first line of the signature verification algorithm something along the lines of “Verify that “r” and “s” are integers in the interval [1, n-1].” It is textbook knowledge that this check must not be omitted, and that things can go very wrong if either “r” or “s” is allowed to be zero.

The Psychic Signatures vulnerability does, however, underline one of the most important considerations for creating a sound cryptographic key management strategy: protection must start from the inside and work its way out. No matter how many new, cutting-edge security solutions you have, they can’t save you from human error or bad key management practices if security measures are not enforced.

For the past 20 years, the financial services industry followed an outside in model to security that prioritized identification and mitigation of external threat, often at the expense of focusing on vulnerabilities that arise from within an organization. This worked largely because data was housed in a single, central data center that could be easily controlled. Now that the traditional data center has been replaced by centers of data and Edge computing, IoT, Bring Your Own Device programs and cloud storage have upended traditional ways of accessing, using, managing, and storing data, it’s high time for a rethink. Just as our systems have evolved, so too must the way we protect our digital assets. A single person with an Excel spreadsheet might have been an adequate way to manage cryptographic keys in the past, but today, that person represents a single, potentially catastrophic fail point.

Instead, inside out protection establishes good practices within an organization and adds layers of security checks at every level. It requires organizations to determine what is most important, and then to take appropriate measures to really tighten down their core digital assets. Once your core is protected, what will the bad actors really get access to in a breach?

I don’t know why Oracle failed to perform the signature verification algorithm according to standards specification or to prioritize checking or testing the code. I do know that, as Neil Madden, the cryptographer who discovered the vulnerability notes, “Cryptographic code is very tricky to implement correctly and public key signature algorithms are some of the trickiest.” Creating and maintaining a successful cryptographic key management strategy can no longer be an afterthought. It must be an integral part of a holistic, comprehensive approach to cybersecurity that starts inside your organization.