QUANTUM RESISTANT LEDGER FOR SECURE COMMUNICATIONS

According to an embodiment, a method includes identifying, by a first network component, data and determining a security level from a plurality of security levels associated with the data. The method also includes determining an encryption scheme from a plurality of encryption schemes to apply to the data and applying, using a Quantum Resistant Ledger (QRL), the encryption scheme to the data to generate encrypted data. The method further includes communicating the encrypted data to a second network component.

TECHNICAL FIELD

The disclosure generally relates to secure communications, and more specifically to a quantum resistant ledger for secure communications.

BACKGROUND

The emerging 5G infrastructure allows for high throughput and low latency. Data encryption continues to be an Achilles' heel in this new environment. Quantum technology may defeat known encryption schemes (e.g., Rivest-Shamir-Adleman (RSA) 2048) using, for example, Shor's algorithm with quantum computers.

SUMMARY OF THE DISCLOSURE

According to some embodiments, a first network component includes one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions that, when executed by the one or more processors, cause the first network component to perform operations. The operations include identifying data and determining a security level from a plurality of security levels associated with the data. The operations also include determining an encryption scheme from a plurality of encryption schemes to apply to the data and applying, using a Quantum Resistant Ledger (QRL), the encryption scheme to the data to generate encrypted data. The operations further include communicating the encrypted data to a second network component.

In certain embodiments, the QRL represents a blockchain that includes a plurality of blocks. Each of the plurality of blocks may include a hash-based signature. In some embodiments, the encryption scheme is associated with one of the following: classical encryption, post-quantum encryption, or distributed ledger technology (DLT). In certain embodiments, the security level is associated with one of the following: an 80-bit security level, a 112-bit security level, a 128-bit security level, a 192-bit security level, or a 256-bit security level.

In certain embodiments, the operations include generating, using the QRL, a single public key and/or leveraging the single public key to generate public/private key pairs. In some embodiments, the operations include securing, using the QRL, signatures used for transactions. In certain embodiments, the operations include categorizing the first network component and the second network component in accordance with a role-based validation rule.

According to other embodiments, a method includes identifying, by a first network component, data and determining a security level from a plurality of security levels associated with the data. The method also includes determining an encryption scheme from a plurality of encryption schemes to apply to the data and applying, using a QRL, the encryption scheme to the data to generate encrypted data. The method further includes communicating the encrypted data to a second network component.

According to other embodiments, one or more computer-readable non-transitory storage media embody instructions that, when executed by a processor, cause the processor to perform operations. The operations include identifying, by a first network component, data and determining a security level from a plurality of security levels associated with the data. The operations also include determining an encryption scheme from a plurality of encryption schemes to apply to the data and applying, using a QRL, the encryption scheme to the data to generate encrypted data. The operations further include communicating the encrypted data to a second network component.

Technical advantages of certain embodiments of this disclosure may include one or more of the following. In certain embodiments, the QRL described herein counters the potential advent of a sudden non-linear quantum computing advance. Certain embodiments of this disclosure do not require a quantum computer to deploy the Post Quantum Cryptography (PQC) solution, thereby making it very feasible. The QRL technology can be implemented on classical binary computers available today instead of waiting for quantum computers to mature. In certain embodiments, the QRL/Blockchain/DLT solutions operate on top of 5G/XG for better data protection in a military setting. The QRL solution may be applied at different levels of security for different quality of service (QoS) levels. In certain embodiments, the QRL solution described herein leverages government validated post-quantum encryption schemes to enhance data security and integrity. Certain embodiments described herein secure communications in an enterprise IP and 5G environments.

In certain embodiments, quantum resistant DLT is layered on top of the XG network architecture, which ensures high throughput, low latency, and secure communications. Certain embodiments of this disclosure use low power, high frequency bandwidths, which allows for better Low Probability of Intercept/Detection (LPI/LPD) in a contested/congested environment. DLT may be layered on top of the radio frequency (RF) oriented secure exchange schemes. In certain embodiments, DLT leverages blockchain architecture and is coupled with advanced quantum-resistant encryption (as described herein). This later feature enhances the immutable nature of a traditional blockchain architecture. Certain embodiments described herein are scalable and can accommodate blockchain as it moves toward a proof-of-stake security (PoS) scheme that allows for a high transaction rate. This fits in the fire-control loop environment, as many sensors emit at high update rates. By adapting the quantum resistant ledger concept described herein, sensitive data can be distributed, ensuring data confidentiality, integrity, and availability (C-I-A).

Blockchain's built in characteristics (e.g., immutability and traceability) provide users with a means to ensure data integrity. When paired with QRL running post-quantum encryption, data becomes even more secure. The 51 percent rule in blockchain and the consensus protocol in QRL enhance confidentiality. Given that both public and private blockchain consist of multiple nodes, users can make a node under attack redundant and continue to operate business as usual. Thus, even if a major part of the blockchain network is under attack, the blockchain network will continue to operate due to the distributed nature of the technology. Additionally, if an attacker gains access to a blockchain network and the data, this does not necessarily mean the attacker can read or retrieve the information. Full encryption of the data blocks may be applied to data being transacted, effectively guaranteeing its confidentiality.

DETAILED DESCRIPTION OF THE DISCLOSURE

