Future-proof the protection of your data by using the strongest quantum-safe encrypted communication today.

What is the Post Quantum Computing problem?

In order to keep sensitive or critical information confidential, organizations rely on encryption algorithms. These algorithms take digital information in the clear and transform it into a computationally hard-to-decode unintelligible message that can only be re-constructed if you have the right digital key. This encryption process has been used to protect data-in-transit (communications), data-at-rest (stored), data-in-use (in memory), to provide data integrity (digital signing), and to drive all authentication protocols (identity validation). There are several encryption algorithms in use today with varying degrees of strength, but all are, generally, out of reach of the computing power available to be able to practically brute-force the decoding.  

Until now.

With the onset of quantum computing, it will be possible to speed up the time required to break some of the encryption algorithms in use today, especially the asymmetric algorithms (i.e., public key algorithms), which are commonly used to establish communication protocols like SSL or TLS (used for HTTPS) or to digitally sign information.

While quantum computing is still not widely available nor practical yet, rapid improvements will make it so in a few years. Organizations that are interested in breaking confidentiality (criminally or not) are taking action now in anticipation of having enough computing power to decipher today’s communications or payloads. These intruder organizations are tapping current communications in order to break them and extract the sensitive information once quantum computing makes it possible.

What is QSC TLS?

There are quantum-safe crypto (QSC) algorithms being developed to protect against the exposure created by quantum computing, but these algorithms are still going through the NIST process of standardization. Many companies — including IBM — have proposed candidates for standardization. However, it is hard to predict which QSC algorithms will be picked.  

IBM is at the forefront of this standardization work. IBM Research is backing and contributing to the open source Crystal Project, which develops the Kyber QSC algorithms. After lots of scrutiny, Kyber has made the final selection round — competing with two other algorithms. Given its security strength, performance, and adaptation capabilities, Kyber remains the top contender.  

With this uncertainty, what is the best strategy for an organization to adopt to protect their most sensitive data while waiting for an approved QSC standard? IBM wants to help these organizations preempt data leakage attacks that expect to use quantum computing to uncover confidential communications and storage of sensitive data.

To this effect, we are applying Kyber to protect the most vulnerable and impactful processes if breached — the TLS communication with a Key Management Server (KMS) and the workload routing (Ingress Controller) for Kubernetes or OpenShift. Additionally, this hardening needs to be done in a way that allows for coexistence with current functions and provides the ability to seamlessly upgrade to whichever is the NIST evaluation, without incurring into rip and replace migrations.

In this writeup, we will focus on the innovative approach to proactively protect the Key Protect KMS system with QSC TLS.   The other process for enhancing protection on Ingress controllers for both Kubernetes and OpenShift will be treated separately.

IBM Key Protect is the IBM Cloud key management solution (KMS) to securely serve and manage the lifecycle of symmetric keys for a wide set of backend cloud services and customer applications. Key Protect uses TLS to exchange or onboard the master root key provided by customers to encrypt the subsequent keys that are used to encrypt the backend or customer resources.

This initial TLS communication is exposed to the internet, where there is higher risk for traffic tapping. Given that the initial TLS session establishment is done using asymmetric keys, which are more vulnerable to a quantum computing breach, the master root key is at greater risk of breach in the future. Once an attacker gets the master root key, they can use that to get all the other keys in the KMS and use those to decrypt the data stored on the backend services.

What are the QSC algorithms IBM is proposing?

NIST selected four algorithms as third-round finalists for Public-key Encryption and Key-establishment in TLS communications: Classic McEliece, Crystals-Kyber, NTRU, and Saber. In parallel, NIST’s third-round finalists for Digital Signature Algorithms are Crystals-Dilithium, Falcon, and Rainbow. The expected availability for the final NIST draft standards is between 2022 and 2024 — some years away. While the selection process continues to narrow down the candidate algorithms, IBM has decided to make a quantum-safe algorithm available in the IBM Public Cloud, given the urgency to protect against the current potential attacks described above.

IBM Research has been actively involved in the design and implementation of quantum-safe algorithms as part of the Crystal project and co-authored submissions to NIST for Crystals-Kyber (Public-key cryptography), Crystals-Dilithium (Digital Signature), and also as part of Falcon project with co-authored Falcon (Digital Signature) submissions.

The IBM Public Cloud Key Management service (Key Protect) has selected to offer the Crystals-Kyber algorithm in hybrid mode. Kyber is an IND-CCA2-secure key encapsulation mechanism (KEM) that bases its security strength on the complexity of solving the learning-with-errors (LWE) problem over module lattices.

