End-to-end encryption with roaming functionality

Abstract

A system and method related to end-to-end encryption. By storing an encrypted private key on the server, encrypted data stored on or transmitted through the server can be accessed from any number of authenticated client devices. The encrypted data can only be decrypted by a decrypted version of the encrypted private key. The encrypted private key cannot be decrypted by the server, and can only be decrypted using user-provided credentials (e.g., user-provided passwords / passwords). To allow a user to access encrypted data, a client device used by the user downloads an encrypted private key with the encrypted data. The encrypted private key is then decrypted using credentials provided by the user, and the decrypted private key is used to decrypt the downloaded encrypted data. The decrypted private key does not leave the client device all the time and is also not used by the server all the time.

Description

Technical Field

[0001] The present invention relates to cryptography and secure communications. More particularly, the present invention relates to systems and methods for providing end-to-end encryption for multiple clients while preventing a server from accessing stored encrypted communications. Background Art

[0002] The digital and communications revolution of the past two decades has highlighted not only the centrality of communications in the modern world, but also the need for privacy. While we can now digitally converse with almost anyone in the world at our leisure, there is no guarantee that our communications are secure from eavesdropping. To this end, end-to-end encryption was designed to allow users to securely communicate with each other digitally. Communications are encrypted and only decrypted at the user's client device. In this communication scheme, a public-private key pair is used, where the transmitting user encrypts the communication at his client device using the public key. The receiving user then receives the encrypted communication and decrypts it at his client device using his private key.

[0003] However, while End-to-End Encryption (E2EE) is useful, current E2EE systems have a significant flaw. The private keys used for end-to-end encryption are typically generated and stored only at one user endpoint on the client side. Other endpoints used by the same customer do not have access to the private key and therefore cannot decrypt any server-side stored or relayed data encrypted using the public key paired with the private key. This can cause problems for users if they need to switch endpoints (i.e., from a mobile device to a workstation or to replace a lost device, etc.) because they will lose the ability to read server-stored data and cause ongoing communications to be interrupted. If the E2EE private key could be stored on the server side, this would allow new and existing endpoints belonging to that customer to share the private key, but unless this can be done in a secure manner, it would defeat the entire purpose of using E2EE because the operator of the system can simply reset the account password to access old and new client data. Even if the client encrypts the private key on the client side with the account password before storing the result on the server side, it is still vulnerable because the password can still be intercepted on the server side when it is used via the TLS password during authentication.

[0004]

[0006] For the reasons stated above, there is a need for systems and methods that allow secure E2EE communications and also allow users to securely switch client devices or endpoint devices without losing access to their secure communications. Summary of the invention

[0005] The present invention provides systems and methods related to end-to-end encryption. By storing an encrypted private key on a server, encrypted data stored on or transmitted through a server can be accessed from any number of authenticated client devices. The encrypted data can only be decrypted by a decrypted version of the encrypted private key. The encrypted private key cannot be decrypted by the server and can only be decrypted using credentials provided by the user (e.g., a password / password provided by the user). In order for the user to access the encrypted data, the client device used by the user downloads the encrypted private key along with the encrypted data. The encrypted private key is then decrypted using the credentials provided by the user, and the decrypted private key is used to decrypt the downloaded encrypted data. The decrypted private key never leaves the client device and is never used by the server.

[0006] In a first aspect, the present invention provides a method for accessing encrypted data using a client device, the encrypted data being transmitted from a server to the client device, the method comprising: - undergoing a login and authentication process, thereby authenticating the user and the client device to the server, the login and authentication process involving a user first password; - receiving, at the device, an encrypted private key from the server; - decrypting the encrypted private key at the client device using a private key decryption key, the private key decryption key being obtained from a user second password and from at least one user identification element; - receiving said encrypted data from said server; - decrypting the encrypted data using the decrypted private key; in - Only the user can obtain the user's first password and the user's second password; - the encrypted private key cannot be decrypted by the server; - the encrypted private key can only be decrypted using the private key decryption key; - The decrypted private key is only ever used by the client device.

