Generation of Post-Quantum Certificates

Once the LACChain nodes have access to quantum entropy on demand, this entropy is consumed by OpenSSL as illustrated in Figure 2. Permanent quantum-safe cryptographic solutions such as QKD are not scalable today and require substantial investments in infrastructure. Feasible and practical solutions that provide quantum-resistance today involve PQC. Instead of replacing current Internet and blockchain protocols with new ones that incorporate PQC, we tried to introduce PQC in existing frameworks.

Based on the analysis presented above, we decided to use the traditional X.509 standard, which defines an internationally accepted format for digital documents that securely associates cryptographic key pairs with identities such as websites, individuals, and organizations.

By using a modified version of libSSL, the X.509 specification was extended to incorporate post-quantum and Ethereum (ECDSA) public keys, allowing blockchain nodes to use the modified libSSL to establish peer-to-peer quantum-safe channels that leverage those keys. Libssl is the portion of OpenSSL that supports TLS (SSL and TLS Protocols) and depends on libcrypto.

The nodes use the post-quantum keys to encapsulate communication with other nodes and sign transactions broadcasted to the blockchain. We decided to use the same algorithm for the generation of both types of keys (i.e., encryption keys and signing keys). Given the versatility of OpenSSL to incorporate any post-quantum algorithm, the election of the post-quantum algorithm was based on the restrictions inherent in executing blockchain transactions -essentially execution time and payload size- as different algorithms present substantial differences that condition the feasibility of on-chain verifications and storage.

We evaluated the two finalists of the NIST competition in the signature category in round 3 submissions, Crystals-Dilithium and Falcon (after round 4 submissions, NIST selected these two algorithms as recommendations in the digital signature category.). Figure 3 presents some of the differences between these two algorithms in terms of public key size, private key size, and signature size.

Both algorithms are very demanding regarding processing, memory, and amount of random material required to compute keys and signatures. However, Falcon has been acknowledged as the most compact and contains a built-in SHA3 compliant Extendable Output Function (XOF Shake256). The Ethereum VM natively supports the Keccak hashing algorithm upon which SHA 3 NIST FIPS202 is based, but it does not provide the extendable output functions (XOF) required. Further, implementing the shake XOF functionality is not straightforward. 

We evaluated the other signing algorithms but speed, complexity, and the fact that we would have to implement a SHA3 compliant ecosystem for the qRNG source to feed those schemes proved Falcon to be the best option. Our solution allows for the incorporation of new post-quantum algorithms, such as those that can be standardized by organizations such as NIST in the upcoming months and years.

To use Falcon, we needed to add a new object identifier (OID), the 1.3.9999.3.1, to libSSL in order to recognize the post quantum Falcon-512 algorithm. The process for the generation of post-quantum certificates is summarized in Figs. (4,5) and broken down into the following seven steps:

Figure 2 - Detailed flows describing the generation and consumption of entropy on demand by the Open SSL.
Figure 3 - Comparison between Falcon and Crystals-Dilithium algorithms.

The process for the generation of post-quantum certificates is summarized in Figs. (4,5) and broken down into the following seven steps:

  • The applicant requests and receives the entropy form the qRNG
  • The applicant generates a post-quantum Falcon-512 key pair using the quantum entropy through a modified version of the OpenSLL CLI (this modification has been made by the Open Quantum Safe Initiative and we have contributed with a Debian package to simplify its installation) and builds a certificate signing request (CSR).
  • The applicant generates a second CSR with an Ethereum key pair that will be used to sign transactions using the default method set by Ethereum (currently ECDSA).
  • The applicant sends to a certificate authority (CA) -a role played by the LACChain Technical Team in our pilot- (i) a traditional X.509 issued by a trusted CA, (ii) a certificate signing request (CSR) for the Ethereum key, and (iii) a CSR associated for the Falcon post-quantum key.
  • The CA verifies that (i) the traditional X.509 is valid, (ii) the subject in the traditional X.509 matches the subject in the CSRs, and (iii) the signature of the CSRs matches the public keys that are requested to be certified (i.e., the CSRs are valid).
  • If the verification fails, the certification process is rejected, and an error message is returned to the applicant.
  • If the validation process is passed, the CA proceeds to register three items into the smart contract within the blockchain called “the Decentralized Identifier (DID) Registry.” DIDs are URIs that follow a W3C standard70, which are suitable for the identification of individuals, entities, or other components within decentralized environments such as blockchain networks. The three items registered in the smart contract are (i) the DID, (ii) the Ethereum and Falcon post-quantum public keys, and (iii) the subject data or alternatively a proof of the subject’s identity that does not reveal subject data. Simultaneously, the CA also returns several items to the applicant, including the Falcon post-quantum X.509 certificate that contains the Ethereum public key, the Falcon post-quantum public key, and a new DID controlled by another DID derived from the ETH key.
Figure 4: High level diagram of the post-quantum certification and on-chain registration of an entity.
Figure 5: High level diagram of the post-quantum certification and on-chain registration of an entity.

Each of these steps is essential and additional useful clarifications are listed below:

  • CSR are files of encoded text that contain information to be included in the requested certificate such as the organization name, common name (domain name), address, and country. It also contains the public key that will be included in the certificate, but the private key is not disclosed. Instead, the private key is used to sign the request so the CA can verify that the requester is indeed in control of that particular private key.
  • The applicant is required to present a traditional X.509 so the blockchain CA does not have to accomplish the verification of the applicant’s identity from scratch. Both the applicant and the CA take advantage of a previous X.509 and the CA only verifies that the certified subject data in the X.509 matches the subject data in the CSRs.
  • The DID Registry follows the DID standard from the W3C which presents a data model for identifiers particularly designed to be resolved and verified in decentralized registries. Every time the CA certifies a new entity, it registers the DID in the blockchain with the information about the certified Ethereum and Falcon public keys, so that anyone with access to the public blockchain ledger can resolve the entity’s DID and verify the keys associated with them. For example, this would occur when the entity is using the Ethereum key, the Falcon key, or both to sign a transaction.

Check our terms and conditions, privacy policies, and cookies policy.

Twitter Linkedin Youtube

Copyright 2024 © All rights Reserved. Designed by LACNet