SECURE AND ZERO KNOWLEDGE DATA SHARING FOR CLOUD APPLICATIONS

• US 20180013562A1
• Filed: 07/06/2017
• Published: 01/11/2018
• Est. Priority Date: 07/06/2016
• Status: Active Grant

• Current Assignee: Masimo Corporation
• Original Assignee: Patient Doctor Technologies, Inc. (Masimo Corporation)
• Inventors: Haider, Amer, Ahmed, Ali
• Granted Patent: US 10,608,817 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 16/951 Indexing; Web crawling techniques
• CPC Class Codes: G06F 21/14 against software analysis or reverse engineering, e.g. by obfuscation
• CPC Class Codes: G06F 21/6218 to a system of files or objects, e.g. local or distributed file system or database
• CPC Class Codes: G06F 21/6227 where protection concerns the structure of data, e.g. records, types, queries
• CPC Class Codes: H04L 2463/062 applying encryption of the keys cryptographic mechanisms or cryptographic arrangements for key distribution using key encryption key H04L9/0822
• CPC Class Codes: H04L 63/0428 wherein the data content is protected, e.g. by encrypting or encapsulating the payload
• CPC Class Codes: H04L 63/06 for supporting key management in a packet data network cryptographic mechanisms or cryptographic arrangements for key management H04L9/08
• CPC Class Codes: H04L 67/10 in which an application is distributed across nodes in the network software deployment G06F8/60; multiprogramming arrangements G06F9/46
• CPC Class Codes: H04L 9/0825 using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
• CPC Class Codes: H04L 9/14 using a plurality of keys or algorithms
• CPC Class Codes: H04L 9/3221 interactive zero-knowledge proofs

Abstract

Disclosed is a zero-knowledge distributed application configured to securely share information among groups of users having various roles, such as doctors and patients. Confidential information may be encrypted client-side, with private keys that reside solely client side. Encrypted collections of data may be uploaded to, and hosted by, a server that does not have access to keys suitable to decrypt the data. Other users may retrieve encrypted data from the server and decrypt some or all of the data with keys suitable to gain access to at least part of the encrypted data. The system includes a key hierarchy with multiple entry points to a top layer by which access is selectively granted to various users and keys may be recovered.

Claims

1. A method, comprising:

obtaining, by one or more processors of a first client device, a private key for a first user of the first client device that is paired to a public key for the first user of the first client device;

receiving, by one or more processors of the first client device, encrypted user data over a network, the encrypted user data having been created by a second user of a second client device;

receiving, by one or more processors of the first client device, a shared data key hierarchy structure (SD-KHS) over the network, the SD-KHS comprising one or more encrypted shared data encryption keys (ESDEKs);

decrypting, by one or more processors of the first client device, an ESDEK with the private key to make available a shared data encryption key (SDEK); and

decrypting, by one or more processors of the first client device, the encrypted user data with the SDEK to make available the user data.

2. The method of claim 1, further comprising:

editing, by one or more processors of the first client device, one or more elements of the user data;

encrypting, by one or more processors of the first client device, a notification message using a public key for the second user of the second user device, wherein the notification message comprises an indication of the user data having been edited to at least the second user of the second user device;

sending, by one or more processors of the first client device, the notification message over the network.

3. The method of claim 1, wherein the private key is obtained by decrypting an encrypted private key (EPK) that was stored as part of a key hierarchy structure (KHS).

4. The method of claim 1, wherein the SDEK is encrypted with the public key of the first user of the first user device by the second user device.

5. The method of claim 1, wherein the SDEK is not stored in a non-volatile memory.

6. The method of claim 1, wherein each of the ESDEKs is stored as a different array or set of arrays of the SD-KHS.

7. The method of claim 1, wherein the second user is a service provider.

8. The method of claim 1, wherein when the user data created by the second user is to be shared with at least the first user a shared copy of the user data is created.

9. A method, comprising:

deriving, by one or more client-side processors, a derived key (DK) based on information provided by a user of a client device without the information or the DK being made available to other parties;

receiving, by one or more client-side processors, encrypted user data sent from a server over a network, the encrypted user data having been created by the user of the client device;

decrypting, by one or more client-side processors, an encrypted master encryption key (EMEK) with the DK to make available a master encryption key (MEK), wherein the MEK serves to encrypt data encryption keys;

decrypting, by one or more client-side processors, an encrypted data encryption key (EDEK) with the MEK to make available a data encryption key (DEK), wherein the DEK serves to encrypt user data; and

decrypting, by one or more client-side processors, the encrypted user data with the DEK.

10. The method of claim 9, wherein the EMEK and the EDEK had been stored in a key hierarchy structure (KHS).

11. The method of claim 10, wherein the information provided by the user, the DK, the MEK, and the DEK are not stored in non-volatile memory before or after the information is provided.

