[go: up one dir, main page]

GB2568966A - An encryption process - Google Patents

An encryption process Download PDF

Info

Publication number
GB2568966A
GB2568966A GB1720175.7A GB201720175A GB2568966A GB 2568966 A GB2568966 A GB 2568966A GB 201720175 A GB201720175 A GB 201720175A GB 2568966 A GB2568966 A GB 2568966A
Authority
GB
United Kingdom
Prior art keywords
message
server
receiver
sender
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB1720175.7A
Other versions
GB201720175D0 (en
Inventor
Ramanlal Patel Ajit
Modi Himanshu
Vala Vijay
Sanal Thomas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wellness Tech And Media Group Ltd
Original Assignee
Wellness Tech And Media Group Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wellness Tech And Media Group Ltd filed Critical Wellness Tech And Media Group Ltd
Priority to GB1720175.7A priority Critical patent/GB2568966A/en
Publication of GB201720175D0 publication Critical patent/GB201720175D0/en
Priority to GB2009751.5A priority patent/GB2583419A/en
Priority to PCT/EP2018/083456 priority patent/WO2019110574A1/en
Publication of GB2568966A publication Critical patent/GB2568966A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Transfer Between Computers (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention provides methods of sending a secure message from a sender to a receiver, wherein both the sender and receiver each have a corresponding public key and private key and each have access to the other's public key, the method comprising: the sender generating a message-encryption key; encrypting the message with the message-encryption key to generate an encrypted message and sending the encrypted message to the receiver via a first server; and the sender encrypting the message-encryption key with the receiver's public key and/or the sender's private key to generate an encrypted message-encryption key and sending the encrypted message-encryption key to the receiver via a second server along with corresponding methods for receiving a secure message.

Description

METHODS OF SECURE COMMUNICATION
This invention relates to methods of secure communication and systems for use in such methods.
Background of the Invention
Messages can be securely sent and securely received using encryption techniques such that only authorised parties can view the message.
The two most common forms of encryption are symmetric encryption and asymmetric encryption.
In symmetric encryption, the same key is used to both encrypt and decrypt a message. Once the message has been encrypted with an encryption key, both the message and the encryption key are sent to the receiver. The receiver can then use the encryption key to decrypt and read the message. However, if the encryption key and encrypted message are both intercepted, an unauthorised third party can decrypt and view the message.
In asymmetric encryption (also referred to as public key cryptography), each user has a related pair of encryption keys - a public encryption key and a private encryption key. The public encryption key is shared with the intended recipient(s), while the private encryption key is never shared. Each public encryption key is associated with a corresponding private encryption key, such that only the public key can decrypt messages encrypted with the associated private key and vice versa.
A sender typically sends an encrypted message to a receiver by encrypting the message with the receiver’s public key. The encrypted message is then sent to the receiver who can decrypt the message with their own private key. As only the receiver’s private key can decrypt the message encrypted with the receiver’s public key, even if both the encrypted message and public encryption key are intercepted, an unauthorised third party cannot use the public encryption key to decrypt and view the encrypted message.
Hybrid encryption methods use a combination of both symmetric and asymmetric encryption techniques.
GB2524369 describes a client and server that are arranged to communicate with each other. A message is encrypted with a symmetric key and the symmetric key is encrypted using an asymmetric key. Both the encrypted message and the encrypted encryption key are sent from the client to the server. The server is then able to decrypt the symmetric encryption key and also decrypt the encrypted message. This only provides communication between a client and a server (rather than two clients) and the message and encryption key are both sent directly from the client to the server.
US6009173 also describes a similar arrangement where an encrypted encryption key is appended to an encrypted message before sending from a sending unit to a receiving unit.
US2013/0046986 describes an electronic data communication system in which encrypted messages are sent in two parts. Message data is first encrypted by a symmetric encryption key and the symmetric encryption key is encrypted with an asymmetric encryption key. If the recipient uses a webmail service to access the encrypted message, the encrypted key data is sent to a third party server which has access to the private key of the user. The third party server decrypts the encrypted key using the private key of the user, and then sends the decrypted key to a remote network device for decryption of the encrypted message. This requires a third party server to be in possession of a user’s private key and the decrypted message is sent from the third party server to the receiver. This final step makes the message susceptible to interception.
In these systems/processes, the encrypted message and encrypted encryption key are often sent from a client to a server or from one client to another (sometimes via a server) via the same channels. Therefore, by intercepting one of these channels both the encrypted message and encryption key can be acquired.
US6904521 describes a system that allows an encrypted message to be sent directly to a recipient. When the recipient opens the message, the recipient automatically sends a request to a server to retrieve decryption information. This process requires decryption information to be stored on a server and the information is only made available to the receiver once the encrypted message has been received.
Other systems exist where encryption keys are stored on a server and can only be accessed by a user upon request. Therefore, when the user wishes to decrypt an encrypted message using the encryption key, they must first connect to the server to retrieve the encryption key. However, this requires connection to the server to read the message and therefore its use is limited as it requires the receiver to be in connection with the server to read the message.
Therefore, there exists a need for further and/or improved methods of sending and receiving secure messages which are less susceptible to unauthorised access via interception.
The Invention
It is one object of the invention to provide an improved, more secure method for sending and receiving messages (such as email messages or SMS messages).
Accordingly, in a first aspect the invention provides a method of sending a secure message from a sender to a receiver, wherein both the sender and receiver each have a corresponding public key and private key and each have access to the other’s public key, the method comprising:
a) generating a message-encryption key;
b) encrypting the message with the message-encryption key to generate an encrypted message and sending the encrypted message to the receiver via a first server; and
c) encrypting the message-encryption key with the receiver’s public key and/or the sender’s private key to generate an encrypted message-encryption key and sending the encrypted message-encryption key to the receiver via a second server.
The invention also provides a method of receiving a secure message from a sender to a receiver, wherein both the sender and receiver each have a corresponding public key and private key and each have access to the other’s public key, the method comprising:
a) receiving an encrypted message from a sender via a first server;
b) receiving an encrypted message-encryption key from the sender via a second server;
c) decrypting the encrypted message-encryption key with the sender’s public key and/or the receiver’s private key to provide a decrypted message-encryption key; and
d) decrypting the encrypted message with the decrypted message-encryption key.
By sending the encrypted message and the encrypted message-encryption key to the receiver via two separate channels, should one of the channels become intercepted, the security of the message is not comprised.
References herein to the “sender”/“receiver” may mean the sender’s device I receiver’s device respectively. The term “user” refers to a person using either the sender/receiver (i.e. the sender’s device / receiver’s device).
The method is typically carried out using an application (an “app”, also referred to as a “client”) on a mobile phone or another portable electronic device, for example a smart phone or a tablet. The sender and receiver (for example, the sender app and receiver app) each comprise or have associated therewith a storage database. The storage database may be used to store messages, details of other devices (for example, another user’s public keys and/or authentication certificates) and the sender/receiver’s private key.
The message being sent and received may be or comprise a text message and may optionally include other attachments such as image files, music files, video files or other electronic documents. In one embodiment, the invention provides methods of sending/receiving email messages. In another embodiment, the invention provides methods of sending/receiving SMS messages. When the message to be sent in an SMS message, the method may further comprise a step of converting/formatting the encrypted SMS message into a format that can allow it to be sent via a third party SMS server (for example, into JavaScript Object Notation, “JSON”, format).
Prior to sending/receiving the secure message, the sender is in possession of the receiver’s public key and the receiver is in possession of the sender’s public key. The public keys may be retrievable from a server (for example, a third server) by the sender or the receiver. As the sender’s public key is stored on the receiver’s device, the receiver can decrypt and read the message (once received) without needing to be connected to any server (i.e. when the receiver is “offline”).
The methods may therefore comprise, prior to sending/receiving a message, the sender/receiver transmitting their public key to a server. The methods may also comprise the sender/receiver retrieving the receiver’s/sender’s public key respectively from the server. One user may retrieve another user’s public key by submitting a request for a public key along with the name or another means for identifying the user to the server.
In one embodiment, the methods of the invention may further comprise a process of exchanging public keys between a sender and a receiver comprising:
i) the sender and the receiver each generating a pair of corresponding public and private keys;
ii) the sender and/or receiver transmitting their public key(s) to a third server; and iii) the sender retrieving the receiver’s public key from the third server and/or the receiver retrieving the sender’s public key from the third server.
The third server may be the same as the first server or the second server. However, the third server is usually different and separate to the first server and/or second server.
The sender does not have access to the receiver’s private key and the receiver does not have access to the sender’s private key.
The message-encryption key used to encrypt the message may be generated on the sender’s device (for example, by the sender application). The messageencryption key may be a randomly generated number of a predetermined length. The message-encryption key is typically a symmetric encryption key. In one embodiment, the message-encryption key is a 256-bit AES encryption key.
Numerous algorithms are known to those skilled in the art which both generate encryption keys and encrypt messages with these encryption keys. The encryption algorithms themselves do not form part of the present invention. Examples of symmetric encryption algorithms include Advanced Encryption Standard (AES), Blowfish, CAST5, DES, IDEA, RC2, RC4, RC6, Serpent, Triple DES and Twofish. In one embodiment, the symmetric encryption algorithm is AES.
The public and private keys are asymmetric encryption keys. Examples of asymmetric encryption algorithms include Rivest-Shamir-Adleman (RSA) asymmetric algorithm, Diffe-Hellman, Digital Signature Algorithm (DSA), EIGamal, ECDSA and XTR. In one embodiment, the asymmetric encryption algorithm is RSA.
The first server may be a third-party service provider server, for example an SMS service provider server or an email service provider server.
The message-encryption key may itself be encrypted using double asymmetric encryption. For example, when sending a secure message, the messageencryption key may first be encrypted with the receiver’s public key followed by subsequent encryption with the sender’s private key.
When receiving the secure message, the message-encryption key may then be first decrypted with the sender’s public key. This confirms the authenticity of the sender. The message-encryption key (which has been partially decrypted) can then be decrypted with the receiver’s private key. The decrypted messageencryption key can then be used to decrypt the secure message received from the first server.
The encrypted message-encryption key is sent to the receiver via the second server. The second server may then (directly or indirectly) communicate with the receiver to inform it that the encrypted message-encryption key is available for retrieval. For example, the second server may signal to a fourth server (for example, an FCM server) to send a message (e.g. an FCM message) to the receiver to inform it that there is an encrypted message-encryption key that the receiver can retrieve from the second server. The second server may be an XMPP server in communication with an FCM server (the fourth server).
XMPP (Extensible Messaging and Presence Protocol) is a known communications protocol for message-oriented middleware for communicating between a client and a server (i.e. an XMPP server).
FCM (Firebase Cloud Messaging) is a known cross-platform solution for messages and notifications for numerous smart phone platforms (such as Android, iOS and web applications). Client servers can send message requests to one or more FCM servers, which then send messages to client applications.
In one embodiment, the method of sending a secure message further comprises:
i) sending the encrypted message-encryption key to the second server;
ii) the second server sending a message request to a fourth server;
iii) the fourth server sending a notification to the receiver informing the receiver that the encrypted message-encryption key is available for retrieval from the second server.
Correspondingly, the method of receiving a secure message may further comprise:
i) receiving a notification from a fourth server that the encrypted messageencryption key is available for retrieval from the second server;
ii) the receiver retrieving the encrypted message-encryption key from the second server.
The second server may be an XMPP server and communications between the XMPP server and the sender/receiver therefore may be based on the XMPP protocol. The fourth server may be a FCM server and communications between the second server/the receiver may therefore be based on the FCM protocol.
In certain methods of the invention, the encrypted encryption key may be sent with an encrypted authentication certificate to so that the receiver can confirm the authenticity of the message from the sender. Authentication certificates are digital certificates, usually an electronic document, that may contain information on the identity of the sender, the authority it was issued by, a unique serial number and the dates for which the certificate is valid. Types of authentication certificates include client/server SSL certificates, S/MIME certificates, object-signing certificates and CA certificates.
Authentication certificate may be exchanged between the sender and the receiver before sending/receiving a secure message, e.g. at the same time the public keys of the sender and the receiver are exchanged. When sending a secure message, the authentication certificate may be encrypted with either the sender’s private key or the receiver’s public key (typically the receiver’s public key). The encrypted authentication certificate is then sent with the encrypted message-encryption key to the receiver, as described above. The receiver can then use the sender’s public key or the receiver’s private key (typically the receiver’s private key) to decrypt the encrypted authentication certificate to confirm the authenticity of the sender.
The method of sending a secure message may further comprise, following sending the encrypted message to the first server, receiving a unique message ID from the first server. This unique message ID may then be sent with the encrypted message-encryption key (and if present, the encrypted authentication certificate) to the receiver via the second server. Accordingly, in the methods described above the encrypted message-encryption key (and optionally the encrypted authentication certificate) may be sent/received in combination with a unique message ID. As the encrypted message and encrypted message-encryption key are sent separately to the receiver, the unique message ID allows the receiver to match each message it receives to an encrypted message-encryption key that it receives. This allows the receiver to correctly use the message-encryption key to decrypt the message that it was used to encrypt.
The method of receiving a secure message therefore also may further comprise receiving a message with a unique message ID from the first server and receiving an encrypted message-encryption key with the same unique message ID from the second server to allow the encrypted message to be matched to the encrypted message-encryption key. In this way, the receiver can use a single encrypted message-encryption key to decrypt a single encrypted message.
The message typically remains encrypted on the receiver device when not being displayed to the user on the device. In this embodiment, the message is only decrypted when the user is reading the message through the client application. However, as the sender’s public key can be stored on the storage device of the receiver, the user of the receiver can use the sender’s public key to decrypt the encrypted message, even if it is offline and not connected to any of the servers.
When the user attempts to send a secure message to a receiver device which is not registered on the second server, the sender device may prompt the user that the receiver device is not registered on the second server and therefore cannot receive messages encrypted as described above. The sender device may then allow the user to send the message unencrypted or send the encrypted message along with a request for the receiver device to register with the second server.
In the case where the user chooses to send the encrypted message along with a request for the receiver device to register with the second server, the message and message-encryption key may be encrypted and temporarily stored in the sender device’s storage database until the receiver has registered with the server.
Accordingly, the invention also provides a method of sending a secure message, the method comprising:
i) encrypting a message with a message-encryption key to generate an encrypted message;
ii) sending the encrypted message to the receiver via a first server along with a request for the receiver to register with a third server;
iii) receiving a unique message ID from the first server;
iv) encrypting the message-encryption key with the sender’s public key to generate a first encrypted message-encryption key;
v) storing the first encrypted message-encryption key (typically in combination with the unique message ID) in a storage database associated with the sender;
vi) receiving the receiver’s public key from the third server once the receiver has registered with the third server;
vii) decrypting the first encrypted message-encryption key with the sender’s private key;
viii) reencrypting the message-encryption key (as detailed above, e.g. with the receiver’s public key, followed by encrypting with the sender’s private key) to generate a second encrypted message-encryption key; and ix) sending the second encrypted message-encryption key to the receiver (typically with the unique message ID), for example via a second server.
The method may also comprise encrypting the sender’s authentication certificate (for example, with the receiver’s public key) and sending the encrypted authentication certificate to the receiver, for example via a second server.
The invention also provides a method of receiving a corresponding message and request to join the second server, the method comprising:
i) receiving an encrypted message along with a request to join a third server from a sender via a first server;
ii) registering with the third server;
iii) receiving an encrypted message-encryption key from the sender via a second server;
iv) decrypting the encrypted message-encryption key with the sender’s public key and/or the receiver’s private keys to provide a decrypted message-encryption key; and
v) decrypting the encrypted message with the decrypted message-encryption key.
The method may also comprise receiving an encrypted authentication certificate from the second server and decrypting the encrypted authentication certificate (for example, with the receiver’s private key). The receiver can then determine whether the decrypted authentication certificate corresponds (e.g. matches) the authentication certificate held on receiver’s storage database for the sender of the secure message.
As an alternative to a mobile phone application, the sender may use a computer (with a client application installed thereon or with access to the client application via the internet).
Before sending the message, the sender can determine whether the intended receiver is registered on the third server and therefore able to receive secure messages using the methods described above.
When the sender wishes to send a secure message to a receiver, the sender can access a server (for example, the third server described herein), to establish whether the receiver is also registered with the third server. In the case that the receiver is registered with the server, the sender can receive the public key (along with other information) associated with the receiver.
In one embodiment of the invention there is provided a method of transmitting a secure message from a sender to a receiver using a first server, a second server and a third server, the method comprising:
a) the sender and receiver each generating a pair of public keys and private keys;
b) the sender and receiver each transmitting their public key to the third server;
c) the sender retrieving the receiver’s public key from the third server and optionally the receiver retrieving the sender’s public key from the third server;
d) the sender generating a message-encryption key;
e) the sender encrypting the message with the message-encryption key to generate an encrypted message and sending the encrypted message to the receiver via the first server;
f) the sender encrypting the message-encryption key with the receiver’s public key and/or the sender’s private key to generate an encrypted encryption key and sending the encrypted encryption key to the receiver via a second server;
g) the receiver receiving the encrypted message from a sender via a first server (sent in step e));
h) the receiver receiving the encrypted message-encryption key from the sender via a second server (sent in step f));
i) the receiver decrypting the encrypted message-encryption key with the sender’s public key and/or the receiver’s private key to provide the decrypted messageencryption key; and
j) the receiver decrypting the encrypted message with the decrypted messageencryption key.
As only a corresponding private key can be used to decrypt data encrypted with a public key, when the message-encryption key is encrypted with the receiver’s public key in step f), the receiver decrypts the encrypted message-encryption key in step i) with the receiver’s private key only. Likewise, if the message-encryption key is encrypted with the sender’s private key in step f), the receiver decrypts the encrypted message-encryption key in step i) with the receiver’s public key only.
In one embodiment, both the receiver’s public key and the sender’s private key are used in step e) to encrypt the message-encryption key and both the sender’s public key and the receiver’s private key are used to decrypt the messageencryption key in step i).
The method may further comprise other features and limitations described in relation to the above methods.
The invention also provides a system comprising a sender device, a receiver device, wherein each device has associated therewith a corresponding public key and private key; a first server and a second server, wherein the sender device is programmed to be capable of sending an encrypted message to the receiver device via a first server and is programmed to be capable of sending an encrypted encryption key to the received device via the second server.
The sender device, receiver device, first server and second server may have the features and/or properties described above in relation to the methods of the invention.
The public keys of the sender and receiver may be stored on a third server which may also form part of the system of the invention.
It is a further object of the invention to provide an improved, more secure method for sending and receiving messages between two devices.
Accordingly, in a second aspect, the invention provides a method of using a first device to send a secure message to a second device, the method comprising:
a) a registration step, wherein an application installed on the first device registers with a server and generates a public key and a private key;
b) an exchange step, wherein the first device sends its public key to the server and receives a public key of a second device from the server;
c) a connection step, wherein the first device establishing a secure peer-to-peer connection with the second device;
d) an authentication step, wherein the first device authenticates the second device; and
e) a messaging step, wherein the first device sending an encrypted message to the second device and/or the second device sending an encrypted message to the first device.
The method is carried out using an application (an “app”, also referred to as a “client”) on a mobile phone or another portable electronic device, for example a smart phone or a tablet. Alternatively, wherein the device is a computer (e.g. a desktop computer or a laptop computer), the method can be carried out using software installed on the computer or using a software development kit (SDK). Each client has associated therewith a storage database. The storage database may be used to store messages, details of other devices and the device’s private key.
The message being sent and received may be or comprise a text message and may optionally include other attachments such as image files, music files, video files or other electronic documents.
Prior to sending/receiving the secure message, the client application on each device must be registered with the server. In the registration step, the client generates a pair of corresponding public and private keys. The client sends its public key to the server and the private key remains on a storage database associated with the client. Upon registration, the server may also assign each device/client with a unique user ID (e.g. a XMPP ID).
Once each device has been registered with the server, the devices may exchange details of the devices with each other via the server. These details may include the public keys of each device.
Prior to sending/receiving the secure message, each device must be in possession of the other device’s public key. The public key associated with each device is typically retrievable from the server.
The method therefore comprises an exchange step, which may comprise, each device transmitting their public key to a server. The method may also comprise the first device retrieving the second device’s public key from the server and/or the second device retrieving the first device’s public key from the server. One device may retrieve another device’s public key by submitting a request for a public key along with the name or another means for identifying the user to the server. The server may then communicate this request to the device whose public key is being requested. The device may then provide a prompt to the user asking whether they wish to accept the request. Once the request has been accepted by the user, the public keys are shared between the two devices. A similar protocol can be used to share the unique user IDs between the two devices. These may be shared at the same time as the public keys.
The server may also provide the devices with a unique pair ID, which is unique to the pair of users.
In one embodiment, the exchange step may comprise:
i) the first device transmitting their public key to a server;
ii) the first device sending a request to retrieve the second device’s public key and/or unique user ID from the server;
iii) the user of the second device accepting the request; and iv) the server sending the public key and/or the unique user ID of the first device to the second device and sending the public key and/or unique user ID of the second device to the first device.
The peer-to-peer connection may be made using the WebRTC protocol or another similar secure TLS protocol. Once the devices have been connected, each device may need to authenticate the other before secure messages can be sent between the devices, in the authentication step.
The authentication step may comprise:
i) a first device encrypting their unique user ID with their private key;
ii) the first device sending their encrypted unique user ID to a second device;
iii) the first device receiving a unique user ID from the second device, wherein the unique user ID is encrypted with the second device’s private key;
iv) the first device decrypting the unique user ID received from the second device with the second device’s public key; and iv) the first device confirming the authenticity of the second device.
In the authentication process, the first device may be the same device as the first device described in the registration/exchange process and the second device may be the same device as the second device in the registration/exchange process. Alternatively, the first device in the authentication process may be the second device in the registration/exchange process and the second device in the authentication may be the first device in the registration/exchange process.
Only if both devices are able to confirm the authenticity of the other, are the users the devices then able to send/receive secure messages to/from each other.
Once both parties have authenticated each other, a secure communication can be sent via an end-to-end encryption process.
When a secure message is to be sent, firstly one of the devices (the sender) encrypts their message using an encryption key which is unique for each message (a “message-encryption key”).
The message-encryption key may be generated on the sender’s device. The message-encryption key may be a randomly generated number of a predetermined length. The message-encryption key is typically a symmetric encryption key. In one embodiment, the message-encryption key is a 256-bit AES encryption key. The public and private keys are asymmetric encryption keys.
Numerous algorithms are known to those skilled in the art which both generate encryption keys and encrypt messages with these encryption keys. The encryption algorithms themselves do not form part of the present invention. Examples of symmetric and asymmetric encryption algorithms are provided above.
The message could be or contain text, media, files and/or videos.
The sender then encrypts the message-encryption key using the other device’s (the receiver’s) public key.
The encrypted message and the encrypted message-encryption key are then sent from the sender to the receiver via the secure peer-to-peer connection.
The message typically remains encrypted on the receiver device when not being displayed to the user of the device.
The invention also provides a computer program for loading onto a mobile phone or other portable electronic device for carrying out all or part of any of the foregoing methods.
In a further aspect, there is provided a data carrier (for example, a mobile phone or other portable electronic device) having a computer program described herein loaded onto the data carrier.
Further aspects and embodiments of the invention will be apparent from the specific description below and the drawings.
Brief Description of the Drawings
Figure 1 is a schematic diagram showing a process of verifying a mobile phone in a first aspect of the invention.
Figure 2 is a schematic diagram showing a registration process in accordance with the first and a second aspect of the invention.
Figures 3A, 3B and 3C are schematic diagrams showing a first encryption process and process of sending the encrypted message and encrypted encryption key from the sender to the receiver in the first aspect of the invention.
Figures 4A and $b are schematic diagrams showing a second first encryption process and process of sending the encrypted message and encrypted encryption key from the sender to the receiver in the first aspect of the invention.
Figure 5 is a schematic diagram showing the process of “making friends” in the second aspect of the invention.
Figure 6 is a schematic diagram showing the process of establishing a secure peer-to-peer connection in the second aspect of the invention.
Figure 7 is a schematic diagram showing the encryption process in the second aspect of the invention.
Figure 8 is a schematic diagram showing how communications are transmitted securely between a server and a client in both the first and second aspects of the invention.
Detailed Description of the Invention
The invention will now be described in more detail, but not limited, by reference to the specific embodiment illustrated in the drawings.
Definitions
Client: A client is a piece of software that accesses a service made available by a server. In this patent application, the term “Client” includes all mobile device platforms including, but not limited to, Android Applications, iOS Applications, Windows Applications, and Mac Applications.
FCM: Firebase Cloud Messaging (FCM) is a cross-platform messaging solution for sending messages and notifications for a variety of applications (including Android, iOS and web applications). Client servers send message requests to one or more FCM servers, which then send messages to client applications.
FCM ID: A unique numerical value created when the Firebase project was created which is used to identify each application server that can send messages to the client application.
RSA encryption: An algorithm used by modern computers to encrypt and decrypt messages using two different keys - both the public and the private keys can encrypt a message; the opposite key from the one used to encrypt a message is used to decrypt the message.
API: Application Programming Interface (API) is a list of commands and their format that one program can send to another. The API is the part of the server that receives requests and send responses.
XMPP: Extensible Messaging and Presence Protocol is a communications protocol for message-oriented middleware based on XML for communicating messages a client and a server.
WebRTC: Web Real-Time Communication (WebRTC) is an open framework that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs.
WebSync: WebSync is a high-performance, high-volume, pub/sub .NET server that makes it easy to add non-streaming real-time functionality such as text chat, signalling/connection management, and server-side content pushing to applications
Authentication Certificate: An electronic document or data string that identifies an individual, a server, a company, or some other entity. The certificate may include the name of the entity it identifies, an expiration date, the name of the certificate authority that issued the certificate, a serial number, and other information.
QR Code: A Quick Response code (QR Code) is a machine-readable code which can be used to store information.
TLS: Transport Layer Security is a cryptographic protocol that provides communications security over a computer network by using symmetric cryptography to encrypt the data transmitted.
XMPP ID: Every user on the XMPP network has a unique XMPP address which is structured like an email address with a username and a domain name for the server where that user resides.
Signing Process: The process of using a cryptographic hash to validate authenticity and integrity - it uses a digital signature to confirm that the information has not been altered or corrupted.
Authenticated Encryption: A form of encryption which simultaneously provides confidentiality, integrity, and authenticity assurances on the data.
Peer to Peer Connection: A peer to peer connection is created when two (or more) clients are connected and share resources without going through a separate server computer.
AES Encryption: Advanced Encryption Standard is a method for encrypting and decrypting information - it encrypts data on a per-block basis and requires the use of keys during the encryption and decryption process.
Token: A type of two-factor authentication security that can be used to authorise the use of computer services.
OTP: A One-time password (OTP) is a password that is only valid for a single login session or transaction.
First Aspect - Email and SMS Communications
The system according to one embodiment of the invention comprises a plurality of user devices each having a client application (a “client”) installed thereon. When the device is a mobile phone, the client application is typically downloadable from an app store (for example, Apple App Store for iOS platforms or Google Play Store for Android platforms). Each client is associated with a client storage database for storing information such as received messages, information on other user devices (e.g. device public keys), and the device’s own private key.
The clients on the user devices are in secure communication with an application server. The application server is capable of communicating with an XMPP Server and a third-party signalling server (e.g. a Websync Server). An FCM server is also provided which is in communication with the client and FCM messages can be sent from the FCM server to the client.
The system can be used in a method for sending/receiving secure messages between two users (e.g. a first user and a second user) where one user (the sender) can securely send a message to the other user (the receiver). Encrypted messages are transmitted via an intermediary service provider (for example, an email service provider or an SMS service provider), whilst the encryption keys for the messages are transmitted to the receiver via the XMPP server.
A user must first register their device with the application server (see Figure 1). The user can register with their mobile phone number, which will need to be verified via OTP. Once the client uploads the user’s mobile phone number to the server (Figure 1, Step 1), the server sends the mobile phone number and an OTP SMS request to an SMS service provider (Figure 1, Step 2). The SMS service provider then sends an SMS to the user’s device with the OTP in the SMS message (Figure 1, Step 3). The client then uploads the OTP to the application server and the mobile phone number is hence verified (Figure 1, Step 4).
The client will then register with the FCM server so that it can receive FCM messages (Figure 2, Step 1). The FCM server will provide the client with a unique FCM ID which is specific to the client (Figure 2, Step 2). Once the FCM ID has been received, the client will upload the FCM ID to the secure application server (Figure 2, Step 3).
At the time of registration, the client creates a pair of 2048-bit RSA encrypted public and private keys (Figure 2, Step 4). The client saves the private key to the client storage database - this private key will never be shared (Figure 2, Step 5). The client sends the public key through secure API to the secure server, where it is stored (Figure 2, Step 6).
Once registered, the secure server will send the client their XMPP ID and WebRTC login details, which is unique to the client, via secure API (Figure 2, Step 9). The secure server receives these the XMPP ID and WebRTC login details from an
XMPP Server and a third party signalling server (e.g. a Websync Server) respectively (Figure 2, Steps 7 and 8).
When the intermediary is an email service provider, the user also enters their email account log in details (e.g. email address and password) into their device. The client then synchronises the content of the user’s email account with the client, so that the email messages from the third-party email service can be accessed through the client.
Each client may also have a unique authentication certificate. Once the device is registered, the client uploads data from a contact database (for example, an electronic phonebook stored on the device and/or contact data from the third-party email service provider) to the application server. The application server will analyse the uploaded data and provide the client with the name, XMPP ID, public encryption key and, if present authentication certificate, for any contact in the user’s contact database, who is already registered on the application server.
A user may have multiple devices registered with the same account on the application server. In order to add another device, the client on the second device must be registered with the application server as described above. Once any existing clients have verified the new client, the user’s existing XMPP ID and public/private keys will replace the corresponding data on the second device so the clients on both devices have the same XMPP ID and public/private keys.
When one user wishes to send a secure message (for example, an SMS message or email message) to another user, the client encrypts the message (including any attachments) with a unique 256-bit AES key generated by the client (Figure 3A, Steps 1 and 2). The encrypted message is then sent to the receiver via the thirdparty service provider (Figure 3A, Step 3). The third-party service provider will assign a unique message ID to the message and provide this to the client (Figure 3A, Step 4).
The unique 256-bit AES key is then encrypted twice. Firstly, the 256-bit AES key is encrypted with the receiver’s public encryption key (Figure 3A, Step 5). The encrypted 256-bit AES encryption key is then further encrypted with the sender’s private encryption key (Figure 3A, Step 6).
The double encrypted encryption key and the unique message ID are then sent to the receiver’s client via the XMPP server in parallel to the encrypted message (sent via the third-party service provider server) (Figure 3B, Step 7).
The transmission of the encrypted message and encrypted encryption key is also shown in Figure 3C. The sender sends the encryption key to the XMPP server (Figure 3C, Step 1). The sender also sends the encrypted message to the third party service provider server (Figure 3C, Step 2). The XMPP then signals to the FCM server that it has received an encryption key from the sender (Figure 3C, Step 3) and the FCM Server sends an FCM message to the receiver to inform it that the encryption key is available on the XMPP server (Figure 3C, Step 4). The receiver can then log into the XMPP server and retrieve the encryption key from the XMPP server (Figure 3C, Steps 5 and 6). The receiver also in parallel receives a message from the third party service provider server (Figure 3C, Step 7) and can use the encryption key obtained from the XMPP server to decrypt the encrypted message (Figure 3C, Step 8), as detailed below.
Once the receiver has received both the encrypted message with its unique message ID from the third-party service provider and the encrypted encryption key (along with the unique message ID) from the secure server (Figure 3B, Steps 7 and 9), the receiver can then decrypt the message.
Firstly, the receiver decrypts the double encrypted encryption key with the sender’s public encryption key to confirm the authenticity of the sender (Figure 3B, Step 8). The receiver can then identify the encrypted message receiver from the third-party service provider using the unique message ID (received in parallel via XMPP with the encrypted encryption key).
To view the message, the receiver then further decrypts the encrypted encryption key with their private key (Figure 3B, Step 10) and can subsequently use the fullydecrypted 256-bit AES encryption key to decrypt the message received via the third-party service provider (Figure 3B, Step 11).
As an alternative to the double encryption method described above, where each client has a unique authentication certificate, the message can be encrypted and sent from the sender to the receiver with an encrypted authentication certificate so that the authenticity of the message can be confirmed.
In this case, when one user wishes to send a secure message (for example, an SMS message or email message) to another user, the client encrypts the message (including any attachments) with a unique 256-bit AES key generated by the client (Figure 4A, Steps 1 and 2). The encrypted message is then sent to the receiver via the third-party service provider (Figure 3A, Step 3). The third-party service provider will assign a unique message ID to the message and provide this to the client (Figure 3A, Step 4).
The unique 256-bit AES key is then encrypted with the receiver’s public encryption key (Figure 3A, Step 5). The sender’s authentication certificate is separately encrypted with the sender’s private encryption key (Figure 3A, Step 6).
The encrypted encryption key, the encrypted authentication certificate and the unique message ID are then sent to the receiver’s client via XMPP and FCM to the receiver’s client in parallel to the encrypted message (sent via the third-party service provider server) (Figure 4B, Step 7).
The transmission of the encrypted message and encrypted encryption key/encrypted authentication certificate as described for the double encryption process described above and shown in Figure 3C.
Once the receiver has received both the encrypted message with its unique message ID and from the third-party service provider and the encrypted encryption key (along with the unique message ID and the encrypted authentication certificate) from the secure server (Figure 4B, Steps 7 and 9), the receiver can then decrypt the message.
Firstly, the receiver decrypts the encrypted authentication certificate with the sender’s public encryption key. The receiver can confirm that the decrypted authentication certificate matches the authentication certificate received from the application server when it also received other information regarding the sender (e.g. their XMPP ID and public encryption key) to confirm the authenticity of the sender (Figure 4B, Step 8). The receiver can then identify the encrypted message receiver from the third-party service provider using the unique message ID (received in parallel via XMPP with the encrypted encryption key).
To view the message, the receiver then decrypts the encrypted encryption key with their private key (Figure 4B, Step 10) and can subsequently use the decrypted
256-bit AES encryption key to decrypt the message received via the third-party service provider (Figure 4B, Step 11).
When the message to be sent is an SMS message, the encrypted SMS message (encrypted with the 256-AES Key) may be, for compatibility reasons, incorporated/converted into a JavaScript Object Notation (JSON) file before the SMS message can be sent to the third-party SMS service provider. The JSON file may be further encrypted with an encryption key available to both the sender and the receiver before being transmitted to the third-party SMS service provider.
The message is only decrypted when the user is viewing the message through the client. The message is recrypted when the message is not being read. Both the message data and the encryption key remain encrypted on the client when not being viewed and will only be decrypted when the user is viewing the message.
As the message remains encrypted on the client and is only accessible through the client, the message cannot be viewed through any third-party application, as only the client application is able to decrypt and display the message to the user.
Messages can be sent to users who are not registered on the secure server. When a user attempts to send a message to another user who is not registered on the secure server they are prompted with one of two options:
i) The message can be sent without encryption ii) The message can be sent with encryption along with a request asking the receiver to register with the secure server in order to view the message.
In the case where the user wishes for the message to be sent encrypted with a request asking the receiver to register with the server.
The client encrypts the message (including any attachments) with a unique 256-bit AES key generated by the client. The encrypted message is sent to the receiver, along with a request to register with the secure server, via the third-party service provider. The third-party service provider will assign a unique message ID and provide this to the client. In the meantime, the 256-bit AES key is encrypted with the sender’s public key and stored in the sender’s client database along with the unique message ID. This ensures that the 256-bit AES encryption key is securely stored on the sender’s device for the time period where the sender is waiting for the receiver the register with the secure server.
After the receiver has registered with the secure server (using the registration procedure outlined above), the sender will be notified via SMPP and FCM and the sender is provided with the receiver’s public key (and optionally their authentication certificate).
Once the sender has received notification that the receiver has registered with the server, the sender decrypts the 256-bit AES encryption key (which has been temporarily stored on their client database) with their private key.
The sender then encrypts the encryption key with the receiver’s public key, followed by encrypting with their private key, as detailed above. The encrypted encryption key is then sent to the receiver via XMPP and FCM.
The receiver can then decrypt and view the message in the manner described above.
Second aspect - Device to Device Communications
The system according to a second aspect of the invention comprises two user devices each having a client application installed thereon. When the user device is a mobile phone, the client application is typically downloadable from an app store (for example, Apple App Store for iOS platforms or Google Play Store for Android platforms). Each client has a client storage database associated therewith.
The clients on the user devices are in secure communication with an application server.
The application server is also in communication with XMPP Server and a third party signalling server (for example, a Websync Server). An FCM Server is also provided which is in communication with the user devices and FCM messages can be sent from the FCM server to the client.
The system can be used in a method for secure messages between two users (e.g. a first user and a second user) where one user (the sender) can securely send a communication to the other user (the receiver). The messages are transmitted directly from device-to-device.
Before two users can send secure messages to each other, they must first register the clients on their devices with the application server.
A user registers with their own unique pin by entering this pin into their device. The client will then register with the FCM server so that it can receive FCM messages (Figure 2, Step 1). The FCM server will provide the client with a unique FCM ID which is specific to the client (Figure 2, Step 2). Once the FCM ID has been received, the client will upload the FCM ID to the secure application server (Figure 2, Step 3).
Users can provide their email address to the application server when registering so that they are able to recover their password and to alert them of any suspicious activity regarding their account.
At the time of registration, the client creates a pair of 2048-bit RSA encrypted public and private keys (Figure 2, Step 4). The client saves the private key to a secure database - this private key will never be shared (Figure 2, Step 5). The client sends the public key through secure API to the secure D2D server, where it is stored (Figure 2, Step 6).
Once registered, the secure server will send the client their XMPP ID and WebRTC login details, which is unique to the client, via secure API (Figure 2, Step 9). The secure server receives these the XMPP ID and WebRTC login details from an XMPP Server and third party signalling server (e.g. Websync Server) respectively (Figure 2, Steps 7 and 8).
Before a message can be sent from a sender to a receiver, both the sender and the receiver must be connected as “friends” (see Figure 5). A first user can send a “friend request” to a second user via the application server by entering the second user’s details (e.g. their name and/or their unique pin), either manually or by scanning a QR code (Figure 5, Step 1). A request is sent from the application server to the second user and the second user can choose to either accept or reject the request (Figure 5, Step 2). If the second user accepts the request, the public key, XMPP ID and a unique room ID for both users is exchanged via secure API (Figure 5, Steps 3 and 4). The room ID is unique for each “friendship” pair. The room ID may be static for each “friendship” pair or alternatively may be a onetime access ID, where a new one-time access ID is generated each time the sender wishes to send a message to the receiver.
When the sender wishes to send a secure communication to the receiver, the sender sends a connection request to the XMPP server (Figure 6, Step 1). The sender will then log into the third party signalling server using the unique room ID exchanged at the time of adding the receiver as a friend (Figure 6, Step 2). Upon receiving the request from the sender, the XMPP server sends a request to the FCM server (Figure 6, Step 3). The FCM Server then sends a request to the receiver informing it that a connection request has been transmitted to the XMPP server (Figure 6, Step 4). The receiver then logs into the XMPP server and retrieves the connection information from the XMPP server (Figure 5, Steps 5 and 6). After receiving the connection information, the receiver will log into the third party signalling server using the same unique room ID which was exchanged at the time of adding the sender as a friend (Figure 5, Step 7). A secure TLS peer to peer connection is then established between the sender and the receiver using a secure TLS Peer-to-Peer protocol (for example, the WebRTC protocol) (Figure 5, Step 8).
Before a communication is sent from the sender to the receiver, both users will need to authenticate each other using a signing process. Each user will encrypt their XMPP ID with their private key and send it to the other user. The receiver will then decrypt the encrypted XMPP ID using the sender’s public key to confirm authenticity. Only if both clients are able to confirm the authenticity of the other then the users will be able to send messages each other.
If both clients are not able to confirm the authenticity then the users will not be able to message each other. If the client is not able to confirm the authenticity of the other user then it will automatically leave the room ID and end the session. When one client leaves the room ID and ends the session, the other user will also automatically leave the room ID and end the session.
Once both parties have authenticated each other, a secure communication can be sent via an end-to-end encryption process (See Figure 7).
When a secure communication is to be sent, firstly the sender encrypts their message using a 256-bit AES encryption key which is generated by the client and is unique for each message (Figure 7, Steps 1 and 2). The message may comprise text, media, files and/or videos. The sender then encrypts this 256-bit AES encryption key using the receiver’s public key (Figure 7, Step 3).
The encrypted communication and the encrypted encryption key are then sent from the sender to the receiver via the secure peer-to-peer connection (Figure 6, Steps 4 and 5). The receiver is able to decrypt the encrypted encryption key using their own private key (Figure 7, Step 6). The receiver is then able to use the decrypted 256-bit AES encryption key to encrypt the message from the sender (Figure 7, Step 7). The encrypted message remains encrypted on both devices and can only be decrypted using the same client.
Additional Privacy Features
The methods/system may comprise additional privacy features to further secure the message once it has been sent. Example of these additional privacy features are listed below:
Users can remotely delete all of their client data stored on their device, in case their device is lost or stolen. This can be done by logging into a website with the user’s login details. A “burn” request is then sent from the website to the client via the XMPP or FCM server. Once the request to remotely delete all data has been received by the client, all login information and data including the user’s private encryption key, media and messages stored in the client storage database is remotely wiped.
The sender can specify a period of time within which the message is viewable. After a pre-determined time limit, the encrypted message, encryption key and message ID is deleted from the receiver’s client database and the XMPP server.
Messages or parts of messages can be recalled. The recall command is sent to the receiver via XMPP or FCM. After the recall command is receiver by the receiver’s client, the message will be destroyed and no longer visible to the receiver.
Users can scramble messages contained on the client to prevent the messages from being read from others in close proximity. With this feature enabled, the user can quickly make the content illegible when viewing sensitive information which other people may be able to see on the device.
The client may be password protected or have additional separate privacy features to provide an additional level of security. Therefore, even if an authorised party acquires possession of a user device, they are unable to open the app to view encrypted messages.
The messages may additionally be password protected. The sender can decide whether they would like their messages to be password protected. The password-protected email is then sent via the third-party service provider. A separate command is sent with the unique message ID to the receiver to inform them that the email is password protected. The receiver is then required to enter their password every time they wish to view the email.
As well as emails being password protected by the sender, once received a receiving user can also decide to password protect specific emails on their client. Once the user has locked a particular email, a password will be required every time the user would like to open the email.
Senders can prevent receiver’s from forwarding their message to other users. This gives users total control over their messages allowing them to disable the ability for their messages to be copied or forwarded by the receiver. This command is sent from the sender to the receiver by XMPP/FCM.
Senders can also prevent the receiver from capturing screenshots of their message(s). This command is sent from the sender to the receiver by XMPP/FCM.
Timestamp Validation
Communications between the client and the server are secure by means of a timestamp validation process (see Figure 8). When the client is opened, a new session is initiated from the secure server. The session ends when the client is closed. The server provides a unique session ID via the app settings API for each session (Figure 8, Step 1). Each time the client needs to communicate with the secure server, the client creates a unique token using the current timestamp in nanoseconds (Figure 8, Step 2). The token is encrypted with the client’s private key (Figure 8, Step 3) and is sent to the secure server via secure API along with the request for data (Figure 8, Step 4). At the time of communication, the server will decrypt the client’s token using the client’s public key which is stored on the server (Figure 8, Step 5) and the authenticity of the request for data is validated (Figure 8, Step 7).
If the server is not able to decrypt the client’s token using the client’s public key (for example if the token has been encrypted with a different user’s private key), then the server will not provide the data requested by the client and an error message is transmitted to the client (Figure 8, Step 6). If the server is able to decrypt the client’s token using the client’s public key and the timestamp is less than 3 minutes, then the server will provide the data requested by the client. If the timestamp of the token is greater than 3 minutes, then the server will give a response that the request has been timed out.
Equivalents
It will readily be apparent that numerous modifications and alterations may be made to the specific embodiments of the invention described above without departing from the principles underlying the invention. All such modifications and alterations are intended to be embraced by this application.

