FORWARD SECRECY QSL

A method for forward security Quantum Secure Layer (QSL), where the method causing a server to hold long-term public/private Key Encapsulation Mechanism (KEM) keypair; uses KEM to establish a pre-master shared secret; causing the server to send ephemeral KEM public key to the client; uses KEM to establish master shared secret; and generates a session key by the server and encrypted to the client using the master shared secret. A method for forward secrecy Quantum Secure Layer (QSL), where the method causing a server to hold a pre-shared ephemeral public/private Key Encapsulation Mechanism (KEM) keypair; uses KEM to establish a master shared secret; and generates a session key by the server and encrypted to the client using the master shared secret.

BACKGROUND

The present invention relates to data encryption, and more specifically, to providing post-quantum communication security over a computer network.

SUMMARY

According to at least one embodiment of the present invention, this is a method for forward secrecy Quantum Secure Layer (QSL), whereby a server to holds a long-term public/private Key Encapsulation Mechanism (KEM) keypair, uses a KEM to establish a pre-master shared secret and causes the client to send an ephemeral KEM public key to the server, which uses a KEM to establish master shared secret and generates a session key which establishes encryption to the client using the master shared secret. According to at least one embodiment of the present invention, a method for forward secrecy Quantum Secure Layer (QSL), where the method causing a server to hold a pre-shared ephemeral public/private Key Encapsulation Mechanism (KEM) keypair; uses KEM to establish a master shared secret; and generates a session key by the server and establishes encryption to the client using the master shared secret.

According to at least another embodiment of the present invention, a server computer system for forward secrecy Quantum Secure Layer (QSL), the server computer system comprising a memory and at least one processor coupled to the memory, the server computer system is configured to cause a server to hold long-term public/private Key Encapsulation Mechanism (KEM) keypair, the server uses the KEM to establish a pre-master shared secret, a client computing device is configured to cause a client to send an ephemeral KEM public key to the server, and the server uses the KEM to establish a master shared secret, wherein a session key is generated by the server and establishes encryption to the client using the master shared secret.

DETAILED DESCRIPTION

Aspects of the invention are not limited in their application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The embodiments of the invention described herein are applicable to other embodiments or are capable of being practiced or carried out in various ways. The phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting. As will be appreciated by one skilled in the art, aspects of the present invention can be embodied as a system, method or computer program product.

Many of the most notorious cybersecurity hacks have been the result of SNDL campaigns (steal now, decrypt later) in which a bad actor will steal an encrypted data source and sit on it for several months or years until they are able to decrypt it. Once decrypted, the data is then distributed or sold on the dark web.

With reference toFIGS.1A and1B, shown is a current preferred embodiment of the invention. In this illustration, the aspects as described within this disclosure show the elimination of unnecessary steps in the negotiation during the security handshake protocol. These steps include customization of the client/server behavior regarding the elimination of the need for certificate exchange and a trusted Root Certificate Authority (CA) that generates self-signed public key used to distribute signed public/private key pairs down the certificate chain to sub-CAs. Additionally, the invention creates a zero trust negotiation during QSL handshake to provide a post-quantum secure security protocol.

Forward Secrecy (FS) is a property relating to key agreement protocols, for instance between a client and a server, which states that if the server's private key is compromised, all past communications will remain secure. TLS1.3 instantiates Ephemeral Diffie-Hellman key exchange in its handshake, which provides FS. This is because the server generates a one-time secret which is discarded after each session. Without this ephemeral key, an adversary cannot retrieve the established key (unless they break the cipher itself). Furthermore, if they somehow retrieve the current secret key of the server, it does not provide any information about the past secrets or session keys. Hence, we say it provides FS.

However, in QSL the invention uses a post-quantum Key Encapsulation Mechanism (KEM) to establish shared secrets, to share the session keys. In QSL, the long-term secret is the Server's private key. The session key is a QRNG-derived key, generated by the server, and sent to the client under encryption by a “master” shared secret. This master shared secret is the output of ephemeral KEM key exchange. The method by which this is performed guarantees FS.