[0007] In a second aspect, the present invention provides a method for accessing encrypted data via a server, the encrypted data being transmitted from the server to a client device, the method comprising: - authenticating the user and the client device to the server; - at the client device, receiving an encrypted private key from the server, the encrypted private key being pre-stored on the server by the user; - decrypting the encrypted private key at the client device using a private key decryption key to obtain a decrypted private key, the private key decryption key being obtained from the credentials provided by the user; - receiving said encrypted data from said server; - decrypting the encrypted data using the decrypted private key; in - the encrypted private key cannot be decrypted by the server; - the encrypted private key can only be decrypted using the private key decryption key; - The decrypted private key is only ever used by the client device.

[0008] In another aspect, the present invention provides a computer-readable medium having computer-readable and computer-executable code encoded thereon, which when executed implements a method of accessing encrypted data through a server, the encrypted data being transmitted from the server to a client device, the method comprising: - authenticating the user and the client device to the server; - at the client device, receiving an encrypted private key from the server, the encrypted private key being pre-stored on the server by the user; - decrypting the encrypted private key at the client device using a private key decryption key to obtain a decrypted private key, the private key decryption key being obtained from the credentials provided by the user; - receiving said encrypted data from said server; - decrypting the encrypted data using the decrypted private key; in - the encrypted private key cannot be decrypted by the server; - the encrypted private key can only be decrypted using the private key decryption key; - The decrypted private key is only ever used by the client device. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Embodiments of the present invention will now be described with reference to the following drawings, in which like reference numerals in different drawings represent like elements, and in which: Figure 1 is a block diagram of an environment in which the present invention may be practiced; Figure 2 shows a block diagram illustrating components used in one embodiment of the present invention; Figure 3 is a block diagram illustrating a communication system implementing one aspect of the present invention; and Figure 4 is a flow chart detailing the steps of another aspect of the present invention. DETAILED DESCRIPTION

[0010] refer to Figure 1, presents a block diagram of an environment in which the present invention may be practiced. In this case, a user 10 is using a client device 20 communicating with a server 30. The user and client device have logged in and been authenticated, the user has uploaded encrypted data 40 to the server 30 and wishes to access this stored data using E2EE. As described above, while this is possible using the client device 20, attempting to do so from another client device 20A may be difficult using current technology.

[0011] Reference Figure 2 , showing one aspect of the present invention. In the present invention, the user 10 can access the encrypted data 40 from the client device 20A by having the client device 20A authenticated and logged into the server 30. Then, the user 10 downloads the encrypted private key 50 previously stored on the server 30. The encrypted data 40 can only be decrypted by the decrypted version of the encrypted private key 50, and the encrypted private key 50 can only be decrypted by the client device 20A using a unique password / decryption password from the user. Therefore, the user downloads the encrypted private key 50 to the client device 20A, decrypts the encrypted private key on the client device 20A, and then downloads the encrypted data 40. The encrypted data 40 can then be decrypted using the decrypted private key 50A. It should be noted that the server 30 does not have the ability to decrypt the encrypted data 40 or the encrypted private key 50 or cannot decrypt the encrypted data 40 or the encrypted private key 50. Similarly, the decrypted version of the private key 50A never leaves the client device 20A or the client device 20. This ensures that the server 30 cannot access the encrypted data 40.

[0012] The above aspects of the present invention allow a user to use E2EE on multiple client devices while ensuring that the server (or any other potential eavesdropper) cannot access the stored encrypted data.

