MANAGEMENT AND DISTRIBUTION OF KEYS IN DISTRIBUTED ENVIRONMENTS

Abstract

A computer-implemented method for securely retrieving data on a client device in a distributed environment is disclosed. The method comprises retrieving a key encryption key from a local storage, retrieving an encrypted private key associated with the key encryption key from the distributed environment, the encrypted private key being remotely stored in the distributed environment, decrypting the encrypted private key using the key encryption key, thereby generating a private key, retrieving encrypted data from the distributed environment, the encrypted data being remotely stored in the distributed environment, and decrypting the encrypted data using the private key. A respective client device, a method for securely providing data in the distributed environment, and a distributed environment are disclosed.

Claims

1. A computer-implemented method for securely retrieving data on a client device in a distributed environment, the method comprising: retrieving a key encryption key from a local storage; retrieving an encrypted private key associated with the key encryption key from the distributed environment, the encrypted private key being remotely stored in the distributed environment; decrypting the encrypted private key using the key encryption key, thereby generating a private key; retrieving encrypted data from the distributed environment, the encrypted data being remotely stored in the distributed environment; and decrypting the encrypted data using the private key.

2. The computer-implemented method of claim 1, wherein the encrypted private key is stored in a cloud storage of the distributed environment.

3. The computer-implemented method of claim 1, wherein the encrypted data is stored in a further cloud storage of the distributed environment that is separate from the cloud storage storing the encrypted private key.

4. The computer-implemented method of claim 1, further comprising generating the key encryption key using an encryption passphrase received from a user of the client device.

5. The computer-implemented method of claim 4, further comprising changing the encryption passphrase, including receiving a new encryption passphrase, generating a new key encryption key, encrypting the retrieved private key using the new key encryption key, thereby generating a new encrypted private key, and storing the new encrypted private key together with a hash of the new key encryption key remotely in the distributed environment.

6. The computer-implemented method of claim 4, further comprising receiving, from a user of the client device, an input specifying a recovery key, generating a hash of the recovery key, and evaluating the hash of the recovery key with a hash of the private key, the hash of the private key being remotely stored in the distributed environment, wherein if the hash of the recovery key matches the hash of the private key, the user is enabled to change the encryption passphrase.

7. The computer-implemented method of claim 1, further comprising receiving, from a user of the client device, an input specifying a passphrase, generating a further key encryption key based on the passphrase, generating a hash of the further key encryption key, and evaluating the generated hash with a hash of the key encryption key, the hash of the key encryption key being remotely stored in the distributed environment.

8. The computer-implemented method of claim 7, further comprising comparing the hash of the further key encryption key with the hash of the key encryption key.

9. The computer-implemented method of claim 7, wherein the encrypted private key is retrievable only if the hash of the further key encryption key matches the hash of the key encryption key.

10. The computer-implemented method of claim 1, further comprising authenticating a user of the client device.

11. The computer-implemented method of claim 1, wherein the encrypted data is symmetrically encrypted using a symmetric key, wherein the symmetric key is based on the private key.

12. The computer-implemented method of claim 1, wherein the encrypted data is asymmetrically encrypted using a public key associated with the private key.

13. The computer-implemented method of claim 1, wherein the data is medical patient data.

14. A client device, comprising: a local memory; and one or more processors, wherein the client device is configured to execute a secured application, the secured application configured to: retrieve a key encryption key from a local storage; retrieve an encrypted private key associated with the key encryption key from the distributed environment, the encrypted private key being remotely stored in the distributed environment; decrypt the encrypted private key using the key encryption key, thereby generating a private key; retrieve encrypted data from the distributed environment, the encrypted data being remotely stored in the distributed environment; and decrypt the encrypted data using the private key.

15. The client device of claim 14, wherein the local memory is configured to provide a secured storage area for storing of the key encryption key and/or of the private key.

16. The client device of claim 15, wherein the secured storage area is automatically purged after exiting the secured application.

17. A distributed environment, comprising: at least one cloud storage; at least one server; and one or more client devices, wherein the at least one server is configured to securely provide data in the distributed environment by: providing access to an encrypted private key associated with a key encryption key, the encrypted private key being remotely stored in the distributed environment, wherein the encrypted private key is decryptable using a key encryption key stored locally on a client device of the distributed environment; and providing access to encrypted data, the encrypted data being remotely stored in the distributed environment, wherein the encrypted data is decryptable using the private key.

18. The distributed environment of claim 17, further comprising receiving, from the client device, a request for the encrypted private key, the request including a hash, and comparing the hash with a hash associated with the encrypted private key.

