Secure, multi-level access to fuzzy data used for analysis

Abstract

In a computer-implemented method for providing fuzzy data to a user, firstly, a user request to access data is received; then, an authorization level associated with the received request is identified. Next, fuzzy data corresponding to the received request is accessed within a protected enclave. The accessed data is fuzzified using a fuzzing algorithm that generates a fuzziness level compatible with the identified authorization level. Finally, the accessed fuzzy data is provided to the user from the protected enclave. Related system and computer program products are also disclosed.

Description

Background Technology

[0001] This invention generally relates to the field of computer-implemented methods and systems for providing obfuscated data to a user, for example, to perform analysis based on such data. Specifically, this invention relates to a method relying on a fuzzy algorithm that generates a fuzzy level compatible with the authorization level of the user requesting such data.

[0002] Analysis involves the systematic computational analysis of data, and in particular, the collection and interpretation of patterns hidden within the data. Data analysis can therefore create value from the data. Companies can, for example, apply analysis to understand such patterns and predict business trends and / or improve business performance. Summary of the Invention

[0003] According to one aspect, the present invention is implemented as a computer-based method for providing fuzzy data to a user. First, a user request to access data is received. An authorization level associated with the received request is identified. Next, fuzzy data corresponding to the received request is accessed within a protected enclave. The accessed data is data that has been fuzzed using a fuzzing algorithm that generates a fuzziness level compatible with the identified authorization level. Finally, the accessed fuzzy data is provided to the user from the protected enclave.

[0004] After providing users with fuzzy data, users should typically perform analysis (or other cognitive operations) based on that fuzzy data.

[0005] In this method, all sensitive operations are preferably performed within a protected enclave (starting with ambiguity). This maintains security in an ecosystem where numerous users can interact with large amounts of data subject to varying access permissions. According to a preferred embodiment, this method makes it possible for users to perform analytics based on massively available data (e.g., in a data lake) while preserving data usage authorizations (e.g., as stipulated by the data owner) and complying with other potential requirements (legal, regulatory, contractual, etc.). Thus, different users may have access to the same data, but with different levels of ambiguity. Such levels establish an intermediate level of accessibility between publicly available data and completely private data.

[0006] In one embodiment, the method further includes encrypting the accessed obfuscated data within a protected enclave using a user key before providing the obfuscated data. The user key is ultimately provided to the user, in addition to the encrypted obfuscated data. In this way, all data leaving the protected enclave, besides the user key, is encrypted (for security reasons); the user can decrypt the encrypted data provided using the user key.

[0007] Preferably, the method further includes providing the user with an encrypted version of the user key and its plaintext version (from the protected enclave). Later, if necessary, the user can still request to receive the user key again (in plaintext) by providing the encrypted version of the key to the system.

[0008] In a preferred embodiment, the protected enclave communicates with the key management system, and the method further includes generating a user key at the key management system for subsequently encrypting obfuscated data.

[0009] Preferably, the protected enclave communicates with a first database storing unobfuscated data in encrypted form. In that case, obfuscated data is accessed as follows (again, within the protected enclave): First, encrypted data, which has not yet been obfuscated, is obtained from the first database. The data obtained from the first database corresponds to the data requested in the received request. Then, the encrypted data obtained from the first database is decrypted. Finally, the decrypted data is obfuscated using an obfuscation algorithm. That is, data is obfuscated on demand from data from a secure storage device.

[0010] In an embodiment, the method further includes continuously encrypting data within a protected enclave and continuously storing the resulting encrypted data on a first database. Preferably, the first database is configured as a data lake.

[0011] In a preferred embodiment, the protected enclave communicates with a second database that stores obfuscated data in encrypted form. Access to the obfuscated data may then include checking whether the data requested in the received request is already available in the second database. If so, encrypted (and obfuscated) data corresponding to the requested data is obtained from the second database. The obtained encrypted obfuscated data is then decrypted so that decrypted obfuscated data can subsequently be provided to the user. As mentioned above, the provided data will preferably be re-encrypted (before export), albeit using a different key. Otherwise, if the requested data is not yet available in the second database, encrypted data corresponding to the requested data is obtained from the first database, as described above.

[0012] Preferably, the method further includes encrypting the obfuscated data with a management key in the protected enclave, and storing the correspondingly encrypted obfuscated data in a second database. This effectively uses the second database as a cache to improve system efficiency.