[0013] Various aspects of the present invention may also be used to ensure E2EE when different users communicate with an intermediate server via a communication medium. Figure 3, this aspect of the present invention is shown in a block diagram. For this scenario, a first user 100 operates a first client device 110 to access a first server 120. Stored in the first server 120 is first encrypted data 130 encrypted by a second client device 150 operated by a second user 160 using the first user's public key 140. Assuming that the first user 100 has been authenticated and logged into the first server 120, the first user can download the first encrypted data 130 and the first encrypted private key 170 to the first client device 110. The user then decrypts the first encrypted private key 170 to obtain a decrypted private key 170A on the first client device 110. The decrypted private key 170A corresponds to the first user's public key 140 and can therefore be used to decrypt the downloaded first encrypted data 130. Therefore, the first user 100 can decrypt the first encrypted data 130 using the decrypted private key 170A on the first client device 110. Since the decrypted private key 170A never leaves the first client device 110, and only the decrypted private key 170A is the only key that can decrypt the first encrypted data 130, the first server 120 cannot access the data in the first encrypted data 30. It should be clear that the first encrypted private key 170 is only decrypted with a password or decryption key that only the first user 100 can provide. This ensures that no other components in the communication system (and other users of the communication system) can decrypt the first encrypted private key 170. Therefore, no user or component of the system can access or decrypt the first encrypted data 130 without the help of the first user.

[0014] On the other side of the communication system, the second user 160 also has a corresponding public key 180, which the first user 100 can use to encrypt data for the second user. The second encrypted data 190 encrypted using the public key 180 is sent and stored on the second server 200. The second user 160, who is also authenticated and logged into the second server 200 by the second client device 150, can access the second encrypted data 190 by downloading the second encrypted data 190 and the second encrypted private key 210. The second encrypted private key 210 can be downloaded to the second client device 150 and decrypted into a second decrypted private key 210A. The second decrypted private key 210A corresponds to the public key 180 and can be used to decrypt the second encrypted data 190. The second decrypted private key 210A cannot be decrypted without assistance or a password or key from the second user 160. Therefore, as with the first side of the communication system, no user of the system can access the data in the second encrypted data 190 without first decrypting the second encrypted private key 210. And, since this cannot be done without the help or input of the second user 160, the system is secure for communications from the first user 100 to the second user 160 or from the second user 160 to the first user 100. On this side of the system, the second server 200 can neither access the data in the second encrypted data 190 nor decrypt the second encrypted private key 210.

[0015] As can be imagined, communications from the first user 100 to the second user 160 are encrypted using the second user's public key and decrypted using the decrypted second private key. Communications from the second user 160 to the first user 100 are encrypted using the first user's public key and decrypted using the decrypted first private key. Since neither server has access to the decrypted private key, and since the decrypted private key never leaves the client device, the system is secure. Preferably, the decrypted private key is only ever used to decrypt encrypted data and is only used on the client device.

[0016] For greater security, the key used to decrypt the encrypted private key can be obtained from a keyword provided by the user as well as the identity credentials provided by the user. Greater security comes from adding a salt to the hash (explained further below). After hashing, the resulting password should be unique and not vulnerable to dictionary attacks. As an example above, in addition to simply using the keyword provided by the user as the decryption key to decrypt the encrypted private key, the decryption key can also be obtained from a combination of a portion of the user's identity credentials in addition to the keyword. Thus, the decryption key can be obtained from a concatenation of a portion of any combination of the user's email address, phone number, username, and keyword. The resulting concatenation can then be run through an irreversible hashing process that produces a decryption key. Thus, for example, a user can have the following identity credentials: Username: AUser Email address: AUser@ema il doma in.com Phone number: 818-555-1212 Keyword: 12ab34cd56ef.

[0017] For such a user, an example of a combined string that could then be hashed to produce a decryption key might be: AUs+AUser@ema i l+818555+12ab34cd56ef Where + is the concatenation operator. Of course, any combination of any user credentials can be used to create a hash value to produce a decryption key. Likewise, while this example only uses a portion of each credential, any combination of these credentials can be used. As mentioned above, it is more preferred if the result of an irreversible hash of the concatenated string / value is used as the decryption key.

[0018] In another example, using the user credentials above, another suitable basis for the decryption key could be {user phone_number}+{keyword}+{app_passphrase_for_pr ivate_key}