Embodiments of this disclosure describe a PQC solution called QRL. PQC and blockchain/DLT together are combined to leverage advanced encryption algorithms from PQC and the immutability feature from Blockchain/DLT. This blended QRL and National Institute of Standards and Technology (NIST)-compliant PQC solution resists the Shor's integer factorization quantum attack scheme. Since many Manned-unmanned teaming (MUM-T) use cases are typically short range in nature (e.g., having an autonomous wingman next to a human-piloted aircraft), 5G/Next Generation (XG) can use low power, high frequency bandwidths to communicate between platforms. While certain types of waveforms provide low probability intercept (LPI)/low probability detect (LPD) capabilities in a contested/congested environment at the physical radio frequency (RF) layer, there is no such encryption at the data layer.

The QRL approach described herein uses any number of encryption approaches, such as Kyber for key encryption and Dilithium for digital signatures. Both Kyber and Dilithium are industry and Department of Defense (DoD) compliant. Both Kyber and Dilithium offer larger key sizes than other schemes, so higher transaction rates can be achieved in a 5G or XG use case. Since 5G and XG each provide a layered architecture (similar to 7-layer Open Systems Interconnection (OSI) architecture for network), the QRL runs like any software application and will be transparent to the end users.

QRL is a blockchain with hash-based signatures for the blocks. In certain embodiments, QRL mitigates quantum advances through one time signature (OTS). QRL leverages a single public key, and QRL generates subsequent public/private key pairs after that. In certain embodiments, QRL leverages the Merkle Tree Signature Scheme (MTSS), which is digital signature scheme formalized by NIST SP 800-208. QRL secures signatures used for transactions against brute forcing by quantum advances and/or Grover's Algorithm. For example, quantum computers are advantageous for integer factorization. However, selected approaches disclosed herein (e.g., Kyber and Dilithium algorithms) do not rely on integer factorization for encryption.

QRL supports different forms of consensus models (e.g., proof-of-work (PoW), proof-of-stake (PoS), etc.). For example, QRL supports new protocols such as the RandomX PoW algorithm. To allow a higher transaction rate, QRL can be set up as a PoS architecture. QRL allows secure communications via on-chain lattice key creation/storage.

FIG.1illustrates a table100showing layers of encryption, in accordance with certain embodiments. The illustrated embodiment ofFIG.1includes the following layers110: an application layer110a, a logical network layer110b, a physical data link/network layer110c, a physical RF layer110d, and a QRL layer110e. Layers110athrough110deach include a data plane120, a control plane130, and a visibility plane140. Specifically, application layer110aincludes a data plane120a, a control plane130a, and a visibility plane140a. Logical network layer110bincludes a data plane120b, a control plane130b, and a visibility plane140b. Physical data link/network layer110cincludes a data plane120c, a control plane130c, and a visibility plane140c. And physical RF layer110dincludes a data plane120d, a control plane130d, and a visibility plane140d.

Data planes120of table100include encryptors121and hardware security controller interfaces122. Specifically, data plane120aof application layer110aincludes a Transport Layer Security (TLS) encryptor121aand a hardware security controller interface122a. Data plane120bof logical network layer110bincludes a Network Function Virtualization (NFV) encryptor121band a hardware security controller interface122b. Data plane120cof physical data link/network layer110cincludes Media Access Control security (MACsec)/Internet Protocol Security (IPsec) encryptors121cand a hardware security controller interface122c. And data plane120dof physical RF layer110dincludes a communications security (COMSEC) encryptor121dand a hardware security controller interface122d.

In the illustrated embodiment ofFIG.1, each control plane130of each layer110includes a session manager131, a key manager132, a hardware security controller interface133, an authentication (AuthN)134, an authorization (AuthZ) policy enforcement point135, and an AuthZ policy decision point136. Specifically, control plane130aof application layer110aincludes a session manager131a, a key manager132a, a hardware security controller interface133a, an AuthN134a, an AuthZ policy enforcement point135a, and an AuthZ policy decision point136a. Control plane130bof logical network layer110bincludes a session manager131b, a key manager132b, a hardware security controller interface133b, an AuthN134b, an AuthZ policy enforcement point135b, and an AuthZ policy decision point136b. Control plane130cof physical data link/network layer110cincludes a session manager131c, a key manager132c, a hardware security controller interface133c, an AuthN134c, an AuthZ policy enforcement point135c, and an AuthZ policy decision point136c. And control plane130dof physical RF layer110dincludes a session manager131d, a key manager132d, a hardware security controller interface133d, an AuthN134d, an AuthZ policy enforcement point135d, and an AuthZ policy decision point136d.

As illustrated inFIG.1, QRL150of QRL layer110eis unique due to its flexibility. Within the communications and networking domains, there can be many layers of encryption. For example, within the OSI physical layer (e.g., physical RF layer110d), COMSEC encryption (e.g., by COMSEC encryptor121d) is very common in the physical domain. MACsec and/or IPsec (e.g., by MACSec/IPSec encryptors121c) are typical encryptions found at the data link or network layers (e.g., physical data link/network layer110c). NFV encryptions (e.g., by NFV encryptor121b) are popular at logical network layer110b. And at application layer110a, TLS encryption (e.g., by TLS encryptor121a) may be present to enhance data security. These encryptions may be run independent from each other with no interference of each other's performance. QRL150can be seen as another layer of security running on top of these layers. Systems and/or security engineers may use QRL150in absence or in conjunction with any of these other encryptions residing at different layers.

