FIELD OF INVENTION

The present invention generally relates to electronic device communications, and more particularly, to end-to-end encryption.

BACKGROUND

Communications security on a computer network requires the generation, distribution, storage, and management of cryptographic keys. Transmitted information can include text messages, files, voice, video and other formats. (For the purposes here, messaging will be defined as data encrypted and delivered in any format.) Messages are generally stored in an encrypted state prior to transmission, and operations can be performed on already encrypted data. End-to-end encryption is generally characterized by communicating parties being the only users capable of decrypting messages. End-to-end encryption can prevent intermediaries and third parties used to facilitate the communications from eavesdropping and can facilitate secure communications even on compromised networks.

Secure Messaging (SM) has become the primary means of communication among billions of people worldwide, but the term lacks universally accepted formal definitions and proofs with a few exceptions. The Axolotl Ratchet aka the Double Ratchet Algorithm is modeled on the Diffie-Hellman asymmetric ratchet in the Off-the-Record (OTR) messaging system and symmetric key ratchets used by the Silent Circle messaging protocol, resulting in the currently ubiquitous Signal Protocol. Encrypting and authenticating every message with a new symmetric key is the foundation of many modern end-to-end encrypted messaging products in commercial use.

While there are a limited number of security proofs of specific implementations, there are none for the generalized protocol nor are any provably secure against brute force attack by quantum computers. Specifically, a Diffie Hellman algorithm (currently used in the Signal Protocol for asymmetric ratcheting) is generally more vulnerable compared to post-quantum cryptography like lattice or code-based algorithms. While some existing ratcheting protocols achieve desirable properties like forward secrecy and post-compromise security, formal proofs of Signal-like protocols sacrifice immediate decryption and have limited or no message loss retrieval (MLR) functionality.

There is therefore a need for improved methods, devices, and systems for improved end-to-end message encryption.

SUMMARY

It is an object of the present invention to provide systems, devices, and methods to automatically and instantaneously decrypt data in an end-to-end encrypted secure messaging session while maintaining forward secrecy and post-compromise security. Generally, example communication devices presented herein can each include a pseudo-random number generator (PRG) to generate a sequence of message keys, a Continuous Key Agreement (CKA) engine, a Pseudo-Random Function (PRF-PRNG) fed by the CKA to reset the state of the PRG and provide a refresh key to the PRG. Each communication device in a communication session can utilize the Continuous Key Agreement (CKA) to independently generate the symmetric key on each device, provide the symmetric key and a previous state of the PRG to the PRF-PRNG, generate an updated state and the refresh key with the PRF-PRNG based on the symmetric key and the previous state, initialize the PRG with the state, provide the root key to the PRG to generate a first message key, recursively feeding each message key into the PRG to generate the subsequent message key and a sequence of message keys for a given one-way communication epoch, and when the direction of message transmission changes such that a receiving device becomes a sending device, generating a new symmetric key via the CKA to thereby generate a new sequence of message keys using the PRF-PRNG and the PRG in a similar manner as was used to generate the message keys for the first epoch, the new sequence of message keys being the message keys for a second one-way communication epoch.

Another object of the invention is to provide a protocol in which messages can be received out of order from the sender but can nevertheless be immediately decrypted and properly ordered in the messaging queue by the receiver. Cryptographic ratchets can be used to maintain liveness even when some messages are permanently lost. Each message can include a header that can be used by the receiving device to verify the authenticity of the message and/or to determine the order in which the message was sent from the sending device.

An example method of exchanging messages between devices can include one or more of the following steps presented in no particular order, and the method can include additional steps not included here. Two communication devices, “Device A” and “Device B”, can be provided that are capable of transmitting data to each other via an end-to-end encryption protocol. Data structures can be provided to facilitate the end-to-end encryption including a root state and a first asymmetric key pair having a first public key and a first private key. The root state can be stored on both Device A and Device B, the first public key can be stored on Device A, and the first private key can be stored on Device B. A first epoch key can be generated on Device A based on the first public key, and Device A can also generate a second asymmetric key pair having a second private key and a second public key. The first epoch key and the second public key can be transmitted by Device A and received by Device B. Each of Device A and B can independently generate a first refresh key and a first state. On Device A, the first refresh key and the first state can each be generated based on the first public key and the root state. On Device B, the first refresh key and the first state can each be generated based on the first private key, the first epoch key, and the root state. Each of Device A and B can independently generate a first message key such that on each device the first message key is based on the first state and the first refresh key.

With the first message key in hand on Device A, Device A can begin sending encrypted messages to Device B. Device A can encrypt a first message with the first message key and transmit the encrypted first message to Device B. Device B can receive the first message key and decrypt it using the first message key, having previously generated the first message key or having generated the first message key upon receipt of the first message.