[0019] For clarity, "passphrase_For_private_key" is a hard-coded string (password) in the client software and is the same for everyone using that particular implementation. This passphrase is generated by the company that wrote the software implementation (similar to a root certificate for a certificate authority). The same passphrase is used by all client software using the same implementation. Depending on the implementation, there may be one passphrase for the decryption key and a different passphrase for the login / authentication password. The passphrase acts as a salt that makes the hash less reversible in a dictionary attack, since a dictionary would require a specific implementation and therefore would not be feasible. For some implementations, two passphrases are used to generate different results, depending on the use case, i.e., one passphrase can be used to generate the private key decryption key, while the other passphrase can be used to generate the login / authentication password, as described below.

[0020] Using the above credential and decryption key scheme, the decryption key would therefore be: 818555121212ab34cd56ef+[password] This resulting string / value can then be run through a one-way hashing process to arrive at the decryption key.

[0021] In another alternative, for the convenience of the user, the credentials provided by the user for the correct login are preferably only the user's password and another credential (e.g., the user's user ID, email address, or phone number). The user's password and other credentials can then be combined to produce a string / value that can be hashed. Thus, the result of the one-way hashing process can be the above-mentioned decryption key. Of course, as described above, a password can also be incorporated into this process.

[0022] As described above, in addition to the above-mentioned combined string values ​​(with or without passwords), a one-way hash function is preferably applied to the string value, and the resulting hash value will be the decryption key used to decrypt the encrypted private key. It should be clear that it is necessary to encrypt the private key before storing it on the server. As far as the encryption key is concerned, this may not be important as long as the encrypted private key can be decrypted using the user-provided identification credentials and the user-provided keyword. Therefore, encryption / decryption can be symmetric (using the same encryption / decryption key) or asymmetric (using an encryption key different from the decryption key), as long as the resulting encrypted private key can be decrypted using the user-provided credentials.

[0023] For increased security, the login and authentication process that a user must go through to log in and authenticate with the server is preferably separate and independent from the process associated with downloading the encrypted private key or encrypted data from the server. The login and authentication process may involve a password that is also derived from the credentials provided by the user and the keywords provided by the user. As with the decryption key described above, the login and authentication password may be obtained from the user credentials and the keywords provided by the user, but as can be imagined, it is different from the decryption key described above. Of course, the generation of the authentication password may involve the use of a password as described above. As previously mentioned, the password will be generated by the software developer involved in producing the application and may be different from the password used to generate the decryption key.

[0024] As an example of the above, instead of the combined key detailed above, a login / authentication password could be generated based on (using the user credentials above and before passing the result through a one-way hashing process): Use+ema il doma i n+555+12ab34cd56ef As in the above example, + is a concatenation operator. As can be seen, the basis for the decryption key (before the hashing process) is derived by using the first few characters of each user credential, while the pre-hashed basis for the login / authentication password is derived by using the middle of each user credential. The only exception is the user keyword, as the entire keyword is used in both instances. As described above, the string resulting from the user credential is passed through an irreversible hashing process, and the result of the hashing process is used as the decryption key or login password. Of course, this process can also use the password before the hashing process, as described above.

[0025] As mentioned above, like the decryption key, the login / credential password is not an actual string generated from the user's credentials, but is the result of a one-way hash of a string generated from the credentials. The resulting password can be used to authenticate the user and client device to the server. In this way, no passwords or credentials are exchanged or transmitted in clear text between the client device and the server.

[0026] Although the above-described login / authentication process and decryption key use a single user-supplied keyword, one alternative is for the user to use different keywords for the login / authentication process and for the decryption key. In another alternative, a single master password can be obtained from all user credentials entered (including the user-supplied keyword). A hash of this single master password is created, and half of the resulting hash can be used as the login / authentication password, while the other half of the resulting hash can be used as the decryption key.

[0027] As an alternative to using the result of a one-way hash for the login / authentication password and decryption key, the string in the credential can be encrypted instead of being processed by hashing. To make this more difficult to reverse or decrypt, and to ensure that the process is a one-way process, the same string can be used as the key used to encrypt the string. The result of encrypting the string can then be used as the login / authentication password or the decryption key. As an alternative, after encryption, half of the resulting string can be used as the login / authentication password, and the other half as the decryption key.

