PROVIDING ACCESS TO SENSITIVE DATA

Abstract

Methods of providing access to sensitive data associated to a user are disclosed. These methods include receiving a user request requesting the provision of access; retrieving an encrypted version of the encryption key; retrieving at least one auxiliary key; obtaining a decrypted version of the encryption key by decrypting the encrypted version of the encryption key using the at least one auxiliary key; obtaining a decrypted version of all or part of the sensitive data by decrypting all or part of the encrypted version of the sensitive data using the decrypted version of the encryption key; and providing access to the decrypted version of all or part of the sensitive data through a secure communication channel. Systems and computer program products suitable for performing said methods of providing access to sensitive data are also disclosed.

Claims

1. Method of providing, by a data system, access to sensitive data associated to a user, the data system storing an encrypted version of the sensitive data obtained as a result of encrypting the sensitive data using an encryption key associated to the user, the method comprising: receiving, from a user system, a user request requesting the provision of access; retrieving an encrypted version of the encryption key; retrieving at least one auxiliary key; obtaining a decrypted version of the encryption key by decrypting the encrypted version of the encryption key using the at least one auxiliary key; obtaining a decrypted version of all or part of the sensitive data by decrypting all or part of the encrypted version of the sensitive data using the decrypted version of the encryption key; and providing access to the decrypted version of all or part of the sensitive data through a secure communication channel.

2. Method according to claim 1, the encrypted version of the encryption key being retrieved from a repository in the data system.

3. Method according to claim 2, the received user request comprising a user key created by the user; and the at least one auxiliary key comprising said user key.

4. Method according to claim 3, the user key being a passphrase or password created by the user.

5. Method according to claim 3, further comprising: retrieving a hash value of reference pre-calculated using a predefined hash function; hashing the user key using the predefined hash function; and validating the user key by comparing the hashed user key to the hash value of reference.

6. Method according to claim 3, the at least one auxiliary key further comprising a system key associated to the data system.

7. Method according to claim 1, the received user request comprising the encrypted version of the encryption key which is therefore retrieved from the received user request.

8. Method according to claim 7, the at least one auxiliary key comprising a system key associated to the system.

9. Method according to claim 8, the received user request comprising a user key created by the user.

10. Method according to claim 9, further comprising encrypting the decrypted version of the encryption key using the user key comprised in the received user request.

11. Method according to claim 10, the decrypted version of the encryption key being encrypted further using the system key.

12. Method according to claim 9, further comprising hashing the user key using a predefined hash function for obtaining a hash value of reference for validation purposes.

13. Method according to claim 8, the system key being a passphrase or password associated to the data system.

14. Method according to claim 8, the system key being retrieved from a volatile memory in the data system.

15. Method according to claim 14, the system key being inputted in the data system through data entry functionality when the data system is initiated.

16. Method according to claim 1, the providing access to the decrypted version of all or part of the sensitive data through the secure communication channel comprises providing the user system with access to the decrypted version of all or part of the sensitive data through the secure communication channel.

17. Method according to claim 1, the received user request comprising authorization data indicating that a third party system has been authorized by the user to be provided with the access; and the providing access to the decrypted version of all or part of the sensitive data through the secure communication channel comprises providing the third party system with access to the decrypted version of all or part of the sensitive data through the secure communication channel, based on the authorization data.

18. Method according to claim 1, the sensitive data associated to a user being genomic data of a person associated to the user optionally including one or more of a whole genome sequencing experiment or any other sequencing experiment of the person.

19. (canceled)

20. (canceled)

21. Computer program comprising program instructions for causing a computing system to perform a method according to claim 1 of providing access to sensitive data associated to a user.

22. (canceled)

23. (canceled)

24. A computing system comprising a memory and a processor, embodying instructions stored in the memory and executable by the processor, the instructions comprising functionality to execute a method according to claim 1 of providing access to sensitive data associated to a user.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0065] Non-limiting examples of the present disclosure will be described in the following, with reference to the appended drawings, in which:

[0066] FIG. 1 illustrates a block diagram of a data system according to examples.

[0067] FIG. 2 schematically illustrates a data system equal or similar to the one shown in FIG. 1 in communication with a user system and a third party system.

[0068] FIG. 3 illustrates a flow diagram of a method of providing access to sensitive data according to further examples.

[0069] FIG. 4 illustrates a flow diagram of a method of providing access to sensitive data according to still further examples.

DETAILED DESCRIPTION