19. The distributed environment of claim 18, further comprising providing the encrypted private key to the client device only if the received hash matches the hash associated with the encrypted private key, wherein the encrypted data is symmetrically encrypted using the private key or asymmetrically encrypted using a public key associated with the private key.

20. The distributed environment of claim 17, wherein the at least one cloud storage includes a key cloud storage and a separate data cloud storage, wherein the encrypted private key is stored in the key cloud storage and the encrypted data is stored in the data cloud storage.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0043] The specific features, aspects and advantages of the present disclosure will be better understood with regard to the following description and accompanying drawings where:

[0044] FIG. 1 depicts a schematic representation of a distributed environment with a client device according to one embodiment of the present disclosure;

[0045] FIG. 2 illustrates a schematic representation of data retrieval according to an embodiment of the present disclosure;

[0046] FIG. 3 shows a flow chart of a method for securely retrieving data on a client device in a distributed environment according to one embodiment of the present disclosure; and

[0047] FIG. 4 shows a flow chart of a method for securely providing data in a distributed environment according to one embodiment of the present disclosure.

DETAILED DESCRIPTION

[0048] In the following description, reference is made to drawings, which show by way of illustration various embodiments. Also, various embodiments will be described below by referring to several examples. It is to be understood that the embodiments may include changes in design and structure without departing from the scope of the claimed subject matter.

[0049] FIG. 1 depicts a schematic representation of a distributed environment 100 with a client device 102 according to one embodiment of the present disclosure. The distributed environment 100 includes a first cloud storage 104 and a second cloud storage 106, which is separate from the first cloud storage 104. Preferably, the first cloud storage 104 and the second cloud storage 106 are provided by completely separate cloud providers that do not have mutual access to their storage devices in the respective first 104 and second 106 cloud. The distributed environment 100 may further include at least one server 108, which can be implemented on one or more computing devices. The at least one server 108 may be controlled by a service (or platform) provider. The service (or platform) provider may control secure retrieval and/or secure provision of data in the distributed environment. All entities within the distributed environment 100 may be interconnected by a network 110, such as an IP-based network or a network using another communication technology. It is to be understood that the distributed environment 100 could also be located within the network 110 or represent the network 110.

[0050] Sensitive data may be encrypted and stored on one of the first and second cloud storages 104, 106, such as on the first cloud storage 104. The keying material, which may include a private key, may be stored in an encrypted form on the same or on the other cloud storage, such as on the second cloud storage 106. In order to obtain access to the sensitive data, the client device 102 may send a request for encrypted keying material, including the encrypted private key. This request may be submitted, to the service (or platform) provider via the at least one server 108. The at least one server 108 may forward the request to the second cloud storage 106, in order to retrieve the encrypted keying material. Additionally or as an alternative, after approval by the service (or platform) provider, the client device 102 may directly forward the request for the encrypted keying material to the second cloud storage 106.

[0051] The client device 102 may be authenticated with the server 108. For example, a user of the client device 102 may provide credentials to the server 108, which may authenticate the user. The server 108 may process any subsequent requests from the client device 102 for authenticated users only.

[0052] The client device 102 may retrieve a key encryption key that is associated with the retrieved encrypted keying material from its local storage and may decrypt the retrieved encrypted keying material, including the private key, using the key encryption key, in order to obtain the decrypted keying material, including the private key. The keying material and/or the private key may be stored in a secured local storage of the client device 102.

[0053] Subsequently, the client device 102 may submit a request for the sensitive data via the server 108 or directly to the first cloud storage 104. Again, the service (or platform) provider operating the server 108 may grant access to the sensitive data only for authenticated users. In response to the request, the sensitive data in an encrypted form may be submitted from the first cloud storage via the network 110 to the client device 102. The client device 102 may use the keying material, including the private key, to decrypt the encrypted data.

[0054] Storing data in the cloud delivers many advantages for users of sensitive data, such as in healthcare. In particular, this may be advantageous if multiple parties have to share and process the sensitive data, including clinics, practices, patients, or health insurance companies. Cloud-based storage is cost-efficient since no own infrastructure has to be maintained, and no IT technicians have to be employed. Moreover, cloud-based storage is reliable because the cloud provider arranges backups and redundancy, secure because the cloud provider offers a professional IT infrastructure, sustainable because resources are shared between users, and fast because computation power can be dynamically changed and multiple datacenter locations may be offered.

