WO2019110574A1

WO2019110574A1 - Methods of secure communication

Info

Publication number: WO2019110574A1
Application number: PCT/EP2018/083456
Authority: WO
Inventors: Ajit PATEL; Himanshu MODI; Vijay VALA; Sanal THOMAS
Original assignee: Wellness Technology and Media Group Ltd
Priority date: 2017-12-04
Filing date: 2018-12-04
Publication date: 2019-06-13
Also published as: GB2568966A; GB202009751D0; GB2583419A; GB201720175D0

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: 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 along with corresponding methods for receiving a secure message 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.

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, SMS messages or other electronic data files).

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“senderTreceiver” may mean the sender’s device / 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, other users’ 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. The message may be in the form of an electronic data file, for example an electronic document or an image, music or video file. In one embodiment, the invention provides methods of sending/receiving email messages. In another embodiment, the invention provides methods of sending/receiving SMS messages. In a further embodiment, the invention provides methods of sending/receiving electronic data files. When the message to be sent in an email or SMS message, the method may further comprise a step of

converting/formatting the encrypted email or SMS message into a format that can allow it to be sent via a third party email or 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 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.

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, an email service provider server, a cloud storage server or a social media platform server.

The message-encryption key may itself be encrypted using double asymmetric encryption. For example, when sending a secure message, the message- encryption 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 message- encryption 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 message- encryption 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 an 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 certificates 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 sender’s private 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 sender’s public 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.

The methods of the invention may additionally allow users to verify the authenticity of the messages received. This can be done by generating hash values of the messages to be sent. The hash value of a message sent by the sender can be compared with the hash value of the message once received by the receiver to determine whether the content of the message has been altered since it was sent by the sender.

Accordingly, the methods of the invention may further comprise: i) the sender generating a first hash value (using a hash function) of the message to be sent by the sender; ii) the sender sending the first hash value to the receiver (e.g. via the second server); iii) the receiver receiving the first hash value from the sender (e.g. via the second server) and iii) the receiver generating a second hash value using the hash function of the message received by the receiver; wherein the receiver informs the user if the first hash value does not equal the second hash value (e.g. in the form of a notification that the content of the message has been changed).

For improved accountability, the generated hash values (first hash values and/or second hash values) may be stored on a blockchain. For example, the first hash value may be recorded onto the blockchain when the message is sent from the sender. Therefore, if the message is subsequently modified by the receiver, then the hash value of the message will change. Comparing the first hash value of the message stored on the blockchain with a second hash value generated by the received would indicate whether there are any modifications to the 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 message- encryption key; and j) the receiver decrypting the encrypted message with the decrypted message- encryption 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 message- encryption key in step i).

Communications between the clients/devices described herein and the servers described herein are secure. In one example, the server has its own pair of public and private keys wherein the public key is made available to the clients. As described above, the client’s public encryption key is made available to the server. The data to be transmitted from the client to the server is typically encrypted with a symmetric data-encryption key (typically generated by the client) to form encrypted data. The data-encryption key is then encrypted with the server’s public key to form an encrypted data-encryption key. The client then transmits to the server the encrypted data, the encrypted data-encryption key and optionally other information such as identifiers (e.g. unique numerical or alphanumerical codes that represent the user, the client and/or the device) and the time (e.g. the time when the information was encrypted or the time when the data was sent from the client to the server). The other information may also be encrypted using either the client’s private key or the server’s public key.

The server then receives the encrypted data, the encrypted data-encryption key and optionally other information from the client. The server can decrypt the encrypted data-encryption key using the server private key to retrieve the data- encryption key. The data-encryption key can then be used to decrypt the data being sent from the client to the server. When the other information transmitted from the client to the server has been encrypted with the client’s private key or the server’s public key, the server can decrypt this information with the client’s public key or the server’s private key respectively.

When a time is sent from the client to the server, the server will validate the time by decrypting data (as described above, when necessary). If the time difference between the time sent from the client to the server and the time when the server receives the time is greater than 3 minutes, then the data-encryption key and/or the encrypted data will not be decrypted.

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 4B 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 embodiments 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.

JSON File: JavaScript Object Notation (JSON) is a way to store information in an organised, easy-to-access manner. It gives a human-readable collection of data that can be accessed in a logical manner.

DTLS Connection: Data Transport Layer Security (DTLS) is a communications protocol that provides security for datagram-based applications by allowing them to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery.