[0028] One advantage of various aspects of the present invention is that it allows a user to access his or her data from any client device that complies with the present invention. That is, the E2EE can be possessed by any client device that logs in and authenticates to the server. The client device can then download the encrypted private key and decrypt the encrypted private key using the credentials entered by the user. The decrypted private key can then be used to decrypt the encrypted data received from the server.

[0029] In one embodiment, further security may be achieved by placing the encrypted data in an RSA / AES envelope.For an irreversible or one-way hash function that may be used with various aspects and embodiments of the present invention, SHA512 may be used.

[0030] refer to Figure 4 , a flowchart detailing the steps in a method according to another aspect of the present invention is shown. The method begins at step 300, i.e., receiving user credential input from a user on a client device. The credential input may include a user's username, email, phone number, and at least one keyword. The next step is to create a login / authentication password based on the credentials entered by the user (step 310). The login / authentication password is then used in a login / authentication process (step 320), which logs in and authenticates the user and client device to the server. Once the login and authentication process is complete, step 330 is to download the encrypted private key from the server to the client device. Then, step 340 is to download encrypted data from the server. The encrypted data may be data stored by the user in the server, or it may be incoming data from another user. This encrypted data can only be decrypted using a decrypted version of the encrypted private key. Step 350 is to decrypt the encrypted private key using a decryption key obtained from the credentials entered by the user. As described above, the generation of the decryption key may involve / include generating a one-way hash and / or merging portions of different user credentials entered. Once the private key is decrypted using the decryption key, the decrypted private key is used to decrypt the encrypted data (step 360).

[0031] It should be clear that various aspects of the present invention can be implemented as software modules in the entire software system. Therefore, the present invention can take the form of computer executable instructions, which, when executed, implement various software modules with predefined functions.

[0032] Furthermore, it should be clear that any reference herein to an "image" or "images" refers to one or more digital images including pixels or image elements unless otherwise specified. Likewise, any reference to an "audio file" or "audio files" refers to digital audio files unless otherwise specified. "Video," "video file," "data object," "data file," and all other such terms should be considered digital files and / or data objects unless otherwise specified.

[0033] Embodiments of the present invention may be performed by a computer processor or similar device programmed with the method steps, or may be performed by an electronic system equipped with means for performing these steps. Similarly, electronic memory devices, such as computer floppy disks, CD-ROMs, random access memories (RAMs), read-only memories (ROMs), or similar computer software storage media known in the art, may be programmed to perform these method steps. Likewise, electronic signals representing these method steps may also be transmitted via a communication network.

[0034] Embodiments of the present invention may be implemented in any conventional computer programming language. For example, preferred embodiments may be implemented in a procedural programming language (e.g., "C" or "Go") or an object-oriented language (e.g., "C++", "java", "PHP", "PYTHON" or "C#"). Alternative embodiments of the present invention may be implemented as pre-programmed hardware elements, other related components, or a combination of hardware and software components.

[0035] Embodiments may be implemented as computer program products for computer systems. Such implementations may include a series of computer instructions that are fixed on tangible media, such as computer-readable media (e.g., floppy disks, CD-ROMs, ROMs, or fixed disks), or may be transmitted to a computer system via a modem or other interface device (such as a communication adapter connected to a network via a medium). The medium may be a tangible medium (e.g., an optical or electrical communication line) or a medium implemented with wireless technology (e.g., microwaves, infrared, or other transmission technologies). The series of computer instructions implements all or part of the functions described above herein. It will be appreciated by those skilled in the art that such computer instructions may be written in a variety of programming languages ​​for use in many computer architectures or operating systems. In addition, these instructions may be stored in any storage device, such as semiconductor, magnetic, optical, or other storage devices, and may be transmitted using any communication technology, such as optical, infrared, microwave, or other transmission technologies. It is expected that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documents (e.g., shrink-wrapped software), pre-installed in a computer system (e.g., on a system ROM or fixed disk), or distributed from a server via a network (e.g., the Internet or the World Wide Web). Of course, some embodiments of the present invention may be implemented as a combination of software (eg, a computer program product) and hardware. Other embodiments of the present invention may be implemented as entirely hardware, or entirely software (eg, a computer program product).