[0070] FIG. 1 illustrates a block diagram of a data system 100 according to some examples. Basically, a data system 100 may include a processing module 101, a data storage module 102 for storing data such as e.g. genomic data, and a network access module 103 for providing access to a communication network 104, for example a global communication network such as the Internet. The data system 100 may communicate with other systems through the communication network 104 by using suitable communication protocol(s).

[0071] The data storage module 102 may include one or more databases 105, 106. For example, a first database 105 may be used to store genomic data of people associated to the users of the data system 100, and a second database 106 may be used to store other user-related data. The genomic data stored in the first database 105 may include e.g. data on whole genome sequencing experiments. This genomic data may be raw and/or processed genomic data to provide biologically/medically meaningful interpretation of such data. The second database 106 may be used to store management data such as e.g. unique user identifiers, encrypted unique encryption keys individually assigned to users, system keys, hashed user keys, etc.

[0072] The processing module 101 may be implemented by computing devices, systems or methods, electronic elements or a combination thereof. The computing elements may be a set of instructions (that is, a computer program) and then the processing module may include a memory and a processor, embodying said set of instructions stored in the memory and executable by the processor. The instructions may include functionality to execute at least a method of providing access to sensitive (genomic) data as will disclosed below. In case the processing module 101 is implemented only by one or more electronic elements, the processing module may be, for example, a CPLD, an FPGA or an ASIC. In case the processing module 101 is a combination of electronic and computing elements, the computing element or elements may be a set of instructions and the electronic element or elements may be any electronic circuit capable of implementing the corresponding step or steps of the cited method.

[0073] It is important to highlight that said processing module 101 may be implemented in the data system 100 by a system (or by a computing system) disposed in it or connected to it, and configured to specifically perform this method, or may be the data system itself as a whole. In this last case, the same resources (e.g. memory, processor, electronic circuits, etc.) of the data system 100 may be configured to perform different tasks (for example, among other tasks, the execution of the cited method).

[0074] The processing module 101 may be configured to provide necessary functionalities for performing methods of providing access to sensitive (genomic) data according to examples, such as the ones described in other parts of the description. For example, the processing module 101 may be configured to decrypt genomic data retrieved from the genomic database 105 by using corresponding key(s) retrieved from the management database 106. The processing module 101 may also be configured to provide other systems with secure access to the decrypted genomic data by using corresponding functionalities of the network access module 103.

[0075] The network access module 103 may be configured to be connected to a network access point such as a router (not shown in this figure). The router may be available in the vicinity of the data system 100 or may be disposed in the data system 100. The router may be connected to the communication network such as the Internet 104. This way, the data system 100 may communicate with other systems through the Internet 104 by using functionalities of the network access module 103 connected to the router.

[0076] FIG. 2 schematically illustrates a data system 200 equal or similar to the one shown in FIG. 1 in communication with a user system 205 and a third party system 209. As shown in this figure, the data system 200 may include a web server module 201, which may have necessary functionalities for providing other systems (e.g. the user system 205 and the third party system 209) with web access.

[0077] The data system 200 may be connected to a communication network 204 such as the Internet. A router 202 may provide access to the communication network 204 for the data system 200. The router may be protected by a firewall 203 or not. The user system 205 may also be connected to the communication network 204 in a similar manner as the data system 200, for example. This way, the data system 200 and the user system 205 may communicate with each other through the communication network 204 via a secure channel based on e.g. an SSL tunnel or an HTTP/TLS protocol.

[0078] Therefore, the configuration proposed in FIG. 2 may establish a secure communications gateway via the communication network 204, such as the Internet, to enable bi-directional connections between the user system 205 and the data system 200. Bi-directional communications may be established in a secured form so that the information, the user system 205 and the data system 200 are safe from unauthorized use. The communications may be dynamically set regardless of whether the IP addresses of the devices are static or dynamic.

[0079] Concerning the user system 205, it may basically include a processing module 208, a web client module 207, and a network access module 206 for accessing the communication network 204.

[0080] The processing module 208 of the user system 205 may be implemented by computing devices, systems or methods, electronic elements or a combination of them. The computing elements may be a set of instructions and the processing module 208 may include a memory and a processor, embodying said set of instructions stored in the memory and executable by the processor. These instructions may include functionalities to execute corresponding methods at the side of the user system 205 for accessing sensitive (genomic) data residing at the data system 200. In case the processing module 208 is implemented only by electronic elements, said processing module may be, for example, a CPLD, an FPGA or an ASIC. In case the processing module 208 is a combination of electronic and computing elements, the computing part or parts may be or include a set of instructions and the electronic part or parts may be or include any electronic circuit capable of implementing the corresponding step or steps of the cited methods.