[0013] As previously mentioned, the protected enclave can communicate with the key management system. Therefore, the method should preferably further include generating a management key at the key management system for encrypting obfuscated data.

[0014] In one embodiment, the received request specifies a given level of ambiguity. In this case, the ambiguity data is accessed only if the given level of ambiguity is compatible with the identified authorization level.

[0015] In a variant, the request can specify the objective to be achieved using the data referenced in the request. In this case, the accessed obfuscated data is data obfuscated using an obfuscation algorithm selected based on the objective, provided that the resulting obfuscation level is compatible with the identified authorization level.

[0016] In other variations, the request may specify a blurring algorithm. If so, the blurred data is blurred using the specified blurring algorithm, but the method further includes selecting a blur level generated by the algorithm so that the blur level is compatible with the identified authorization level.

[0017] All such variations (i.e., specifying a given fuzziness level, target, or fuzzy algorithm itself) may be offered as options in the user interface.

[0018] Various fuzzy algorithms can be envisioned. For example, fuzzy algorithms can rely on one or more of the following: naive anonymization, K-anonymity, differential privacy, homomorphic encryption, data aggregation, and data sampling.

[0019] According to another aspect, the present invention is implemented as a computer system. The system includes a request processing module and a protected enclave (e.g., each provided in a server). Consistent with the method, the request processing module is configured to receive user requests for accessing data and identify the authorization level associated with the received user request. Furthermore, this module is configured to obfuscate the data (via the protected enclave) using one or more obfuscation algorithms, which produce different obfuscation levels. Additionally, the module is designed to access the obfuscated data corresponding to the user request, wherein the data is obfuscated using one or more obfuscation algorithms to produce an obfuscation level compatible with the authorization level identified when the request is received. Finally, this module can provide the obfuscated data accessed via the protected enclave in response to the user request.

[0020] Preferably, the request processing module is further configured to: encrypt the obfuscated data accessed by the user using a user key in the protected enclave, and in response to a user request, provide the user key to the user in addition to the encrypted obfuscated data.

[0021] In one embodiment, the system further includes a key management system configured to generate such user keys. It can also communicate data with such a key management system.

[0022] Preferably, the system further includes a first database storing unambiguous data in encrypted form, and a second database storing ambiguous data in encrypted form, as previously discussed.

[0023] According to another aspect, the present invention is embodied as a computer program product for providing fuzzy data to a user. The computer program product includes a computer-readable storage medium having program instructions embodied therein. The program instructions are executable by one or more processors to cause the implementation of the steps according to the method.

[0024] Computerized systems, methods, and computer program products embodying the present invention will now be described by way of non-limiting examples and with reference to the accompanying drawings. Attached Figure Description

[0025] Preferred embodiments of the invention will now be described by way of example only and with reference to the following accompanying drawings. Throughout these individual views, the same reference numerals denote the same or functionally similar elements:

[0026] Figure 1 Selected components of a system according to an embodiment of the present invention are schematically shown;

[0027] Figure 2 This is a diagram depicting selected components of a system according to a preferred embodiment of the present invention, and the basic operations performed in the system; and

[0028] Figure 3 This is a detailed flowchart illustrating the steps of a preferred method for providing fuzzy data to a user according to an embodiment of the present invention.

[0029] The accompanying drawings illustrate a simplified representation of the device or a portion thereof involved in the embodiments. Unless otherwise specified, similar or functionally similar elements in the drawings have been assigned the same reference numerals. Detailed Implementation

[0030] Overall reference Figures 1 to 3 The first embodiment of the present invention will now be described, which relates to a computer-implemented method for providing fuzzy data to a user.

[0031] For illustration, consider the following context: Data owner 5 stores the data it generates (S200) or otherwise owns on data storage device 25, which may be configured, for example, as a data lake. Such data is typically stored encrypted, for example, via encryption server 20. Furthermore, some user 10 may want to perform analysis on such data. For this purpose, user 10 interacts with server 30, which forms a... Figure 1 This is part of a computerized ecosystem 1. Note that such a user can be any entity (person, law, and / or computerization, such as an automated process). However, in all cases, the user request is mediated via a computerized entity. That is, computerized interaction is assumed.

[0032] This method proposes processing requests from user 10 based on the user's authorization level. In response to such a request, data is provided to the user in an ambiguous (i.e., modified) form, where the level of ambiguity depends on the user's authorization level. In this context, ambiguity means altering the original data so that not all information contained in the original data is retained. That is, at least partially, the original information is lost to potentially meet different requirements.