One way the invention demonstrates the FS of QSL is as followed. Suppose the long-term KEM private key of the server is compromised, and the adversary has recorded all previous executions of the protocol. Due to the design of FS-QSL, the adversary would at best be able to obtain copies of the ciphertext of the master shared secret, encapsulated under the ephemeral KEM key of that session. Hence, they would not be able to retrieve the session key of past sessions and forward secrecy is achieved.

On implementing FS-QSL, the invention makes use of post-quantum KEMs. The invention requires running the key generation for each login. Kyber is particularly well suited to this due to its efficient key generation process. The BIKE submission also states that it lends itself well to the ephemeral setting.

FIGS.1A and1Bshow a block diagram of System140, an example of a system for handshaking without a certificate authority, to provide at least post-quantum communications security over a computer network. The system140includes a server100, clients120aand120b, and a communication networks130,132,134. The System140illustrated inFIGS.1A and1Bis provided as one example of such a system. The methods described herein may be used with systems with fewer, additional, or different components in different configurations than the System140illustrated inFIGS.1A and1B. For example, in some implementations, the Server100may include additional servers, may include additional or fewer clients, and/or may include more communication networks. Although illustrated as separate components inFIG.1A, in some implementations, the Server100and one or more clients120aand120bmay be included in a single electronic device. For example, the Server100and the initiator120aor120bmay be included in a single electronic device. As a further example, the Server100and the recipient120aor120bmay be included in a single electronic device.

Unique Identifier DatasetFIG.1C101illustrates the current preferred embodiment of the database scheme used to identify a unique entity for communication with the Quantum Secure Layer (QSL) Service116aor the Key Management Service113a. This communication uses the data structure to complete the handshake as in Quantum Secure Layer Handshake110bfor the purpose of encrypting the necessary data and keys between multiple clients120aor120b, and to complete the handshake as in Key Add Service114aor Key Get Service115afor the purpose of encrypting the necessary data and keys for a single client120aor120b.

Key Management DatasetFIG.1D102illustrates the current preferred embodiment of the database scheme used to identify elements within the Key Management Service113a. The Key Management Dataset102FIG.1Dis used to add symmetric keys when requested from other services using Key Add Service114a, and to use keys that are in the processes with the Key Get Service115a. Because the Key Management Service113aresides within the Hardware Security Module logic construct an actual “Handle” is used versus the key for better security retrieval.

Hardware Security Module (HSM)FIG.1A108all KEM and cryptographic operations are controlled though the HSM. This component has all cryptographic algorithms and systems logic to avoid security side channel attacks on key pairs or symmetric keys, not limited to other elements requiring vaulting protection. The Hardware Security Module (HSM)108controls but is not limited to key creation and extraction from the Quantum Random Number Generator109and associated storage.

Quantum Random Number Generator (QRNG)FIG.1A109QRNG delivers random numbers to act as cryptographic keys and other security parameters, deterministic RNG seeding, initialization vectors, nonces, random challenges, authentication and DSA signing. Other applications include Entropy as a Service (EaaS), simulations, modeling and computer gaming. This generator feeds the cryptographic keys directly into the Hardware Security Module for greater entropy security retrieval. Other outside processes are shielded from this generator. Only protocols that reside within the HSM can access the n-dimensional quantum key source that is produced.

Quantum Secure Layer ServiceFIG.1A116aThis component uses the Quantum Secure Layer Handshake110awhich is the interaction between key distribution center and client120aor120b. QSL Service116ais used by the Clients120aand120bto create a secure communications session between the two clients. This supplies the necessary symmetric key by reaching out to the Hardware Security Module (HSM)108. The interaction between the client peers requests a communication with the necessary unique identifier to establish communications for but not limited to file transfer, messaging and hypertext communications. This service will query all information required from the Unique Identifier Dataset101to establish communication including but limited to symmetric keys. This follows File Transfer116band Hypertext Transfer116cas it interacts with the Quantum Secure Layer Handshake110aand the Quantum Secure Layer Service116a.

