While post quantum cryptography has been sidelined by the recent advances in AI and the final results in the NIST competition, one question is still very much on a lot of executives’ lips: "Are we quantum safe?". Yvan Rolland-Chatila, CISSP, CCSP, a cybersecurity consultant working with banks and payment companies for over a decade, shares his view.
Disclaimer: The views and opinions expressed in this article belong solely to the author and do not necessarily reflect those of ISC2.
The quantum safe question has a lot of relevance in the context of protecting data at rest or in transit – even more so when considering what I would call 'traditional' data (financial, HR records, internal exchanges). But what about payments? Nothing seems more frightening to many people than the prospect of quantum computer attacks on payments and payment networks, through which billions of dollars transact every day. Could all our transactions, account information and the like, suddenly cease to be safe from attacks if launched from quantum computers?
Well, not so fast! As a payment security professional, certain things keep me awake at night – but quantum is not one of them. Why?
Understanding Payment Data
Let's focus first on payment data. Here, we’re talking about account data – in the Payment Card Industry council definition this means your Personal Account Number (PAN; the actual number on your credit/debit card), your Personal Identification Number (PIN; usually the 4-6 digits that you have to key in when going to a cash dispenser or when purchasing goods), and your Card Validation Value (CVV; the 3-4 digits on the back or front of your card that you use for additional verification when purchasing goods or services online).
How is this data used? The PAN and the PIN are stored at the issuer side, i.e., the bank or institution providing the end customer with the means of payment – or, in other words, the end customer's bank or institution. Then, when a purchase is made, whether online or directly with a card, some of this data transits from the card (or our mobile/web browser) through the merchant's bank, the payment scheme (for example, the card platform), or through any payment acquiring third party, usually occurring invisibly to the customer. That is to say: the data transits via multiple endpoints before a payment is effectively cleared, the money taken from the client's account and deposited into the merchant's account.
Now we know the landscape, let's focus on how quantum computing might break the payment ecosystem. If payments don’t use quantum safe algorithms, then a quantum computer, using a variety of means – particularly Shor's algorithm – could break the cryptography and decrypt the data. But when would such an attack be practical?
The Quantum Challenge
At least in the very near term, quantum computers that have enough qubits (basic units of quantum information, the quantum version of a binary bit) are going to be anything but cheap, so no one really sees them as widespread. Also, they will be efficient when dealing with asymmetric cryptography, mostly the RSA and ECC algorithms. So, a quantum computer will be able to break the overall encryption of the transactions – the different tags that do the authorization.
But, usually, PINs, PANs and CVVs are protected by symmetric cryptography, normally considered quantum safe. And there is limited value, even if you do 'harvest and decrypt’: by definition, a transaction is limited in time, and mechanisms against reinjection have long existed.
Normally, symmetric cryptography is quantum safe. But this is true only for the AES symmetric algorithm and, especially, with keys of 256 bits. Unfortunately, while support for AES is spreading, it isn’t yet implemented everywhere: PCI DSS, at the time of writing, still considers 3DES 2 (112 bits of effective key material) to be 'strong’ cryptography. Though we should acknowledge that PCI DSS requires a “minimum of 112-bit” encryption, making it the lowest threshold an entity can implement and still be compliant.
Only last year, I witnessed a financial institution moving away from a single DES key; as a reminder, single DES was broken by a brute force attack back in 1997, led to the introduction of Triple DES (or 3DES). But, incorrectly implemented, a 3DES scheme could be masking (called key 'masquerading’) a single DES key. In comparison, breaking a single DES key can be done in quickly, in less than a day, with limited computing power. As an attacker, why would I invest in expensive quantum computing, when I could still exploit weaknesses and deficient implementations on single and 3DES?
Multiple Points of Risk
Finally, let's remember that a transaction, unlike data at rest, moves through various nodes. One essential point of payment cryptography is interoperability and its reliance on standards widely accepted like PCI. This means that should one endpoint in the payment chain be a weak implementation then, potentially, all endpoints are vulnerable to that weak implementation. However, if you ban 3DES on your network while other points or the scheme accepts it, you may lose transactions and money. This means, you cannot, as a single actor, decide on your own to cease using certain algorithms and start using only new quantum safe mechanisms. The chances are, in this case, that you will be alone and not able therefore to clear a transaction.
In the payment ecosystem, what can you do to be quantum safe, and should it be considered at all?
The very first step is to review your cryptographic landscape, set up an inventory of keys, either managed via a hardware security module (HSM)/key manager (a physical device that securely generates, stores and manages cryptographic keys, and performs cryptographic operations like encryption, decryption and digital signing), or standalone – yes, hardcoded keys still exist in some places, and they must be accounted for.
At the same time, you should establish a cryptography policy. This will encompass the mandatory guidelines (PCI, for instance) for setting up permitted algorithms, lifecycle, exposure, or any other criteria. A rating system can then be established for each of the crypto assets, enabling a fine-tuned management system. (Note: if you look at PCI DSS v4.0.1, requirement 3.6.1.1 for service providers, a cryptographic architecture that fits this purpose is mandatory.)
Such a system may then be enhanced to produce periodic dashboards and even automate key management processes. For instance: for keys for which the renewal cannot be automated and has several dependencies, the system would trigger an alert for all stakeholders at a defined period prior to the expiration of the cryptoperiod of the key.
The Quantum Outcome
The goal of these efforts and this system is to produce cryptographic ‘agility’. This means that when an algorithm gets broken, deprecated, or superseded by a safer version, as well as accepted in the payment ecosystem, you’re positioned to action a change, knowing the assets impacted and the effort needed for the change. If all of this sounds too complex then I urge you to source external help, especially when it comes to discovering cryptography, hard coded keys or mechanisms hidden in your application.
At the end of the day, if you’re serious about managing the system, you must own the way it evolves. After all, cryptography is here to protect your data. When discussing the principles of managing keys with C-executives, I’ve always found useful to use a car analogy: crypto keys protect data the same way that car keys protect your vehicle. That is to say: we all need to pay attention to where these keys are, how they are used, in order to protect our car.
Yvan Rolland-Chatila , CISSP, CCSP, PCIP, has 15 years of experience in cybersecurity, payments and the banking sector. He has held management and technical roles, with responsibility for consulting, performing audits, managing and implementing Hardware Security Modules. His cyber security work spans over the private and public sectors.
Related Insights