Keychain: A Keychain is a password management system used to store

passwords and other sensitive information. Keystore: A Keystore is a repository where private keys, certificates, and symmetric keys can be stored.

First Aspect - Email, SMS and Cloud Storage 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, an SMS service provider, a cloud storage provider or social media platform), 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 (described in more detail below) to the secure application 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 external third-party service provider (e.g. an email service provider, a cloud storage provider or a social media platform), the user also enters their log in details for the external service provider (e.g. email

address/username and password) into their device. The external service provider then authenticates the client and provides login access through the client. The client then synchronises the content of the user’s account with the external service provider (e.g. their email account, their cloud storage account or their social media account) with the client, so that the email messages or electronic data files from the external third-party service provider 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, email message or an electronic data file) 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 message will also include associated metadata, including its properties, such as the file type and its last modified date. The encrypted message may also (when required by the third-party service provider) be inserted into a JSON file. The JSON file is then encrypted using a SMS/Email 256-bit universal AES encryption key before being sent to the third- party service provider. 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 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 received 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 fully- decrypted 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, email message or electronic data file) 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). As described above, the encrypted message may also be inserted into a JSON file. The encrypted message is then sent to the receiver via the third-party service provider (Figure 4A, Step 3). The third-party service provider will assign a unique message ID to the message and provide this to the client (Figure 4A, Step 4).

The unique 256-bit AES key is then encrypted with the receiver’s public encryption key (Figure 4A, Step 5). The sender’s authentication certificate is separately encrypted with the sender’s private encryption key (Figure 4A, 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 received 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 encryption methods described herein may also be used to establish secure voice/video calls. In this case, the secure message is a connection request. The connection request is encrypted (as described above) with a 256-bit AES encryption key and is then sent via a third-party server to the receiver. The 256-bit AES encryption key is then encrypted using the receiver’s public key and the sender’s authentication certificate is encrypted with the sender’s private key. The encrypted encryption key and the encrypted authentication certificate are sent to the receiver client via the XMPP server. The receiver receives the encrypted encryption key and the encrypted authentication certificate from the sender via the XMPP server and decrypts the authentication certificate using the sender’s public key in order to confirm the authenticity of the sender (by confirming that the decrypted authentication certificate matches the authentication certificate received when the users first exchanged authentication certificates). The receiver can then decrypt the encrypted encryption key with their private key and use this to decrypt the encrypted connection request. The receiver is then able to establish a secure peer-to-peer connection with the sender via a secure DTLS connection using the WebRTC protocol. All voice/video data exchanged via the DTLS connection is encrypted and can only be decrypted by the other client.

The message is only decrypted when the user is viewing the message through the client. The message is re-encrypted 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.

The content of the message can be verified as authentic by making use of hash values. Hash values are numeric values of a fixed length that uniquely identify a piece of data. For this purpose, the hash functions used to generate the hash values from the message data must be collision-resistant, that is that is very hard to find a message which will generate the same hash value. Hash functions for generating hash values from data are known to the person skilled in the art and do not per se form part of the present invention.

The sender will create a hash value of the message both before encryption and after encryption. Each of these hash values will be sent along with the encrypted encryption keys to the receiver client. The receiver client will then generate a hash value of the received encrypted message and compare it against the hash value received from the sender client corresponding to the hash value of the message after encryption.

If the hash values match, then the receiver will proceed to decrypt the message with the encryption key (once decrypted). If the hash values do not match, the receiver client will alert the user that the message has been corrupted. This process allows the receiver to determine if the message it has received is identical to the message that was sent by the sender.

The advantage of this process is that the user will be alerted if for any reason someone has been able to intercept and manipulate the message. An additional benefit of this process is that it will help resolve disputes if for any reason there is a conflict between the sender and receiver regarding the message sent and the message received.

Additionally, accountability may be provided by storing the hash values in a Blockchain.

A Blockchain is form of ledger containing a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data. In a Blockchain, all transactions are authenticated in a decentralised manner by all other users in the Blockchain. Each transaction is added as a block to the Blockchain. As each user has its own record of the Blockchain, it is impossible to amend the block after the transaction has been recorded. The blocks are open for all users to see but these cannot be edited.

This would be useful for dispute resolutions which may occur as there is an unchangeable record of what was sent/received between various parties which is recorded as a hash value of the content and will remain the same on the blockchain. For example, the hash value of the message is recorded on the Blockchain when it is sent. If the message is subsequently modified by the receiver, then the hash value of the message will change. Comparing the hash value of the message with the hash value on the Blockchain would therefore indicate whether any modifications to the message have been made since the message was sent by the sender.

Additionally or alternatively, a Blockchain may be used to store users hash values of users’ public and/or private encryption keys (along with a timestamp indicating the date and time the keys were generated). The public and private encryption keys can then be verified by comparing their hash values with the hash values of the encryption keys stored on the Blockchain. Users are able to backup their public and private encryption keys onto a keychain to enable them to access their encrypted messages on multiple devices. This removes the dependency on a single device. This will also resolve compliance issues faced by enterprises as they will have a backup to be able to access encrypted SMS/emails/files sent and received by all employees/associates.

The client allows users to take a backup of their public/private encryption keys in various ways such as: i. Uploading the keys to a keystore provider which the client has a partnership with; ii. Uploading the keys to a third party keystore provider which the client has no partnership with; iii. Password protecting the public/private encryption keys from the client keychain and moving them into the database, password protecting the database and moving this password protected database file to a) the device storage, b) a cloud storage provided by the client or c) a third-party cloud storage provider; iv. Entering a password which will be used to encrypt the public/private encryption keys and generating a QR code which contains the encrypted data which can only be decrypted by entering the same password.

