INSIGHTS

DLT Quantum Threat Analysis

Daniel Szego - December 2024

Introduction

Part one of this series {link}introduced generally the field of quantum computing, the problems that quantum computers can cause for cryptography and blockchain systems and some possible resolutions, like quantum or post-quantum cryptography. In this piece, we introduce a systematic approach to evaluate the quantum risk specific blockchain platforms. 

Quantum threat of blockchain systems

Considering blockchain-based applications and platforms, there are several areas where quantum risk can be a serious threat. The field is getting especially crucial because there are more and more blockchain applications that are mission critical. Examples are:

  • Payment: There are many blockchain-based payment applications, from cryptocurrencies via stablecoins to more regulated CBDC (Central Bank Digital Currency) use cases. They are regarded as mission critical applications so the security of such systems is critical, even under quantum advisory and attack. 
  • Store of value: Some of the cryptocurrencies are not used as payment but rather as a store of value. As store of value use cases, it is even more critical to have hacking resistant systems because such systems are supposed to store value for 10 - 20 - 30 years. Hence, a possible quantum hack, even if it affects only one account, might cause severe economic damage for the rest of the network as well.
  • Tokens of financial institutions: There are some innovative use cases for tokens issued by regulated financial institutions. Examples might range from deposit tokens to financial security tokenization. In such use cases, security, hacking resistance and even quantum resistance can be highly important because a possible vulnerability might not only cause financial loss but a serious reputation loss at the issuing institute. 
  • Blockchain and identity: Identity use cases such as self-sovereign identity or decentralized identity solutions are usually used together with an identity blockchain to improve data authenticity and consistency. Most of the identity use cases are considered to be highly mission critical so a possible quantum hack can cause serious damage.

To analyze possible quantum threat of a blockchain platform or blockchain based application, we propose the following framework, with the following systematic evaluation steps (Figure 1):

Figure 1. Quantum risk evaluation process 

  1. Threat model: Assessing attack models, possible hacks and applied cryptographic elements of the system.
  2. Impact analysis: Determining the impact of a successful quantum attack.
  3. Quantum readiness: Analyzing how far in the future is the threat of this attack. 
  4. Prevention possibilities and risk mitigation: Evaluating whether an upgrade of the system, like to post-quantum cryptography, will protect against a category of threat.
  5. Overall risk evaluation: Aggregating information to create a high-risk, medium-risk, low-risk evaluation for certain points. 
  6. The assessment process: Establishing ongoing assessments for technology management and organizational aspects with regular evaluation periods 

In the following we will investigate the individual substeps more in detail. 

Threat model

Assessing a threat mode of a blockchain system might be considered from several angles. There are more or less formal methods and more or less systematic approaches. One systematic approach is the so-called STRIDE model; other initiatives try to bring formal verification methods into the field.

If formal threat model analysis is not available, we can use a more pragmatic approach as well. From a practical point of view, assessing a threat model can contain listing the different possible attacks against a system. Possible attacks are usually categorized as follows: 

  • Attack against the consensus: like trying to manipulate consensus by having 51% of the voting resources;   
  • Attack against the network: like separating part of the network nodes by hacking the network; 
  • Attack of a node: like attacking a specific node, typically the leader in a Nakatmoto consensus;
  • Smart contract attacks: like exploiting smart contract implementation vulnerability; 
  • Attacking private keys: like stealing or forging private keys; and 
  • Application level attacks (dApp-s, DeFi): like flash loan attacks against certain DeFi protocols. 

Another way of assessing elements of a threat model for our blockchain system is to evaluate the used cryptographic primitives, which we can call as cryptographic inventory. Quantum computing will primarily attack computational hard elements of these cryptographic elements, like prime factorization or elliptic curve exponentiation or multiplication. Basic blockchain systems contain mostly hash functions and digital signatures. However these core cryptographic elements are usually extended by further cryptographic primitives in most recent DLT designs, such as: 

  • Digital signatures for authenticity or identity proofs;
  • Public - private key cryptography for asymmetric encryption, like for key exchange in secure communication protocols; 
  • Hash functions for data consistency or as a cryptographic primitive for other protocols, like mining in Nakamoto consensus;
  • Random generation: used in key generation in wallets;
  • Multi-signatures, like Shamir’s secret sharing: used for example in wallets for splitting the signing keys into several subparts; 
  • Zero knowledge proofs, like Groth16: used for example in rollups or in realizing private blockchain transactions; 
  • Stealth addresses: used in Monero for increasing privacy features of the system; 
  • Ring signatures: used in many use-cases, like for increased privacy; 
  • Commitment schemes (e.g., hash commitment, Pedersen commitment): used for instance in private non-repudiability schemes; and
  • Further advanced cryptographic constructs, like functional or homomorphic encryption: used. 