[0081] The processing module 208 may be implemented in the user system 205 by a system (or by a computing system) disposed in it or connected to it, and configured to specifically perform the cited methods, or may be the user system itself as a whole, that is, the same resources (e.g. memory, processor, electronic circuits, etc.) of the user system 205 may be configured to perform different tasks (for example, among other tasks, the execution of the cited methods).

[0082] By or through the network access module 206, the user system 205 may connect through the communication network 204 with the data system 200 for exchanging information between them in a secure manner. For that purpose and others, the network access module 206 may be configured to be connected to a network access point such as a router (not shown). The router may be available in the vicinity of the user system or may be disposed in the user system 205, and may be connected to the communication network 204. As described above, the established communication between the user system 205 and the data system 200 may be a secure communication. Consequently, the user system 205 and the data system 200 may exchange information (user requests, sensitive data, etc.) through the secured communication.

[0083] The web client module 207 in the user system 205 may include functionalities so as to perform web-based access through a web interface (e.g. web pages) provided by the web server module 201 in the data system 200. This way, access to sensitive (genomic) data provided by the data system 200 may be performed by the user system 205 in a web-based manner.

[0084] The third party system 209 may have a configuration based on similar principles as the ones described above with respect to the user system 205, so that a secure communication between the third party system 209 and the data system 200 may also be established. The third party system 209 may be a system of a service provider dedicated to e.g. analysing sensitive genomic data from the data system 200, for providing biologically/medically meaningful interpretation of such genomic data.

[0085] The third party system 209 may be authorised from the user system 205 to access selected subsets of sensitive genomic data associated to the user, said subsets being stored encrypted in the data system 200. How this authorization may be received and processed by the data system 200 is explained in other parts of the description. Selected subsets of genomic data may be decrypted and then provided by the data system 200 in the form of e.g. persistent views, which may be generated and stored following a host-proof model by using an asymmetric pair of keys.

[0086] In particular, the persistent views may be provided by the data system 200 encrypted with a public key (of the pair of keys) that has been previously provided by the third party system 209 to the data system 200. This provision of the public key may have occurred as a result of a registration of a service provider from the third party system 209. Selected subsets can be either downloaded or accessed within the data system 200 from the third party system 209 using corresponding private key (of the pair of keys) for decrypting the persistent views.

[0087] Examples of data systems such as the data system 100 of FIG. 1 or the data system 200 of FIG. 2 may be configured to perform a method of registration of a (new) user in the data system. This registration of the user may include creating a unique encryption key exclusively associated to the user. This encryption key may be a random key, for example, and may be used to encrypt sensitive data associated to the user, such as e.g. genomic data of the person related to the user. The encrypted sensitive data of the user may be stored in a repository or database part that may be exclusive to the user.

[0088] The unique encryption key exclusively generated for the user may be stored encrypted in the data system. The unique encryption key may be encrypted using a user key (of reference, only known by the user) and, optionally, a system key (only known by the data system). The unique encryption key may be decrypted (using the user key and, optionally, the system key) each time the data system needs to decrypt all or part of the sensitive data of the user to provide the user with access thereto. Once used, the decrypted encryption key may be immediately deleted in order to minimize the risk that an attacker can stole the encryption key.

[0089] The registration of a (new) user may further include generating a hash value of reference by hashing a user key of reference created by the user and not stored anywhere in the data system, i.e. said user key is only known by the user. The hash value of reference may be stored in the data system and used for validation purposes when performing a method of providing the user with access to sensitive data assigned to the user.

[0090] The registration of a (new) user may still further include obtaining an encrypted version of the encryption key of the user by encrypting the unique encryption key using only the system key (known by the data system and unknown by the user). This encrypted version of the encryption key may be provided to the user as a backup of the encryption key that the user may provide to the data system when the user has forgotten the current user key. Details about this backup approach will be provided in other parts of the description.

[0091] The system key, which is known by the data system and unknown by the user, may be a single key for the entire data system and, hence, for all the users having sensitive data stored in the data system. The system key may only exist in a volatile memory (e.g. RAM) of the data system for increasing the security of the system. This may be achieved by inputting the system key manually each time the data system is initiated. Avoiding storing the system key in a non-volatile memory, the risk that an attacker can retrieve the system key for malicious usage is reduced.