[0033] In detail, suppose, for example, a request processing module implemented in server 30 receives a request S10, S12 from user 10 for accessing data. Then, the authorization level associated with the request (S10) is identified in order to take steps to serve the request (if possible). Note that the authorization level can be identified upon receiving the request, as part of the request itself, or even before receiving the request. Any authentication mechanism is conceivable.

[0034] Next, the ambiguous data S30-S50 in the protected enclave 32 are accessed. This data corresponds to the data addressed in the received request. The accessed data is data S50 that has been ambiguous or has been ambiguous using a suitable ambiguous algorithm. That is, the algorithm must produce ambiguous levels S12 and S14 that are compatible with the previously identified authorization level S10. Therefore, the core principle of this method is to link the data access authorization to the strength of the data ambiguous algorithm used for the ambiguous data. An example of the ambiguous algorithm will be discussed later.

[0035] Finally, the fuzzy data accessed in steps S30-S50 is provided to the requesting user 10 from the protected enclave 32 (S82). After receiving (S82) the fuzzy data 36, ​​the user 10 can perform, for example, S100 analytics, analyses, or any kind of cognitive operation based on the fuzzy data 35 provided in S82.

[0036] A protected enclave is a computerized area with restricted access. Such an enclave can, for example, simply consist of one or more private (and preferably encrypted) areas of a computer system's memory, allocated, for instance, by a set of instructions from a central processing unit (CPU). That is, such instructions allow user-level code to allocate private (and preferably encrypted) areas of memory protected from processes running even at higher privilege levels. A secure boot server with memory encryption is an example of a protected enclave when specifically designed for a single application with strict access control and limited network visibility.

[0037] A protected enclave can be further configured to restrict network access through that enclave. For example, a network enclave can be isolated from its surrounding networks to restrict access to selected entities, applications, or services on the surrounding networks. More generally, specific resources within a protected enclave can be designed to restrict interaction with external entities or networks. Access can be further restricted in other ways due to security access control mechanisms (e.g., including dedicated resources such as internal firewalls) and network admission control mechanisms.

[0038] Protected enclaves can be implemented, in particular, as virtualized, pre-integrated service-oriented architecture (SOA) platforms. Nevertheless, such platforms may host trusted applications and allow them to interact with users and other external systems (albeit in a controlled and secure manner).

[0039] Typically, any protected enclave as used herein can be implemented, for example, in hardware (e.g., a secure boot server with exclusive use) or software (e.g., based on Intel® Software Protection Extensions SGX), or in a zSeries Security Services Container (SSC).

[0040] In the current situation, all sensitive operations are performed within the protected enclave (starting with obfuscated step S50). This maintains security within the ecosystem, where numerous users interact with vast amounts of data, and their access is subject to different types and levels of authorization.

