GB2584455A - An encryption process - Google Patents

An encryption process Download PDF

Info

Publication number
GB2584455A
GB2584455A GB1907940.9A GB201907940A GB2584455A GB 2584455 A GB2584455 A GB 2584455A GB 201907940 A GB201907940 A GB 201907940A GB 2584455 A GB2584455 A GB 2584455A
Authority
GB
United Kingdom
Prior art keywords
encrypted
encryption
content
server
digital fingerprint
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB1907940.9A
Other versions
GB201907940D0 (en
Inventor
Ramanlal Patel Ajit
Modi Himanshu
Vala Vijay
Thomas Sanal
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Wellness Tech And Media Group Ltd
Original Assignee
Wellness Tech And Media Group Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Wellness Tech And Media Group Ltd filed Critical Wellness Tech And Media Group Ltd
Priority to GB1907940.9A priority Critical patent/GB2584455A/en
Publication of GB201907940D0 publication Critical patent/GB201907940D0/en
Publication of GB2584455A publication Critical patent/GB2584455A/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/562—Static detection
    • G06F21/565—Static detection by checking file integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0827—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving distinctive intermediate devices or communication paths
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/145—Countermeasures against malicious traffic the attack involving the propagation of malware through the network, e.g. viruses, trojans or worms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Virology (AREA)
  • Bioethics (AREA)
  • Storage Device Security (AREA)

Abstract

A method of encrypting content, the method comprising: a) generating a session key; b) encrypting the content with the session key to generate encrypted content; c) c) generating a post-encryption digital fingerprint (hash) of the encrypted content; and d) encrypting the session key and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and post-encryption digital fingerprint in an encrypted state. A corresponding method of decrypting encrypted content is also disclosed comprising: a) receiving the encrypted content, b) receiving an encrypted encryption data file; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted post-encryption digital fingerprint: d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same, decrypting the encrypted content with the session key to access the content. Virus/malware protection is provided by detecting changes made to encrypted content before the content is used (or decrypted). In particular verifying content included in email or SMS messages or other electronic data files or verifying content sent from a transmitter to a receiver or sent/retrieved from storage.

Description