Claims (32)

1. A method of sending a secure message from a sender to a receiver, wherein both the sender and receiver each have a corresponding public key and private key and each have access to the other’s public key, the method comprising:
a) generating a message-encryption key;
b) encrypting the message with the message-encryption key to generate an encrypted message and sending the encrypted message to the receiver via a first server; and
c) encrypting the message-encryption key with the receiver’s public key and/or the sender’s private key to generate an encrypted message-encryption key and sending the encrypted message-encryption key to the receiver via a second server.
2. A method of receiving a secure message from a sender to a receiver, wherein both the sender and receiver each have a corresponding public key and private key and each have access to the other’s public key, the method comprising:
a) receiving an encrypted message from a sender via a first server;
b) receiving an encrypted message-encryption key from the sender via a second server;
c) decrypting the encrypted message-encryption key with the sender’s public key and/or the receiver’s private key to provide a decrypted message-encryption key; and
d) decrypting the encrypted message with the decrypted message-encryption key.
3. A method according to claim 1 or claim 2 where the method further comprises, prior to sending/receiving a message, the sender/receiver transmitting their public key to a third server.
4. A method according to claim 3 wherein the method further comprises the sender/receiver retrieving the receiver’s/sender’s public key respectively from the third server.
5. A method according to claim 1 or claim 2, the method further comprising a process of exchanging public keys between a sender and a receiver, the process of exchanging public keys comprising:
i) the sender and the receiver each generating a pair of corresponding public and private keys;
ii) the sender and/or receiver transmitting their public key(s) to a third server; and iii) the sender retrieving the receiver’s public key from the third server and/or the receiver retrieving the sender’s public key from the third server.
6. A method according to claim 5, the method further comprising a process of exchanging authentication certificates, the process of exchanging authentication certificates comprising:
i) the sender and/or receiver transmitting their authentication certificates to a third server; and iii) the sender retrieving the receiver's authentication certificate from the third server and/or the receiver retrieving the sender’s authentication certificate from the third server.
7. A method according to any one of claims 1 to 7 wherein the first server is a third-party service provider server, for example an SMS service provider server or an email service provider server.
8. A method according to claim 1 or any claim dependent thereon, wherein the method further comprising a process of exchanging authentication certificates (for example, a process of exchanging authentication certificates as defined in claim 5), and wherein step c) comprises either:
i) encrypting the message-encryption key with the sender’s private key to generate an encrypted message-encryption key and encrypting the sender’s authentication certificate with the receiver’s public key to generate an encrypted authentication certificate and sending the encrypted message-encryption key and the encrypted authentication certificate to the receiver via a second server; or ii) encrypting the message-encryption key with the receiver’s public key to generate an encrypted message-encryption key and encrypting the sender’s authentication certificate with the sender’s private key to generate an encrypted authentication certificate and sending the encrypted message-encryption key and the encrypted authentication certificate to the receiver via a second server.
9. A method according to claim 1 or any claim dependent thereon wherein step c) comprises:
encrypting the message-encryption key with the receiver’s public key and the sender’s private key to generate an encrypted message-encryption key and sending the encrypted message-encryption key to the receiver via the second server.
10. A method according to claim 9 wherein step c) comprises:
encrypting the message-encryption key with the receiver’s public key followed by encrypting the message-encryption key with the sender’s private key to generate an encrypted message-encryption key and sending the encrypted messageencryption key to the receiver via the second server.
11. A method according to claim 2 or any claim dependent thereon, wherein the method further comprising a process of exchanging authentication certificates (for example, a process of exchanging authentication certificates as defined in claim 5), and wherein step c) comprises either:
i) receiving an encrypted message-encryption key and an encrypted authentication certificate from a second server, decrypting the message-encryption key with the sender’s public key to provide a decrypted message-encryption key and decrypting the sender’s authentication certificate with the receiver’s private key to provide a decrypted authentication certificate; or ii) receiving an encrypted message-encryption key and an encrypted authentication certificate from a second server, decrypting the message-encryption key with the receiver’s private key to provide a decrypted message-encryption key and decrypting the sender’s authentication certificate with the sender’s public key to provide a decrypted authentication certificate.
12. A method according to claim 11 wherein the decrypted authentication certificate is matched to the authentication certificate received in the process of exchanging authentication certificates to confirm the authenticity of the sender.
13. A method according to claim 2 or any claim dependent thereon wherein step c) comprises:
c) decrypting the encrypted message-encryption key with the sender’s public key and the receiver’s private key to provide a decrypted message-encryption key.
14. A method according to claim 13 wherein step c) comprises:
c) decrypting the encrypted message-encryption key with the sender’s public key followed by decrypting the encrypted message-encryption key with the receiver’s private key to provide a decrypted message-encryption key.
15. A method according to any one of claim 1 or any claim dependent thereon, the method further comprising: following sending the encrypted message to the first server, receiving a unique message ID from the first server.
16. A method according to claim 2 or any claim dependent thereon, the method further comprising: receiving a message with a unique message ID from the first server and receiving an encrypted message-encryption key with the same unique message ID from the second server to allow the encrypted message to be matched to the encrypted encryption key.
17. A method according to any one of claims 1 to 12 wherein the message remains encrypted on the receiver when not being displayed to a user device.
18. A method of sending a secure message, the method comprising:
i) encrypting a message with a message-encryption key;
ii) sending the encrypted message to the receiver via a first server along with a request for the receiver to register with a third server;
iii) receiving a unique message ID from the first server;
iv) encrypting the message-encryption key with the sender’s public key to generate a first encrypted message-encryption key
v) storing the first encrypted message-encryption key in a storage database associated with the sender;
vi) receiving the receiver’s public key from the third server once the receiver has registered with the third server;
vii) decrypting the first encrypted encryption key with the sender’s private key;
viii) reencrypting the encryption key (for example, with the receiver’s public key, followed by encrypting with the sender’s private key) to generate a second encrypted message-encryption key; and ix) sending the second encrypted message-encryption key to the receiver with the unique message ID.
19. A method of receiving a corresponding message and request to join the third server, the method comprising:
i) receiving an encrypted message along with a request to join a third server from a sender via a first server;
ii) registering with the third server;
iii) receiving an encrypted message-encryption key from the sender via a second server;
iv) decrypting the encrypted message-encryption key (for example, with the sender’s public key and/or the receiver’s private keys) to provide a decrypted message-encryption key; and
v) decrypting the encrypted message with the decrypted message-encryption key.
20. A method of transmitting a secure message from a sender to a receiver using a first server and a second server, the method comprising:
a) the sender and receiver each generating a pair of public keys and private keys;
b) the sender and receiver each transmitting their public key to the third server;
c) the sender retrieving the receiver’s public key from the third server and optionally the receiver retrieving the sender’s public key from the third server;
d) the sender generating a message-encryption key;
e) the sender encrypting the message with the message-encryption key to generate an encrypted message and sending the encrypted message to the receiver via the first server;
f) the sender encrypting the message-encryption key with the receiver’s public key and/or the sender’s private key to generate an encrypted encryption key and sending the encrypted encryption key to the receiver via a second server;
g) the receiver receiving the encrypted message from a sender via a first server;
h) the receiver receiving the encrypted encryption key from the sender via a second server;
i) the receiver decrypting the encrypted message-encryption key with the sender’s public key and/or the receiver’s private key to provide the decrypted messageencryption key; and
j) the receiver decrypting the encrypted message with the decrypted messageencryption key.
21. A system comprising a sender device, a receiver device, wherein each device has associated therewith a corresponding public key and private key; a first server and a second server, wherein the sender device is programmed to be capable of sending an encrypted message to the receiver device via a first server and is programmed to be capable of sending an encrypted encryption key to the received device via the second server.
22. A method of using a first device to send a secure message to a second device, the method comprising:
a) a registration step, wherein an application installed on the first device registers with a server and generates a public key and a private key;
b) an exchange step, wherein the first device sends its public key to the server and receives a public key of a second device from the server;
c) a connection step, wherein the first device establishing a secure peer-to-peer connection with the second device;
d) an authentication step, wherein the first device authenticates the second device; and
e) a messaging step, wherein the first device sending an encrypted message to the second device and/or the second device sending an encrypted message to the first device.
23. A method according to claim 22 wherein the exchange step comprises each device transmitting their public key to the server.
24. A method according to claim 22 or 23 wherein the exchange step comprises the first device retrieving the second device’s public key from the server and/or the second device retrieving the first device’s public key from the server.
25. A method according to claim 22 wherein the exchange step may comprise:
i) the first device transmitting their public key to a server;
ii) the first device sending a request to retrieve the second device’s public key and/or unique user ID from the server;
iii) the user of the second device accepting the request;
iv) the server sending the public key and/or the unique user ID of the first device to the second device and sending the public key and/or unique user ID of the second device to the first device.
26. A method according to any one of claims 22 to 25 wherein the authentication step comprises:
i) a first device encrypting their unique user ID with their private key;
ii) the first device sending their encrypted unique user ID to a second device iii) the first device receiving a unique user ID from the second device, wherein the unique user ID is encrypted with the second device’s private key;
iv) the first device decrypting the unique user ID received from the second device with the second device’s public key;
iv) the first device confirming the authenticity of the second device.
27. A method according to any one of claims 22 to 26 wherein the messaging step comprises one of the devices (the sender) encrypting a message using a message-encryption key which is unique for each message.
28. A method according to claim 27 wherein the sender then encrypts the message-encryption key using the other device’s (the receiver’s) public key to generate an encrypted message-encryption key.
29. A method according to claim 28 wherein the encrypted message and the
5 encrypted message-encryption key are then sent from the sender to the receiver via the secure peer-to-peer connection.
30. A method according to any one of claims 22 to 29 wherein the message remains encrypted on the receiver device when not being displayed to the user on the device.
10
31. A computer program for loading onto a mobile phone or other portable electronic device for carrying out all or part of any of the methods of claims 1 to 30.
32. A data carrier (for example, a mobile phone or other portable electronic device) having a computer program according to claim 31 loaded thereon.
GB1720175.7A 2017-12-04 2017-12-04 An encryption process Withdrawn GB2568966A (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
GB1720175.7A GB2568966A (en) 2017-12-04 2017-12-04 An encryption process
GB2009751.5A GB2583419A (en) 2017-12-04 2018-12-04 Methods of secure communication
PCT/EP2018/083456 WO2019110574A1 (en) 2017-12-04 2018-12-04 Methods of secure communication

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1720175.7A GB2568966A (en) 2017-12-04 2017-12-04 An encryption process

Publications (2)

Publication Number Publication Date
GB201720175D0 GB201720175D0 (en) 2018-01-17
GB2568966A true GB2568966A (en) 2019-06-05

Family

ID=60950157

Family Applications (2)

Application Number Title Priority Date Filing Date
GB1720175.7A Withdrawn GB2568966A (en) 2017-12-04 2017-12-04 An encryption process
GB2009751.5A Withdrawn GB2583419A (en) 2017-12-04 2018-12-04 Methods of secure communication

Family Applications After (1)

Application Number Title Priority Date Filing Date
GB2009751.5A Withdrawn GB2583419A (en) 2017-12-04 2018-12-04 Methods of secure communication

Country Status (2)

Country Link
GB (2) GB2568966A (en)
WO (1) WO2019110574A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021154368A1 (en) * 2020-01-29 2021-08-05 Citrix Systems, Inc. Secure message passing using semi-trusted intermediaries
US11750572B2 (en) 2020-08-12 2023-09-05 Capital One Services, Llc System, method, and computer-accessible medium for hiding messages sent to third parties

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12278893B2 (en) * 2018-04-25 2025-04-15 EMC IP Holding Company LLC Lightweight security for internet of things messaging
WO2021028831A1 (en) * 2019-08-12 2021-02-18 Pi-Taa Technology Ltd. Real time decryption system and method for its use
CN111192050B (en) * 2019-12-31 2023-08-11 成都库珀创新科技有限公司 Digital asset private key storage and extraction method and device
CN113300999B (en) * 2020-02-21 2023-12-05 北京沃东天骏信息技术有限公司 Information processing methods, electronic devices and readable storage media
CN111600701B (en) * 2020-04-28 2023-06-27 广州华工信元通信技术有限公司 Private key storage method, device and storage medium based on blockchain
KR20220005963A (en) 2020-07-07 2022-01-14 삼성전자주식회사 Method and electronic device for encrypting message
CN112564893B (en) * 2020-10-22 2023-02-03 北京芯盾集团有限公司 Key transmission method combining circuit domain and IP domain
US11854553B2 (en) 2020-12-23 2023-12-26 Optum Technology, Inc. Cybersecurity for sensitive-information utterances in interactive voice sessions
US11900927B2 (en) 2020-12-23 2024-02-13 Optum Technology, Inc. Cybersecurity for sensitive-information utterances in interactive voice sessions using risk profiles
JP6877727B1 (en) * 2021-01-06 2021-05-26 Ａｒａｖ株式会社 Connection method between terminals via the room site of the signaling server, cloud server and program
CN112668029A (en) * 2021-02-19 2021-04-16 张爽 Private social software and private implementation method thereof
CN113242121B (en) * 2021-04-15 2023-07-25 哈尔滨工业大学 Safety communication method based on combined encryption
CN115734031A (en) * 2021-08-27 2023-03-03 武汉玖成信息科技有限公司 A broadcast interaction method and system thereof
CN114338156A (en) * 2021-12-28 2022-04-12 北京深思数盾科技股份有限公司 Data processing method, device and storage medium
US12003575B2 (en) 2022-02-22 2024-06-04 Optum, Inc. Routing of sensitive-information utterances through secure channels in interactive voice sessions
EP4581791A1 (en) * 2022-08-31 2025-07-09 Entrust Corporation One-time password delivery via in-band unauthenticated channel
WO2024216648A1 (en) * 2023-04-21 2024-10-24 北京小米移动软件有限公司 Key exchange method, apparatus, device, and storage medium
CN117201113B (en) * 2023-09-07 2024-04-30 上海雷龙信息科技有限公司 Block chain digital signature method and system based on asymmetric encryption

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1667355A1 (en) * 2001-02-21 2006-06-07 RPK New Zealand Limited Encrypted media key management
US20150229471A1 (en) * 2014-02-11 2015-08-13 Telefonaktiebolaget L M Ericsson (Publ) System and method for securing content keys delivered in manifest files

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760752B1 (en) * 1999-06-28 2004-07-06 Zix Corporation Secure transmission system
GB2434947B (en) * 2006-02-02 2011-01-26 Identum Ltd Electronic data communication system
US8762712B1 (en) * 2012-07-27 2014-06-24 Trend Micro Incorporated Methods and system for person-to-person secure file transfer

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1667355A1 (en) * 2001-02-21 2006-06-07 RPK New Zealand Limited Encrypted media key management
US20150229471A1 (en) * 2014-02-11 2015-08-13 Telefonaktiebolaget L M Ericsson (Publ) System and method for securing content keys delivered in manifest files

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021154368A1 (en) * 2020-01-29 2021-08-05 Citrix Systems, Inc. Secure message passing using semi-trusted intermediaries
US11159497B2 (en) 2020-01-29 2021-10-26 Citrix Systems, Inc. Secure message passing using semi-trusted intermediaries
US11750572B2 (en) 2020-08-12 2023-09-05 Capital One Services, Llc System, method, and computer-accessible medium for hiding messages sent to third parties
US12069034B2 (en) 2020-08-12 2024-08-20 Capital One Services, Llc System, method, and computer-accessible medium for hiding messages sent to third parties

Also Published As

Publication number Publication date
GB2583419A (en) 2020-10-28
GB202009751D0 (en) 2020-08-12
GB201720175D0 (en) 2018-01-17
WO2019110574A1 (en) 2019-06-13

Similar Documents

Publication Publication Date Title
GB2568966A (en) An encryption process
US12058115B2 (en) Systems and methods for Smartkey information management
US12177351B2 (en) Authorized data sharing using smart contracts
US9590949B2 (en) Confidential message exchange using benign, context-aware cover message generation
US9705859B2 (en) Key exchange through partially trusted third party
US20190222583A1 (en) Signed envelope encryption
US11790100B2 (en) Encryption of cloud-based data
US8261061B2 (en) Methods and systems for encouraging secure communications
JP2022522788A (en) Blockchain-based secure email system
US20160065571A1 (en) System and methods for secure file sharing and access management
GB2584455A (en) An encryption process
US12363080B2 (en) System and method for web-browser based end-to-end encrypted messaging and for securely implementing cryptography using client-side scripting in a web browser
US20160359822A1 (en) Sovereign share encryption protocol
US10417437B2 (en) Maintaining data security in a network device
CA3093869A1 (en) Trust extension in a secure communication framework
US9160739B2 (en) Secure data transmission system
CN113691495B (en) Network account sharing and distributing system and method based on asymmetric encryption
WO2016033208A1 (en) System and methods for secure file sharing and access management
WO2019138399A1 (en) A method and a computer program for exchanging secured peer-to-peer communications
CN102510431B (en) Method, system, device and user terminal for obtaining remote resource
US20250337573A1 (en) Authentication Using A Public Key Distribution Framework
WO2022264457A1 (en) File transfer system

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)