Each approach has its own benefits and shortcomings. For example, some approaches perform better than others in certain conditions, some approaches have larger or smaller key sizes, etc. Hence, the real encryption world is not a one-size-fits-all. QRL150has the flexibility to accommodate for different PQC algorithms, which allows the algorithms to evolve independently over time and not have an interoperability issue with QRL150itself.

In the 5G use case, some PQCs will likely have performance advantages over others in terms of resource overhead, delay time, encryption/decryption power requirements, etc. This opens the door for fine-tuning a given PQC for different application use case scenarios within the 5G context. With the implementation of QRL layer110e, different security levels may be allowed as a function of quality of service (QoS).

FIG.2illustrates a QRL ephemeral messaging system200, in accordance with certain embodiments. QRL ephemeral messaging system200ofFIG.2includes a network202, network nodes210, master seeds212, KEMs214, signature mechanisms216, KEM key pairs218, signature key pairs220, exporter master secrets222, and lattice transmissions224. Specifically, node210aof network nodes210includes a master seed212a, a KEM214a(KEMHkeygen), a signature mechanism216a(SIGNHkeygen), a KEM key pair218a(skAK, pkAK), a signature key pair220a(skAS, pkAS), an exporter master secret222a(EMSAO=pkAK·skAK), and a lattice transmission224a(lattice tx of A signed with XMSS). Node210bof network nodes210includes a master seed212b, a KEM214b(KEMHkeygen), a signature mechanism216b(SIGNHkeygen), a KEM key pair218b(skBK, pkBK), a signature key pair220b(skBS, pkBS), an exporter master secret222b(EMSBO=pkBK·skBK), and a lattice transmission224b(lattice tx of B signed with XMSS).

Network202of QRL ephemeral messaging system200is any type of network that facilitates communication between components of QRL ephemeral messaging system200. Network202may connect one or more components of QRL ephemeral messaging system200. One or more portions of network202may include an ad-hoc network, the Internet, an intranet, an extranet, a virtual private network (VPN), an Ethernet VPN (EVPN), a local area network (LAN), a wireless LAN (WLAN), a virtual LAN (VLAN), a wide area network (WAN), a wireless WAN (WWAN), a software-defined WAN (SD-WAN), a metropolitan area network (MAN), a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a Digital Subscriber Line (DSL), an Multiprotocol Label Switching (MPLS) network, a 3G/4G/5G network, a Long Term Evolution (LTE) network, a cloud network, a combination of two or more of these, or other suitable types of networks. Network202may include one or more different types of networks. Network202may be any communications network, such as a private network, a public network, a connection through the Internet, a mobile network, a Wi-Fi network, etc. Network202may include a core network (e.g., a 5G core network), an access network of a service provider, an Internet service provider (ISP) network, and the like. One or more components of QRL ephemeral messaging system200may communicate over network202. Network202of QRL ephemeral messaging system200includes a post-quantum (PQ) message network202a.

Network nodes210of QRL ephemeral messaging system200are connection points within network202that receive, create, store and/or send data along a path. Network nodes210may include one or more redistribution points that recognize, process, and forward data to other nodes of network202. Network nodes210may include virtual and/or physical nodes. For example, network nodes210may include one or more physical devices, virtual machines (VMs), bare metal servers, and the like. As another example, network nodes210may include data communications equipment such as computers, routers, servers, printers, devices, workstations, switches, bridges, modems, hubs, and the like.

In the illustrated embodiment ofFIG.2, network nodes210(node210aand node210b) are set up in a virtual environment for testing purposes. Node210ais the sender, and node210bis the receiver. QRL ephemeral messaging system200is created to pass data (e.g., messages) between node210aand node210b. This configuration allows for a quantitative measurement of the network traffic metric and encryption times. Specific Measures of Effectiveness (MOE) are used to gauge the effectiveness of this QRL solution.

Master seeds212of QRL ephemeral messaging system200represent n-byte strings that are used to generate keys. In certain embodiments, master seeds212are public information. In the illustrated embodiment ofFIG.2, master seed212a(SEED A) is assigned to node210a, and master seed212b(SEED B) is assigned to node210b. In certain embodiments, master seeds212are used to generate KEM key pairs218and signature key pairs218based on selected encryption schemes.

The QRL approach described herein may use any number of encryption schemes. Encryption schemes may include classical encryption schemes (e.g., RSA-2048), post-quantum encryption schemes (e.g., Kyber-1024), DLT/blockchain encryption schemes, and the like. In certain embodiments, encryption schemes include KEMs214and signature mechanisms216.

KEMs214may include one or more of the following: Classic McEliece, Cryptographic Suite for Algebraic Lattices (CRYSTALS) Kyber, the NTRU encryption algorithm (NTRUEncrypt), SABER, or any other suitable KEM. In the embodiment ofFIG.2, the user selected Kyber for KEM214ato use within QRL ephemeral messaging system200.

Signature mechanisms216may include one or more of the following: Falcon, CRYSTALS Dilithium, Rainbow, or any other suitable digital signature scheme. In the embodiment ofFIG.2, the user selected Dilithium for signature mechanisms216aand216bto use within QRL ephemeral messaging system200.