[0041] In a simple implementation, user 10 requests (S12) access to data at a given fuzzy level. For example... Figure 3 As assumed in the text, the authorization level associated with the request (i.e., the user's authorization level) S10 is identified (before or after identifying the fuzzy level expected by S10). And if the given fuzzy level identified (S10) is compatible with the identified authorization level S12, then the fuzzy data S30-S50 is accessed as described above and provided to the user in S82.

[0042] In other, more complex implementations, users can specify their objectives (e.g., the analysis to be performed on such data), in which case the system automatically selects an appropriate algorithm, or the level of fuzziness produced by that algorithm, as discussed in detail later.

[0043] By convention, authorization levels can be defined such that the highest authorization level allows access to data with any fuzzy level. For example, similar to privilege levels in the Intel x86 instruction set, authorization levels can range from 0 (highest privilege) to n > 0, where n has fewer privileges than n – 1, n – 1 has fewer privileges than n – 2, and so on. Therefore, any resource available for level n will also be available for authorization levels 0 to n. Similarly, fuzzy levels can be encoded from 0 (corresponding to low-level changes) to m > 1 (corresponding to higher-level changes). Thus, given a desired data fuzzy level of 1 and a data access authorization level k identified by the requester, access to the requested data is allowed only if the authorization level is higher than (in terms of privilege) or equal to the data fuzzy level (i.e., if l ≤ k). Therefore, authorized users with high authorization levels (e.g., data owners) can typically access data with any fuzzy level.

[0044] Since the data 36 ultimately provided (S82) is obfuscated, all rights attached to the data provided (S82) can be complied with by taking into account the requester's level of authorization.

[0045] As the inventors have already realized, this method makes it possible for users to perform analytics based on large-scale available data (e.g., in a data lake) while retaining data use authorizations as specified by the data owner and / or in accordance with other requirements. All of these will now be described in detail with reference to specific embodiments of the invention.

[0046] First, see Figure 3 This method may further include encrypting the obfuscated data accessed in S64 within the protected enclave 32 using a user key. Step S64 is performed before providing the obfuscated data in S82 to the user. In addition to the encrypted obfuscated data, the user key in S82 is provided to the user 10. In this way, for security reasons, all data 36 leaving the protected enclave is encrypted (in addition to the user key); however, the user can use the provided user key to decrypt the provided data.

[0047] In this embodiment, in addition to the plaintext version of the key, an encrypted version of the user key can be further provided to user 10 (S82) from the protected enclave 32. In this way, the user can first decrypt the provided data based on the provided (plaintext) user key and then delete the key (for security reasons). Later, if necessary, the user can still request to receive the user key again (in plaintext form) by providing an encrypted version of the key (here envisioned as a symmetric encryption scheme).

[0048] A user key is, for example, a cryptographic key generated for a user via a key management system (KMS). Figure 1 As shown, the protected enclave 32 can, for example, communicate with the KMS 40. Therefore, the latter can be relied upon to generate the S62 user key, which is received in the protected enclave 32 and subsequently used to encrypt the S64 obfuscated data. The KMS can be a hierarchical key management system (HKMS): the user key can, for example, be a user-level key generated at a given hierarchical level of the HKMS using methods known per se.

[0049] In one embodiment, the protected enclave 32 communicates with a first database 25 (e.g., a data lake) that stores unobfuscated data in encrypted form. In that case, the encrypted data obtained in S22 can be first obtained from the database 25, and then the encrypted data, corresponding to the data requested in the received request S10, can be accessed in the protected enclave 32. Next, the encrypted data obtained in S22 is decrypted in S40, S42 to S44 (still in the protected enclave 32), and then the decrypted data is obfuscated in S50 using an appropriately selected obfuscation algorithm. That is, the data is obfuscated on demand, originating from data generated from the secure storage device 25. Again, the decryption process S40 can advantageously involve a KMS, i.e., the decryption S44 can first request access to the key (e.g., master key) from the KMS in S42.

[0050] like Figure 1 and Figure 2 As shown, data can be continuously generated by the data owner 5 (S200) and thus continuously encrypted (S15) (e.g., by a dedicated server 20) and stored on the first database 25. Note that the encryption step S15 is preferably also performed in a protected enclave 22, which does not necessarily correspond to the enclave 32 provided in the server 30. Instead, the enclave 22 can be provided in a dedicated encryption server 20, which is used to store the owner data on the storage device 25.

[0051] As mentioned earlier, the first database 25 can be configured, for example, as a data lake, i.e., a storage repository that holds large amounts of raw or granular data in its native format. Data lakes typically rely on Hadoop-compatible object storage, where an organization's data is loaded into the Hadoop platform. Business analytics and data mining tools can then be applied to the data residing on the Hadoop cluster. However, depending on the organization's needs and objectives, data lakes can also be used effectively without Hadoop. More generally, a data lake is a large pool of data in which schemas and data requirements are typically not defined before the data is queried.

[0052] In this context, data owners can specify the desired level of ambiguity, for example, based on the data user's trust level. As a result, different users may have access to the same data (but with different levels of ambiguity). Such ambiguity establishes an intermediate level of accessibility between publicly available data and completely private data.

[0053] See still Figure 1 and 3 The protected enclave 32 preferably communicates with the second database 35. The obfuscated data S50 is later stored in encrypted form (e.g., in response to a previous query). In this case, typically the obfuscated data S30-S50 should be accessed by first checking whether the data requested in S18 is already available in the second database 35. If it is determined that the requested data is indeed available in database 35 (S18: yes), an encrypted version of the obfuscated data S21 (which is loaded in the protected enclave) is obtained from that database 35. Then, the obtained data S21 is decrypted (S30, S32-S34, e.g., by obtaining the S32 key from the KMS, e.g., the master key), and subsequently provided to user 10 in S60, S82. Otherwise, as previously described, if it is determined in step S18 that the requested data is not available in the second database 35, the requested data is obtained from the first database 25 and decrypted before being obfuscated and transmitted to the user.

[0054] As in Figure 3As shown in the flowchart, to make the system more efficient, the data that has been obfuscated (S50) needs to be stored in a second database (35) that is effectively used as a cache. Specifically, the recently obfuscated data (S50) can first be encrypted (S70, S72–S74, in the protected enclave (32)) using a management key (different from the user key), and then stored (S90) in the second database (35). Similarly, a key provided by KMS40 can be used. That is, the management key used to encrypt the obfuscated data (S72) in S74 can be obtained from the KMS and used in the protected enclave (32). Once S90 is stored in the second database, the obfuscated data can be easily used for subsequent related queries (S10–S18: yes, S21).

[0055] like Figure 3 As assumed, the request received in S12 may have already specified a given, desired level of ambiguity. In this case, the ambiguity data in S30-S50 is accessed only if the specified ambiguity level is compatible with the authorization level identified in step S10 (S14: Yes).

[0056] In more complex methods, the received request may specify a goal (e.g., in terms of analysis) to be achieved using the data pointed to in the request. In that case, the system may automatically select a blurring algorithm (according to the goal) in step S50 or access cached data that has already been blurred with a suitable algorithm. In all cases, the system ensures that the accessed data S30-S50 is data that has been blurred using the blurring algorithm selected according to the goal, provided that the resulting blurring level is compatible with the identified authorization level.

[0057] The received request can specifically specify the objective to be achieved in relation to the analysis to be performed using such data, and the fuzzy algorithm is selected based on said objective. For example, a user might want to reveal trends from data range queries, counts, etc. In this case, the resulting fuzziness could be equivalent to anonymized histogram / sketch-based counting schemes, etc.

[0058] In other methods, the received request may specify the desired fuzzing algorithm itself. In that case, the fuzzy data accessed in S30-S50 is fuzzed using the specified fuzzing algorithm, but the system selects a fuzziness level generated by the algorithm so that this level is compatible with the previously identified authorization level (an error message is returned if this is not possible). For example, a set of standard fuzzing algorithms may be available, in which case the user is invited to select a given algorithm.

[0059] Note that the user interface or program used to implement user queries may provide the user with several options, including those mentioned above, so that the user can select the fuzziness level, specify the target, or the fuzzy algorithm itself.

[0060] Such algorithms can specifically include naive anonymization algorithms, k-anonymization algorithms, differential privacy algorithms, homomorphic encryption attribute-preserving algorithms, data aggregation algorithms, and / or sampling algorithms, etc. All such algorithms modify the original information in different ways and potentially with varying strengths. That is, different intermediate levels of accessibility can therefore be provided. In all cases, access is provided only if the specified algorithm is compatible with the user's access level.

[0061] See now for more details. Figure 1 and 2 Another embodiment of the invention will now be described, relating to a computerized system 1. Certain features of such a system have been implicitly described with reference to this method and will be described only briefly below. Such a system 1 includes at least a request processing module, typically implemented in software at a server 30.

[0062] The system (e.g., server 30) is otherwise designed to provide (i.e., form) a protected enclave 32 in hardware and / or software. In all cases, the request processing module is configured to perform the steps described previously, namely, receiving a user request to access data, identifying the authorization level associated with the request, and performing the sensitive operations S30-S70 as discussed previously. That is, the request processing module is adapted to obfuscate the data using one or more obfuscation algorithms (via the protected enclave 32) to provide different levels of obfuscation. The module is otherwise configured to access the obfuscated data corresponding to the user request.

[0063] As previously discussed, it is possible to cache obfuscated data. However, in all cases, one or more obfuscation algorithms are used to obfuscate, or should already be obfuscated, the data to produce an obfuscation level compatible with the authorization level for user identification. Finally, in response to a user request, the module provides the obfuscated data as accessed via Protected Enclave 32.

[0064] As discussed, in addition to the encrypted obfuscated data, the request processing module can be further configured to encrypt the obfuscated data using the user key before transmitting the user key to the user. System 1 may specifically include (or be designed to communicate with) a KMS40 adapted to generate such a user key, as well as any keys required by the system when performing the operations described prior to steps S30, S40, S60, and S70.

[0065] In addition, system 1 should preferably include a first database 25 (which stores unambiguous data in encrypted form) and a second database 35 (which stores already ambiguous data in encrypted form), the latter serving as a cache.

[0066] Next, according to another embodiment, the present invention can be further implemented as a computer program product for providing fuzzy data to a user. This computer program product includes a computer-readable storage medium having program instructions embodied therein. The program instructions can be executed by one or more processors (e.g., server 30) to cause the steps as previously described with reference to this method to be performed.

[0067] Therefore, the present invention can be a system, method, and / or computer program product at any possible level of integration technical detail. The computer program product may comprise a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0068] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices (such as perforated cards or raised structures in grooves having instructions recorded thereon), and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0069] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network may include copper transmission cables, optical fiber transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the corresponding computing / processing device.