AN ENCRYPTION PROCESS
This invention relates to encryption processes and systems for use in such processes.
Background of the Invention
Digital content 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 the content. Once the content has been encrypted with an encryption key, both the content and the encryption key are sent to the receiver. The receiver can then use the encryption key to decrypt and access the content. However, if the encryption key and encrypted content are both intercepted, an unauthorised third party can decrypt and access the content.
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 encrypted content to a receiver by encrypting the content with the receiver's public key. The encrypted content is then sent to the receiver who can decrypt the content with their own private key. As only the receiver's private key can decrypt the content encrypted with the receiver's public key, even if both the encrypted content and public encryption key are intercepted, an unauthorised third party cannot use the public encryption key to decrypt and view the encrypted content.
Hybrid encryption methods use a combination of both symmetric and asymmetric encryption techniques.
Whilst such encryption techniques can prevent authorised viewing of the encrypted content, either when being transmitted from one device to another or when being stored on a single device, it is still possible for a virus or hack to be inserted to the encrypted content whilst the content remains encrypted. Upon decryption by the user, the virus or malware is then executed. This therefore compromises the security of the encryption system.
Therefore, there exists a need for further and/or improved encryption methods which safeguard against the release of viruses or malware which could corrupt or infect user devices.
In addition, it is possible for the content to be modified at a time after its initial encryption. This may be while the content is encrypted or at a point in time when the content is in a decrypted state. Therefore, there also exists the need for a method to detect changes to content and alert a user when changes have been made.
The Invention It is one object of the invention to provide an improved method of encrypting content (such as email messages, SMS messages or other electronic data files), preferably an improved encryption method which safeguards against attacks by viruses of malware.
Accordingly, in a first aspect the invention provides a method of encrypting content, the method comprising: a) generating a session key; b) encrypting the content with the session key to generate encrypted content; c) generating a post-encryption digital fingerprint of the encrypted content; and d) encrypting the session key and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and post-encryption digital fingerprint in an encrypted state.
The invention also provides a method of decrypting encrypted content, the method comprising: a) receiving the encrypted content; b) receiving an encrypted encryption data file; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same, decrypting the encrypted content with the session key to access the content.
By generating digital fingerprints both after encryption (post-encryption) and before decryption (pre-decryption), it can be detected whether there have been any modifications in the encrypted content, as any differences between the fingerprints would be indicative of a change in content. As a condition for the decryption of the encrypted content is that the digital fingerprints must match, if the content is altered (e.g. by the insertion of a virus or malware) while it is in an encrypted state, the content will not be decrypted and hence the virus will not be released.
Digital fingerprints can also be generated from the unencrypted content. By comparing the digital fingerprint of the content before encryption (pre-encryption) and a digital fingerprint of the content after decryption (post-decryption), it can be verified whether any changes have been made to the content since its initial encryption process (e.g. when the content has been in an unencrypted state).
Accordingly, the invention also provides a method of encrypting content, the method comprising: a) generating a pre-encryption digital fingerprint of the content; b) generating a session key; c) encrypting the content with the session key to generate encrypted content; and d) encrypting the session key and the pre-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and pre-encryption digital fingerprint in an encrypted state.
The invention also provides a method of decrypting encrypted content, the method comprising: a) receiving the encrypted content; b) receiving an encrypted encryption data file; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted pre-encryption digital fingerprint; d) decrypting the encrypted content with the session key to provide the decrypted 35 content; e) generating a post-decryption digital fingerprint of the decrypted content; and f) comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint and providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
These methods provide a way of notifying users whether or not content has been modified since its initial encryption.
Both of these methods can be used in parallel and digital fingerprint generation can therefore take place both before and after encryption and before and after decryption.
Accordingly, the invention also provides a method of encrypting content, the method comprising: a) generating a pre-encryption digital fingerprint of the content; b) generating a session key; c) encrypting the content with the session key to generate encrypted content; d) generating a post-encryption digital fingerprint of the encrypted content; and e) encrypting the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint in an encrypted state.
The invention also provides a method of decrypting encrypted content, the method comprising: a) receiving the encrypted content; b) receiving an encrypted encryption data file; c) opening the encrypted encryption data file and generating a decrypted session key, a decrypted pre-encryption digital fingerprint and a decrypted post-encryption digital fingerprint d) generating a pre-decryption digital fingerprint of the encrypted content; e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same: (i) decrypting the encrypted content with the session key to access the content; (h) generating a post-decryption digital fingerprint of the decrypted content and comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint; and (Hi) providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
The encryption data file can be generated in a number of ways. Firstly, the session key and post-encryption and/or pre-encryption digital fingerprints may separately be encrypted and then combined to form the encryption data file. For example, the session key may be encrypted with an asymmetric encryption key (for example, a user's public key) while the digital fingerprint(s) may be encrypted with the session key. Typically, the digital fingerprint(s) is/are inserted into a JSON file which itself is encrypted with the session key. The separately encrypted session key and digital fingerprint(s) (or more specifically encrypted JSON file containing the digital fingerprint(s)) are combined to form the encryption data file.
When the methods of the invention also involve the transmission of authentication certificates (see below) from one user to another (i.e. from a sender to a receiver), the authentication certificates may themselves be encrypted (e.g. using a user's private key) and be combined with the encrypted session key and digital fingerprint(s) to form the encryption data file.
Accordingly, the step of encrypting the session key and digital fingerprint(s) and forming an encryption data file may comprise: a) encrypting the session key with the user's public key; b) encrypting the digital fingerprint(s) with the session key; and optionally when present c) encrypting the user's authentication certificate with the user's private key.
Similarly, the step of opening the encryption data file and generating a decrypted session key and decrypted digital fingerprint(s) may comprise: a) opening the encryption data file to provide an encrypted session key; an encrypted digital fingerprint(s); and optionally an encrypted authentication certificate; b) optionally decrypting the authentication certificate with a user's public key; c) decrypting the encrypted session key with a user's private key to generate a decrypted session key; and d) decrypting the encrypted digital fingerprint(s) with the decrypted session key to generate decrypted digital fingerprints.
The encryption data file is typically formed in this way when the content is intended to be securely stored and accessed by a single user.
Alternatively, the session key and digital fingerprint(s) can be combined into a single file before encryption. The file containing the session key and digital fingerprint(s) is then encrypted as a whole (for example, using a user's public key) to form the encryption data file. In this case the session key, pre-and post-encryption digital fingerprints, and optionally when present the encrypted authentication certificate (e.g. encrypted with a user's private key) are combined into a single encryption data file. This encryption data file is then encrypted as a whole to generate an encrypted encryption data file.
When a user wishes to decrypt the content, the encrypted encryption data file is decrypted to provide the session key, the pre-and post-encryption digital fingerprints, and optionally the encrypted authentication certificate. By forming and encrypting the encryption data file, the data file (which comprises the session key and digital fingerprints) is secured from unauthorised access.
Accordingly, the step of encryption the session key and digital fingerprint(s) and forming an encryption data file may comprise combining the session key and digital fingerprints (and optionally the encrypted authentication certificate) into a single file and encrypting the file with a user's asymmetric encryption key (e.g. a user's public key) to generate an encrypted encryption data file.
Similarly, the step of opening the encryption data file and generating a decrypted session key and decrypted digital fingerprint(s) may comprise: decrypting the encryption data file with a user's asymmetric key (e.g. a user's private key) to provide a session key and digital fingerprint(s) (and optionally encrypted authentication certificate).
The encryption data file is typically formed in this way when the content is intended to be securely sent from one user (i.e. a sender) to another user (i.e. a receiver).
A digital fingerprint is a string of binary digits that uniquely identifies a data file.
The digital fingerprint is generated by applying a function (i.e. an algorithm) to the data file. Altering the data file (even by only a single character) results in a different digital fingerprint and therefore each unique data file has its own corresponding unique digital fingerprint. Examples of digital fingerprints/digital fingerprinting algorithms include Rabin's algorithm and cryptographic hash functions. Various algorithms are known for generating hash values of data files and examples of such algorithms include the MD5, SHA-1, SHA-2 and SHA-256 algorithms.
For improved accountability, the digital fingerprints may be stored on a blockchain. For example, the pre-encryption and/or post-encryption digital fingerprints may be recorded onto the blockchain when the content is initially encrypted by the user.
Therefore, if the content is subsequently modified (e.g. by another user who has access to the content -either authorised or unauthorised), then the digital fingerprint of the content will be changed. Comparing the digital fingerprint of the content which is stored on the blockchain with a second digital fingerprint which is subsequently generated (e.g. a pre-decryption or post-decryption digital fingerprint) indicates whether there have been any modifications to the content since its initial encryption (again, by either authorised or unauthorised users).
The session key used to encrypt the content may be generated locally on the user's device (e.g. on the sender's device where the content is to be transmitted from a sender to a receiver). The session key may be a randomly generated number of a predetermined length. The session key is typically a symmetric encryption key. In one embodiment, the session 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/content with these encryption keys. The encryption algorithms themselves do not form part of the present invention.
Examples of symmetric encryption algorithms for generating symmetric encryption keys include Advanced Encryption Standard (AES), Blowfish, CASTS, DES, IDEA, RC2, RC4, RC6, Serpent, Triple DES and Twofish. In one embodiment, the symmetric encryption algorithm is AES.
The asymmetric encryption keys are one of a corresponding pair of public and private keys. Examples of asymmetric encryption algorithms for generating such keys include Rivest-Shamir-Adleman (RSA) asymmetric algorithm, Diffe-Hellman, Digital Signature Algorithm (DSA), ElGamal, ECDSA and XTR. In one embodiment, the asymmetric encryption algorithm is RSA.
The methods of the invention are 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 user devices on which the application is installed each comprise or have associated therewith a storage database. The storage database may be used to store content, details of other devices (for example, other users' public keys and/or authentication certificates) and the user's private key.
As an alternative to a mobile phone application, the sender may use a desktop computer or laptop (with a client application installed thereon or with access to the client application via the internet).
The content 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 content 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 content is one or more email messages. When the content is an email message and the email message comprises a body and one or more attachments, digital fingerprints (both pre-encryption and post-encryption) may be generated separately for the email body and each of the one or more attachments. In another embodiment, the content is one or more SMS messages.
In a further embodiment, the content is one or more electronic data files. When the content is 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).
The encryption methods described above can be used both when transmitting content from a sender to a receiver (i.e. between two different devices) and also when storing content on a user's device or user's remote storage system (e.g. a cloud storage system).
Digital fingerprints of the content may be taken before and after transmission of the content from a first device (i.e. a sender's device) to a second device (i.e. a receiver's device). I n this case, by comparing the digital fingerprints prior to decryption on the receiver's device, it can be determined whether the encrypted content has been altered during its transmission.
Accordingly, the invention also provides a method of sending content from a sender to a receiver, the method comprising: a) generating a session key; b) encrypting content with the session key to generate encrypted content; c) generating a post-encryption digital fingerprint of the encrypted content; d) sending the encrypted content to the receiver via a first server; e) encrypting the session key and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and post-encryption digital fingerprint in an encrypted state; and f) sending the encrypted encryption data file to the receiver via a second server.
The invention also provides a method of receiving content from a sender to a receiver, the method comprising: a) receiving encrypted content from a sender from a first server; b) receiving an encrypted encryption data file from the sender from a second server; c) opening the encrypted encryption data file and providing a decrypted session key and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two digital fingerprints are the same, decrypting the encrypted content with the session key to access the content.
As discussed above, as well as or instead of generating a digital fingerprint after encryption of the content, a digital fingerprint of the content prior to encryption can be generated.
Accordingly, the invention also provides a method of sending content from a sender to a receiver, the method comprising: a) generating a pre-encryption digital fingerprint of the content; b) generating a session key; c) encrypting the content with the session key to generate encrypted content; d) sending the encrypted content to the receiver via a first server; e) encrypting the session key and the pre-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and the pre-encryption digital fingerprint in an encrypted state; and f) sending the encrypted encryption data file to the receiver via a second server. 5 The invention also provides a method of receiving content from a sender to a receiver, the method comprising: a) receiving the encrypted content from a sender from a first server; b) receiving an encrypted encryption data file from the sender from a second server; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted pre-encryption digital fingerprint; d) decrypting the encrypted content with the session key to provide the decrypted content; e) generating a post-decryption digital fingerprint of the decrypted content; and f) comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint and providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
As above, digital fingerprint generation can take place both before and after encryption.
Accordingly, the invention also provides a method of sending content from a sender to a receiver, the method comprising: a) generating a pre-encryption digital fingerprint of the content; b) generating a session key; c) encrypting the content with the session key to generate encrypted content; d) generating a post-encryption digital fingerprint of the encrypted content; e) sending the encrypted content to the receiver via a first server; f) encrypting the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint in an encrypted state; and g) sending the encrypted encryption data file to the receiver via a second server.
The invention also provides a method of receiving content from a sender to a receiver: a) receiving the encrypted content from a first server; b) receiving an encrypted encryption data file from a second server; c) opening the encrypted encryption data file and generating a decrypted session key, a decrypted pre-encryption digital fingerprint and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same: (i) decrypting the encrypted content with the session key to access the content; (ii) generating a post-decryption digital fingerprint of the decrypted content and comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint; and (iii) providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
The methods of forming and opening the encryption data file are typically the same as those described above.
Typically the encrypted content and the encryption data file are sent from the sender to the receiver via separate servers. Accordingly, the encrypted content may be sent from the sender to the receiver via a first server and the encryption data file may be sent from the sender to the receiver via a second server.
Likewise, the encrypted content may be received by the received from a first server and the encryption data file may be received by the receiver via a second server.
By sending the encrypted content and the encryption data file to the receiver via two separate channels, should one of the channels become intercepted, the security of the content is not comprised.
References herein to the "sender"/"receiver' 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).
As an alternative to the method of sending/receiving content from a sender to a receiver, the encryption methods of the invention can be used to safeguard against alteration of encrypted content when the content is being stored by the user, either locally on their device or remotely on a storage system, such as a cloud storage system.
Accordingly, the invention also provides a method of storing content, the method comprising: a) generating a session key; b) encrypting content with the session key to generate encrypted content; c) generating a post-encryption digital fingerprint of the encrypted content; d) storing the encrypted content in a first storage location; e) encrypting the session key and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and the post-encryption digital fingerprint in an encrypted state; and f) storing the encrypted encryption data file in a second storage location.
The invention also provides a method of retrieving stored content, the method comprising: a) retrieving encrypted content from a first storage location; b) receiving an encrypted encryption data file from a second storage location; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and pre-decryption digital fingerprints and only if the two second digital fingerprints are the same, decrypting the encrypted content with the session key to access the content.
As discussed above, as well as or instead of generating a digital fingerprint after encryption of the content, a digital fingerprint of the content prior to encryption can be generated.
Accordingly, the invention also provides a method of storing content, the method comprising: a) generating a pre-encryption digital fingerprint of the content; b) generating a session key; c) encrypting the content with the session key to generate encrypted content; d) storing the encrypted content in a first storage location; e) encrypting the session key and the pre-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and the pre-encryption digital fingerprint in an encrypted state; and f) storing the encrypted encryption data file in a second storage location.
The invention also provides a method of retrieving stored content, the method comprising: a) retrieving encrypted content from a first storage location; b) receiving an encrypted encryption data file from a second storage location; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted pre-encryption digital fingerprint; d) decrypting the encrypted content with the session key to provide the decrypted content; e) generating a post-decryption digital fingerprint of the encrypted content; and f) comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint and providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
As in other methods of the invention, digital fingerprint generation can take place both before and after encryption.
Accordingly, the invention also provides a method of storing content, the method comprising: a) generating a pre-encryption digital fingerprint of the content; b) generating a session key; c) encrypting the content with the session key to generate encrypted content; d) generating a post-encryption digital fingerprint of the encrypted content; e) storing the encrypted content in a first storage location; f) encrypting the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint in an encrypted state; and g) storing the encrypted encryption data file in a second storage location.
The invention also provides a method of decrypting encrypted content, the method comprising: a) receiving the encrypted content; b) receiving an encrypted encryption data file; c) opening the encrypted encryption data file and generating a decrypted session key, a decrypted pre-encryption digital fingerprint and a decrypted post-encryption digital fingerprint d) generating a pre-decryption digital fingerprint of the encrypted content; e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same: (i) decrypting the encrypted content with the session key to access the content; (ii) generating a post-decryption digital fingerprint of the decrypted content and comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint; and (iii) providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
Again, the methods of forming and opening the encryption data file are typically the same as those described above.
Whilst the first and second storage locations may be the same, they are preferably different. Therefore, if the security of one of the storage locations becomes compromised (and either the encrypted content or encrypted encryption data file is made available to an unauthorised party), the encrypted content cannot be decrypted.
The first and second storage locations may be independently selected from storage on the user's device, a storage device connectable to the user's device (such as a memory stick or memory card, e.g. USB memory stick or SD card), and a cloud storage system.
Use of the Encryption Process in Messaging Applications Further optional features and embodiments of the invention, where the encryption process is used to encrypt content (also referred to as a "message") for sending from a sender to a receiver are detailed below.
In the methods of the invention of sending content from a sender to a receiver, both the sender and receiver typically each have a corresponding public key and private key and each have access to the other's public key.
Prior to sending/receiving the content, 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 content (i.e. 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 content, 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 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 encryption data file, which contains the session key and digital fingerprint(s), is typically encrypted using the receiver's public key and then subsequently decrypted by the receiver using their private key.
Alternatively, the encryption data file may itself be encrypted using double asymmetric encryption. For example, when sending content, the encryption data file may first be encrypted with the receiver's public key followed by subsequent encryption with the sender's private key. In this case, when receiving the secure message, the encryption data file may then be first decrypted with the sender's public key. This confirms the authenticity of the sender. The encryption data file (which has been partially decrypted) can then be decrypted with the receiver's private key. The session key obtained from the decrypted encryption data file can then be used to decrypt the content (provided that the first and second digital fingerprints match) received from the first server.
The encrypted encryption data file may be 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 encryption data file 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 encryption data file 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 content further comprises: i) sending the encrypted encryption data file to the second server; fi) 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 encryption data file 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 encryption data file is available for retrieval from the second server; ii) the receiver retrieving the encrypted encryption data file 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 data file may include an encrypted authentication certificate 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 included in the encryption data file, 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 content may further comprise, following sending the encrypted content to the first server, receiving a unique content ID from the first server. This unique content ID may then be sent with or as part of the encrypted encryption data file to the receiver via the second server. Accordingly, in the methods described above the encrypted encryption data file may be sent/received in combination with a unique content ID. Alternatively, the encryption data file may comprise the session key, digital fingerprint(s), optionally the encrypted authentication certificate and the unique content ID. As the encrypted content and encrypted encryption data file are sent separately to the receiver, the unique content ID allows the receiver to match each content it receives to an encrypted encryption data file that it receives. This allows the receiver to correctly use the session key and digital fingerprint(s) when decrypting the content.
The method of receiving content therefore also may further comprise receiving content with a unique content ID from the first server and receiving an encrypted encryption data file with or comprising the same unique content ID from the second server to allow the encrypted content to be matched to the encrypted encryption data file. In this way, the receiver can use a single encrypted encryption data file to decrypt a single piece of encrypted content.
The content typically remains encrypted on the receiver's device when not being displayed to the user of the device. In this embodiment, the content is only decrypted when the user is accessing the content (e.g. reading the email/SMS) 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 content, even if it is offline and not connected to any of the servers.
When the user attempts to send content 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 encrypted content as described above. The sender device may then allow the user to send the content unencrypted or send the encrypted content 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 content along with a request for the receiver device to register with the second server, the encrypted content and the encryption data file may be encrypted, for example with the sender's public key, and temporarily stored in the sender device's storage until the receiver has registered with the server (as described herein).
Accordingly, the invention also provides a method of sending content, the method comprising: i) encrypting the content with a session key to generate encrypted content; ii) generating a post-encryption digital fingerprint of the encrypted content; ii) sending the encrypted content to the receiver via a first server along with a request for the receiver to register with a third server; iii) receiving a unique content ID from the first server; iv) combining the session key and the post-encryption digital fingerprint into a single file and encrypting the file with the sender's public key to provide a first encrypted encryption data file; v) storing the first encrypted encryption data file (typically in combination with the unique content 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 encryption data file with the sender's private key to regenerate the encryption data file; viii) reencrypting the encryption data file with the receiver's public key to generate a second encrypted encryption data file; and ix) sending the second encrypted encryption data file to the receiver (typically with the unique content ID), for example via a second server.
The method may also comprise encrypting the sender's authentication certificate (for example, with the sender's private key) and sending the encrypted authentication certificate to the receiver, for example via a second server (e.g. within the encryption data file). The method may also comprise generating a pre-encryption digital fingerprint, as described herein.
The invention also provides a corresponding method of receiving content and request to join the second server, the method comprising: i) receiving encrypted content 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 encryption data file key from the sender via a second server; iv) decrypting the encrypted encryption data file with the receiver's private key to generating a session key and a post-encryption digital fingerprint; v) generating a pre-decryption digital fingerprint of the encrypted content; and v) decrypting the encrypted content with the decrypted session key, provided that the post-encryption digital fingerprint and pre-decryption digital fingerprints are the same.
Again, this method may also include the generation and comparison of pre-encryption and post-decryption digital fingerprints as described herein.
The method may also comprise receiving an encrypted authentication certificate from the second server (e.g. within the encryption data file) and decrypting the encrypted authentication certificate (for example, with the sender's public 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.
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 content 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 session key; e) the sender generating a pre-encryption digital fingerprint of the content; f) the sender encrypting the content with the session key to generate an encrypted message; generating a post-encryption digital fingerprint of the encrypted content; and sending the encrypted content to the receiver via the first server; g) the sender together encrypting the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint (and optionally the sender's authentication certificate encrypted with the sender's private key) with the receiver's public key to form an encrypted encryption data file and sending the encrypted encryption data file to the receiver via a second server; h) the receiver receiving the encrypted content from the sender via the first server (sent in step f)); i) the receiver receiving the encrypted encryption data file from the sender via the second server (sent in step g)); j) the receiver decrypting the encrypted encryption with the receiver's private key to provide the session key and pre-encryption and post-encryption digital fingerprints (and optionally an encrypted authentication certificate); k) the receiver optionally decrypting the encrypted authentication certificate with the sender's public key in order to confirm authenticity of the sender; I) the receiver generating a pre-decryption digital fingerprint of the encrypted content (received in step h); and m) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same: (i) decrypting the encrypted content with the session key to access the content; (H) generating a post-decryption digital fingerprint of the decrypted content and comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint; and (hi) providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
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 data file to the received device via the second server, wherein the encryption data file comprises a session key used to encrypt the content in an encrypted form and one or more digital fingerprints of the content (either before or after encryption).
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.
The invention also provides a system comprising a user device, a first storage location and a second storage location, wherein the user device is programmed to be capable of sending and receiving encrypted content to/from the first storage location and sending and receiving an encryption data file comprising one or more of: (i) an encrypted session key used to encrypt the content; (H) a digital fingerprint of the unencrypted content and/or a digital fingerprint of the encrypted content; and optionally (iii) an encrypted authentication certificate to/from a second storage location.
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 and 3B are schematic diagrams showing a first encryption process and process of generating the encrypted message and encryption data file on the sender's device.
Figure 4 is a schematic diagram showing the process of transferring the encryption data file from a sender to a receiver.
Figures 5A and 5B are schematic diagrams showing the decryption process that takes place on the receiver's device.
Figure 6 is a schematic diagram showing the process of "making friends" in the second aspect of the invention.
Figure 7 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.
Figures 8A, 8B and 8C are schematic diagrams showing an encryption process according to a second embodiment of the invention.
Figure 9 is a schematic diagram showing a decryption process according to the second embodiment 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 20 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.
Description of An Embodiment of the Present Invention 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 may be or may be 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 first generates a hash value of the message prior to encryption (Figure 3A, Step 2). The hash value is generated using the SHA-256 ("Secure Hash Algorithm"). When the content is an email messaging comprising an email body and attachments, separate hash values are generated for the body and each of the attachments.
The client then encrypts the message (including any attachments) (Figure 3A, Step 3) with a unique 256-bit AES key generated by the client (previously generated in Figure 3A, Step 1). 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. A hash value of the encrypted message is also generated using the SHA-256 ("Secure Hash Algorithm") algorithm (Figure 3A, Step 4).
The encrypted message is then sent to the third-party service provider server and the client receives a unique message ID which corresponds to the message.
Separately, the sender's authentication certificate is encrypted with the sender's private key (Figure 3A, Step 5).
The two hash values (the one generated prior to encryption of the message and the one generated after encryption of the message) are added to a JSON file (Figure 3B, Step 6). This JSON file along with the 256-AES key and the encrypted authentication certificate are combined into a single file, referred to as an encryption data file. The encryption data file is then encrypted using the receiver's public key (Figure 3B, Step 7).
The encryption data file (containing the 256-AES key, hash values and 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).
The transmission of the encrypted message and encryption data file is shown in Figure 4.
The sender sends the encryption data file to the XMPP server (Figure 4, Step 1). The sender also sends the encrypted message to the third party service provider server (Figure 4, Step 2). The XMPP then signals to the FCM server that it has received the encryption data file from the sender (Figure 4, Step 3) and the FCM Server sends an FCM message to the receiver to inform it that the encryption data file is available on the XMPP server (Figure 4, Step 4). The receiver can then log into the XMPP server and retrieve the encryption data file from the XMPP server (Figure 4, Steps 5 and 6). The receiver also in parallel receives a message from the third party service provider server (Figure 4, Step 7) and can use the encryption data file obtained from the XMPP server to decrypt the encrypted message (Figure 4, Step 8), as detailed below.
Once the receiver has received both the encrypted message with its unique message ID and from the third-party service provider and the encryption data file (along with the unique message ID) from the secure server (Figure 5A, Steps 1 and 2), the receiver can then decrypt the message.
Firstly, the receiver decrypts the encrypted authentication certificate with the sender's public encryption key (Figure 5A, Step 3). 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. 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) (Figure 5A, Step 4).
To view the message, the receiver then decrypts the encrypted encryption data file with receiver's private key to provide the 256-AES key and the JSON file containing the two hash values. The receiver then generates a hash value of the encrypted message received (using the same SHA-256 algorithm as used by the sender) to form a further hash value (Figure 5B, Step 5). The receiver then compares the hash value received from the sender and the hash value locally generated on the receiver (Figure 5B, Step 6).
If the hash values match, the receiver can subsequently use the decrypted 256-bit AES encryption key to decrypt the message received via the third-party service provider. Alternatively, if the hash values do not match, the encrypted message is not decrypted. Any modifications to the content since being sent by the sender will result in the hash value generated by the receiver differing from the hash value generated by the sender. Therefore, if the content has been modified to include a virus or a hack, the different hash values will indicate to the receiver that the content is unsafe to open and will not decrypt the encrypted message, which may release the virus or hack onto the receiver's device.
In addition, once the message has been decrypted, a further hash value of the decrypted message can be generated. By comparing this hash value with the other hash value received from the sender (the hash value that was generated before the message was encrypted), it can be determined whether any modifications to the content have been made.
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.
As described herein, the content of the messages is be verified 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.
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 (AES1) 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 0Auth Token which is saved in secure preference. If the 0Auth token has expired then the client will send a "Refresh Token".
The server response data will be the below: i. D (Data) 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.
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 7). 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 7, 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 7, Step 2). The token is encrypted with the client's private key (Figure 7, Step 3) and is sent to the secure server via secure API along with the request for data (Figure 7, 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 7, Step 5) and the authenticity of the request for data is validated (Figure 7, 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 7, 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.
Secure Storage The methods of the present invention also provide methods of securely storing data. Accordingly, a further embodiment of the invention where a user wishes to securely store data is described below with reference to Figures 8A, 8B, 8C and 9.
When one user wishes to securely store content (e.g. either locally on their device or remotely via a cloud storage system), the client first generating a hash value of the message prior to encryption (Figure 8A, Step 2). The hash value is generated using the SHA-256 ("Secure Hash Algorithm"). The client then encrypts the content (including any attachments) (Figure 8A, Step 3) with a unique 256-bit AES key generated by the client (previously generated in Figure 8A, Step 1). A hash value of the encrypted message is also generated using the SHA-256 ("Secure Hash Algorithm") algorithm (Figure 8A, Step 4).
Once the second hash value has been generated, the encrypted content can then be stored by the client, either locally on the user's device or remotely via a cloud storage service. As an alternative to being locally stored on the user's device, the encrypted content can also be transferred to a storage device which is removably connected to the user's device (e.g. a USB stick or SD memory card).
The 256-AES key used to encrypt the message is itself encrypted with the user public key (Figure 8A, Step 5) and the user's authentication certificate is encrypted with the user's private key (Figure 8A, Step 6).
The two hash values (the one generated prior to encryption of the message and the one generated after encryption of the message) are added to a JSON file (Figure 8B, Step 7) and are encrypted using the 256-AES key used to encrypt the content (Figure 8B, Step 8).
The encrypted unique 256-bit AES key, encrypted authentication certificate and the encrypted JSON file containing the two hash values are combined to form a data file (Figure 8C, Steps 9 and 10). This encryption data file can again be stored on the user's device or backed-up remotely to a cloud storage service (preferably a different cloud storage service to the one used to store the encrypted content).
With the encrypted content and encryption data file both stored in an encrypted state and separately from one another, even if the security of one of the storage locations is compromised, an unauthorised user is unable to access the encrypted content.
When the user wishes to access the content, the client retrieves the encrypted content and the encryption data file from their respectively storage locations. The encrypted 256-AES key and encrypted JSON file containing the hash values is retrieved from the encryption data file. The encrypted 256-AES key is decrypted using the user's private key (Figure 9, Step 1). The JSON file containing the hash values can then be decrypted using the decrypted 256-AES key (Figure 9, Step 2).
Prior to decryption of the content with the 256-AES key, the client generates a hash value of the encrypted content as received from the storage location (Figure 9, Step 3). This hash value is then compared with the hash value that was generated prior to storage of the encrypted content (Figure 9, Step 4). Only if the two hash values match does the client decrypt the encrypted content with the 256-AES. The advantages associated with this are described above. Once the encrypted content has been decrypted, a further hash value is generated based on the decrypted content. Again, this hash value is compared with the one generated prior to encryption of the content. By comparing these two hash values, it can be determined whether the contents of the content has been altered since the encryption took place.
It will be readily understood that other features of the method described in the embodiments described above where encrypted content is sent from a sender to a receiver may also be used to the methods of securing storing content.
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 (25)

  1. CLAIMS1. A method of encrypting content, the method comprising: a) generating a session key; b) encrypting the content with the session key to generate encrypted content; c) generating a post-encryption digital fingerprint of the encrypted content; and d) encrypting the session key and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and post-encryption digital fingerprint in an encrypted state.
  2. 2. A method according to claim 1 further comprising: generating a pre-encryption digital fingerprint of the content prior to encrypting the content with the session key; and encrypting the pre-encryption digital fingerprint with the session key and including the pre-encryption digital fingerprint in the encrypted encryption data file.
  3. 3. A method of decrypting encrypted content, the method comprising: a) receiving the encrypted content; b) receiving an encrypted encryption data file; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same, decrypting the encrypted content with the session key to access the content.
  4. 4. A method according to claim 3 wherein opening the encrypted encryption data file provides a decrypted session key, a decrypted post-encryption digital fingerprint and a decrypted pre-encryption digital fingerprint, the method further comprising: generating a post-decryption digital fingerprint of the decrypted content and comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint and providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
  5. 5. A method of sending content from a sender to a receiver, the method comprising: a) generating a session key; b) encrypting content with the session key to generate encrypted content; c) generating a post-encryption digital fingerprint of the encrypted content; d) sending the encrypted content to the receiver via a first server; e) encrypting the session key and the past-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and post-encryption digital fingerprint in an encrypted state; and f) sending the encrypted encryption data file to the receiver via a second server.
  6. 6. A method of receiving content from a sender to a receiver, the method comprising: a) receiving encrypted content from a sender from a first server; b) receiving an encrypted encryption data file from the sender from a second server; c) opening the encrypted encryption data file and providing a decrypted session key and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two digital fingerprints are the same, decrypting the encrypted content with the session key to access the content.
  7. 7. A method according to claim 5 or claim 6 wherein both the sender and receiver each have a corresponding public key and private key and the method further comprises, prior to sending/receiving content, the sender/receiver transmitting their public key to a third server.
  8. 8. A method according to claim 7 wherein the method further comprises the sender/receiver retrieving the receiver's/sender's public key respectively from the third server.
  9. 9. A method according to claim 5 or claim 6, the method further comprising a process of exchanging public keys between a sender and a receiver, the process of exchanging public keys comprising: i) the sender and the receiver each generating a pair of corresponding public and private keys; ii) the sender and/or receiver transmitting their public key(s) to a third server; and iii) the sender retrieving the receiver's public key from the third server and/or the receiver retrieving the sender's public key from the third server.
  10. 10. A method according to any one of claims 5 to 9 wherein the first server is a third-party service provider server, for example an SMS service provider server or an email service provider server.
  11. 11. A method according to claim 5 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.
  12. 12. A method according to any one of claim 5 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.
  13. 13. A method according to claim 6 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.
  14. 14. A method according to any one of claims 5 to 13 wherein the message remains encrypted on the receiver when not being displayed to a user device.
  15. 15. A method of transmitting content 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 session key; e) the sender generating a pre-encryption digital fingerprint of the content; f) the sender encrypting the content with the session key to generate an encrypted message; generating a post-encryption digital fingerprint of the encrypted content; and sending the encrypted content to the receiver via the first server; g) the sender together encrypting the session key, the pre-encryption digital fingerprint and the post-encryption digital fingerprint (and optionally the senders authentication certificate encrypted with the sender's private key) with the receiver's public key to form an encrypted encryption data file and sending the encrypted encryption data file to the receiver via a second server; h) the receiver receiving the encrypted content from the sender via the first server (sent in step f)); i) the receiver receiving the encrypted encryption data file from the sender via the second server (sent in step g)); j) the receiver decrypting the encrypted encryption with the receiver's private key to provide the session key and pre-encryption and post-encryption digital fingerprints (and optionally an encrypted authentication certificate); k) the receiver optionally decrypting the encrypted authentication certificate with the sender's public key in order to confirm authenticity of the sender; I) the receiver generating a pre-decryption digital fingerprint of the encrypted content (received in step h); and m) comparing the post-encryption digital fingerprint and the pre-decryption digital fingerprints and only if the two fingerprints are the same: (i) decrypting the encrypted content with the session key to access the content; (H) generating a post-decryption digital fingerprint of the decrypted content and comparing the pre-encryption digital fingerprint and post-decryption digital fingerprint; and (hi) providing a notification if the pre-encryption digital fingerprint and post-decryption digital fingerprint are different.
  16. 16. A method of storing content, the method comprising: a) generating a session key; b) encrypting content with the session key to generate encrypted content; c) generating a post-encryption digital fingerprint of the encrypted content; d) storing the encrypted content in a first storage location; e) encrypting the session key and the post-encryption digital fingerprint and forming an encrypted encryption data file containing the session key and the post-encryption digital fingerprint in an encrypted state; and f) storing the encrypted encryption data file in a second storage location. 10
  17. 17. A method of retrieving stored content, the method comprising: a) retrieving encrypted content from a first storage location; b) receiving an encrypted encryption data file from a second storage location; c) opening the encrypted encryption data file and generating a decrypted session key and a decrypted post-encryption digital fingerprint; d) generating a pre-decryption digital fingerprint of the encrypted content; and e) comparing the post-encryption digital fingerprint and pre-decryption digital fingerprints and only if the two second digital fingerprints are the same, decrypting the encrypted content with the session key to access the content.
  18. 18. A method according to any one of claims 1 to 17 wherein the step of encryption the session key and digital fingerprint(s) and forming an encryption data file comprises combining the session key and digital fingerprints into a single file and encrypting the file with a user's asymmetric encryption key (e.g. a user's public key) to generate an encrypted encryption data file.
  19. 19. A method according to any one of claims 1 to 18 wherein the step of opening the encryption data file and generating a decrypted session key and decrypted digital fingerprint(s) comprises: decrypting the encryption data file with a user's asymmetric key (e.g. a user's private key) to provide a session key and digital fingerprint(s).
  20. 20. A method according to any one of claims 1 to 17 wherein the step of encrypting the session key and digital fingerprint(s) and forming an encryption data file comprises: d) encrypting the session key with the user's public key; e) encrypting the digital fingerprint(s) with the session key; and optionally when present f) encrypting the user's authentication certificate with the user's private key.
  21. 21. A method according to any one of claims 1 to 18 wherein the step of opening the encryption data file and generating a decrypted session key and decrypted digital fingerprint(s) comprises: e) opening the encryption data file to provide an encrypted session key; an encrypted digital fingerprint(s); and optionally an encrypted authentication certificate; f) optionally decrypting the authentication certificate with a user's public key; g) decrypting the encrypted session key with a user's private key to generate a decrypted session key; and h) decrypting the encrypted digital fingerprint(s) with the decrypted session key to generate decrypted digital fingerprints.
  22. 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 data file to the received device via the second server, wherein the encryption data file comprises a session key used to encrypt the content in an encrypted form and one or more digital fingerprints of the content (either before or after encryption).
  23. 23. A system comprising a user device, a first storage location and a second storage location, wherein the user device is programmed to be capable of sending and receiving encrypted content to/from the first storage location and sending and receiving an encryption data file comprising one or more of: (i) an encrypted session key used to encrypt the content; (ii) a digital fingerprint of the unencrypted content and/or a digital fingerprint of the encrypted content; and optionally (iii) an encrypted authentication certificate to/from a second storage location.
  24. 24. 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 21).
  25. 25. A data carrier (for example, a mobile phone or other portable electronic device) having a computer program according to claim 24 loaded thereon.