A second message key can be generated independently on each of Device A and Device B, the second message key generated based on the first state and the first message key. With the second message key in hand on Device A, Device A can send a second encrypted message to Device B. Device A can encrypt the second message with the second message key and transmit the second encrypted message to Device B. Device B can receive the second encrypted message and decrypt it with the second message key, having previously generated the second message key or having generated the second message key upon receipt of the second message.

When Device B begins to respond to Device A, the first state can be updated to a second state and the first refresh key can be updated to a second refresh key to generate a new series of message keys. Device B can generate a second epoch key based on the second public key previously generated and transmitted by Device A. Device B can also generate a third asymmetric key pair having a third private key and a third public key. The second epoch key and the third public key can be transmitted by Device B and received by Device A. Device A and Device B can independently generate the second refresh key and the second state on each device. On Device B, the second refresh key and the second state can each be generated based on the second public key and the first state previously generated on Device B. On Device A, the second refresh key and the second state can each be generated based on the second private key previously generated on Device A, the second epoch key received from Device B, and the first state previously generated on Device A. With the second state and second refresh key in hand on each device, Device A and B can independently generate a third and a fourth message key in a similar manner as the first and second message keys were generated as described above.

Further, before Device B transmits the second epoch key and the first public key to Device A, the first message key and/or second message key can be deleted from Device B.

Referring to the first message transmitted by Device A, Device A can generate a first ciphertext including a header, and the first ciphertext can be transmitted to Device B. The header can be used by Device B to verify that the first message key is the appropriate message key to decrypt the first ciphertext. The header can be generated by Device A to include a first message index associated with the first message key and a first epoch index associated with the first state. Device B can verify the first message key based on the first message index and the first epoch index.

Additionally, or alternatively, Device A can generate the first header to include the first epoch key and second public key, and the first epoch key and the second public key can be transmitted to Device B in the first header of the first ciphertext.

Referring to the generation of the first message key on each of Device A and Device B, a first shared key can be generated independently on each device as an intermediary step performed before generating the first message key. On each of Device A and Device B, the first refresh key and the first state can be generated based on the first shared key and the root state. On Device A, the first shared key can be generated based on the first public key, and on Device B, the first shared key can be generated based on the first private key and the first epoch key.

Each of Device A and Device B can have a respective pseudo-random function. Independently on each device, the first shared key and the root key can be provided as inputs to the pseudo-random function, and the first state and the first refresh keys can be generated at outputs of the pseudo-random function.

Referring to the root state stored on Device A and Device B, the root state can be generated independently on each device based on a root key received by each device. Independently on each of Device A and Device B, the root key can be provided to the respective pseudo-random function and the root state can be generated as an output from each respective pseudo-random function.

Device A and Device B can each have a respective random number generator that can be used to generate sequences of message keys for each epoch. Referring to the generation of the first and second message keys, the random number generator can be used on each device to independently generate the first message key and the second message key. On each of Device A and Device B, the respective random number generator can be initialized with the first state, and the first refresh key can be provided as an input to the random number generator. The first message key can be generated by the random number generator initialized in the first state and based on the first refresh key. The first message key can be provided as an input to the random number generator initialized with the first state to produce the second message key.

Alternatively, each respective random number generator and respective pseudo-random function can be used to generate a sequence of message keys for each epoch. On each device, the first message key can be generated like as described above. The second message key can be generated not based on the first message key, but instead by providing the first state as an input to the pseudo-random function, generating a second state as an output to the pseudo-random function, initializing the random number generator with the second state, and generating the second message with the random number generator initialized in the second state.

Another example method of exchanging messages can include one or more of the following steps presented in no particular order, and the method can include additional steps not included here. Two communication devices, “Device A” and “Device B”, can be provided that are capable of transmitting data to each other via an end-to-end encryption protocol. Data structures can be provided to facilitate the end-to-end encryption including a first asymmetric key pair having a first public key and a first private key. The first public key can be stored on Device A, and the first private key can be stored on Device B. Each of Device A and Device B can have stored thereon a respective pseudo-random generator.

A first epoch key can be generated on Device A based on the first public key, and Device A can also generate a second asymmetric key pair having a second private key and a second public key. The first epoch key and the second public key can be transmitted by Device A and received by Device B. A first message key and a second message key can be generated independently on each of Device A and Device B. On Device A, the first message key can be based on the first public key. On Device B, the first message key can be based on the first private key and the first epoch key. On each device, the first message key can be provided as an input to the respective pseudo-random number generator and the second message key can be generated as output of each pseudo-random number generator.

Device A can encrypt a first message with the first message key and a second message with the second message key and transmit a first epoch that includes the first encrypted message and the second encrypted message. Device B can receive the first epoch and decrypt the first encrypted message with the first message key and the second encrypted message with the second message key.

When Device B begins to respond to Device A, Device B can generate a second epoch key based on the second public key previously transmitted by Device A, and Device B can generate a third asymmetric key pair having a third private key and a third public key. The second epoch key and the third public key can be transmitted by Device B and received by Device A. Device A and Device B can independently generate a third message key. On Device B, the third message key can be based on the second public key. On Device A, the third message key can be based on the second private key and the second epoch key.