[0070] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as C or similar languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet provided by an Internet service provider). In some embodiments, electronic circuitry (including, for example, programmable logic circuitry, a field-programmable gate array (FPGA), or a programmable logic array (PLA)) may execute the computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this invention.

[0071] This document describes aspects of the invention with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0072] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, which, when executed by the processor of the computer or other programmable data processing apparatus, creates means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium having the instructions stored therein includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0073] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other apparatus, other programmable apparatus or other device that causes a series of operational steps to be performed on the computer to produce a computer-implemented process, such that the instructions that execute on the computer, other programmable apparatus or other device perform the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0074] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, segment, or part of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions marked in the blocks may occur in a different order than indicated in the figures. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0075] While the invention has been described with reference to a limited number of embodiments, variations, and drawings, those skilled in the art will understand that various changes can be made and equivalents can be substituted without departing from the scope of the invention. Specifically, features (similar devices or similar methods) listed in a given embodiment or variation or shown in the drawings may be combined with or substituted for another feature in another embodiment, variation, or drawing without departing from the scope of the invention. Accordingly, different combinations of features described with respect to any of the foregoing embodiments or variations are contemplated, which remain within the scope of the appended claims. Furthermore, many minor modifications can be made to adapt particular situations or materials to the teachings of the invention without departing from its scope. Therefore, the invention is not intended to be limited to the specific embodiments disclosed, but rather the invention will include all embodiments falling within the scope of the appended claims. In addition, many other variations besides those explicitly stated above are contemplated.