If the user chooses to upload the public/private encryption keys to a keystore provider which the client has a partnership with the user will be required to first register/create an account with the third party keystore. Registration will include providing the user’s name; email address (verified by OTP); phone number (verified by OTP); password; and security questions and corresponding security answers. Each time the user wants to access the keystore they will be required to enter at least one or more of their email address, password, email OTP, SMS OTP and Security Answers. The user will only be granted access to the keystore if the information provided is correct (i.e. it corresponds to the information provided upon registration). After the user has created their account and logged in they will be able to upload their public/private encryption keys to the keystore.

The client will encrypt the public encryption key using a first random 256-bit AES encryption key. The client will also encrypt the private encryption key using a second random 256-bit AES encryption key. Each 256-bit AES encryption key will then be encrypted using a password entered by the user along with a salt value generated from the user’s email.

A hash value is generated from a combination of the user’s password and email salt value which will determine the location on the server where the encrypted public and private keys will be stored. A hash value is also generated from a combination of the user’s email and password salt value which will determine the location on the server where the encrypted 256-bit AES encryption keys will be stored.

The location of the encrypted data will not be stored on the server. For added security this information will be split between two servers. The client will upload a total of four pieces of information to each server

Server 1 : i. Encrypted public encryption key (P1 )

ii. Location for encrypted public encryption key (P1 )

iii. Encrypted 265-bit AES encryption key for private encryption key (AES2) iv. Location for encrypted 265-bit AES encryption key for private encryption key (AES2)

Server 2: i. Encrypted private encryption key (P2)

ii. Location for encrypted private encryption key (P2)

iii. Encrypted 265-bit AES encryption key for public encryption key (AES1 ) iv. Location for encrypted 265-bit AES encryption key for public encryption key (AES 1 )

A keystore can be used to generate and store public/private keys for a group of individual users (e.g. a group of associates/employees within a company). The process for generating public/private keys for employees is described below.

Firstly, the enterprise administrator (an individual within the company responsible creating user accounts for the keystore) will purchase/register for a keystore account (typically online, using an internet browser). The administrator will provide details of their employees (including their name, email address, email password and mobile phone number) to the keystore interface (e.g. online website). A unique code will then be generated for each employee that is added by the administrator and this is sent to the user’s device. Employees will be informed via email to download and register the client using their unique code.

The user client will generate a temporary pair of public/private encryption key and the temporary public encryption key will be uploaded to the company’s server via secure API. The temporary private encryption key will be stored in a keychain within the client.

Employee data including emails and contacts will not synchronise (from e.g. the third party email service provider to the user’s device) until the user has received their private/public keys from the administrator keystore client.

The user client will be a dummy client with no data and will inform the user that the administrator needs to transfer their public/private encryption key pair before they can use the client

The administrator keystore client will generate a public/private encryption key pair for each employee. The administrator will be able to transfer the public/private encryption key pair to each user either by scanning a QR code or by XMPP