[0092] In a data system as the proposed ones, sensitive data associated to different users may thus be stored encrypted, each of the users having his/her data stored in a repository (or database part) individually assigned to the user. For example, according to what is shown in FIG. 1, each of the users may have an exclusively assigned database part in the Genomic Database 105 storing encrypted genomic data associated to the user. Similarly, each of the users may have an exclusively assigned database part in the Management Database 106 storing, for example, a user ID uniquely identifying the user, the encrypted unique encryption key exclusively attributed to the user, the hash value of reference, etc.

[0093] FIG. 3 illustrates a flow diagram of a method of providing access to sensitive data according to further examples. A data system equal or similar to those described with reference to previous figures may be configured to perform this method, which may be started at initial block 300.

[0094] At block 301, a user request may be received by the data system from a user system. The received user request may include a user ID uniquely identifying the user and a user key that is not stored anywhere in the data system.

[0095] At block 302, the method may include retrieving the user ID and the user key from the received user request.

[0096] At block 303, the received user key may be hashed to produce a hashed version of the user key, and said hashed version may be validated against a pre-calculated hash value of reference, which may have been obtained in the context of a registration method such as the ones explained before. The pre-calculated hash value of reference may be stored in the data system for validating received user keys whenever required. A hashed version of the received user key may be obtained by hashing the received user key using a predefined hash function that was also used to generate the pre-calculated hash value of reference.

[0097] The hashed version of the received user key may be compared with the hash value of reference. If the hashed version of the received user key coincides with the stored hash value of reference, the method may continue to block 304. Otherwise, the user may be requested to provide a valid user key up to a predetermined number of times, after which the method may be aborted, i.e. redirected to final block 309, if the received user key has not been validated successfully.

[0098] At block 304, an encrypted version of the unique encryption key exclusively assigned to the user may be retrieved from e.g. a database part in the Management Database 106 assigned to the user. This retrieval may be performed using the received user ID as unique identifier of the user, i.e. as a primary key in a relational database, for example.

[0099] The encryption key (uniquely assigned to the user) may have been initially encrypted, in e.g. a registration process such as the ones described before, exclusively using a user key of reference (only known by the user). Said initial encryption may have been performed further using a system key only known by the data system. Using such a system key may provide the data system with an increased security in the case that e.g. the user key is unexpectedly stolen by an attacker.

[0100] As explained in other parts of the description, the user may be allowed to change his/her user key as many times as desired/required. Each of said changes of the user key may require re-encrypting the encryption key assigned to the user using a user key of reference provided by the user. This aspect will be explained in detail with reference to FIG. 4.

[0101] At block 305, a decrypted version of the encryption key (associated to the user) may be obtained by decrypting the encrypted version of the encryption key retrieved at previous block 304. Said decryption may be performed using the received user key (validated at block 303) and, optionally, the system key, depending on how the encryption key has been (re)encrypted in corresponding (re)initialization process.

[0102] At block 306, all or part of the encrypted sensitive data of the user stored in the data system may be decrypted using the decrypted version of the encryption key (obtained at block 305). The received user request may further include, for example, selection data indicating which part of the sensitive data the user wants to access, such as e.g. a specific genomic region. In this sense, the encrypted sensitive data may be stored partitioned in the data system in such a way that only some partitions need to be decrypted according to the selection data included in the received user request.

[0103] At block 307, the data system may provide suitable access to the (selected) decrypted sensitive data associated to the user through a secure communication channel. As described in detail with reference to e.g. FIG. 2, said access may be provided to the user system and/or to a third party system through a secured communication between the data system and the user system and/or the third party system. This secure communication may be established according to principles equal or similar to those described in other parts of the description, such as e.g. providing persistent views following a host-proof model.

[0104] At block 308, once the provision of the access has been completed, the user key, the decrypted version of the encryption key, and the decrypted version of all or part of the sensitive data may be deleted. Alternatively, each of these deletions may be performed just after corresponding sensitive and key data is no more needed to complete the execution of the method. For example, the user key may be deleted just after the decryption of the encrypted version of the encryption key. These deletions may be explicit or implicit. An explicit deletion of data may be performed by executing an instruction specifically aimed at deleting the data. An implicit deletion may result from the completion of a software execution which may cause the deletion (from RAM memory) of all the data related with the execution.

