RedHat security finds multiple network devices leak ‘RSA-CRT’ keys

A researcher has discovered certain implementations of the Transport Layer Security (TLS) protocol used to encrypt web traffic can leak RSA keys.

It seems efforts to make the internet more secure and private have introduced new weaknesses that could undermine encrypted web communications.

In light of the NSA surveillance activities capturing large volumes of encrypted communications from web companies, those firms have in recent years been implementing “perfect forward secrecy” (PFS) in TLS, the protocol denoted in browsers by “HTTPS” that signal to the user a connection is encrypted.

PFS helps address the event an attacker captures HTTPS encrypted sessions and later acquires the key to decrypt them, say under a warrant. Instead of relying on a single key for multiple sessions, with PFS a new key is generated for every encrypted session, making it more costly for an attacker decrypt.

But a side-effect of the increased use of PFS is that it’s exposed an additional weakness in TLS that an attacker with little computing power could use to recover a server’s private RSA key.

Florian Weimer from Red Hat’s product security team outlined the weakness in a paper on Wednesday after discovering network hardware from multiple vendors in the wild that leaked “RSA-CRT” keys when subjected to a certain attack and that some free software TLS implementations didn’t include hardening against this type of attack.

“The actual key recovery attack can be described in very simple terms: establish a TLS session, negotiate forward secrecy, and watch out for a miscomputed signature. If a signature mismatch is detected, attempt Lenstra’s attack to recover the RSA private key,” Weimer noted the paper he’s called “Factoring RSA Keys With TLS Perfect Forward Secrecy”.

The attack, as Weimer explained in a blog post, was described by Dutch mathematician Arjen Lenstra in a 1996 paper detailing a “side channel attack” against the Chinese Remainder Theorem (CRT) — a method used to speed up calculations of the RSA algorithm, known as “RSA-CRT”. It doesn’t exploit RSA directly, but rather “unexpected implementation behaviour”.

Though it’s an old attack it hasn’t been particularly important due to PFS and more generally encryption wasn’t the norm at that time of Lenstra’s finding.

“At the time, use of cryptography on the Internet was uncommon, and even ten years later, most TLS (or HTTPS) connections were immune to this problem by design because they did not use RSA signatures. This changed gradually, when forward secrecy for TLS was recommended and introduced by many web sites,” Weimer noted.

“If a fault happened during the computation of a signature (using the RSA-CRT optimization), an attacker might be able to recover the private key from the signature (an “RSA-CRT key leak”),” he added.

Once the private key has been leaked, an attacker could “cryptographically impersonate the server, after redirecting network traffic, conducting a man-in-the-middle attack. Either the client making the TLS handshake can see this leak, or a passive observer capturing network traffic,” wrote Weimer, describing the impact.

“The key leak also enables decryption of connections which do not use forward secrecy, without the need for a man-in-the-middle attack. However, forward secrecy must be enabled in the server for this kind of key leak to happen in the first place, and with such a server configuration, most clients will use forward secrecy, so an active attack will be required for configurations which can theoretically lead to RSA-CRT key leaks,” he added.

“RSA-CRT key leak” incidentally is the name Weimer’s given the bug, bucking the recent trend of branded open source bugs like Heartbleed.

The good news is that RSA-CRT optimisation in TLS implementations with appropriate hardening is still considered secure, Weimer noted. These include the widely used OpenSSL and Mozilla NSS libraries while Oracle’s OpenJDK was patched in April. Unlike previous open source bugs that have affected RedHat products, this one does not.

“All browser PKI certificates for which we observed key leaks have been replaced and revoked,” Weimer added.

However, during a global internet probe for the bug, Weimer found several pieces of hardware in the wild that leaked keys under Lenstra’s attack. These included a Citrix Netscaler device, and devices from Hillstone Networks mostly located in China, as well as devices made by Viprinet, QNO Technology, ZyXEL, BEJY, and Fortinet.

Weimer notes in the paper that a potential root cause of the issue is a custom version OpenSSL from US semiconductor maker Cavium, which supplies hardware to several of the vendors.

“Citrix, Hillstone Networks, and ZyXEL confirmed that they use Cavium as a hardware supplier,” said Weimer.

Cavium told Weimer in a statement that it had issued patches for several pieces of hardware using an old version of its cryptographic SDK.

“Cavium has issued a patch and notified all customers (CVE-2015-5738) that are using older SDK 2.x Cavium Cryptographic Software under Linux on older OCTEON II CN6xxx Hardware with details of the vulnerability. OCTEON II running Simple Exec (SE-S) applications and OCTEON III CN7xxx processors are not affected.”

Finally, for those wondering what course of action to take, Weimer does not recommend disabling forward secrecy.

“If you expect that a key leak might happen in the future, it could well have happened already. Disabling forward secrecy would enable passive observers of past key leaks to decrypt future TLS sessions, from passively captured network traffic, without having to redirect client connections. This means that disabling forward secrecy generally makes things worse,” he said.

Join the CSO newsletter!

Error: Please check your email address.

Tags cryptographicallynetwork devicesredhatRSA-CRTTransport Layer Security (TLS)CSO Australia

More about CitrixFortinetLinuxMozillaNSAOracleRedHatRed HatRSATechnologyTransportZyXEL

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by Liam Tung

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place