Quantum-resistance in blockchain networks: Signature of transactions using post-quantum keys

Table of Links

Abstract and 1. Introduction

2. Context

2.1. Quantum computing as a threat to cryptography

2.2. Current approaches for quantum-safe cryptography

2.3. Blockchain and the LACChain Blockchain Network

3. The vulnerabilities of blockchain technology with the advent of quantum computing

4. A Proposal for a Quantum-Safe Blockchain Network

5. Implementation and 5.1 Generation and distribution of quantum entropy

5.2. Generation of Post-Quantum Certificates

5.3. Encapsulation of the communication between nodes using quantum-safe cryptography

5.4. Signature of transactions using post-quantum keys

5.5. On-chain verification of post-quantum signatures

6. Conclusions and next steps, Acknowledgements, and References

5.4 Signature of transactions using post-quantum keys

Unlike the first three phases, the implementation of the fourth phase requires us to be particular about each specific blockchain network. There are blockchain protocols that recognize different encryption algorithms and/or are already flexible in incorporating new ones. At the present moment, this is not the case of Ethereum and the Ethereum-client, Hyperledger Besu, on top of which the LACChain Network used in the pilot is built [65]. In this context, our way for introducing a mechanism to add a quantum signature to the transactions broadcasted to the network without modifying the blockchain protocol was the development of a relay signer and a meta-transaction signing schema.

A meta-transaction is a mechanism through which to wrap a regular transaction into another transaction addressed to a method of a smart contract (a.k.a. relay Hub) which unwraps and executes the original transaction. Because the meta-transaction is a regular call to a smart contract, we can add new parameters along with the original transaction. In this case, our design allows us to add the writer node’s URI (a DID [81]) and a post-quantum signature to the original transaction.

We have developed a relay signer that is provided to the writer nodes -the only nodes allowed to broadcast transactions according to the LACChain topology [82]- that can manage post-quantum keys. This component exposes a JSON-RPC standard interface, instrumenting methods to make the whole operation transparent to the user. Each writer node is responsible for keeping its Falcon512 private key safe, and the signer to generate the meta-transaction. Figure 6 summarizes these concepts. Furthermore, full interaction among components is presented in Fig. 7.

Following the EIP-155 [83], signatures in Ethereum take nine RLP encoded elements: nonce, gasprice, startgas, to, value, data, chainid, 0, 0. For consistency, we took the same stream of data to generate the Falcon-512 signatures. This guarantees the integrity of the original transaction -the writer node cannot modify it- and its quantum resistance by adding the post-quantum signature in the meta transaction. Writer nodes leverage the post-quantum public keys certified by a CA in the post-quantum X.509.

It is worth mentioning that we are only adding a post-quantum signature in the meta transaction that is created by the writer node, but original senders (i.e., blockchain addresses) are still using only the ECDSA signatures to sign their transactions. Ethereum addresses are the 20 bytes of the SHA3 hashed ECDSA public key, so the public key is not directly exposed. However, when an address sends a transaction, the private key is used to sign it and therefore it is necessary to reveal the public key so the transaction can be verified.

Thus, if a blockchain address is in possession of certain tokens or has a particularly relevant role in the network (e.g., being permissioned in a smart contact that can issue digital bonds), a quantum computer could be used to hack the private key associated to that address and send transactions to the blockchain that impersonate the true owner. This would allow the hacker to steal the victim’s funds or to assume their particularly relevant role in the network, respectively.

Our solution allows to remove this threat by enabling each smart contract to require postquantum authentication and leveraging for it one of our on-chain verification mechanisms presented in Section 5.5 . Only the transference of Ether would not be protected, but LACChain does not have Ether enabled.

As in the case of the signatures by validator nodes described in Section 5.3, it would be much easier, ideal, and convenient to have the Ethereum technology enabling the use of quantum-safe cryptographic algorithms that can be used at the protocol level to sign and verify transactions. We believe that Ethereum Improvement Proposals (EIPs) such as the EIP-2938 [84] are moving in the right direction and are very aligned with the work described in this paper.