[0055] Yet, for sensitive data, such as in healthcare, security and performance requirements are high. Even though these requirements may be met by cloud providers, users of sensitive data do not want to trust a cloud provider, since a cloud provider may easily get access to the stored data.

[0056] This problem can be avoided by providing a client-sided encryption of sensitive data. If the sensitive data is encrypted by strong encryption techniques and encryption keys are not accessible by the cloud provider, the cloud provider cannot obtain the sensitive data.

[0057] Key management may require several usability considerations. The keys must be protected from unauthorized access and from accidental loss. Keys should be available at different locations and preferably shareable between multiple authorized parties. Moreover, keys should be preferably accessible to applications.

[0058] Key management can be addressed by storing the key on a mobile device, e.g., a smartcard, a USB drive or within a mobile phone. This may provide weak protection against theft and a low usability, also requiring special interfaces and/or drivers at computing devices used for accessing the sensitive data. As a loss of the key poses a serious problem, backup keys should be well protected. According to another approach biometric data may be used to derive the key. Depending on the implementation, this may carry high security but requires special devices for generating the key, which may be rarely available and/or expensive. In yet another approach the key may be derived from a passphrase which may provide a good usability. However, in order to obtain a reasonable safety level, more complex passphrases have to be used, which may be difficult to memorize. Also, changing of a passphrase may require re-encryption of any previously encrypted data.

[0059] Since according to the embodiment of FIG. 1, the keying material is stored in an encrypted form on a separate cloud storage than the sensitive data, the different cloud providers cannot simultaneous get access to both, the keying material and the sensitive data. Moreover, since the passphrase provided at client device 102 is not used to decrypt the sensitive data, but to get access to the encrypted keying material, the keying material may be selected to be complex enough to maintain a high security level with regard to requirements of the sensitive data.

[0060] It is to be understood that even though embodiments of the present disclosure are advantageous over the previously mentioned approaches for key management and data distribution, aspects of these approaches may be combined with embodiments of the present disclosure in any combination. For example, the encryption passphrase may be based on biometric data and/or using a mobile device, and the like, as discussed above.

[0061] FIG. 2 illustrates a schematic representation of a secured distribution and retrieval of sensitive data according to one embodiment of the present disclosure.

[0062] FIG. 2 shows a schematic view of a client device 202, which may communicate with a network 204. The client device 202 may be the client device 102 as shown in FIG. 1. The network 204 may include a first part 206 and a second part 208. Both parts 206, 208 may be preferably controlled by different entities. For example, the first part 206 may correspond to the first cloud storage 104 and the second part 208 may correspond to the second cloud storage 106, or vice versa, as shown in FIG. 1. Both parts 206, 208 and the respective cloud storage may be provided by different cloud providers. FIG. 2 shows an example embodiment of processing related to retrieval of keying material in order to obtain sensitive data. Access to sensitive data may be mediated via a service or platform provider, who may operate one or more server devices (not shown) within the network 204, such as the at least one server 102 of FIG. 1. The client device 202 may register with the platform provider and the platform provider may control access to the different parts 206, 208 of the network 204.

[0063] Retrieval and distribution of sensitive data may start with a provision of an encryption passphrase 210 on the client device 202. For example, a user of the client device 202 may type in or otherwise input a passphrase, or may use a mobile storage to provide the passphrase to the client device 202. The encryption passphrase 210 may be used to generate a key encryption key 212.

[0064] The key encryption key 212 may be used to encrypt a private key 214, which may form part of keying material. The private key 214 may be randomly selected or generated based on various factors. Additionally, the entire keying material may be encrypted using the key encryption key 212. The private key 214 may be stored in an encrypted form in the network 204, such as on a remote storage in the first part 206. Hence, it is not required to store the private key 214 on the client device 202 locally.

[0065] Hence, during subsequent retrieval, the private key 214 may not be available on the client device 202. In order to retrieve the private key 214, the client device 202 may generate a hash 216 of the key encryption key 212, for example, by applying a hash function to the key encryption key 212, and may submit the hash 216 to the network 204. The request may be directed towards the first part 206 of the network 204. A server in the network 204 may validate the submitted hash 216 with a hash 218. The hash 208 may be a previously generated hash of the key encryption key 212 that may be stored in the network 204, such as locally on the server, in relation to the requested stored encrypted private key 220. Upon successful validation of both hashes 216, 218, for example, if both hashes 216,218 match, the encrypted private key 220 may be returned to the client device 202 that may in turn decrypt the encrypted private key 220 using the key encryption key 212, in order to obtain the private key 214.

