Table of Links Abstract and 1. Introduction Abstract and 1. Introduction 2. Context 2.1. Quantum computing as a threat to cryptography 2.1. Quantum computing as a threat to cryptography 2.2. Current approaches for quantum-safe cryptography 2.2. Current approaches for quantum-safe cryptography 2.3. Blockchain and the LACChain Blockchain Network 2.3. Blockchain and the LACChain Blockchain Network 3. The vulnerabilities of blockchain technology with the advent of quantum computing 3. The vulnerabilities of blockchain technology with the advent of quantum computing 4. A Proposal for a Quantum-Safe Blockchain Network 4. A Proposal for a Quantum-Safe Blockchain Network 5. Implementation and 5.1 Generation and distribution of quantum entropy 5. Implementation and 5.1 Generation and distribution of quantum entropy 5.2. Generation of Post-Quantum Certificates 5.2. Generation of Post-Quantum Certificates 5.3. Encapsulation of the communication between nodes using quantum-safe cryptography 5.3. Encapsulation of the communication between nodes using quantum-safe cryptography 5.4. Signature of transactions using post-quantum keys 5.4. Signature of transactions using post-quantum keys 5.5. On-chain verification of post-quantum signatures 5.5. On-chain verification of post-quantum signatures 6. Conclusions and next steps, Acknowledgements, and References 6. Conclusions and next steps, Acknowledgements, and References 5.3 Encapsulation of the communication between nodes using quantum-safe cryptography Communication between nodes is made through the protocol established by the blockchain technology and varies depending on the network used. In the case of the LACChain Besu Network used for this pilot, nodes communicate via TCP and use the RLPx for data encryption (this is the same for the Ethereum mainnet, as Hyperledger Besu is an Ethereum client.) This protocol seals messages with a ECDSA signature on curve SECP251k1 to link the network message to a peer address. We decided not to modify this protocol because that would require maintenance of a new blockchain technology. Instead, our goal was to keep using the Hyperledger Besu technology and develop a layer on top to make it quantum-resistant. With the aim of developing a layer-2 solution that could be used by any blockchain with any communication protocol and that would not be invasive to the protocol (i.e., does not require layer1 modifications), our solution consist of adding a point-to-point TLS tunnel modified to support post-quantum keys where the post-quantum X.509 certificates described in Subsection 5.2 are used for identification and authorization. For the pilot, we used Falcon-512 asymmetric keys. As this is built on a TLS connection that is not sensitive to the key length, unlike blockchain transactions, it is possible to use other postquantum algorithms. However, in order to be consistent with the use of a single post-quantum algorithm in the different phases of the pilot, we used Falcon-512. Once this tunnel is established, each node must route the traffic aimed at its counterpart through the TLS tunnel, making it unfeasible for a quantum computer to intercept the traffic and impersonate a node. This protects the blockchain network from different types of attacks. For example, because we are not modifying the blockchain protocol in our permissionless network, the node producers that vote for the generation of new blocks are still materializing this vote in an ECDSA signature (the consensus protocol requires 2/3+1 of node producer’s signatures for a block to be considered valid) that is neither replaced not complemented with a post-quantum signature. However, if a hacker was to discover all the private ECDSA keys of the validator nodes and tried to tamper with the block production by changing the valid transactions and use the validator nodes’ signatures to sign them, it could not achieve it because it cannot intercept the communication between nodes where they could provoke this type of man-in-the-middle attack. The hacker would need to hack and access each of the validator node servers, for which quantum computers present no advantage. In any case, despite the fact that we believe this threat is removed with our solution, it would be easier and more convenient to modify the Ethereum protocol so cryptographic algorithms different from ECDSA, such as Falcon-512, are recognized and can be used by validator nodes to sign blocks. 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. Authors: (1) M. Allende, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (2) D. López Leon, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (3) S. Ceron, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (4) A. Leal, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (5) A. Pareja, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (6) M. Da Silva, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (7) A. Pardo, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (8) D. Jones, Cambridge Quantum Computing - Cambridge, United Kingdom; (9) D.J. Worrall, Cambridge Quantum Computing - Cambridge, United Kingdom; (10) B. Merriman, Cambridge Quantum Computing - Cambridge, United Kingdom; (11) J. Gilmore, Cambridge Quantum Computing - Cambridge, United Kingdom; (12) N. Kitchener, Cambridge Quantum Computing - Cambridge, United Kingdom; (13) S.E. Venegas-Andraca, Tecnologico de Monterrey, Escuela de Ingenieria y Ciencias. Monterrey, NL Mexico. Authors: Authors: (1) M. Allende, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (2) D. López Leon, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (3) S. Ceron, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (4) A. Leal, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (5) A. Pareja, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (6) M. Da Silva, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (7) A. Pardo, IDB - Inter-American Development Bank, 1300 New York Ave, Washington DC, USA and LACChain - Global Alliance for the Development of the Blockchain Ecosystem in LAC; (8) D. Jones, Cambridge Quantum Computing - Cambridge, United Kingdom; (9) D.J. Worrall, Cambridge Quantum Computing - Cambridge, United Kingdom; (10) B. Merriman, Cambridge Quantum Computing - Cambridge, United Kingdom; (11) J. Gilmore, Cambridge Quantum Computing - Cambridge, United Kingdom; (12) N. Kitchener, Cambridge Quantum Computing - Cambridge, United Kingdom; (13) S.E. Venegas-Andraca, Tecnologico de Monterrey, Escuela de Ingenieria y Ciencias. Monterrey, NL Mexico. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. This paper is available on arxiv under CC BY-NC-ND 4.0 DEED license. available on arxiv