Quantum Secure Layer HandshakeFIG.1A110bThis handshake is used to interact with any application with the examples of File Transfer116band Hypertext Transfer116c. Any initiating client will pass their Unique Identification and the Unique Identification of its recipient to the QSL Service116aat which time the symmetric session keys will be generated. The QSL Service116awill encrypt these symmetric keys with post-quantum algorithms used within the Hardware Security Module108and the relevant moving target information. This is performed using the recipient client's symmetric key that was established during the Login Service103aso only the recipient can decrypt that particular portion and then using the symmetric key the initiator established during the Login Service103aso only the initiator can decrypt, thereby verifying it came from the Quantum Secure Layer Service116a.

Variable Length Buffer HandshakeFIG.1A111to create a handshake for transferring a buffer of variable length to be used by all services involving a logged-in client, reliant only on Authenticated Encryption with Associated Data (AEAD). The length is sent over followed by the buffer to ensure the recipient has the correct size to read.

Variable Length Buffer Handshake Steps:1. The initiator sends the length of buffer to the recipient using AEAD;2. The initiator sends the buffer to the recipient using AEAD.

Login ServiceFIG.1A103aClient authentication, login103bon the client would communicate with the login service103ato perform authentication. Other components that are contained within this include but not limited to organization onboarding, administration onboarding, and individual client onboarding.FIG.1AandFIG.1Brepresent2clients in an organization that communicate to the Server100. This also implies multi-tenancy communication from client120aand120bto Server100. An additional component within the Login Service103ais the Registration Handshake104ato identify the individual clients to the Server100. This populates the unique identifier101FIG.1Cfor the first time within the Server100. The unique identifier elements and post-quantum token will be passed to the client. Other elements that are captured include items such as, IP address, MAC, routing address.

As part of the registration the client will need to perform the Forward Secrecy Handshake106aand that includes communication with the key encapsulation system of the Server100using but not limited to Saber or Kyber Post Quantum algorithms. These associate a post quantum key pair structure the Server100retains the secret key portion of the pair structure. The Client120a, Client120breceives the public key portion and uses said key to establish a shared secret or symmetric key with Server100. This process then creates a second post quantum key pair communicated using the symmetric key to transmit in a protected manner thus reducing the probability of interception of the communication and data. This second post quantum key pair is unique to each session; for data to be compromised, the Server100secret key and the second secret key must be broken to get access to the data or session.

Device Authority HandshakeFIG.1A105bis used when the Client120a, or120bneed to log into the system. This is accomplished by using the unique identifier and post quantum token with the same Forward Secrecy Handshake106bto establish the client's authentication from the Unique Identifier Dataset101FIG.1C. The Server100and Device Authority Handshake105will update the symmetric key of Unique Identifier Dataset101FIG.1Cat login for the individual client unique identifiers. In some embodiments, the Registration Handshake and Device Authority Handshake can be configured to generate and share an ephemeral KEM public key with the client at their conclusion. In such an embodiment, the Forward Secrecy Handshake is not needed by the Device Authority Handshake—since the client can initiate the handshake with an ephemeral KEM public key. The resulting Ephemeral KEM Handshake118bused allows for a login with a reduced number of roundtrips.

Logout ServiceFIG.1A112aclears the dataset symmetric keys associated with the unique identifier at close of session. Logout112bhas access to Unique Identifier Dataset101associatedFIG.1C. The Logout Service offloads symmetric encryption/decryption to the HSM. The Logout Service pulls in the symmetric key(s) and routing address associated with relevant unique identifiers from Unique Identifier Dataset. The Logout Service may be activated by a lack of a response from the relevant client.

Authentication of clients and establishing a connection through cryptography. KEM utilization which gives a performance advantage over Digital Signature utilization.