12. The method of claim 10, wherein names of entries of the KHS are obfuscated.

13. The method of claim 10, further comprising:

decrypting, by one or more client-side processors, another encrypted data encryption key with the MEK to make available a private key, the private key being paired to a public key stored in a lookup directory of the server device;

receiving, by one or more client-side processors, encrypted shared user data sent from the server device over the network, the encrypted shared user data having been created by another user of another client device;

receiving, by one or more client-side processors, a shared data key hierarchy structure sent from the server device over the network, the shared data key hierarchy structure comprising one or more encrypted shared data encryption keys (ESDEKs) and having been created for the another client device;

decrypting, by one or more client-side processors, an ESDEK with the private key to make available a shared data encryption key (SDEK); and

decrypting, by one or more client-side processors, the encrypted shared user data with the SDEK.

14. The method of claim 9, comprising:

requesting, by a server-side processor, a password from the user; and

receiving, by the server-side processor, the password from the user, wherein the information provided by the user comprises the password such that the DK is a password derived key (PDK).

15. The method of claim 14, comprising:

generating, by the one or more client-side processors, a random salt variable;

hashing, by the one or more client-side processors, the password; and

repetitively applying a pseudorandom function, by the one or more client-side processors, to the hashed password and the random salt variable.

16. The method of claim 15, comprising:

concatenating, by the one or more client-side processors, the one or more answers and the one or more security questions;

generating, by the one or more client-side processors, a random salt variable;

hashing, by the one or more client-side processors, the concatenation; and

passing, by the one or more client-side processors, the hashed concatenation and the random salt variable through a Password-Based Key Derivation Function (PBKDF).

17. The method of claim 9, comprising:

requesting, by a server-side processor, one or more answers to one or more security questions from the user;

receiving, by the server-side processor, the one or more answers to the one or more security questions from the user, wherein the information provided by the user comprises the one or more answers to the one or more security questions such that the DK is a questions-based derived key (QDK).

18. The method of claim 9, wherein two or more of the encryption of the user data, encryption of the DEK, and encryption of the MEK are performed with means for encrypting data.

19. The method of claim 9, wherein each of the encryption of the user data, encryption of the DEK, and encryption of the MEK is performed with a different algorithm.

20. A tangible, non-transitory, machine-readable media storing instructions that when executed by a client computing device in a zero knowledge messaging system effectuate operations comprising:

deriving, by the one or more client-side processors, a derived key (DK) based on information provided by a user of the client device without the information or the DK being made available to other parties;

receiving, by the one or more client-side processors, encrypted user data sent from another device over a network;

decrypting, by the one or more client-side processors, an encrypted master encryption key (EMEK) with the DK to make available a master encryption key (MEK), wherein the MEK serves to encrypt data encryption keys;

decrypting, by the one or more client-side processors, an encrypted data encryption key (EDEK) with the MEK to make available a data encryption key (DEK), wherein the DEK serves to encrypt user data; and

decrypting, by the one or more client-side processors, the encrypted user data with the DEK.

21. The media of claim 20, wherein the EMEK and the EDEK had been stored in a key hierarchy structure (KHS).

22. The media of claim 21, wherein the information provided by the user, the DK, the MEK, and the DEK are not stored in non-volatile memory before or after the information is provided.

23. The media of claim 20, the operations comprising:

requesting, by a server-side processor, a password from the user; and

receiving, by the server-side processor, the password from the user, wherein the information provided by the user comprises the password such that the DK is a password derived key (PDK).

24. The media of claim 23, the operations comprising:

generating, by the one or more client-side processors, a random salt variable;

hashing, by the one or more client-side processors, the password; and

repetitively applying a pseudorandom function, by the one or more client-side processors, to the hashed password and the random salt variable.

25. The media of claim 24, the operations comprising:

concatenating, by the one or more client-side processors, the one or more answers and the one or more security questions;

generating, by the one or more client-side processors, a random salt variable;

hashing, by the one or more client-side processors, the concatenation; and

passing, by the one or more client-side processors, the hashed concatenation and the random salt variable through a Password-Based Key Derivation Function (PBKDF).

26. The media of claim 20, the operations comprising:

requesting, by a server-side processor, one or more answers to one or more security questions from the user;

receiving, by the server-side processor, the one or more answers to the one or more security questions from the user, wherein the information provided by the user comprises the one or more answers to the one or more security questions such that the DK is a questions-based derived key (QDK).

27. The media of claim 20, wherein two or more of the encryption of the user data, encryption of the DEK, and encryption of the MEK are performed with means for encrypting data.

28. The media of claim 20, wherein each of the encryption of the user data, encryption of the DEK, and encryption of the MEK is performed with a different algorithm.