[0066] Sensitive data 222 may be encrypted such that they can be decrypted using the private key 214 only. The sensitive data 222 in an encrypted form may be stored in the network 204, for example, on a separate remote storage in the second part 208 of the network 204 as encrypted sensitive data 224. Since the client device 202 is in possession of the private key 214, the encrypted sensitive data 224 may be retrieved from the network 204 and decrypted using the private key 214.

[0067] The sensitive data may be encrypted on client side, which may be understood as a zero knowledge encryption, and then stored remotely in the cloud. The sensitive data cannot be decrypted by any unauthorized party since the keying material, including the private key, is only known to the user.

[0068] The sensitive data may be encrypted by a user, stored remotely, and again retrieved by the user. However, the sensitive data may also be encrypted by another party, which may desire to provide the sensitive data to the user. In this case, preferably asymmetric encryption may be used to exchange data between multiple users, such as between a doctor and a patient, or between a plurality of doctors. Additionally or as an alternative, a hybrid encryption scheme may be used, wherein asymmetric encryption may be used for exchange of a random symmetric key. In one preferred use case, the Libsodium library may be used for authenticated public key encryption. This may use, in one example, one or more of key exchange: X25519; encryption: XSalsa20 stream cipher; and authentication: Poly1305 MAC.

[0069] As described above, the sensitive data may be stored by the user for own purposes only. In this case, symmetric encryption may be used for storage of sensitive data of the user, such as doctor's data, or patient's data. In one preferred use case, the Libsodium library may be used for authenticated secret key encryption. This may use, in one example, one or more of encryption: XSalsa20 stream cipher; and authentication: Poly1305 MAC.

[0070] In asymmetric encryption schemes, the private key (PK) allows the user to decrypt data sent to the user after the data has been encrypted with a corresponding public key of the user. The same or a modified PK may also be used as a secret for symmetric encryption. For example, in another preferred use case, X25519 and XSalsa20 both use 256 bit keys.

[0071] During registration, the user may enter an arbitrary encryption passphrase (EP) 210. The user should ensure confidentiality of the EP 210. The EP 210 should only be shared between trusted parties, such as authorized co-workers requiring access to the sensitive data. This may include staff of a clinic department. In one example, a key deriving/password hashing function, such as the Libsodium's Argon2 key deriving/password hashing function, may be used to generate the key encryption key (KEK) 212.

[0072] The PK 214 may be generated randomly during user registration. Preferably, the PK 214 is not derived from the EP 210 to grant maximum entropy irrespective of the strength of the EP 210. Instead, the KEK 212 is used to encrypt the PK 214. The encrypted private key (EPK) 220 may then be stored in a cloud storage in the network 204.

[0073] Whenever a user logs into the client device 202, the EPK 220 may be retrieved from the network 204, decrypted on client side using the entered EP 210, and used to decrypt any encrypted sensitive data 224 on the client device 202.

[0074] In a preferred embodiment, access to the EPK 220 and to the encrypted sensitive data 224 may be granted after a valid user authentication with the platform provider. Authentication may be performed by a server within the network, such as the server 108. The hash 216 of the KEK 212, such as a SHA-256 hash, may be used to further improve the security of the system by comparing the hash 218 with the hash 216 derived from the EP 210 entered by the user, to validate correctness of the EP 210 on server side without disclosing the EPK 220 to the user.

[0075] By storing the EPK 220 in a cloud in the network 204, access from different locations is ensured. The platform therefore supports access from various locations, such as home office and mobile office out-of-the-box.

[0076] If the EP 210 must be changed, such as due to security requirements or when an entity becomes an unauthorized entity, for example, during routine rotations or when an employee leaves, a new EP is chosen and a new KEK is generated based on the EP. Only the PK 214 has to be re-encrypted with the new KEK. The sensitive data needs not to be re-encrypted since the PK 214 remains the same.

[0077] According to one embodiment, the EP 210 is memorized by the user. The KEK 212 may be stored in a local secured memory of the client device 202. The secured storage may be accessed by selected applications having respective access rights. In particular, the KEK 212 is preferably never disclosed to the server on the network 204 or any other entity outside of the client device 202. The secured storage may be purged or wiped after application exit.

[0078] The encrypted sensitive data 224 and encrypted keys are preferably stored on different storage devices or databases in different storage clouds. Hence, they can be stored and managed by different cloud providers, such as a first and a second cloud provider, and even in different countries.