KEM key pairs218(e.g., KEM key pair218aand KEM key pair218b) of QRL ephemeral messaging system200represent Kyber public/private key pairs. In certain embodiments, the private/secret key (sk) of each signature key pair218is used to generate the key, and the public key (pk) of each signature key pair218is used to verify the key.

Signature key pairs220(e.g., signature key pair220aand signature key pair220b) of QRL ephemeral messaging system200represent Dilithium public/private key pairs. In certain embodiments, the private/secret key (sk) of each signature key pair220is used to generate the digital signature, and the public key (pk) of each signature key pair220is used to verify the digital signature.

Ephemeral messaging systems222of QRL ephemeral messaging system200represent values derived from KEM key pairs218and signature key pairs220. For example, EMS222a(EMSAO) for node210ais generated by multiplying the public keys pkAKand pkASgenerated by KEM214aand signature mechanism216a, respectively, and EMS222b(EMSBO) for node210bis generated by multiplying the public keys pkBKand pkBSgenerated by KEM214band signature mechanism216b, respectively.

Lattice transmissions224of QRL ephemeral messaging system200are the transmissions from network nodes210to QRL blockchain230that are signed with XMSS. In QRL ephemeral messaging system200, lattice transmission224aof node210aand lattice transmission224bof node210b, which are signed with XMSS, are communicated to QRL blockchain230.

In the illustrated embodiment ofFIG.2, QRL blockchain230is a blockchain/DLT that is run on top of QRL (e.g., QRL150ofFIG.1). As shown inFIG.2, users may utilize public keys (pk) and private/secret keys (sk) to digitally sign and securely transact within QRL ephemeral messaging system200. In certain embodiments, a blockchain is a distributed database with a list (or a chain) of records (or blocks) linked and secured by digital fingerprints (e.g., cryptographic hashes). Hashing is a method of applying a cryptographic hash function to data. In some embodiments, hashing calculates a relatively unique output (called a message digest, or just digest) for an input (e.g., a file, text, or image) of nearly any size. Hashing allows users to independently take input data, hash that data, and derive the same result to prove that there was no change in the data. Even the smallest change to the input (e.g., changing a single bit) will result in a completely different output digest. A hash (e.g., eb8ecbf6d5870763ae246e37539d82e37052cb32f88bb8c59971f9978e437743) is a small digest checksum calculated with a one-way crypto hash digest checksum function (e.g., Secure Hash Algorithm (SHA) 256 Bits) from the data. In certain embodiments, the blockchain algorithm uses a block timestamp (e.g., 1637-09-15 20:52:38), a hash from the previous block (e.g., edbd4e11e69bc399a9ccd8faaea44fb27410fe8e3023bb9462450a0a9c4caalb), and block data (e.g., transaction data).

In PQ message network202a, node210auses an encryption algorithm232a(KEMHenc(pkBK)) that on input of node210b's public key (pkBK) and a message outputs ciphertext231(C1). Ciphertext231is communicated to node210bvia PQ message network202a. Node210buses a decryption algorithm232b(KEMHdec(skBK·C1) that on input of node210b's secret key (skBK) and ciphertext231(C1) outputs a message. Node210aand node210bnow both have access to P1and K1(234afor node210aand234bfor node210b) of the message. P1represents the plain text space or clear text space of the message, C1represents the cypher text space, and K1represents the key space. The messages are then hashed using a hash algorithm (e.g., Secure Hash Algorithm and KECCAK (SHAKE)). As illustrated inFIG.2, lattice transmission238afrom node210ato QRL blockchain230includes the public key (pkBK) of node210b.