Although assessing the cryptographic identity might seem to be a good start, it can be sometimes misleading. The problem is that some of the cryptographic primitives might be used in several complex protocols as building blocks. As a consequence, it should be carefully analyzed the possible impacts of quantum vulnerability of a given building element. Another point to consider is a possible quantum attack to a non-cryptographic building block. As an example, quantum machine learning might be capable of guessing human generated passwords efficiently in the future. As a consequence cryptographic inventory should be used with care after a detailed analysis. Due to the fact, however, that most blockchain applications do not have explicit threat models, we usually start with a list of the used cryptographic building blocks.

Consider the Bitcoin network as an example., There is mostly classical cryptography in the system such as  digital signatures based on elliptic curve cryptography for providing a kind of identity proof for the holders of Bitcoin. Cryptographic hash functions like sha256 or optionally RIPDEM-160 have more application areas. The most important areas of hash functions in the Bitcoin protocol are:

  • Hash functions are used for providing consistency in the ledger. 
  • Hash functions used in the mining process. Practically the pre-images resistance of the cryptographically secure hash function guarantees that the necessary work was invested into the proof of work process. It also guarantees that the chosen leader in the Nakamoto consensus was chosen by real randomness. 
  • Hash functions used in address generation to provide an additional layer of quantum security. Bitcoin addresses are not solely the public keys, but the double hash of the public keys. The reason for that is that from a public key based on elliptic curve cryptography it is possible to derive the private key with the Shor’s quantum algorithm. Having a double hash on it provides additional quantum security though. 
  • - Hash functions used in address generation of the HD (hierarchical deterministic) wallets as well, to provide addresses that can be used only once. This provides extra privacy on the Bitcoin network. 

Taking Hyperledger Fabric as another example, we find mostly the application of the asymmetric cryptography and cryptographic hash functions as well. Public private key cryptography is used in digital signatures for providing identity for organizations and organizational roles. It is also used with hierarchical certificate authorities and with X509 certificates to provide a PKI-based role and identity system. On top, communication between Fabric components is based on TLS that uses PKI for key exchange for symmetric encryption keys as well. Cryptographic hash functions are the basis of several other components. They are used in ensuring ledger consistency and in digital signatures as a building block of the signing process. Besides classical cryptographic primitives, there are initiatives of advanced cryptography as well. As an example, the identity mixer component of Hyperledger Fabric uses zero knowledge proof for advanced privacy.  

Impact analysis

The next step of the quantum threat analysis is to assess the possible impact of a successful attack. In terms of impact, we can consider two dimensions: category of impact and severity of impact. Category of the impact describes what kind of problem can be caused by a successful quantum attack; severity tries to evaluate how serious the problem can be. 

Categorization considers the possible effect of an attack. An attack can be different, for example, if it targets system privacy, or if it is a data integrity hack or simply a false impersonation. The most important categories are the followings:

  • Confidentiality: Targeting information that can be accessed only by the authorized parties, e.g., secrets;
  • Integrity: Compromising data that can be edited only by the authorized party;
  • Availability: Impacting data or the service available, it can be accessed online without system outage;
  • Authenticity: Impersonating or forging fake identity, like spoofing;
  • Integrity/Consistency: Forging and hacking relevant information in the system, like tampering;
  • Non-repudiability: Denying  the initiation of a critical transaction; 
  • Privacy: Gaining access and visibility into protected data and information; 
  • Availability: Degrading the availability of the system for, example by, denial of service attacks; and
  • Authorization: Elevating the privilege with protecting access for users without proper rights. 

For evaluating impact severity, there can be many methods. One method might be to try to assess the economic impact of a successful quantum attack. As an example, if a Bitcoin address is hacked, it causes direct financial loss up to the hacked amount. However, It might indirectly cause  an even more significant economic loss by hurting its reputation as a stable store of value. If this leads to a significant loss in the Bitcoin price, it passes on an additional indirect loss to the cryptocurrency holder. A similar economic loss mechanism is possible with consortium networks realized by Hyperledger Fabric. Although in such situations estimating the exact direct or indirect economic loss is even more complicated. It heavily depends on the application as well that Fabric realizes. 

As measuring the exact economic loss of an attack might be quite challenging, an optional way is to assess the impact of a threat on a qualitative scale, ranking how serious the possible attack might be. The easiest way is to evaluate on a three level scale, having low impact, medium impact or high impact. Examples for different impacts can be: 