For transfer by QR Code, the Keystore client will encrypt the public/private encryption keys using a password entered by the administrator and create a QR code for every employee which contains their encrypted public/private encryption key pair. The user client can then be used to scan this QR code and enter the password to decrypt and receive their public/private encryption key pair. The user client will then replace the temporary public/private encryption key pair with their actual public/private encryption key pair and the user client will then upload its public encryption key to the company’s server via secure API.

For transfer by XMPP, the Keystore client will encrypt the public/private encryption key pair with the user’s temporary public encryption key. This encrypted encryption key pair will be sent to the user client via XMPP. The user client will decrypt the encrypted encryption key pair using the temporary private encryption key and the user client will then replace the temporary public/private encryption key pair with their actual public/private encryption key pair.

For both transfer by QR Code and XMPP, the user client will then upload its public encryption key to the company’s server via secure API. This system will help to resolve compliance issues faced by companies as they will have a backup to be able to access encrypted SMS/emails/files sent and received by their employees.

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.

The clients communicate with the various servers referred to herein via secure API. All API requests from the client are sent with the parameters listed below: i. D (Data)

ii. K (Key)

iii. U (User ID)

iv. T_dt (Time)

v. A (App ID) - this is a unique ID which is hard coded in the client vi. I (IMEI or unique device ID) - this unique to the device on which the client is installed.

vii. T (Token)

To facilitate secure communication between the client and the server, the server also has associated therewith a pair of RSA encryption keys consisting of a public key and a private key. The server’s private key remains on the server whereas the server’s public keys are hard-coded in the client.

The data is an encrypted JSON which contains the different request parameters encrypted using a random 256-bit AES encryption key. The encryption key is a random 256-bit AES encryption key which is encrypted using the server public key.

The user ID is provided by the server after successful registration (if User ID is not available then the client will send 0 (zero). Time is the current time of the client converted to UTC and encrypted using the user’s private key. The token is an OAuth Token which is saved in secure preference. If the OAuth token has expired then the client will send a“Refresh Token”.

The server response data will be the below: i. D (Data)

ii. K (Key)

iii. T_dt (Time) Again, the data is an encrypted JSON which contains the different response parameters encrypted using a random 256-bit AES encryption key and the key is an AES encryption key which is encrypted using the user’s public key

Request Process

The client will create a random AES 256-bit encryption key and encrypt the request JSON data with this key as D parameter. The client will then encrypt this AES 256- bit encryption key using the server public key as K parameter. The time is the current time of the client converted to UTC and encrypted using the user’s private key. This package of data/parameters are then sent from the client to the server.

Response Process

The server will first validate the OAuth Token. If the Token has expired then the server will reply with an error. The server will validate the time by decrypting data using the user’s public key and if the time is greater than 3 minutes then it will respond with an error. If the time is less than 3 minutes, the server will decrypt the key (K) using the server’s private key and get a decrypted AES encryption key.

The server can then decrypt the encrypted data (D) with this AES key and then forward the parameters to the appropriate API.

The API response will be an encrypted JSON which contains different request parameters encrypted with a random 256-bit AES key.

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 one- time 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

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;

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;

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:

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 message- encryption key to the receiver via the second server.

1 1. 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 16 wherein the message remains encrypted on the receiver when not being displayed to a user device.

18. A method according to any one of claims 1 to 17 further comprising: i) the sender generating a first hash value using a hash function of the message to be sent by the sender; ii) the sender sending the first hash value to the receiver (e.g. via the second server); iii) the receiver receiving the first hash value from the sender (e.g. via the second server) and iii) the receiver generating a second hash value using the hash function of the message received by the receiver; wherein the receiver informs the user if the first hash value does not equal the second hash value (e.g. in the form of a notification that the content of the message has been changed).

19. 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.

20. 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.

21. 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 message- encryption key; and j) the receiver decrypting the encrypted message with the decrypted message- encryption key.

22. 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.

23. 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.

24. A method according to claim 23 wherein the exchange step comprises each device transmitting their public key to the server.

25. A method according to claim 23 or 24 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.

26. A method according to claim 23 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;

27. A method according to any one of claims 23 to 26 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.

28. A method according to any one of claims 23 to 27 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.

29. A method according to claim 28 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.

30. A method according to claim 29 wherein 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.

31. A method according to any one of claims 23 to 30 wherein the message remains encrypted on the receiver device when not being displayed to the user on the device.

32. 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 31.

33. A data carrier (for example, a mobile phone or other portable electronic device) having a computer program according to claim 32 loaded thereon.