Device B can encrypt a third message with the third message key and transmit a second epoch including the third encrypted message. Prior to transmitting the second epoch, Device B can delete the first message key and the second message key from the first epoch. Device A can receive the second epoch and decrypt the third encrypted message with the third message key.

Multiple epochs, each epoch including one or more encrypted messages, can be transmitted. For each epoch, all transmitted encrypted messages in the epoch can be transmitted from only one of Device A or Device B. Epochs can be transmitted from each of Device A and Device B in an alternating fashion such that Device A transmits every odd epoch and Device B transmits every even epoch.

Referring to the first message in the example method, a first header can be generated on Device A, Device A can generate a first ciphertext including the encrypted header and the first encrypted message, the header in plaintext can be appended to the first ciphertext, and Device A can transmit the first ciphertext and plaintext header. Device B can receive the first ciphertext and plaintext header and authenticate the ciphertext based on the plaintext header.

Device A can generate a message index, and the first header can include the message index. Device B can generate an nth message key based on the message index.

A root state can be provided at each of Device A and Device B. The respective pseudo-random number generator on each of Device A and Device B can be initialized based on the root state. An updated state can be generated on each of Device A and Device B based on the root state, and the pseudo-random number generator can be reinitialized based on the updated state.

A first shared key can be generated independently on each of Device A and Device B. On Device A the first shared key can be generated based on the first public key, and on Device B the first shared key can be generated based on the first private key and the first epoch key. A refresh key and a first state can each be generated independently on each of Device A and Device B, each based on the shared key and the root state. To generate the first message key on each device, the pseudo-random number generator can be initialized to the first state, the first refresh key can be provided as an input to the initialized pseudo-random number generator, and the first message key can be generated as an output of the pseudo-random number generator.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further aspects of this invention are further discussed with reference to the following description in conjunction with the accompanying drawings, in which like numerals indicate like structural elements and features in various figures. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating principles of the invention. The figures depict one or more implementations of the inventive devices, by way of example only, not by way of limitation.

FIG. 1 is a flow diagram illustrating, example functional blocks, data structures, and method steps that can be used to send messages from a first device to a second device according to aspects of the present invention;

FIG. 2 is a flow diagram illustrating an example implementation including iterative calls to a pseudo-random number generator to produce a sequence of message keys according to aspects of the present invention;

FIG. 3 is a flow diagram outlining example functional blocks, data structures, and method steps that can be included in a sending ratchet according to aspects of the present invention;

FIG. 4 is a flow diagram outlining example functional blocks, data structures, and method steps that can be included in a receiving ratchet according to aspects of the present invention;

FIG. 5 is a flow diagram illustrating initialization of a CKA according to aspects of the present invention;

FIG. 6 is a flow diagram illustrating the creation of a shared key on a sending and a receiving device based on an asymmetric key pair according to aspects of the present invention;

FIG. 7 is a flow diagram illustrating an example exchange of public keys and propagation of private keys to generate a symmetric key for subsequent epoch ratchets according to aspects of the present invention;

FIG. 8 is a flow diagram illustrating functionality an example CKA functional block from the perspective of a sending device according to aspects of the present invention;

FIG. 9 is a flow diagram illustrating functionality of an example CKA functional block from the perspective of a receiving device according to aspects of the present invention;

FIGS. 10, 11, 12, and 13 are flow diagrams illustrating initialization, seeding, and progression of a PRG according to aspects of the present invention;

FIG. 14 is a flow diagram illustrating the use of epochs as a message grouping mechanism according to aspects of the present invention;

FIG. 15 is a flow diagram illustrating example functional blocks, data structures, and method steps for sending messages from a first device to a second device where each message includes a header according to aspects of the present invention;

FIG. 16 is a flow diagram illustrating example functional blocks, data structures, and method steps that can be used to initialize a PRG and an index for counting messages in an epoch according to aspects of the present invention;

FIG. 17 is a flow diagram illustrating example functional blocks, data structures, and method steps for sending a message that includes a header from the perspective of a sending device according to aspects of the present invention;

FIG. 18 is a flow diagram illustrating example functional blocks, data structure, and method steps for receiving a message that includes a header from the perspective of a receiving device according to aspects of the present invention;

FIG. 19 is a flow diagram illustrating example functional blocks, data structures, and method steps for performing a ratchet according to aspects of the present invention;

FIG. 20 is a flow diagram illustrating example functional blocks, data structures, and method steps for performing a ratchet according to aspects of the present invention;

FIG. 21 is a flow diagram illustrating message recovery according to aspects of the present invention; and

FIGS. 22A, 22B, and 22C are illustrations of example system environments that can be used to facilitate certain aspects of the present invention.

DETAILED DESCRIPTION