[0036] The above-described alternative constructions and embodiments or variations may now occur to those who understand the invention, all of which are intended to fall within the scope of the invention as defined in the following claims.

Claims

1. A method for accessing encrypted data using a client device, the encrypted data being transmitted from a server to the client device, the method comprising: - undergoing a login and authentication process, thereby authenticating the user and the client device to the server, the login and authentication process involving a user first password; - receiving at the device an encrypted private key from the server; - decrypting the encrypted private key at the client device using a private key decryption key, the private key decryption key being obtained from a user second password and at least one user identification element; - receiving said encrypted data from said server; - decrypting the encrypted data using the decrypted private key; in: - Only the user can obtain the user's first password and the user's second password; - the encrypted private key cannot be decrypted by the server; - the encrypted private key can only be decrypted using the private key decryption key; - The decrypted private key is only ever used by the client device.

2. The method according to claim 1, wherein the encrypted data is encrypted by a public key corresponding to the private key.

3. The method of claim 1, wherein the first user password and the second user password are both obtained from a master password, and only the user can obtain the master password.

4. The method according to claim 1, wherein the login and authentication process comprises: - receiving user credentials from the user, the user credentials comprising a password entered by the user; - creating an authentication password based on said user credentials; - sending a version of the authentication password to the server, thereby causing the server to authenticate the client device and the user.

5. The method of claim 4, wherein the authentication password is generated by a combination of at least two user credentials, the user credentials comprising at least one of the following: -username; -email address; - Telephone number; and - User-supplied password.

6. The method according to claim 1, wherein: Obtaining the first user password and the second user password involves an irreversible hashing process.

7. The method according to claim 1, wherein: Obtaining the first user password and the second user password involves a one-way encryption process.

8. The method of claim 1, wherein the generation of the private decryption key involves a specific password for implementing the method.

9. The method of claim 4, wherein creation of the authentication password involves a specific password for implementing the method.

10. A method for accessing encrypted data via a server, the encrypted data being transmitted from the server to a client device, the method comprising: - authenticating the user and the client device to the server; - at the client device, receiving an encrypted private key from the server, the encrypted private key being pre-stored on the server by the user; - decrypting the encrypted private key at the client device using a private key decryption key to obtain a decrypted private key, the private key decryption key being obtained from the credentials provided by the user; - receiving said encrypted data from said server; - decrypting the encrypted data using the decrypted private key; in: - the encrypted private key cannot be decrypted by the server; - the encrypted private key can only be decrypted using the private key decryption key; - The decrypted private key is only ever used by the client device.

11. The method of claim 10, wherein the user credentials include at least one of: -username; -email address; - Telephone number; and - User-supplied password.

12. The method of claim 10, wherein the encrypted data is encrypted by a public key corresponding to the decryption private key.

13. The method of claim 10, wherein the encrypted data is transmitted from another user to the server via a communication system.

14. The method of claim 10, wherein the user-supplied credentials are used to generate a password for authenticating the user and the client device to the server.

15. A computer readable medium having encoded thereon computer readable and computer executable code which, when executed, implements a method for accessing encrypted data via a server, the encrypted data being transmitted from the server to a client device, the method comprising: - authenticating the user and the client device to the server; - receiving, at the client device, an encrypted private key from the server, the encrypted private key being pre-stored on the server by the user; - decrypting the encrypted private key at the client device using a private key decryption key to obtain a decrypted private key, the private key decryption key being obtained from the credentials provided by the user; - receiving said encrypted data from said server; - decrypting the encrypted data using the decrypted private key; in: - the encrypted private key cannot be decrypted by the server; - the encrypted private key can only be decrypted using the private key decryption key; - The decrypted private key is only ever used by the client device.

Images