Entropy RefillFIG.1B107bis used during high volume communications to replenish the clients120aor120bentropy pool to continue the post-quantum secure communication or Data at Rest process. The Entropy Refill Service offloads symmetric encryption/decryption to the HSM. The Entropy Refill Service provides bulk entropy from the QRNG to the client to maintain the Client's entropy pool, the advantage allows offline and high-volume key availability. The Entropy Refill Service pulls in the symmetric key(s) and routing address associated with relevant unique identifiers from Unique Identifier Dataset.

Key Management ServiceFIG.1A113aThe KMS pulls in the symmetric key(s) and routing address associated with relevant unique identifiers from Unique Identifier Dataset.

Key Add ServiceFIG.1A114aand Key AddFIG.1B114bAdd symmetric keys encrypted with HSM into the Server100database encryption keys system. This data is stored externally but cannot be access without the HSM to decrypt prior to transmittal. The Key Management DatasetFIG.1Dcontains the information used in this process.

Key Get ServiceFIG.1A115aand Key GetFIG.1B115breaches out to HSM to get keys get decrypted key from database.

File TransferFIG.1B116bFile Transfer uses the QSL Handshake to receive session keys from the QSL Service for a secure connection with a peer. File Transfer then utilizes the functions provided by the QSL Library (libqsl) for the QSL equivalent of the TLS Record Protocol. Symmetric encryption/decryption (AEAD) is offloaded to the S/HSM.

HyperText TransferFIG.1B116cHypertext Transfer uses the QSL Handshake to receive session keys from the QSL Service for a secure connection with a peer. Hypertext Transfer then utilizes the functions provided by the QSL Library (libqsl) for the QSL equivalent of the TLS Record Protocol. Symmetric encryption/decryption (AEAD) is offloaded to the S/HSM.

EncryptFIG.1B113bEncrypt (Data-At-Rest) utilizes Key Add114bto reach out to the Key Management Service113a, specifically the Key Add Service114ato get encryption keys. Encrypt encrypts the data using the Moving Target Design to switch between encryption keys. Symmetric encryption (AEAD) is offloaded to the S/HSM.

Key Add Service114badds symmetric keys encrypted with HSM into the Server100database encryption keys system. This data is stored externally but cannot be accessed without the HSM to decrypt prior to transmittal. The Key Management DatasetFIG.1Dcontains the information used in this process.

DecryptFIG.1B113cDecrypt (Data-At-Rest) utilizes Key Get115bto reach out to the Key Management Service113a, specifically the Key Get Service115ato get decryption keys. Decrypt decrypts the data using the Moving Target Design to switch between decryption keys. Symmetric decryption (ADAD) is offloaded to the S/HSM. Key Get Service115areaches out to HSM to get keys get decrypted key from database.

FIG.2is a block diagram of an example computer system200which can perform any one or more of the methods described herein, in accordance with one or more aspects of the present disclosure. In one example, the computer system200may include a computing device and correspond to one or more of the servers100, the client120a,120b, or any suitable component ofFIG.1A. The computer system200may be connected (e.g., networked) to other computer systems in a local area network (LAN), an intranet, an extranet, or the Internet, including via the cloud or a peer-to-peer network. The computer system200may operate in the capacity of a server in a client-server network environment. The computer system200may be a personal computer (PC), a tablet computer, a wearable (e.g., wristband), a set-top box (STB), a personal Digital Assistant (PDA), a mobile phone, a smartphone, a camera, a video camera, an Internet of Things (IoT) device, or any device capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device. Further, while only a single computer system is illustrated, the term “computer” shall also be taken to include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