FIG.3illustrates a screenshot300of executing QRL (e.g., QRL150ofFIG.1) on a command line interface (CLI), in accordance with certain embodiments. In certain embodiments, QRL is provided with a CLI, where end users can execute specific commands for development and testing purposes. Screenshot300ofFIG.3includes hashes (e.g., a48fbef41fe4164164ed331685d27f2975f), block timestamps (e.g., 2021-05-20 08:55:28), the programming language used (e.g., Python), mining block identifiers (e.g., #229299), hash rates (e.g., 40 hashes/second), nonces (e.g., 2), a hash from the previous block (e.g., 19182884b5d218ddOdb7ab79911a1d68), as well as other block data.

FIG.4illustrates a screenshot400showing QRL key creation, in accordance with certain embodiments. After successful installation and implementation of QRL (e.g., QRL150ofFIG.1), keys are created. The keys include an XMSS key410, an Elliptic Curve Digital Signature Algorithm (ECDSA) key420, Kyber keys430, and Kilithium keys440. XMSS key410is used to generate ECDSA key420.

FIG.5illustrates a screenshot500showing classical encryption, in accordance with certain embodiments. Once a key (e.g., ECDSA key420ofFIG.4) is created, classical encryption may be used to encrypt data (e.g., messages) in a virtual environment. In the illustrated embodiment ofFIG.5, classical encryption is enabled without errors.

FIG.6illustrates a screenshot600showing post-quantum encryption, in accordance with certain embodiments. In addition to classical encryption, QRL allows end users the option to run post-quantum secure encryption of messages. This is important because it allows users to compare quantitatively between the classical and post-quantum encryption performance. The expectation was that post-quantum encryption should take longer because of the complexity of the scheme. In potential use cases for 5G and 21st century warfare, there may be instances where users (e.g., operators, administrators, software engineers, etc.) need to have different levels of security. Post-quantum encryption is more secure than classical encryption but at the expense of performance penalty. This corresponds to the concept of network slicing in 5G.

FIG.7illustrates a screenshot700showing a blockchain implementation, in accordance with certain embodiments. For certain classes of applications (or traffic) that require a higher level of security, users (e.g., operators, administrators, software engineers, etc.) may decide to run Blockchain/DLT on top of QRL.FIG.7shows the recipient as “all,” which means the sender node (e.g., node210aofFIG.2) is broadcasting the block to every node on the private network. The key, as indicated in screenshot700, has been encrypted. In this embodiment, only the nodes that possess the right key can decrypt the hashed block. Some nodes may have permission to read the ledger, while other nodes may have permission to both read and write to the ledger. The read-only nodes, while they may be compromised by a quantum computer, do not have the ability to write to the ledger.

Blockchains have no single point of failure, which highly decreases the chances of an IP-based Distributed Denial of Service (DDoS) attack disrupting the normal operation. If a node is taken down, data is still accessible via other nodes within the network since all of them maintain a full copy of the ledger at all times. The distributed nature of the technology solves the Byzantine General's problem of false consensus. As an example, the well-publicized Bitcoin survived multiple DDoS attacks over its decade old history. Blockchain infrastructure provides a further level in data accessibility, given that data is accessible through any of the nodes in the network, even in the event of a DDoS attack disrupting some of the nodes.

In certain embodiments, blockchain networks are categorized based on their permission models. A permission model determines who can maintain the blockchain (e.g., publish blocks). For a transaction to be valid in a permissioned blockchain environment, both the transmitter and the block information need to be validated before the new block becomes part of the existing blockchain. In certain embodiments, a validation rule is used to add additional source code to check whether the sender nodes have the privilege to push data to the distributed data environment where all the other nodes can receive the same data hash. In some embodiments, a role-based validation rule is used, which is based on the roles of the nodes. While it is feasible to set up the rules where every node that belongs to the blockchain group can both send and receive data, it is less likely that this is how it works on a platform or mission system where there are only a handful of nodes that play the role of a data source. Nonetheless, it may be beneficial in certain embodiments to categorize nodes based on their roles within an organization. Even if this role-based validation rule is not needed for a given application, it is helpful in managing the network from an efficiency standpoint.

FIG.8illustrates a graph800of key generation time analytical results810, in accordance with certain embodiments. In the initial setup for the key generation time analysis, tests via local loopback were conducted in a VM environment. Once QRL (e.g., QRL150ofFIG.1) was running properly, two Amazon Elastic Compute Cloud (EC2) servers were used as end points. The servers included two different network interface cards (NIC) instead of the internal loopback, which only included one NIC. Key generation time analytical results810captured inFIG.8illustrate a key generation time820for a Monte Carlo set of 20 runs/occurrences830. As expected, there were some variances depending on the central processing unit (CPU) and memory usage at any given moment. Mean value840for key generation time820of 20 runs/occurrences830was 6.97 seconds. The highest key generation time820was 14 seconds.

FIGS.9A and9Billustrates graphs900of analytical results910for message send times920with versus without an encryption key assigned, in accordance with certain embodiments. Message send time analytical results910captured inFIGS.9A and9Billustrate message send times920for a Monte Carlo set of 10,000 runs/occurrences930. As illustrated in graph900aofFIG.9A, when the messages were sent without encryption, mean value940afor message send time920aof 10,000 runs/occurrences930awas 0.086 seconds. As illustrated in graph900bofFIG.9B, when the same test was repeated but with RSA-2048 encryption, mean value940bfor message send time920bof 10,000 runs/occurrences930bbecame 0.27 seconds. This aligns to the qualitative expectation that the group of runs without encryption should be sent quicker than those with encryption because of the additional overhead resources being spent on encrypting the messages themselves.

FIGS.10A and10Billustrate graphs1000of analytical results1010showing classical encryption versus decryption of messages, in accordance with certain embodiments. Classical encryption and decryption incur additional overheads. Graphs1000capture the amount of time1020taken for classical encryption and decryption of messages. Analytical results1010captured inFIGS.10A and10Billustrate times1020for a Monte Carlo set of 10,000 runs/occurrences1030. As illustrated in in graph1000aofFIG.10A, the mean value1040afor time1020ato encrypt the messages for 10,000 runs/occurrences1030awas 0.074 seconds. As illustrated in in graph1000bofFIG.10B, the mean value1040bfor time1020bto decrypt the same messages for 10,000 runs/occurrences1030bwas 0.083 seconds, which is slightly higher. The length of the messages will play a role. It is expected that longer messages with more bits will take longer to encrypt and decrypt.

FIG.11illustrates a screenshot1100of post-quantum encryption results, in accordance with certain embodiments. Screenshot1100was generated using CRYSTALS Kyber public key encryption/KEM (Kyber 1024). In certain embodiments, this encryption scheme is used as a KEM to securely transfer an AES symmetric key. Screenshot1100ofFIG.11shows post-quantum encryption being successfully executed.

Multiple security levels may be implemented for KEMs. In cryptography, a security level is a measure of the strength that a cryptographic primitive (e.g., a cipher or hash function) achieves. In certain embodiments, the security level is expressed as a number of bits (e.g., 80 bits, 112 bits, 128 bits, 192 bits, 256 bits, etc.) of security. For example, AES-128 provides a 128-bit security level. As another example, Kyber-512 roughly corresponds to AES 128, which provides a 128-bit security level. As still another example, Kyber-768 roughly corresponds to AES 192, which provides a 192-bit security level. As yet another example, Kyber-1024 roughly corresponds to AES 256, which provides a 256-bit security level. For the testing performed for screenshot1100, Kyber-1024 was used.

FIG.12illustrates a 5G end-to-end testbed1200, in accordance with certain embodiments. 5G end-to-end testbed1200is used to quantify network effects. In certain embodiments, 5G end-to-end testbed1200is more representative of an actual network stack than local loopback/intra subnet traffic. 5G end-to-end testbed1200allows for user equipment (UE)-to-UE message transition. In certain embodiments, 5G end-to-end testbed1200is assumed to capture all traffic for later analysis. In some embodiments, 5G end-to-end testbed1200is assumed to impair the network to produce legacy speeds.

In the illustrated embodiment ofFIG.12, 5G end-to-end testbed1200includes VMs1210, a client1220, a 5G UE device1230, a remote radio unit1240, a 5G multi-access edge computing (MEC) base station server1250, a software-defined (SD) edge computing platform1260, a 5G core network server1270, and an IP gateway1280.

VMs1210(e.g., VM1210aand VM1210b) of 5G end-to-end testbed1200represent virtual machines that serve as endpoints for 5G end-to-end testbed1200. In certain embodiments, QRL runs on VMs1210. In some embodiments, VMs1210need to be compatible with the VMWare set up in LoadCore of 5G end-to-end testbed1200.

Client1220of 5G end-to-end testbed1200represents any application, plug-in, or other executable code that runs as a computer program on 5G UE device1230. For example, in the illustrated embodiment ofFIG.12, client1220may represent a post-quantum messaging application.

5G UE device1230of 5G end-to-end testbed1200represents any user equipment (e.g., a workstation, a desktop computer, a smartphone, a tablet, a laptop, etc.) that is used to access a network. In the illustrated embodiment ofFIG.12, 5G UE device1230is a Samsung Galaxy S20 Ultra 5G.

Remote radio unit1240of 5G end-to-end testbed1200represents a radio hardware device that transform radio signals from/to the antenna into digital signals that may be sent across packet networks. In the illustrated embodiment ofFIG.12, remote radio unit1240includes a radio head and firmware.

5G MEC base station server1250of 5G end-to-end testbed1200represents a MEC application server that is deployed at a 5G base station. In the illustrated embodiment ofFIG.12, 5G MEC base station server1250is a Systel ruggedized server. In certain embodiments, 5G MEC base station server1250is associated with a 5G gNB O-RAN compliant Radio Unit (O-RU).

SD edge computing platform1260of 5G end-to-end testbed1200represents an edge platform for deploying edge networks. In certain embodiments, SD edge computing platform1260is Kubernetes-based. SD edge computing platform1260may deliver MEC for applications, containers, VMs, etc. SD edge computing platform1260may use the Radisys MEC solution, Intel Smart Edge, and the like.

5G core network server1270of 5G end-to-end testbed1200represents any suitable 5G network server. In certain embodiments, 5G core network server1270uses the 5G system architecture consisting of network functions (NF), These NFs include an Authentication Server Function (AUSF); a Core Access and Mobility Management Function (AMF); a Data network (DN), e.g. operator services, Internet access or 3rd party services; a Structured Data Storage network function (SDSF); an Unstructured Data Storage network function (UDSF); a Network Exposure Function (NEF); a NF Repository Function (NRF); a Policy Control function (PCF); a Session Management Function (SMF); a Unified Data Management (UDM); a User plane Function (UPF); and an Application Function (AF). In certain embodiments, 5G core network server1270is a rackmount server (e.g., a Colfax1U server).

IP gateway1280of 5G end-to-end testbed1200represents a network device or computer system that serves as an access point or intermediary between different networks.

In certain embodiments, QRL is run over 5G end-to-end testbed1200. Since the QRL instance works both in a local loopback as well as on the Amazon Web Service (AWS) EC2 server environment, the QRL instance was ran on the 5G infrastructure. 5G end-to-end testbed1200utilizes the 5G LoadCore product from Keysight. LoadCore provides a testing environment of the 5G Core. For example, LoadCore may provide different impairments that realistically represent the dynamic 5G environment. To ensure QRL works in the 5G/XG environment, VMs1210were used with 5G end-to-end testbed1200, and quantitative measurements were performed. The goal was to determine 5G impacts on the QRL performance.

FIG.13illustrates code1300showing python TCP socket message exchange of a given length, in accordance with certain embodiments.FIG.13illustrates, in a simplified manner, the way in which the test was run on 5G end-to-end testbed1200ofFIG.12. Code1300arepresents the code used for sender node1310a, and code1300brepresents the code used for receiver node1310b. Receiver node1310bwas set up as an application running on a UE in the Loadcore system. Sender node1310awas located on the distributed network (DN) within Loadcore. The QRL (e.g., QRL150ofFIG.1) was configured to transfer the keys via a socket on port8000. LoadCore provided the appropriate routing, delay, and other impairments consistent with operating on a real 5G network.

FIG.14illustrates graphs1400(e.g., graph1400aand graph1400b) of message time delays, in accordance with certain embodiments. Data was collected from tests conducted in accordance with 5G end-to-end testbed1200ofFIG.12to analyze total message send time. Graph1400aillustrates time delays1430for messages1440adelivered to the UE, and graph1400billustrates time delays1430for messages1440bdelivered to the DN. Messages1400(e.g., messages1400aand messages1400b) may include text messages (e.g., Short Message Service (SMS) messages), multimedia content (e.g., Multimedia Messaging Service (MMS) messages), instant messaging, rich-content messages (e.g., rich-communication services (RCS) messages), push notifications, in-app messages, email messages, and the like.

Graphs1400illustrate an example case of sending an AES-256 key without encryption and the two encryption schemes, classical encryption (RSA-2048) and post quantum encryption (Kyber-1024). The differences in the schemes are simplified in graphs1400to the total number of bytes to be sent. Message size1420of 32 bytes represents no encryption, message size1420of 256 bytes represents classical encryption, and message size14201024 bytes represents post-quantum encryption.

The results of the testing on 5G end-to-end testbed1200ofFIG.12show that there is no slowdown with the larger key sizes. The box plots in graphs1400show an actual decrease in the overage time to deliver a message to the UE. This could be attributed to TCP slow start or other network optimizations that are activated as more data is sent. There is a slight increase in the time to deliver messages to the DN. These results show that even with the larger key sizes, the 5G network is not impacted. The public key exchange here is just the first step in transferring larger amounts of data. These public keys in the RSA and Kyber cases act as a KEM to derive an AES key. From there, only data will need to be exchanged and/or encrypted with this AES key. Only when connecting to a new receiver would new public keys need to be generated and/or shared.

In certain embodiments, to further enhance security and data protection, a permissioned-oriented blockchain network may be set up. Permissioned blockchain networks are ones where users publishing blocks must be authorized. Since only authorized users are maintaining the blockchain, it is possible to restrict read access and to restrict who can issue transactions. Permissioned blockchain networks may allow anyone to read the blockchain, or they may restrict read access to authorized users. They may allow any user to submit transactions to be included in the blockchain, or they may restrict this access only to authorized users.

In certain embodiments, permissioned blockchain networks have the same traceability of digital assets as they pass through the blockchain, as well as the same distributed, resilient, and redundant data storage system as a permissionless blockchain networks. In some embodiments, permissioned blockchain use consensus models for publishing blocks, but these methods often do not require the expense or maintenance of resources (as is the case with current permissionless blockchain networks). This is because the establishment of a user's identity is required to participate as a member of the permissioned blockchain network. Those maintaining the blockchain have a level of trust with each other, since they were all authorized to publish blocks and since their authorizations can be revoked if they misbehave. Consensus models in permissioned blockchain networks are then usually faster and less computationally expensive.

FIG.15illustrates a method1500for using a QRL for secure communications, in accordance with certain embodiments. Method1500starts at step1510. At step1520of method1500, a first network component identifies data. For example, referring toFIG.2, node210amay identify messages that are to be communicated to node210b. Method1500then moves from step1520to step1530.

At step1520of method1500, the first network component determines a security level from a plurality of security levels associated with the data. In certain embodiments, the security level is associated with one of the following: an 80-bit security level, a 112-bit security level, a 128-bit security level, a 192-bit security level, or a 256-bit security level. Method1500then moves from step1530to step1540.

At step1540of method1500, the first network component determines an encryption scheme from a plurality of encryption schemes to apply to the data. The encryption scheme may be associated with one of the following: classical encryption, post-quantum encryption, or blockchain/DLT. Method1500then moves from step1540to step1550.

At step1550of method1500, the first network component applies, using QRL (e.g., QRL150ofFIG.1), the encryption scheme to the data to generate encrypted data. In certain embodiments, QRL represents a blockchain that includes a plurality of blocks. Each of the plurality of blocks may include a hash-based signature. In some embodiments, a single public key is generated using QRL and the single public key is leveraged to generate public/private key pairs. In some embodiments, QRL secures signatures used for transactions. In certain embodiments, the first network component and a second network component are categorized in accordance with a role-based validation rule. Method1500then moves from step1550to step1560.

At step1560of method1500, the first network component communicates the encrypted data to the second network component. For example, referring toFIG.2, node210amay communicate the encrypted data to node210b. Method1500then moves from step1560to step1570, where method1500ends.

Although this disclosure describes and illustrates particular steps of method1500ofFIG.15as occurring in a particular order, this disclosure contemplates any suitable steps of method1500ofFIG.15occurring in any suitable order. Although this disclosure describes and illustrates an example method for using QRL to apply an encryption scheme to data, including the particular steps of the method ofFIG.15, this disclosure contemplates any suitable method for using QRL to apply an encryption scheme to data, including any suitable steps, which may include all, some, or none of the steps of the method ofFIG.15, where appropriate. AlthoughFIG.15describes and illustrates particular components, devices, or systems carrying out particular actions, this disclosure contemplates any suitable combination of any suitable components, devices, or systems carrying out any suitable actions.

FIG.16illustrates a computer system1600, in accordance with certain embodiments. In particular embodiments, one or more computer systems1600perform one or more steps of one or more methods described or illustrated herein. In particular embodiments, one or more computer systems1600provide functionality described or illustrated herein. In particular embodiments, software running on one or more computer systems1600performs one or more steps of one or more methods described or illustrated herein or provides functionality described or illustrated herein. Particular embodiments include one or more portions of one or more computer systems1600. Herein, reference to a computer system may encompass a computing device, and vice versa, where appropriate. Moreover, reference to a computer system may encompass one or more computer systems, where appropriate.

In particular embodiments, computer system1600includes a processor1602, memory1604, storage1606, an input/output (I/O) interface1608, a communication interface1610, and a bus1612. Although this disclosure describes and illustrates a particular computer system having a particular number of particular components in a particular arrangement, this disclosure contemplates any suitable computer system having any suitable number of any suitable components in any suitable arrangement.

In particular embodiments, processor1602includes hardware for executing instructions, such as those making up a computer program. As an example and not by way of limitation, to execute instructions, processor1602may retrieve (or fetch) the instructions from an internal register, an internal cache, memory1604, or storage1606; decode and execute them; and then write one or more results to an internal register, an internal cache, memory1604, or storage1606. In particular embodiments, processor1602may include one or more internal caches for data, instructions, or addresses. This disclosure contemplates processor1602including any suitable number of any suitable internal caches, where appropriate. As an example and not by way of limitation, processor1602may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction caches may be copies of instructions in memory1604or storage1606, and the instruction caches may speed up retrieval of those instructions by processor1602. Data in the data caches may be copies of data in memory1604or storage1606for instructions executing at processor1602to operate on; the results of previous instructions executed at processor1602for access by subsequent instructions executing at processor1602or for writing to memory1604or storage1606; or other suitable data. The data caches may speed up read or write operations by processor1602. The TLBs may speed up virtual-address translation for processor1602. In particular embodiments, processor1602may include one or more internal registers for data, instructions, or addresses. This disclosure contemplates processor1602including any suitable number of any suitable internal registers, where appropriate. Where appropriate, processor1602may include one or more arithmetic logic units (ALUs); be a multi-core processor; or include one or more processors1602. Although this disclosure describes and illustrates a particular processor, this disclosure contemplates any suitable processor.

In particular embodiments, memory1604includes main memory for storing instructions for processor1602to execute or data for processor1602to operate on. As an example and not by way of limitation, computer system1600may load instructions from storage1606or another source (such as, for example, another computer system1600) to memory1604. Processor1602may then load the instructions from memory1604to an internal register or internal cache. To execute the instructions, processor1602may retrieve the instructions from the internal register or internal cache and decode them. During or after execution of the instructions, processor1602may write one or more results (which may be intermediate or final results) to the internal register or internal cache. Processor1602may then write one or more of those results to memory1604. In particular embodiments, processor1602executes only instructions in one or more internal registers or internal caches or in memory1604(as opposed to storage1606or elsewhere) and operates only on data in one or more internal registers or internal caches or in memory1604(as opposed to storage1606or elsewhere). One or more memory buses (which may each include an address bus and a data bus) may couple processor1602to memory1604. Bus1612may include one or more memory buses, as described below. In particular embodiments, one or more memory management units (MMUs) reside between processor1602and memory1604and facilitate accesses to memory1604requested by processor1602. In particular embodiments, memory1604includes random access memory (RAM). This RAM may be volatile memory, where appropriate. Where appropriate, this RAM may be dynamic RAM (DRAM) or static RAM (SRAM). Moreover, where appropriate, this RAM may be single-ported or multi-ported RAM. This disclosure contemplates any suitable RAM. Memory1604may include one or more memories1604, where appropriate. Although this disclosure describes and illustrates particular memory, this disclosure contemplates any suitable memory.

In particular embodiments, storage1606includes mass storage for data or instructions. As an example and not by way of limitation, storage1606may include a hard disk drive (HDD), a floppy disk drive, flash memory, an optical disc, a magneto-optical disc, magnetic tape, or a Universal Serial Bus (USB) drive or a combination of two or more of these. Storage1606may include removable or non-removable (or fixed) media, where appropriate. Storage1606may be internal or external to computer system1600, where appropriate. In particular embodiments, storage1606is non-volatile, solid-state memory. In particular embodiments, storage1606includes read-only memory (ROM). Where appropriate, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory or a combination of two or more of these. This disclosure contemplates mass storage1606taking any suitable physical form. Storage1606may include one or more storage control units facilitating communication between processor1602and storage1606, where appropriate. Where appropriate, storage1606may include one or more storages1606. Although this disclosure describes and illustrates particular storage, this disclosure contemplates any suitable storage.

In particular embodiments, I/O interface1608includes hardware, software, or both, providing one or more interfaces for communication between computer system1600and one or more I/O devices. Computer system1600may include one or more of these I/O devices, where appropriate. One or more of these I/O devices may enable communication between a person and computer system1600. As an example and not by way of limitation, an I/O device may include a keyboard, keypad, microphone, monitor, mouse, printer, scanner, speaker, still camera, stylus, tablet, touch screen, trackball, video camera, another suitable I/O device or a combination of two or more of these. An I/O device may include one or more sensors. This disclosure contemplates any suitable I/O devices and any suitable I/O interfaces1608for them. Where appropriate, I/O interface1608may include one or more device or software drivers enabling processor1602to drive one or more of these I/O devices. I/O interface1608may include one or more I/O interfaces1608, where appropriate. Although this disclosure describes and illustrates a particular I/O interface, this disclosure contemplates any suitable I/O interface.