Claims

1. A computer-implemented method for providing obfuscated data to a user, the method comprising: receiving a request from a user to access data; identifying an authorization level associated with the received request; in a protected enclave, accessing obfuscated data corresponding to the received request, wherein the accessed data has been obfuscated with an obfuscation algorithm that produces an obfuscation level compatible with the identified authorization level; and providing the accessed obfuscated data from the protected enclave to the user, wherein the protected enclave is in data communication with a first database that stores non-obfuscated data in encrypted form and with a second database that stores obfuscated data in encrypted form, wherein accessing the obfuscated data comprises, in the protected enclave, checking whether data requested in the received request is already available in the second database, if so, obtaining encrypted obfuscated data corresponding to the requested data from the second database, and decrypting the obtained encrypted obfuscated data so as to be able to subsequently provide the decrypted obfuscated data to the user, otherwise, obtaining encrypted data corresponding to the data requested in the received request from the first database, decrypting the obtained encrypted data, and obfuscating the decrypted data using the obfuscation algorithm.

2. The method of claim 1, wherein the method further comprises: prior to providing the obfuscated data, encrypting the accessed obfuscated data in the protected enclave with a user key, and providing the user key to the user in addition to the encrypted obfuscated data.

3. The method of claim 2, wherein the method further comprises: providing the user key to the user from the protected enclave in an encrypted version and in a clear version.

4. The method of claim 2, wherein the protected enclave is in data communication with a key management system, and the method further comprises generating the user key for subsequently encrypting the obfuscated data at the key management system.

5. The method of claim 1, wherein the method further comprises continuously encrypting data in the protected enclave and continuously storing the resulting encrypted data on the first database.

6. The method of claim 5, wherein the first database is a data lake.

7. The method of claim 1, wherein the method further comprises encrypting the obfuscated data in the protected enclave with a management key and storing the correspondingly encrypted obfuscated data on the second database.

8. The method of claim 7, wherein the protected enclave is in data communication with a key management system, and the method further comprises generating the management key for encrypting the obfuscated data at the key management system.

9. The method of claim 1, wherein the received request specifies a given obfuscation level; and the obfuscated data is accessed only if the given obfuscation level is compatible with the identified authorization level.