Hybrid mode was selected based on the Crystals Project recommendations encompassing the classic public key cryptography algorithm (for example Elliptic curve Diffie-Hellman) and Quantum-safe Kyber algorithm. By using hybrid key exchange algorithms, users are safe to continue using classic public key exchange cipher protection and can leverage the additional layer of security protection from quantum-safe cryptography. This hybrid mode is preferable for current transparent operations until NIST standardizes quantum-safe algorithms. As NIST continues its evaluation process, these algorithms will evolve and strengthen security. IBM continues to follow the NIST evaluation process and will make available the final standardized algorithm in its public cloud when available. Until then, it the best and most flexible option to use quantum-safe algorithms in hybrid mode.

As quantum computing continues to advance, a sufficiently powerful quantum computer is expected to break classic public key cryptography in a matter of minutes by running the “SHOR” algorithm. While large quantum computers are not available today, any TLS data-in-transit could be snooped, stored, and decrypted when these large quantum computers are a reality. Data like financial, health, or personal information tends to have long shelf life and value, so it is critical that present TLS data-in-transit is protected using a quantum-safe algorithm in hybrid mode to guard from data breaches.

A malicious user can break the classic ECC/RSA (current public key cryptography scheme) communication with a quantum computer, getting access to the session key and decrypting its contents. With the IBM hybrid approach, the Kyber algorithm and the current ECC algorithm are used for TLS session establishment and deriving the session keys that will be used to encrypt the content shared during the TLS session. 

IBM Key Protect manages secure cryptographic key stores. Enhancing TLS security ensures that the customer’s cryptographic keys and their operations are secured from future breaches while in transit. IBM has introduced a new separate Key Protect endpoint in the public cloud to support TLS 1.3 hardened with hybrid-mode Kyber. Hybrid mode supports the following three key sizes:

• p256_kyber512: Combines kyber512 with ECDH using p_256 curve. L1 security.
• p384_kyber768: Combines kyber768 with ECDH using p_384 curve. L3 security. (Default recommendation.)
• p521_kyber1024: Combines kyber1024 with ECDH using p_521 curve. L5 security.

The CA certificate for this TLS 1.3 QSC endpoint continues to support the classic ECC digital signature to allow users to leverage their existing classic certificates without needing changes. This part was not updated with Kyber Dilithium to avoid disruption. See more detailed documentation for Key Protect.

How is QSC used in Key Protect?

The Key Protect Client SDK is enhanced to support QSC algorithms in hybrid mode. Users can leverage this SDK to connect to a Key Protect QSC-enabled endpoint.

Proxy servers such as HAProxy and Nginix are built with QSC-enabled libraries to support QSC algorithms and QSC in hybrid mode. By leveraging these proxy servers in the environment where you run your workloads, you can use QSC TLS termination. IBM also provides QSC enabled custom Ingress controllers for IBM Cloud Kubernetes Service and Red Hat OpenShift on IBM Cloud clusters. 

By leveraging QSC-enabled proxy servers and IBM QSC-enabled Ingress controllers, customers can use QSC algorithms as described in the following scenarios:

Scenario 1

A Key Protect client or application using Key Protect APIs and running in a Kubernetes worker node within an IBM Cloud Kubernetes Service cluster can use QSC TLS algorithms. The Kubernetes cluster includes two changes:

1. A custom QSC-enabled Ingress controller.
2. A QSC-enabled HAProxy in a node.

With these two changes, the TLS termination on Ingress happens in the Ingress controller. On egress, the TLS termination happens in the QSC HAProxy, which establishes QSC TLS connection to Key Protect. In this use case, no changes on the client side are needed:

Scenario 2

A Key Protect client is enhanced to use a QSC algorithm in hybrid mode. The traffic between the client and the Key Protect endpoint is QSC hybrid-mode TLS:

What are the key benefits of getting on board with IBM for QSC?

Future-proof the protection of your data by using the strongest quantum-safe encrypted communication today. Hardening the TLS communication for IBM Key Protect with QSC provides IBM Cloud customers with the following: 

• An alternative way to communicate with Key Protect using a TLS 1.3 session hardened by QSC algorithms that protect the asymmetric key exchange protocol for TLS session establishment.
  • The ability to protect the key material used in encrypting sensitive data-at-rest or other services from future potential breaches.
  • Additional protection for importing key material (master root key) in Bring-your-own-Key (BYOK) scenarios.
  • A hybrid approach allows for coexistence with current TLS communications.
• State-of-the-art QSC algorithms backed by IBM Research (KYBER).
  • With the best performance and strongest algorithms compared to the few other CSPs attempting QSC.
  • Top contender for the NIST standardization offers high probability of selection.
  • Flexibility to adapt to the final NIST QSC selection — when available — saving on rip/replace costs.
• Support for the broadest sets of client sources (Linux now, Windows and Mac following).

How can I get started?

We wanted to make the QSC TLS enhanced IBM Key Protect code available ASAP, and you can read about it in our documentation.

Visit our catalog entry to try it out. Start protecting your sensitive data in the IBM Cloud against post quantum computing threats today. Come to the IBM Cloud, where bringing your own key to protect your resources is not exposed now or in the future. We welcome your feedback at any time.