The computer system200(one example of a “computing device”) illustrated inFIG.2includes a processing device202, a main memory204(e.g., read-only memory (ROM), flash memory, solid state drives (SSDs), dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory206(e.g., flash memory, solid state drives (SSDs), or static random access memory (SRAM)), and a memory device208, wherein any of the foregoing may communicate with each other via a bus210. In some implementations, the computer system200may further include a hardware security module (not shown).

The computer system200illustrated inFIG.2further includes a network interface device212. The computer system200also may include a video display214(e.g., a liquid crystal display (LCD), a light-emitting diode (LED), an organic light-emitting diode (OLED), a quantum LED, a cathode ray tube (CRT), a shadow mask CRT, an aperture grille CRT, or a monochrome CRT), one or more input devices216(e.g., a keyboard and/or a mouse or a gaming-like control), and one or more speakers218(e.g., a speaker). In one illustrative example, the video display214and the one or more input devices216may be combined into a single component or device (e.g., an LCD touchscreen).

The memory device208may include a computer-readable storage medium202on which the instructions222cembodying any one or more of the methods, operations, or functions described herein are stored. The instructions222cmay also reside, completely or at least partially, within the main memory204as instructions222band/or within the processing device202during execution thereof by the computer system200. As such, the main memory204or as instruction222aand the processing device202also constitute computer-readable media. The instructions222may further be transmitted or received over a network via the network interface device212.

While the computer system environment of200shows the basic components, the addition of a Hardware Security Module224associated with a Quantum Random Number Generator226completes the entropy required for Post Quantum computations and interactions. The use of these components is critical as described previously in the overall methods used for this system.

Referring toFIG.3a flow diagram of an example method for forward security Quantum Secure Layer (QSL). The method includes causing a server to hold long-term public/private Key Encapsulation Mechanism (KEM) keypair302, using KEM to establish a pre-master shared secret304. The method causing the client to send ephemeral KEM public key to the server306, using KEM to establish master shared secret308, and generating a session key by the server and encrypted to the client using the master shared secret310.

Referring toFIG.4a flow diagram of an example method for forward security Quantum Secure Layer (QSL). The method includes causing a server to hold an ephemeral public/private Key Encapsulation Mechanism (KEM) keypair402, using KEM to establish a master shared secret404, and generating a session key by the server and encrypted to the client using the master shared secret406.

Referring toFIG.5a flow diagram of another example method for forward security Quantum Secure Layer (QSL). Forward Secrecy Handshake500The Forward Secrecy Handshake allows two parties to establish forward secrecy using Key Encapsulation Mechanisms. The first shared secret is exchanged using a static KEM keypair. The shared secret is then used to exchange an ephemeral KEM keypair, which is used to establish a second shared secret. The second shared secret is not vulnerable if the long-term secret, the static KEM key pair, is compromised. Blocks502-518show a sequence of establishing proper secrecy novel and highly protective.

Still referring toFIG.5, the method causes the client to encapsulate a symmetric keypair using the server's static KEM public key to produce a ciphertext502, which causes the client to generate an ephemeral KEM keypair504, which causes the client to use Authenticated Encryption with Associated Data (AEAD) with the symmetric keypair to encrypt the ephemeral KEM public key to produce encrypted text506, and this causes the client to send the ciphertext concatenated with the encrypted text to the server508. The method still further causes the server to decapsulate the ciphertext using their static KEM secret key to produce the symmetric keypair510, causing the server to use AEAD with the symmetric keypair to decrypt the encrypted text by producing the ephemeral KEM public key512, causing the server to encapsulate a second symmetric keypair by using the client's ephemeral KEM public key to produce a second ciphertext514, causing the server to send the second ciphertext to the server516and causing the client to decapsulate the second ciphertext using their ephemeral KEM secret key to produce the second symmetric keypair518.

Referring toFIG.6a flow diagram of another example method for forward security Quantum Secure Layer (QSL). Ephemeral KEM Handshake600The Ephemeral KEM Handshake allows two parties to establish forward secrecy using Key Encapsulation Mechanisms. An ephemeral KEM keypair is used to establish a shared secret. The shared secret is not vulnerable since there is no long-term secret. Block602-606show a sequence of establishing proper secrecy novel and highly protective.

Still referring toFIG.6, the method causes the client to encapsulate a symmetric keypair using the server's ephemeral KEM public key to produce a ciphertext602, which causes the client to send the ciphertext to the server604, and causes the server to decapsulate the ciphertext using their ephemeral KEM secret key to produce the symmetric keypair606.