[0105] At block 309, the execution of the method may be finalized without keeping any sensitive and key data decrypted in the data system. In particular, the user key is not kept in the data system neither encrypted nor decrypted, but it is deleted when unneeded. The user key is seen by the data system only when it is strictly required for providing access to the sensitive data in decrypted (or clear) form. Hence, access to sensitive data associated to the user is completely under control of the user, since the data system cannot provide such an access without receiving the user key from the user.

[0106] In the examples illustrated in FIG. 3, the data system may not provide access to sensitive data of the user if the user key provided by the user does not coincide with the user key (of reference) that was used in the last (re)encryption of the encryption key. In this case, the method fails the validation of the received user key (performed at block 303) and the access to sensitive data is not permitted.

[0107] FIG. 4 illustrates a flow diagram of a method of providing a user with access to sensitive data of the user, according to still further examples. Data systems similar to those disclosed in other parts of the description may be configured to perform the illustrated method, which may start at initial block 400.

[0108] At block 401, the method may include receiving, from a user system, a user request requesting access to sensitive data associated to the user, and change of the user key associated to the user.

[0109] This method may be suitable for situations in which methods according to FIG. 3 produce an unsuccessful validation of the received user key (at block 303). This unsuccessful validation may occur if e.g. the user has forgotten the user key with which his/her encryption key is currently encrypted. In these circumstances, the user may be allowed to provide the data system with a user key of reference to be used for re-encrypting the encryption key of the user.

[0110] At block 402, a user ID uniquely identifying the user, an encrypted version of the encryption key of the user, and a user key may be retrieved from the received user request. The received user key may be, in this case, a user key of reference as defined in other parts of the description. The encrypted version of the encryption key may be a backup encrypted version of the encryption key in the terms defined in other parts of the description.

[0111] The user ID may be used as a unique identifier of the user to access database parts exclusively assigned to the user for retrieving data related to the user that are necessary for performing the method. The user ID may thus be a primary key in the context of a relational database.

[0112] At block 403, the system key may be retrieved, and at block 404, a decrypted version of the encryption key may be obtained by decrypting the received encrypted version of the encryption key using (only) the system key.

[0113] At block 405, a decrypted version of all or part of the sensitive data assigned to the user ID may be obtained by decrypting all or part of the encrypted version of the sensitive data using the decrypted version of the encryption key (obtained at block 404). Similar considerations to those made with respect to block 306 of FIG. 3 may be taken into account for this block 405.

[0114] At block 406, access may be provided by the data system to the decrypted version of all or part of the sensitive data assigned to the user ID (obtained at block 405) through a secure communication channel. Similar considerations to those made with respect to block 307 of FIG. 3 may be taken into account in this case of block 406.

[0115] At block 408, the decrypted version of the encryption key obtained at previous block 404 may be encrypted using at least the user key of reference. The system key may also be used as auxiliary key, in which case the encryption key is encrypted using both the user key of reference and the system key. From this moment, sensitive data of the user may be accessed by performing methods according to FIG. 3, wherein sensitive data is decrypted using a user key that must coincide with the user key of reference.

[0116] At block 409, the encrypted version of the encryption key obtained at block 408 may be stored in e.g. a database part assigned to the user ID, which may be disposed in a Management Database 106 such as the one of FIG. 1.

[0117] At block 410, a hash value of reference (or hashed version of the user key of reference) may be obtained by hashing the user key of reference using a predefined hash function and, at block 411, said hash value of reference may be stored in a corresponding database part assigned to the user ID. This hash value of reference may be used to perform the validation of block 303 when performing methods according to FIG. 3.

[0118] At block 407, once the blocks 406, 409 and 411 have been completed, the user key of reference, the (backup) decrypted version of the encryption key, and the decrypted version of all or part of the sensitive data may be deleted. Alternatively, each of these deletions may be performed just after corresponding data is no more needed to complete the execution of the method. These deletions may be explicit or implicit as defined in other parts of the description.

[0119] At block 412, the execution of the method is finalized without keeping any sensitive and key data decrypted in the data system, as similarly explained with respect to block 309 of FIG. 3.

[0120] Although only a number of particular embodiments and examples of the invention have been disclosed herein, it will be understood by those skilled in the art that other alternative embodiments and/or uses of the invention and obvious modifications and equivalents thereof are possible. Furthermore, the present invention covers all possible combinations of the particular embodiments described. Thus, the scope of the present invention should not be limited by particular embodiments, but should be determined only by a fair reading of the claims that follow.

[0121] Further, although the examples described with reference to the drawings comprise computing apparatus/systems and processes performed in computing apparatus/systems, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the system into practice.