Figure 2. Impact severity 

  • If the digital signature algorithm is cracked then fake identities can sign transactions giving potential the possibility to steal cryptocurrency or economic value. This is definitely a high impact threat. 
  • If hash function has problems at pseudonym key generation, it might cause a decreased level of privacy on the network. It is certainly not nice, but perhaps not tragic. It might be considered as a medium impact hack. 
  • If the applied hash function leaks information on the preimage at mining, it can cause serious problems for systems using proof of work. At other consensus mechanisms, however, it is perhaps not so critical, so it might be considered as a low impact hack. 

Considering the Bitcoin network, cracking the elliptic curve cryptography of the digital signature by a quantum attacker can have different impacts. If it is a normal address, it might not be so tragic because most of the addresses are protected by an additional hash function, which is not so easy to crack even by quantum computers (Grover’s algorithm). So we can consider it a low impact hack. If we consider an early stage address, like all the Nakamoto addresses, they are without extra hash protection and usually store relatively big value. So, hacking such an address can surely be regarded as a high impact hack.

Considering Hyperledger Fabric, the situation depends on the exact use case. We can surely identify compromising a certificate authority and issuing false but valid certificates to be a high impact hack. On the other hand, quantum vulnerabilities of cryptographic hash function maintaining the consistency of the blockchain are not so critical. Due to the consortium, multi-company setup there might be a way for easy identification and a good coordinated resolution for such attacks. Nevertheless, we would probably identify as a medium impact hack.   

Quantum readiness

Another aspect of quantum analysis is the question of quantum readiness. In other words, when will quantum computers be ready to exploit the vulnerabilities of the different cryptographic primitives in real life. There are many different estimates when quantum computers will be really capable of cracking currently used cryptographic primitives. Although the question seems to be simple, it is far from being trivial to answer. There are two problems here to consider: 

  • On the one hand, some quantum computers, like D-Wave, are not capable of running quantum gates or circuits but rather designed for optimization problems. As a consequence, it does not matter how many qubits they have, they will not be able to crack current cryptographic primitives. 
  • On the other hand, even quantum computers designed to run for example the Shor’s algorithm are pretty unstable and full of errors. Error correcting algorithms of quantum computers are pretty strongly under research. 

Nevertheless, there are estimates that a few millions of physical qubits can already break currently used crypto systems, like 2048 bit RSA. The biggest quantum computer at the moment is said to be around 1000+ qubit, so we might as well argue there is still time until the quantum threat will be real. It is not necessarily wise, however, to underestimate the speed of an exponentially developed technology. If quantum technology really reaches its tipping point, efficient enough quantum computers can be here in years. 

Instead of giving an exact estimate when quantum computers will be available, we will use a similar quantitative scale as in the previous sections (Figure 3).  

Figure 3. Quantum readiness 

Due to the complexity of the field, we propose a simple three level scale to evaluate how far a quantum threat might be a real threat, having the expected in 10 years, somewhere in 10 to 20 years and over 10 years categories.

As an example, cracking currently used cryptographic elements with quantum computers based on prime factorization or elliptic curve can be expected in 10 years. The same is not necessarily true for hacking the currently used hash functions.       

Prevention / Risk mitigation

The last important question to be answered is if we have any idea how to prevent a possible quantum threat or how to mitigate the risk of a possible quantum attack. Generally the following ideas might be considered: 

  • Increasing key size: Symmetric ciphers or even cryptographic hash functions are meant to be secure against quantum attacks with increased key size, because Grover's algorithm can crack these ciphers only in n(square) time. Unfortunately, the same is not true for digital signatures. 
  • Post-quantum cryptography: These are based on classical computer algorithms that are secure against quantum attacks. The basis of such algorithms is usually a computational hard problem that can not be solved efficiently, not even with quantum computers. The area is under heavy research and the standardization is still in progress, but there might be standardized quantum resistant protocols in the near future.   
  • Quantum cryptography: Working cryptography with quantum computers solutions can be found, for instance, for key exchange or random number generation. These solutions, however, require special hardware considerations and setup. 

Another blockchain-specific aspect to consider is the immutability of distributed ledger protocols. As data can not be deleted from the ledger, it is questionable what can be done with all the cryptographic elements stored immutably on the ledger. Most typically, digital signatures are written into the ledger that are related very strongly to identity verification and data / ledger consistency. Modifying the cryptography behind such a signature can be quite challenging. In terms of blockchain, cryptographic primitives and upgrade, two categories can be distinguished here: 

  • Ledger dependent upgrade: immutable data / signatures recorded on the blockchain; and
  • Ledger independent upgrade: cryptographic primitives that can be changed independently from the ledger.

Similarly to the previous sessions, we can consider the prevention possibilities from a practical perspective having a three level scale again: 