[0079] The first cloud provider storing the encrypted sensitive data may have no access to the key database. To read the sensitive data, the first cloud provider must use brute force attacks or algorithm vulnerabilities. As the private/symmetric key is generated randomly, brute force attacks will generally fail. For example, up to 2{circumflex over ()}128 combinations (a 256 bit curve X25519 key provides for 128 bits of security) have to be tried out, which is computationally impossible in a reasonable time span. If the private/symmetric key would have been directly derived from the user's encryption passphrase, the number of combinations would be directly related to the strength of the used encryption passphrase. Therefore, the first cloud provider will not be able to get access to the encryption sensitive data.

[0080] The second cloud provider storing the encrypted private key could get the private/symmetric key via brute force attacks, depending on the user's encryption passphrase strength and depending on the key hashing algorithm, computational power, and the available time. However, the second cloud provider has no access to the encrypted data stored at the first cloud provider, making the key alone useless.

[0081] By using different cloud providers in different locations, such as different countries, the risk of a single entity obtaining full access to sensitive data by brute force attacks can be avoided or greatly reduced.

[0082] Preferably, in order to further increase the security level, the platform provider, which may operate server 108 of FIG. 1, may continuously monitor the encryption algorithms used by applications on client devices and may switch to other encryption algorithms once the used encryption algorithms cannot be considered safe anymore. This may be seamlessly integrated in the processing of the client device 202 without providing the platform provider with access to the sensitive data or the private key.

[0083] According to yet another preferred embodiment, the platform provider may require an authentication of users of the client device 202. In one example, an Oauth2 compatible authentication provider, such as Auth0, can be used. Users may authenticate by entering credentials, such as a username, an email, and/or a password, and the like in any combination. Two-factor authentication could be further used to improve security. Only in response to a valid authentication, the user may be enabled to enter the encryption passphrase 210. This additional security layer may further protect from direct brute force attacks on the encryption passphrase 210. Accordingly, the encryption passphrase 210 may serve as second authentication, which requires a successful authentication in the first step.

[0084] The authentication provider or the platform provider may lock user accounts after too many failed login attempts and implement other security measures to make it more difficult to break the authentication security layer.

[0085] FIG. 3 shows a flow chart of a method 300 for securely retrieving data on a client device in a distributed environment. The client device may be the client device 102 of FIG. 1 or the client device 202 of FIG. 2 and the distributed environment may be the distributed environment 100 of FIG. 1 or the corresponding network 204 of FIG. 2.

[0086] The method 300 may start in item 302 and may continue in item 304 with retrieving a key encryption key from a local storage. The key encryption key may have been previously generated using an encryption passphrase that has been entered by a user of the client device.

[0087] In item 306, an encrypted private key that is remotely stored in the distributed environment and which is associated with the key encryption key may be retrieved from the distributed environment. The encrypted private key may be stored in a cloud storage of the distributed environment. In item 308, the encrypted private key is decrypted using the key encryption key in order to generate a private key.

[0088] In item 310, encrypted data are retrieved from the distributed environment. The encrypted data may be remotely stored in the distributed environment. Preferably, the encrypted data is stored in a different cloud storage of the distributed environment that may be completely separate from the cloud storage storing the encrypted private key.

[0089] In item 312, the encrypted data may be decrypted using the private key. Thereafter, the method may conclude in item 314.

[0090] FIG. 4 shows a flow chart of a method 400 for securely providing data in a distributed environment. The distributed environment may be the distributed environment 100 of FIG. 1. The method may be executed on a server of the distributed environment, such as a management server located in the distributed environment, for example, the server 108 of FIG. 1.

[0091] The method may start in item 402 and may proceed with item 404, where access to an encrypted private key associated with a key encryption key is provided. The encrypted private key may be remotely stored in the distributed environment, such as in a first cloud. The encrypted private key may be generated using a key encryption key. Hence, the encrypted private key may be decryptable using the key encryption key. The key encryption key may be stored locally on a client device of the distributed environment.

[0092] In item 406, access to encrypted data that are remotely stored in the distributed environment may be provided. For example, the client device that requested access to the encrypted private key may request the remotely stored encrypted data, wherein the encrypted data may be decrypted using the private key. The method may conclude in item 408.

[0093] While some embodiments have been described in detail it is to be understood that aspects of the disclosure can take many forms. In particular, the claimed subject matter may be practiced or implemented differently from the examples described and the described features and characteristics may be practiced or implemented in any combination. The embodiments shown herein are intended to illustrate rather than to limit the invention as defined by the claims.