GB1907940.9A 2019-06-04 2019-06-04 An encryption process Withdrawn GB2584455A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB1907940.9A GB2584455A (en) 2019-06-04 2019-06-04 An encryption process

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB1907940.9A GB2584455A (en) 2019-06-04 2019-06-04 An encryption process

Publications (2)

Publication Number Publication Date
GB201907940D0 GB201907940D0 (en) 2019-07-17
GB2584455A true GB2584455A (en) 2020-12-09

Family

ID=67385971

Family Applications (1)

Application Number Title Priority Date Filing Date
GB1907940.9A Withdrawn GB2584455A (en) 2019-06-04 2019-06-04 An encryption process

Country Status (1)

Country Link
GB (1) GB2584455A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210173950A1 (en) * 2019-12-06 2021-06-10 TEEware Co., Ltd. Data sharing between trusted execution environments
EP4040754A1 (en) * 2021-02-05 2022-08-10 Fujitsu Limited Electronic messaging security and authentication
IT202100010241A1 (en) 2021-04-22 2022-10-22 Alosys Communications S R L CONFIDENTIAL SECURE EXCHANGE METHOD AND SYSTEM OF DIGITAL CONTENT
US20220343925A1 (en) * 2021-04-22 2022-10-27 Xandrie SA System and method for encoding audio data

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112564893B (en) * 2020-10-22 2023-02-03 北京芯盾集团有限公司 Key transmission method combining circuit domain and IP domain

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003007570A1 (en) * 2001-07-10 2003-01-23 Research In Motion Limited System and method for secure message key caching in a mobile communication device
US6760752B1 (en) * 1999-06-28 2004-07-06 Zix Corporation Secure transmission system
US20050198170A1 (en) * 2003-12-12 2005-09-08 Lemay Michael Secure electronic message transport protocol
US20190074968A1 (en) * 2017-09-06 2019-03-07 Alibaba Group Holding Limited Method, apparatus and system for data encryption and decryption

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6760752B1 (en) * 1999-06-28 2004-07-06 Zix Corporation Secure transmission system
WO2003007570A1 (en) * 2001-07-10 2003-01-23 Research In Motion Limited System and method for secure message key caching in a mobile communication device
US20050198170A1 (en) * 2003-12-12 2005-09-08 Lemay Michael Secure electronic message transport protocol
US20190074968A1 (en) * 2017-09-06 2019-03-07 Alibaba Group Holding Limited Method, apparatus and system for data encryption and decryption

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210173950A1 (en) * 2019-12-06 2021-06-10 TEEware Co., Ltd. Data sharing between trusted execution environments
EP4040754A1 (en) * 2021-02-05 2022-08-10 Fujitsu Limited Electronic messaging security and authentication
IT202100010241A1 (en) 2021-04-22 2022-10-22 Alosys Communications S R L CONFIDENTIAL SECURE EXCHANGE METHOD AND SYSTEM OF DIGITAL CONTENT
US20220343925A1 (en) * 2021-04-22 2022-10-27 Xandrie SA System and method for encoding audio data

Also Published As

Publication number Publication date
GB201907940D0 (en) 2019-07-17

Similar Documents

Publication Publication Date Title
US11647007B2 (en) Systems and methods for smartkey information management
WO2019110574A1 (en) Methods of secure communication
US9639711B2 (en) Systems and methods for data verification and replay prevention
EP3631653B1 (en) Encryption of cloud-based data
US11329962B2 (en) Pluggable cipher suite negotiation
CN106104562B (en) System and method for securely storing and recovering confidential data
EP1678666B1 (en) Storage and authentication of data transactions
US9973481B1 (en) Envelope-based encryption method
GB2584455A (en) An encryption process
US11902262B2 (en) System and method for encryption, storage and transmission of digital information
CN112671735B (en) Data encryption sharing system and method based on block chain and re-encryption
WO2015004327A1 (en) Method and device for file encryption

Legal Events

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