Figure 4. Quantum risk mitigation, threat prevention 

  • In the “easily mitigate” category, we have a detailed procedure on what to do if a certain quantum threat becomes realistic. The procedure is well elaborated and tested in detail. 
  • In the “somehow mitigate” category, we have an idea what to do if a certain quantum threat becomes realistic, but the details are still unknown. As an example, TLS protocols will probably be migrated to quantum-resistant protocols having post-quantum cryptography. The details are, however, still unclear, as the whole area is in active research and standardization. 
  •  In the “not known how to mitigate” category, it is still not clear what to do if that quantum threat looks to be close. 

There are some further aspects to consider here. Upgrading cryptographic primitives in complex systems, even if there are standardized cryptographic protocols, can be quite challenging. It can require months or even years of preparation and testing. For this reason such processes should be prepared in time. 

One design technique might help in such upgrades that is called cryptographic agility. It means that the system is built in a way that the used cryptographic primitives are designed to be replaceable. It usually needs a kind of modular systems design having cryptography as a special module that is subject for upgrade and replacement. Although such a design sounds great in principle, it has some difficulties. Afterall, designing a modular system for cryptographic primitives is one thing, but designing the system in a way that modules can be replaced on-the-fly in a running system is much more challenging. It is even more challenging if we consider a blockchain system having cryptographic primitives written into the ledger. 

  Take as an example the idea of post-quantum signature migration, which would mean having new quantum secure addresses in the system and migrating all the data and application from the old addresses to the new ones. After such a migration process, the old quantum vulnerable addresses can be regarded as invalid. Although it sounds good generally, it is more difficult in practice. For example in a Hyperledger Fabric network, the whole application must be designed in a way that such a migration for new addresses can be executed and makes sense. In the Bitcoin network, this migration would mean transferring Bitcoin to new quantum secure addresses. The problem is that owners of the old addresses will not necessarily transfer due to several reasons. As an example, in Bitcoin the initial Nakamoto addresses have never been transferred. We might expect that they will not transfer even in a post-quantum migration. 

Overall risk evaluation

Finally, risk factors of the previous chapters must be aggregated into one risk level. We would propose to use here again a qualitative three level scale, like high risk, medium risk and low risk. It is certainly a question how we can aggregate the individual levels into an overall estimate. Generally, we would propose the following rules: 

  • If we have a high-impact threat that we expect will be available in 10 years and we do not know how to prevent, that will certainly be a high risk. RSA or elliptic curve-based digital signatures can be regarded to be in this category. Efficient attack against prime or elliptic curve  factorization will probably be available in 10 years and identity theft causes serious negative impact and prevention or mitigation techniques are still under research. 
  • Having a high-impact threat that will be realistic in 10 - 20 years with at least an idea how to prevent it can be considered a medium risk. As an example, quantum attacking the cryptographic hash function in the blockchain for hacking consistency can be regarded to be in this category. Having an inconsistent ledger has surely a high negative impact. Quantum attacking for example an sha256 is not so easy even with the Grover's algorithm, so an efficient hack might take here 10 - 20 years. There are good risk mitigation techniques here, like using sha512 instead of sha256.
  • Dealing with low impact threats with well known prevention possibilities can be evaluated as low quantum risk. 

 

Figure 5. Overall risk evaluation 

The assessment process

It is important to point out that the above described assessment is not a one point snapshot. It should be reevaluated continuously. As a general evaluation process, we propose the followings:

  • First system analysis and evaluation: It might be a couple of days workshop with industry and systems experts and roles on the following fields: system architects, security architects, cryptography experts, post-quantum cryptography experts and quantum computing experts. The result of the workshop is the first documented quantum risk analysis of a certain blockchain-based system.
  • Reevaluation periodically (like every year or two years): during the reevaluation, advancements of the following areas should be analyzed:
    • Advancement in quantum computers, like the amount of available qubits;
    • New quantum algorithms available; 
    • New results in attacking classical cryptography with quantum computing;
    • Advancement in post-quantum cryptography, like NIST standardization; and
    • Usability (technical and economic) of quantum cryptography.

Conclusion

In this article, we tried to come up with a high-level approach to assessing quantum threats and quantum risks of a blockchain-based system. It is important to note these fields are extremely complex: quantum computing, cryptography, post-quantum cryptography and blockchain systems are complex fields individually as well. Additionally, real life DLT systems might even be more complicated containing, for example, L2 solutions, blockchain interoperability or hybrid blockchain initiatives. 

Although real quantum attacks are still years ahead, it can never start to assess risks of the field early enough. One reason is that migrating such complex systems to quantum secure versions might take years of preparation, experimentation and testing, especially if we consider blockchain infrastructure and mission critical applications on top. Another reason is that, even if efficient enough quantum computers probably do not exist, there are quantum attack models already that can exploit privacy in a later date having data stored now (store now, harvest later attack). In this sense, having quantum attack analysis of our systems is highly critical even now.