10. The method of claim 1, wherein the received request also specifies a target to be achieved with the data pointed to in the request; and the accessed obfuscated data comprises data that has been obfuscated with an obfuscation algorithm selected according to the target, provided that the resulting obfuscation level is compatible with the identified authorization level.

11. The method of claim 1, wherein, the received request also specifies an obfuscation algorithm; and the accessed obfuscated data comprises data that has been obfuscated with the specified obfuscation algorithm, and the method further comprises selecting an obfuscation level produced by the algorithm so that the obfuscation level is compatible with the identified authorization level.

12. The method of claim 1, wherein, the obfuscation algorithm relies on one or more of: naive anonymization, K-anonymization, differential privacy, homomorphic encryption, data aggregation, and data sampling.

13. The method of claim 1, wherein, the method further comprises, after the user has been provided with the accessed obfuscated data, performing an analysis based on the provided obfuscated data.

14. A computer system for providing obfuscated data to a user, comprising: a request processing module; a first database storing non-obfuscated data in encrypted form; a second database storing obfuscated data in encrypted form; and a protected enclave in data communication with the first and second databases, wherein the request processing module is configured to: receive a user request to access data; identify an authorization level associated with the received user request; and via the protected enclave, obfuscate data with one or more obfuscation algorithms that produce different levels of obfuscation, and access obfuscated data corresponding to the user request, wherein the data is obfuscated with one or more of the obfuscation algorithms so as to produce an obfuscation level that is compatible with the identified authorization level, wherein accessing the obfuscated data comprises: checking whether the data requested in the received request is already available in the second database, if so, obtaining encrypted obfuscated data corresponding to the requested data from the second database, and decrypting the obtained encrypted obfuscated data so as to enable subsequent provision of the decrypted obfuscated data to the user, otherwise, obtaining encrypted data corresponding to the data requested in the received request from the first database, decrypting the obtained encrypted data, and obfuscating the decrypted data using the obfuscation algorithms; and providing the obfuscated data accessed via the protected enclave in response to the user request.

15. The computer system of claim 14, wherein the request processing module is further configured to: encrypt the obfuscated data accessed by the user with a user key in the protected enclave, and provide the user key to the user in addition to the encrypted obfuscated data in response to a user request.

16. The computer system of claim 15, wherein the system further comprises a key management system adapted to generate the user key.

17. The computer system of claim 15, wherein, the system is operable to: providing, from the protected enclave, to the user, an encrypted version of the user key and a clear version of the user key.

18. The computer system of claim 15, wherein, the protected enclave is in data communication with a key management system, and the system is operable to generate, at the key management system, the user key for subsequent encryption of the obfuscated data.

19. The computer system of claim 14, wherein, the system further comprises means for continuously encrypting data in the protected enclave; and means for continuously storing the resulting encrypted data on the first database.

20. The computer system of claim 19, wherein, the first database is a data lake.

21. The computer system of claim 14, wherein, the system further comprises means for encrypting the obfuscated data in the protected enclave with a management key; and means for storing the correspondingly encrypted obfuscated data on the second database.

22. The computer system of claim 21, wherein, the protected enclave is in data communication with a key management system, and the system further comprises means for generating, at the key management system, the management key for encryption of the obfuscated data.

23. The computer system of claim 14, wherein, the received request specifies a given level of obfuscation; and the obfuscated data is accessed only if the given level of obfuscation is compatible with the identified level of authorization.

24. The computer system of claim 14, wherein, the received request further specifies a goal to be achieved with the data pointed to in the request; and the accessed obfuscated data includes data that has been obfuscated with an obfuscation algorithm selected according to the goal, provided that the resulting level of obfuscation is compatible with the identified level of authorization.

25. The computer system of claim 14, wherein, the received request further specifies an obfuscation algorithm; and the accessed obfuscated data includes data that has been obfuscated with the specified obfuscation algorithm, and the method further comprises selecting a level of obfuscation produced by the algorithm so that this level of obfuscation is compatible with the identified level of authorization.

26. The computer system of claim 14, wherein, the obfuscation algorithm relies on one or more of the following: naive anonymization, K-anonymization, differential privacy, homomorphic encryption, data aggregation, and data sampling.

27. The computer system of claim 14, wherein, the system further comprises means for performing analysis based on the provided obfuscated data after the obfuscated data has been provided to the user.

28. A computer program product for providing obfuscated data to a user, the computer program product comprising program instructions executable by one or more processors to cause the one or more processors to perform the method of any one of claims 1 to 13.

Images