US11416633B2 - Secure, multi-level access to obfuscated data for analytics - Google Patents

Secure, multi-level access to obfuscated data for analytics Download PDF

Info

Publication number
US11416633B2
US11416633B2 US16/278,028 US201916278028A US11416633B2 US 11416633 B2 US11416633 B2 US 11416633B2 US 201916278028 A US201916278028 A US 201916278028A US 11416633 B2 US11416633 B2 US 11416633B2
Authority
US
United States
Prior art keywords
data
obfuscated
user
obfuscation
database
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US16/278,028
Other versions
US20200265159A1 (en
Inventor
Martin Schmatz
Navaneeth Rameshan
Patricia M. Sagmeister
Yiyu Chen
Mitch Gusat
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US16/278,028 priority Critical patent/US11416633B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SAGMEISTER, PATRICIA M., CHEN, YIYU, GUSAT, MITCH, RAMESHAN, NAVANEETH, SCHMATZ, MARTIN
Priority to DE112020000134.2T priority patent/DE112020000134T5/en
Priority to JP2021539099A priority patent/JP2022520323A/en
Priority to PCT/IB2020/051074 priority patent/WO2020165756A1/en
Priority to CN202080012938.9A priority patent/CN113396415A/en
Priority to GB2111724.7A priority patent/GB2595167A/en
Publication of US20200265159A1 publication Critical patent/US20200265159A1/en
Publication of US11416633B2 publication Critical patent/US11416633B2/en
Application granted granted Critical
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245Protecting personal data, e.g. for financial or medical purposes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/16Obfuscation or hiding, e.g. involving white box
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42Anonymization, e.g. involving pseudonyms

Definitions

  • the invention relates in general to the field of a computer-implemented methods and systems for providing obfuscated data to users, e.g., to perform analytics based on such data.
  • it is directed to methods relying on obfuscation algorithms that yield levels of obfuscation that are compatible with authorization levels of users requesting such data.
  • Analytics relate to the systematic computational analysis of data and notably comprise the acquisition and interpretation of patterns hidden in data. Analytics on data can thus create value out of data. Companies may for instance apply analytics to data to understand such patterns and predict business trends and/or improve business performance.
  • the present invention is embodied as a computer-implemented method for providing obfuscated data to users.
  • a user request to access data is received.
  • An authorization level associated with the request received is identified.
  • obfuscated data corresponding to the request received are accessed in a protected enclave.
  • the data accessed are data that have been obfuscated with an obfuscation algorithm that yields a level of obfuscation compatible with the authorization level identified.
  • the obfuscated data accessed are provided to the user, from the protected enclave.
  • obfuscated data After obfuscated data have been provided to the user, the latter shall typically perform analytics (or other cognitive operations), based on the obfuscated data.
  • the method further comprises, prior to providing the obfuscated data, encrypting the obfuscated data accessed with a user key, in the protected enclave.
  • the user key is eventually provided to the user, in addition to the encrypted obfuscated data. This way, all data leaving the protected enclave is encrypted (for security reasons), except the user key; the user can decrypt the encrypted data provided using this user key.
  • the method further comprises providing (from the protected enclave) an encrypted version of the user key to the user, in addition to a plain version thereof. Later on, the user may nevertheless still request receiving the user key again (in plain form), if necessary, by providing the encrypted version of the key to the system.
  • the protected enclave is in data communication with a key management system and the method further comprises generating, at said key management system, the user key used to subsequently encrypt the obfuscated data.
  • the protected enclave is in data communication with a first database storing non-obfuscated data, in encrypted form.
  • obfuscated data are accessed as follows (again, in the protected enclave).
  • encrypted data are obtained from the first database, which data are not obfuscated yet.
  • the data obtained from the first database are data that correspond to data as requested in the request received.
  • the encrypted data obtained from the first database are decrypted.
  • the decrypted data are finally obfuscated using said obfuscation algorithm. I.e., data are obfuscated on demand, from data arising from a secure storage.
  • the method further comprises continually encrypting data, in a protected enclave, and continually storing the resulting encrypted data on the first database.
  • the first database is configured as a data lake.
  • the protected enclave is in data communication with a second database, which stores obfuscated data, in encrypted form. Access to the obfuscated data may then comprise checking whether the data as requested in the request received are already available in the second database. If so, then the encrypted (and obfuscated) data, which correspond to the requested data, are obtained from the second database. The encrypted, obfuscated data obtained are then decrypted, so as to be able to subsequently provide the decrypted obfuscated data to the user. As noted above, the data provided will preferably be re-encrypted (prior to being exported), albeit with a different key. Else, if the data requested are not already available in the second database, then encrypted data corresponding to requested data are obtained from the first database, as described above.
  • the method further comprises encrypting, in the protected enclave, the obfuscated data with a management key, and storing the accordingly encrypted, obfuscated data on the second database.
  • the second database is effectively used as a cache, to improve efficiency of the system.
  • the protected enclave may be in data communication with a key management system.
  • the method shall preferably further comprise generating, at said key management system, the management key used to encrypt the obfuscated data.
  • the request received specifies a given level of obfuscation.
  • the obfuscated data are accessed only if said given level of obfuscation is compatible with the authorization level identified.
  • the request may specify a goal to be achieved with data referred to in the request.
  • the obfuscated data accessed are data obfuscated with an obfuscation algorithm selected in accordance with said goal, provided that the resulting level of obfuscation is compatible with the authorization level identified.
  • the request may specify an obfuscation algorithm. If so, the obfuscated data are obfuscated with the obfuscation algorithm specified, but the method further comprises selecting a level of obfuscation produced by this algorithm, so as for this obfuscation level to be compatible with the authorization level identified.
  • the obfuscation algorithm may rely on one or more of the following: naive anonymization, K-anonymity, differential privacy, homomorphic-encryption, data aggregation, and data sampling.
  • the invention is embodied as a computerized system.
  • the system comprises a request processing module and a protected enclave, e.g., each provided in a server.
  • the request processing module is configured to receive a user request to access data and identify an authorization level associated with a user request received.
  • this module is adapted to obfuscate data (via the protected enclave) with one or more obfuscation algorithms, the latter yielding different levels of obfuscation.
  • this module is designed to access obfuscated data corresponding to user requests, wherein the data are obfuscated with one or more of the obfuscation algorithms, so as to yield a level of obfuscation that is compatible with an authorization level identified upon receiving a request.
  • this module may, in response to user requests, provide obfuscated data accessed via the protected enclave.
  • the request processing module is further configured to encrypt, in the protected enclave, obfuscated data it accesses with a user key, and provide, in response to a user request, such a user key to the user in addition to encrypted obfuscated data.
  • the system further comprises a key management system adapted to generate such a user key. It may else be in data communication with such a key management system.
  • the system further comprises a first database storing non-obfuscated data, in encrypted form, and a second database storing obfuscated data, in encrypted form, as discussed earlier.
  • the invention is embodied as a computer program product for providing obfuscated data to users.
  • the computer program product comprises a computer readable storage medium having program instructions embodied therewith.
  • the program instructions are executable by one or more processors, to cause to implement steps according to the present methods.
  • FIG. 1 schematically represents selected components of a system according to embodiments
  • FIG. 2 is a diagram depicted selected components of the system, together with basic operations performed in the system, as in embodiments;
  • FIG. 3 is a detailed flowchart illustrating steps of a preferred method for providing obfuscated data to users, according to embodiments.
  • FIGS. 1-3 a first aspect of the invention is now described, which concerns a computer-implemented method for providing obfuscated data to users.
  • Data owners 5 store data they produce S 200 or otherwise own on data storage means 25 , which may for instance be configured as a data lake. Such data are typically stored encrypted, e.g., via an encryption server 20 . Besides, some users 10 may want to perform analytics on such data. To that aim, users 10 interact with a server 30 , which forms part of a computerized ecosystem 1 as shown in FIG. 1 . Note, such users can be any entity (human, legal, and/or computerized, e.g., an automated process). However, in all cases, the user requests are mediated via a computerized entity. That is, computerized interactions are assumed.
  • What the present methods propose is to handle requests from users 10 based on authorization levels of the users.
  • data are supplied to the user in obfuscated form (i.e., altered), wherein the level of obfuscation of the data provided depends on the authorization levels of the users.
  • obfuscation means altering the original data, so as not to retain all of the information contained in the original data. I.e., the original information is at least partly lost, so as to potentially comply with various requirements, such as originating from authorizations set by the owners, privacy law, and regulatory needs, for example.
  • data provided back to the users 10 are never intended to infringe or circumvent any legal provision.
  • a request S 10 , S 12 to access data from is received from a user 10 , e.g., at a request processing module implemented in a server 30 .
  • An authorization level associated with the request is then identified S 10 , in order to take steps to serve this request (if possible). Note, this authorization level may be identified upon receiving the request, or as part of the request itself, or even before receiving the request. Any authentication mechanism may be contemplated.
  • obfuscated data are accessed S 30 -S 50 in a protected enclave 32 , which data are data corresponding to data addressed in the request received.
  • the data accessed are data that are or have been obfuscated S 50 with a suitable obfuscation algorithm. I.e., this algorithm must yield a level of obfuscation that is compatible S 12 , S 14 with the authorization level identified S 10 earlier.
  • a core principle of the present methods is to link data access authorization to the strength of the data obfuscating algorithm used to obfuscate the data. Examples of obfuscation algorithms are discussed later.
  • the obfuscated data accessed at steps S 30 -S 50 are provided S 82 from the protected enclave 32 to the requesting user 10 .
  • users 10 may at S 102 decrypt the obfuscated data, at S 104 delete the plain version of the user-level key, and at S 106 perform analytics, analyses or any kind of cognitive operations based on the obfuscated data 36 provided at S 82 .
  • a protected enclave is a computerized area of restricted access.
  • Such an enclave may, for example, simply consist of one or more private (and preferably encrypted) regions of the memory of a computerized system, e.g., allocated thanks to a set of central processing unit CPU instructions. I.e., such instructions allow user-level code to allocate private (and preferably encrypted) regions of memory, which are protected from processes run even at higher privilege levels.
  • a secure boot server with memory encryption when used exclusively for a single application with strict access control and limited network visibility is an example of a protected enclave.
  • a protected enclave may further be configured so as to limit network access through this enclave.
  • a network enclave may be separated from its surrounding network so as to limit access thereto to selected entities, applications or services of the surrounding network.
  • the specific resources of the protected enclave may be designed so as to restrict interactions with external entities or networks. Access may otherwise be restricted thanks to secure access control means, e.g., including dedicated resources such as internal firewalls, and network admissions control means.
  • the protected enclave may notably be implemented as a virtualized, pre-integrated service-oriented architecture (SOA) platform. Still, this platform may possibly host trusted applications and allow them to interact with users and other external systems, though in a controlled and secure manner.
  • SOA service-oriented architecture
  • any protected enclave as used herein may be implemented in hardware (e.g., secure boot server with exclusive use) or in software (e.g., based on Intel Software Guard Extensions SGX), or zSeries Secure Service Containers (SSC), for example.
  • hardware e.g., secure boot server with exclusive use
  • software e.g., based on Intel Software Guard Extensions SGX), or zSeries Secure Service Containers (SSC), for example.
  • SSC zSeries Secure Service Containers
  • a user 10 requests S 12 to access data at a given level of obfuscation.
  • the authorization level associated with the request i.e., the authorization level of the user
  • the authorization level associated with the request is identified S 10 (prior to or after identifying S 10 the level of obfuscation desired), as assumed in FIG. 3 .
  • the given level of obfuscation identified S 10 is compatible with the authorization level identified S 12 , then obfuscated data are accessed S 30 -S 50 as described earlier and supplied S 82 to the user.
  • the user may specify his/her goals (e.g., in terms of analytics to be performed on such data), in which case the system automatically selects a suitable algorithm, or a level of obfuscation produced by the algorithm, as discussed later in detail.
  • his/her goals e.g., in terms of analytics to be performed on such data
  • the system automatically selects a suitable algorithm, or a level of obfuscation produced by the algorithm, as discussed later in detail.
  • the authorization level may range from 0 (most privileged) to n>0, where n is less privileged than n ⁇ 1, which is less privileged than n ⁇ 2, etc.
  • any resource available to level n would also be available to authorization levels 0 to n.
  • the obfuscation level may thus similarly be coded from 0 (corresponding to a low level of alteration) to m>1 (corresponding to a higher level of alteration).
  • an authorized user having a high authorization level may typically access data having any level of obfuscation
  • the present approach makes it possible to allow users to perform analytics based on data massively available, e.g., in a data lake, while preserving data usage authorizations as stipulated by the data owners and/or complying with other requirements. All this is now described in detail, in reference to particular embodiments of the invention.
  • the present methods may further comprise encrypting S 64 the obfuscated data accessed with a user key, in the protected enclave 32 .
  • Step S 64 is carried out prior to providing S 82 the obfuscated data to the user.
  • the user key is provided (i.e., supplied) S 82 to the user 10 , in addition to the encrypted, obfuscated data. This way, all data 36 leaving the protected enclave is encrypted (except the user key), for security reasons; the user can nevertheless decrypt the data provided using the user key provided.
  • an encrypted version of the user key may further be provided S 82 to the user 10 (from the protected enclave 32 ), in addition to a plain version of the key.
  • the user can first decrypt the data provided based on the (plain) user key provided, and then delete this key (for security reasons). Later on, if necessary, the user may nevertheless still request receiving the user key again (in plain form), by providing the encrypted version of the key (a symmetric encryption scheme is here contemplated).
  • the user key is a cryptographic key generated for the user, e.g., via a key management system (KMS).
  • KMS key management system
  • the protected enclave 32 may for example be in data communication with a KMS 40 .
  • the latter may thus be relied on to generate S 62 the user key, which is received in the protected enclave 32 and subsequently used to encrypt S 64 the obfuscated data.
  • the KMS may possibly be a hierarchical key management system (HKMS): the user key may for instance be a user-level key 60 that is generated at a given hierarchical level of the HKMS, according to methods known per se.
  • the protected enclave 32 is in data communication with a first database 25 (e.g., a data lake) storing non-obfuscated data, in encrypted form.
  • encrypted data may first be obtained S 22 from this database 25 and then be accessed in the protected enclave 32 , wherein said encrypted data correspond to data as requested in the request received S 10 .
  • the encrypted data obtained S 22 are decrypted S 40 , S 42 -S 44 (still in the protected enclave 32 ), and the decrypted data are then obfuscated S 50 using a suitably selected obfuscation algorithm.
  • the decryption process S 40 may advantageously involve a KMS, i.e., the decryption S 44 may first require accessing S 42 a key (e.g., a master key 50 ) from the KMS.
  • a key e.g., a master key 50
  • data may be continually produced S 200 by data owners 5 and hence continually encrypted S 15 (e.g., thanks to a dedicated server 20 ) and stored on the first database 25 .
  • the encryption step S 15 is preferably performed in a protected enclave 22 too, which does not necessarily correspond to the enclave 32 provided in the server 30 . Rather, the enclave 22 may be provided in a dedicated encryption server 20 , used to store owner data on the storage 25 .
  • the first database 25 may for instance be configured as a data lake, i.e., a storage repository that holds a huge amount of raw or refined data in native format.
  • a data lake typically relies on Hadoop-compatible object storage, according to which organization's data are loaded into a Hadoop platform. Then, business analytics and data-mining tools can possibly be applied to the data where it resides on the Hadoop cluster.
  • data lakes can also be used effectively without incorporating Hadoop, depending on the needs and goals of the organization. More generally, a data lake is a large data pool in which the schema and data requirements are typically not defined until the data is queried.
  • the data owners may for example specify the required obfuscation levels as a function of the trust levels of the data users. As a result, different users may possibly get access to the same data, but with different obfuscation levels. Such levels institute intermediate levels of accessibility between publicly available data and fully private data.
  • the protected enclave 32 is preferably in data communication with a second database 35 .
  • the latter store data that have already been obfuscated S 50 (e.g., in response to previous queries), in encrypted form.
  • obfuscated data shall typically be accessed S 30 -S 50 by first checking S 18 whether the requested data are already available in the second database 35 . If it is determined that the requested data are indeed already available in the database 35 (S 18 : Yes), then encrypted versions of such obfuscated data are obtained S 21 from this database 35 (they are loaded in the protected enclave).
  • the data obtained S 21 are then decrypted S 30 , S 32 -S 34 (e.g., by obtaining S 32 a key from a KMS, e.g., a master key), and subsequently provided S 60 , S 82 to the user 10 .
  • a KMS e.g., a master key
  • S 60 e.g., S 82
  • the requested data are obtained from the first database 25 and decrypted, prior to being obfuscated and passed to the user, as described earlier.
  • data that need be obfuscated S 50 are then stored on the second database 35 , effectively working as a cache, as seen in the flowchart of FIG. 3 . That is, data that have been recently obfuscated S 50 may first be encrypted S 70 , S 72 -S 74 (in the protected enclave 32 ), using a management key (different from the user keys), and then stored S 90 on the second database 35 . Again, use can be made of keys provided by a KMS 40 . I.e., the management key used to encrypt S 74 the obfuscated data may be obtained S 72 from a KMS, for use in the protected enclave 32 . Once stored S 90 on the second database, obfuscated data are readily available for subsequent, related queries (S 10 -S 18 : Yes, S 21 ).
  • the request received S 12 may already specify a given, desired level of obfuscation.
  • obfuscated data are accessed S 30 -S 50 only if the specified level of obfuscation is compatible (S 14 : Yes) with the authorization level identified at step S 10 . Otherwise, exit at S 16 .
  • the request received may specify a goal to be achieved with the data referred to in the request (e.g., in terms of analytics).
  • the system may automatically select the obfuscation algorithm at step S 50 (in accordance with said goal) or access cached data that have previously been obfuscated with a suitable algorithm.
  • the system makes sure that the data accessed S 30 -S 50 are data that have been obfuscated S 50 with an obfuscation algorithm selected in accordance with said goal, provided that the resulting level of obfuscation is compatible with the authorization level identified.
  • the request received may notably specify a goal to be achieved in terms of analytics to be performed with such data and the obfuscation algorithm is selected in accordance with said goal.
  • the user may want to uncover trends from data range queries, counts, etc.
  • the obfuscation produced may be equivalent to anonymized histograms/sketch-based counting schemes, etc.
  • the request received may specify the desired obfuscation algorithm itself.
  • the obfuscated data accessed S 30 -S 50 are obfuscated with the obfuscation algorithm specified, but the system selects a level of obfuscation produced by the algorithm, so as for this level to be compatible with the authorization level identified earlier (if not possible, an error message is returned).
  • a standard set of obfuscation algorithms may be available, in which case the user is invited to select a given algorithm.
  • the user interface or program used to enable user queries may provide several options to users, including those mentioned above, whereby users may thus either select an obfuscation level, specify a goal or the obfuscation algorithm itself.
  • Such algorithms may notably include naive anonymization algorithms, K-anonymity algorithms, differential privacy algorithms, homomorphic-encryption property-preserving algorithms, data aggregation algorithms, and/or sampling algorithms, etc. All such algorithms modify the original information, in various ways and possibly with various intensities. I.e., various intermediate levels of accessibility may hence be provided. In all cases yet, access is only provided if the specified algorithm is compatible with the user access level.
  • Such a system 1 at least includes a request processing module, typically implemented in software at a server 30 .
  • the system e.g., the server 30
  • the system is otherwise designed to provide (i.e., form) a protected enclave 32 , in hardware and/or software.
  • the request processing module is configured to perform steps as described earlier, i.e., receiving user requests to access data, identify authorization levels associated with such requests, and perform sensitive operations S 30 -S 70 as discussed earlier. That is, the request processing module is adapted to obfuscate data (via the protected enclave 32 ) with one or more obfuscation algorithms, so as to provide different levels of obfuscation. This module is otherwise configured to access obfuscated data corresponding to user requests.
  • obfuscated data may possibly be cached. In all cases, however, the data are or must have been obfuscated with one or more of the obfuscation algorithms, so as to yield a level of obfuscation that is compatible with authorization levels identified for the users.
  • the module provides, in response to user requests, obfuscated data as accessed via the protected enclave 32 .
  • the request processing module may further be configured to encrypt the obfuscated data with user keys, prior to passing user keys to users, in addition to encrypted obfuscated data.
  • the system 1 may notably comprise (or be designed to communicate with) a KMS 40 adapted to generate such user keys, as well as any key needed by the system upon performing operations described earlier in reference to steps S 30 , S 40 , S 60 , and S 70 .
  • system 1 shall preferably comprise a first database 25 (storing non-obfuscated data, in encrypted form), and a second database 35 storing already obfuscated data (in encrypted form), the latter serving as a cache.
  • the invention can further be embodied as a computer program product for providing obfuscated data to users.
  • the computer program product comprises a computer readable storage medium having program instructions embodied therewith.
  • the program instructions are executable by one or more processors (e.g., of the server 30 ), to cause to implement steps as described earlier in reference to the present methods.
  • the present invention may accordingly be a system, a method, and/or a computer program product at any possible technical detail level of integration
  • the computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention
  • the computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device.
  • the computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.
  • a non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing.
  • RAM random access memory
  • ROM read-only memory
  • EPROM or Flash memory erasable programmable read-only memory
  • SRAM static random access memory
  • CD-ROM compact disc read-only memory
  • DVD digital versatile disk
  • memory stick a floppy disk
  • a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon
  • a computer readable storage medium is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
  • Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network.
  • the network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers.
  • a network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
  • Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the C programming language or similar programming languages.
  • the computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
  • the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
  • electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
  • These computer readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • 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 instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
  • the computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
  • each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s).
  • the functions noted in the blocks may occur out of the order noted in the Figures.
  • two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.

Abstract

In a computer-implemented method for providing obfuscated data to users, first, a user request to access data is received; then, an authorization level associated with the request received is identified. Next, obfuscated data is accessed in a protected enclave, which data corresponds to the request received. The data accessed has been obfuscated with an obfuscation algorithm that yields a level of obfuscation compatible with the authorization level identified. Finally, the obfuscated data accessed is provided to the user, from the protected enclave. Related systems and computer program products are also disclosed.

Description

BACKGROUND
The invention relates in general to the field of a computer-implemented methods and systems for providing obfuscated data to users, e.g., to perform analytics based on such data. In particular, it is directed to methods relying on obfuscation algorithms that yield levels of obfuscation that are compatible with authorization levels of users requesting such data.
Analytics relate to the systematic computational analysis of data and notably comprise the acquisition and interpretation of patterns hidden in data. Analytics on data can thus create value out of data. Companies may for instance apply analytics to data to understand such patterns and predict business trends and/or improve business performance.
However, issues related to data ownership, privacy, regulatory needs, and discrimination limit the actual possibilities for analytics. For example, there are numerous privacy concerns, originating from privacy law (general data protection regulation), trade secrets, confidential information, etc. As a result, only a small fraction of data is available for analytics, which must be handled with care.
SUMMARY
According to a first aspect, the present invention is embodied as a computer-implemented method for providing obfuscated data to users. First, a user request to access data is received. An authorization level associated with the request received is identified. Next, obfuscated data corresponding to the request received are accessed in a protected enclave. The data accessed are data that have been obfuscated with an obfuscation algorithm that yields a level of obfuscation compatible with the authorization level identified. Finally, the obfuscated data accessed are provided to the user, from the protected enclave.
After obfuscated data have been provided to the user, the latter shall typically perform analytics (or other cognitive operations), based on the obfuscated data.
In the present approach, all sensitive operations (starting with the obfuscation) are performed in a protected enclave. This way, security can be maintained in an ecosystem where numerous users may interact with a vast amount of data subject to various access rights. The present approach makes it possible to allow users to perform analytics based on data massively available, e.g., in a data lake, while preserving data usage authorizations (e.g., as stipulated by the data owners) and complying with other potential requirements (legal, regulatory, contractual, etc.). As a result, different users may possibly get access to the same data, but with different obfuscation levels. Such levels institute intermediate levels of accessibility between publicly available data and fully private data.
In embodiments, the method further comprises, prior to providing the obfuscated data, encrypting the obfuscated data accessed with a user key, in the protected enclave. The user key is eventually provided to the user, in addition to the encrypted obfuscated data. This way, all data leaving the protected enclave is encrypted (for security reasons), except the user key; the user can decrypt the encrypted data provided using this user key.
Preferably, the method further comprises providing (from the protected enclave) an encrypted version of the user key to the user, in addition to a plain version thereof. Later on, the user may nevertheless still request receiving the user key again (in plain form), if necessary, by providing the encrypted version of the key to the system.
In preferred embodiments, the protected enclave is in data communication with a key management system and the method further comprises generating, at said key management system, the user key used to subsequently encrypt the obfuscated data.
Preferably, the protected enclave is in data communication with a first database storing non-obfuscated data, in encrypted form. In that case, obfuscated data are accessed as follows (again, in the protected enclave). First, encrypted data are obtained from the first database, which data are not obfuscated yet. The data obtained from the first database are data that correspond to data as requested in the request received. Then, the encrypted data obtained from the first database are decrypted. The decrypted data are finally obfuscated using said obfuscation algorithm. I.e., data are obfuscated on demand, from data arising from a secure storage.
In embodiments, the method further comprises continually encrypting data, in a protected enclave, and continually storing the resulting encrypted data on the first database. Preferably, the first database is configured as a data lake.
In preferred embodiments, the protected enclave is in data communication with a second database, which stores obfuscated data, in encrypted form. Access to the obfuscated data may then comprise checking whether the data as requested in the request received are already available in the second database. If so, then the encrypted (and obfuscated) data, which correspond to the requested data, are obtained from the second database. The encrypted, obfuscated data obtained are then decrypted, so as to be able to subsequently provide the decrypted obfuscated data to the user. As noted above, the data provided will preferably be re-encrypted (prior to being exported), albeit with a different key. Else, if the data requested are not already available in the second database, then encrypted data corresponding to requested data are obtained from the first database, as described above.
Preferably, the method further comprises encrypting, in the protected enclave, the obfuscated data with a management key, and storing the accordingly encrypted, obfuscated data on the second database. Thus, the second database is effectively used as a cache, to improve efficiency of the system.
As noted earlier, the protected enclave may be in data communication with a key management system. Thus, the method shall preferably further comprise generating, at said key management system, the management key used to encrypt the obfuscated data.
In embodiments, the request received specifies a given level of obfuscation. In that case, the obfuscated data are accessed only if said given level of obfuscation is compatible with the authorization level identified.
In variants, the request may specify a goal to be achieved with data referred to in the request. In this case, the obfuscated data accessed are data obfuscated with an obfuscation algorithm selected in accordance with said goal, provided that the resulting level of obfuscation is compatible with the authorization level identified.
In other variants, the request may specify an obfuscation algorithm. If so, the obfuscated data are obfuscated with the obfuscation algorithm specified, but the method further comprises selecting a level of obfuscation produced by this algorithm, so as for this obfuscation level to be compatible with the authorization level identified.
All such variants (i.e., specifying a given level of obfuscation, a goal or the obfuscation algorithm itself) may possibly be proposed as options in the user interface.
Various obfuscation algorithms can be contemplated. For example, the obfuscation algorithm may rely on one or more of the following: naive anonymization, K-anonymity, differential privacy, homomorphic-encryption, data aggregation, and data sampling.
According to another aspect, the invention is embodied as a computerized system. The system comprises a request processing module and a protected enclave, e.g., each provided in a server. Consistently with the present methods, the request processing module is configured to receive a user request to access data and identify an authorization level associated with a user request received. Moreover, this module is adapted to obfuscate data (via the protected enclave) with one or more obfuscation algorithms, the latter yielding different levels of obfuscation. In addition, this module is designed to access obfuscated data corresponding to user requests, wherein the data are obfuscated with one or more of the obfuscation algorithms, so as to yield a level of obfuscation that is compatible with an authorization level identified upon receiving a request. Finally, this module may, in response to user requests, provide obfuscated data accessed via the protected enclave.
Preferably, the request processing module is further configured to encrypt, in the protected enclave, obfuscated data it accesses with a user key, and provide, in response to a user request, such a user key to the user in addition to encrypted obfuscated data.
In embodiments, the system further comprises a key management system adapted to generate such a user key. It may else be in data communication with such a key management system.
Preferably, the system further comprises a first database storing non-obfuscated data, in encrypted form, and a second database storing obfuscated data, in encrypted form, as discussed earlier.
According to a final aspect, the invention is embodied as a computer program product for providing obfuscated data to users. The computer program product comprises a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by one or more processors, to cause to implement steps according to the present methods.
Computerized systems, methods, and computer program products embodying the present invention will now be described, by way of non-limiting examples, and in reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying figures, where like reference numerals refer to identical or functionally similar elements throughout the separate views, and which together with the detailed description below are incorporated in and form part of the present specification, serve to further illustrate various embodiments and to explain various principles and advantages all in accordance with the present disclosure, in which:
FIG. 1 schematically represents selected components of a system according to embodiments;
FIG. 2 is a diagram depicted selected components of the system, together with basic operations performed in the system, as in embodiments; and
FIG. 3 is a detailed flowchart illustrating steps of a preferred method for providing obfuscated data to users, according to embodiments.
The accompanying drawings show simplified representations of devices or parts thereof, as involved in embodiments. Similar or functionally similar elements in the figures have been allocated the same numeral references, unless otherwise indicated.
DETAILED DESCRIPTION
Referring generally to FIGS. 1-3, a first aspect of the invention is now described, which concerns a computer-implemented method for providing obfuscated data to users.
The following context is assumed, for the sake of exemplification. Data owners 5 store data they produce S200 or otherwise own on data storage means 25, which may for instance be configured as a data lake. Such data are typically stored encrypted, e.g., via an encryption server 20. Besides, some users 10 may want to perform analytics on such data. To that aim, users 10 interact with a server 30, which forms part of a computerized ecosystem 1 as shown in FIG. 1. Note, such users can be any entity (human, legal, and/or computerized, e.g., an automated process). However, in all cases, the user requests are mediated via a computerized entity. That is, computerized interactions are assumed.
What the present methods propose is to handle requests from users 10 based on authorization levels of the users. In response to such requests, data are supplied to the user in obfuscated form (i.e., altered), wherein the level of obfuscation of the data provided depends on the authorization levels of the users. In the present context, obfuscation means altering the original data, so as not to retain all of the information contained in the original data. I.e., the original information is at least partly lost, so as to potentially comply with various requirements, such as originating from authorizations set by the owners, privacy law, and regulatory needs, for example. Note, data provided back to the users 10 are never intended to infringe or circumvent any legal provision.
In detail, assume that a request S10, S12 to access data from is received from a user 10, e.g., at a request processing module implemented in a server 30. An authorization level associated with the request is then identified S10, in order to take steps to serve this request (if possible). Note, this authorization level may be identified upon receiving the request, or as part of the request itself, or even before receiving the request. Any authentication mechanism may be contemplated.
Next, obfuscated data are accessed S30-S50 in a protected enclave 32, which data are data corresponding to data addressed in the request received. The data accessed are data that are or have been obfuscated S50 with a suitable obfuscation algorithm. I.e., this algorithm must yield a level of obfuscation that is compatible S12, S14 with the authorization level identified S10 earlier. Thus, a core principle of the present methods is to link data access authorization to the strength of the data obfuscating algorithm used to obfuscate the data. Examples of obfuscation algorithms are discussed later.
Finally, the obfuscated data accessed at steps S30-S50 are provided S82 from the protected enclave 32 to the requesting user 10. After having received S82 the obfuscated data 36, users 10 may at S102 decrypt the obfuscated data, at S104 delete the plain version of the user-level key, and at S106 perform analytics, analyses or any kind of cognitive operations based on the obfuscated data 36 provided at S82.
A protected enclave is a computerized area of restricted access. Such an enclave may, for example, simply consist of one or more private (and preferably encrypted) regions of the memory of a computerized system, e.g., allocated thanks to a set of central processing unit CPU instructions. I.e., such instructions allow user-level code to allocate private (and preferably encrypted) regions of memory, which are protected from processes run even at higher privilege levels. A secure boot server with memory encryption when used exclusively for a single application with strict access control and limited network visibility is an example of a protected enclave.
A protected enclave may further be configured so as to limit network access through this enclave. For example, a network enclave may be separated from its surrounding network so as to limit access thereto to selected entities, applications or services of the surrounding network. More generally, the specific resources of the protected enclave may be designed so as to restrict interactions with external entities or networks. Access may otherwise be restricted thanks to secure access control means, e.g., including dedicated resources such as internal firewalls, and network admissions control means.
The protected enclave may notably be implemented as a virtualized, pre-integrated service-oriented architecture (SOA) platform. Still, this platform may possibly host trusted applications and allow them to interact with users and other external systems, though in a controlled and secure manner.
In general, any protected enclave as used herein may be implemented in hardware (e.g., secure boot server with exclusive use) or in software (e.g., based on Intel Software Guard Extensions SGX), or zSeries Secure Service Containers (SSC), for example.
In the present case, all sensitive operations (starting with the obfuscation step S50) are performed in a protected enclave. This way, security can be maintained in an ecosystem where numerous users may interact with a vast amount of data, whose access is subject to various types and levels of authorizations.
In simple implementations, a user 10 requests S12 to access data at a given level of obfuscation. The authorization level associated with the request (i.e., the authorization level of the user) is identified S10 (prior to or after identifying S10 the level of obfuscation desired), as assumed in FIG. 3. And if the given level of obfuscation identified S10 is compatible with the authorization level identified S12, then obfuscated data are accessed S30-S50 as described earlier and supplied S82 to the user.
In other, more sophisticated implementations, the user may specify his/her goals (e.g., in terms of analytics to be performed on such data), in which case the system automatically selects a suitable algorithm, or a level of obfuscation produced by the algorithm, as discussed later in detail.
One may, by convention, define the authorization level such that the highest authorization level allows access to data having any level of obfuscation. E.g., similarly to privilege levels in the intel x86 instruction set, the authorization level may range from 0 (most privileged) to n>0, where n is less privileged than n−1, which is less privileged than n−2, etc. Thus, any resource available to level n would also be available to authorization levels 0 to n. The obfuscation level may thus similarly be coded from 0 (corresponding to a low level of alteration) to m>1 (corresponding to a higher level of alteration). Thus, given a data-obfuscation level 1 desired and a data access authorization level k identified for the requester, access to the requested data is only allowed if the authorization level is higher (in the sense of privilege) than or equal to the data-obfuscation level, i.e., if 1≤k. Thus, an authorized user having a high authorization level (e.g., a data owner) may typically access data having any level of obfuscation
As data 36 eventually supplied S82 is obfuscated, all rights attached to the data supplied S82 can be respected, by taking into account the authorization level of the requester.
As present inventors have realized, the present approach makes it possible to allow users to perform analytics based on data massively available, e.g., in a data lake, while preserving data usage authorizations as stipulated by the data owners and/or complying with other requirements. All this is now described in detail, in reference to particular embodiments of the invention.
To start with, referring to FIG. 3, the present methods may further comprise encrypting S64 the obfuscated data accessed with a user key, in the protected enclave 32. Step S64 is carried out prior to providing S82 the obfuscated data to the user. The user key is provided (i.e., supplied) S82 to the user 10, in addition to the encrypted, obfuscated data. This way, all data 36 leaving the protected enclave is encrypted (except the user key), for security reasons; the user can nevertheless decrypt the data provided using the user key provided.
In embodiments, an encrypted version of the user key may further be provided S82 to the user 10 (from the protected enclave 32), in addition to a plain version of the key. This way, the user can first decrypt the data provided based on the (plain) user key provided, and then delete this key (for security reasons). Later on, if necessary, the user may nevertheless still request receiving the user key again (in plain form), by providing the encrypted version of the key (a symmetric encryption scheme is here contemplated).
The user key is a cryptographic key generated for the user, e.g., via a key management system (KMS). As seen in FIG. 1, the protected enclave 32 may for example be in data communication with a KMS 40. The latter may thus be relied on to generate S62 the user key, which is received in the protected enclave 32 and subsequently used to encrypt S64 the obfuscated data. The KMS may possibly be a hierarchical key management system (HKMS): the user key may for instance be a user-level key 60 that is generated at a given hierarchical level of the HKMS, according to methods known per se.
In embodiments, the protected enclave 32 is in data communication with a first database 25 (e.g., a data lake) storing non-obfuscated data, in encrypted form. In that case, encrypted data may first be obtained S22 from this database 25 and then be accessed in the protected enclave 32, wherein said encrypted data correspond to data as requested in the request received S10. Next, the encrypted data obtained S22 are decrypted S40, S42-S44 (still in the protected enclave 32), and the decrypted data are then obfuscated S50 using a suitably selected obfuscation algorithm. I.e., data are obfuscated on demand, from data arising from a secure storage 25. Again, the decryption process S40 may advantageously involve a KMS, i.e., the decryption S44 may first require accessing S42 a key (e.g., a master key 50) from the KMS.
As depicted in FIGS. 1 and 2, data may be continually produced S200 by data owners 5 and hence continually encrypted S15 (e.g., thanks to a dedicated server 20) and stored on the first database 25. Note, the encryption step S15 is preferably performed in a protected enclave 22 too, which does not necessarily correspond to the enclave 32 provided in the server 30. Rather, the enclave 22 may be provided in a dedicated encryption server 20, used to store owner data on the storage 25.
As evoked earlier, the first database 25 may for instance be configured as a data lake, i.e., a storage repository that holds a huge amount of raw or refined data in native format. A data lake typically relies on Hadoop-compatible object storage, according to which organization's data are loaded into a Hadoop platform. Then, business analytics and data-mining tools can possibly be applied to the data where it resides on the Hadoop cluster. However, data lakes can also be used effectively without incorporating Hadoop, depending on the needs and goals of the organization. More generally, a data lake is a large data pool in which the schema and data requirements are typically not defined until the data is queried.
In the present context, the data owners may for example specify the required obfuscation levels as a function of the trust levels of the data users. As a result, different users may possibly get access to the same data, but with different obfuscation levels. Such levels institute intermediate levels of accessibility between publicly available data and fully private data.
Still referring to FIGS. 1 and 3, the protected enclave 32 is preferably in data communication with a second database 35. The latter store data that have already been obfuscated S50 (e.g., in response to previous queries), in encrypted form. In that case, obfuscated data shall typically be accessed S30-S50 by first checking S18 whether the requested data are already available in the second database 35. If it is determined that the requested data are indeed already available in the database 35 (S18: Yes), then encrypted versions of such obfuscated data are obtained S21 from this database 35 (they are loaded in the protected enclave). The data obtained S21 are then decrypted S30, S32-S34 (e.g., by obtaining S32 a key from a KMS, e.g., a master key), and subsequently provided S60, S82 to the user 10. Else, if it is determined at step S18 that the requested data are not already available in the second database 35, the requested data are obtained from the first database 25 and decrypted, prior to being obfuscated and passed to the user, as described earlier.
In order to make the system more efficient, data that need be obfuscated S50 are then stored on the second database 35, effectively working as a cache, as seen in the flowchart of FIG. 3. That is, data that have been recently obfuscated S50 may first be encrypted S70, S72-S74 (in the protected enclave 32), using a management key (different from the user keys), and then stored S90 on the second database 35. Again, use can be made of keys provided by a KMS 40. I.e., the management key used to encrypt S74 the obfuscated data may be obtained S72 from a KMS, for use in the protected enclave 32. Once stored S90 on the second database, obfuscated data are readily available for subsequent, related queries (S10-S18: Yes, S21).
As assumed in FIG. 3, the request received S12 may already specify a given, desired level of obfuscation. In that case, obfuscated data are accessed S30-S50 only if the specified level of obfuscation is compatible (S14: Yes) with the authorization level identified at step S10. Otherwise, exit at S16.
In more sophisticated approaches, the request received may specify a goal to be achieved with the data referred to in the request (e.g., in terms of analytics). In that case, the system may automatically select the obfuscation algorithm at step S50 (in accordance with said goal) or access cached data that have previously been obfuscated with a suitable algorithm. In all cases, the system makes sure that the data accessed S30-S50 are data that have been obfuscated S50 with an obfuscation algorithm selected in accordance with said goal, provided that the resulting level of obfuscation is compatible with the authorization level identified.
The request received may notably specify a goal to be achieved in terms of analytics to be performed with such data and the obfuscation algorithm is selected in accordance with said goal. For example, the user may want to uncover trends from data range queries, counts, etc. In that case, the obfuscation produced may be equivalent to anonymized histograms/sketch-based counting schemes, etc.
In other approaches, the request received may specify the desired obfuscation algorithm itself. In that case, the obfuscated data accessed S30-S50 are obfuscated with the obfuscation algorithm specified, but the system selects a level of obfuscation produced by the algorithm, so as for this level to be compatible with the authorization level identified earlier (if not possible, an error message is returned). For example, a standard set of obfuscation algorithms may be available, in which case the user is invited to select a given algorithm.
Note, the user interface or program used to enable user queries may provide several options to users, including those mentioned above, whereby users may thus either select an obfuscation level, specify a goal or the obfuscation algorithm itself.
Such algorithms may notably include naive anonymization algorithms, K-anonymity algorithms, differential privacy algorithms, homomorphic-encryption property-preserving algorithms, data aggregation algorithms, and/or sampling algorithms, etc. All such algorithms modify the original information, in various ways and possibly with various intensities. I.e., various intermediate levels of accessibility may hence be provided. In all cases yet, access is only provided if the specified algorithm is compatible with the user access level.
Referring now more specifically to FIGS. 1 and 2, another aspect of the invention is now described, which concerns a computerized system 1. Essential aspects of such a system have already been implicitly described in reference to the present methods and are only briefly described in the following. Such a system 1 at least includes a request processing module, typically implemented in software at a server 30.
The system (e.g., the 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 steps as described earlier, i.e., receiving user requests to access data, identify authorization levels associated with such requests, and perform sensitive operations S30-S70 as discussed earlier. That is, the request processing module is adapted to obfuscate data (via the protected enclave 32) with one or more obfuscation algorithms, so as to provide different levels of obfuscation. This module is otherwise configured to access obfuscated data corresponding to user requests.
As discussed earlier, obfuscated data may possibly be cached. In all cases, however, the data are or must have been obfuscated with one or more of the obfuscation algorithms, so as to yield a level of obfuscation that is compatible with authorization levels identified for the users. Finally, the module provides, in response to user requests, obfuscated data as accessed via the protected enclave 32.
As discussed, the request processing module may further be configured to encrypt the obfuscated data with user keys, prior to passing user keys to users, in addition to encrypted obfuscated data. The system 1 may notably comprise (or be designed to communicate with) a KMS 40 adapted to generate such user keys, as well as any key needed by the system upon performing operations described earlier in reference to steps S30, S40, S60, and S70.
In addition, the system 1 shall preferably comprise a first database 25 (storing non-obfuscated data, in encrypted form), and a second database 35 storing already obfuscated data (in encrypted form), the latter serving as a cache.
Next, according to a final aspect, the invention can further be embodied as a computer program product for providing obfuscated data to users. The computer program product comprises a computer readable storage medium having program instructions embodied therewith. The program instructions are executable by one or more processors (e.g., of the server 30), to cause to implement steps as described earlier in reference to the present methods.
The present invention may accordingly be a system, a method, and/or a computer program product at any possible technical detail level of integration. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the C programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.
Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general-purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. 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 instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
While the present invention has been described with reference to a limited number of embodiments, variants and the accompanying drawings, it will be understood by those skilled in the art that various changes may be made, and equivalents may be substituted without departing from the scope of the present invention. In particular, a feature (device-like or method-like) recited in a given embodiment, variant or shown in a drawing may be combined with or replace another feature in another embodiment, variant or drawing, without departing from the scope of the present invention. Various combinations of the features described in respect of any of the above embodiments or variants may accordingly be contemplated, that remain within the scope of the appended claims. In addition, many minor modifications may be made to adapt a particular situation or material to the teachings of the present invention without departing from its scope. Therefore, it is intended that the present invention not be limited to the particular embodiments disclosed, but that the present invention will include all embodiments falling within the scope of the appended claims. In addition, many other variants than explicitly touched above can be contemplated.

Claims (17)

What is claimed is:
1. A computer-implemented method for providing obfuscated data to users, the method comprising
receiving a request to access data from a user;
identifying an authorization level associated with the request received;
in a protected enclave, accessing obfuscated data corresponding to the request received, wherein the data accessed have been obfuscated with an obfuscation algorithm yielding a level of obfuscation that is compatible with the authorization level identified, and
providing, from the protected enclave, the obfuscated data accessed to the user,
wherein
the protected enclave is in data communication with a first database storing non-obfuscated data, in encrypted form, and is in data communication with a second database storing obfuscated data, in encrypted form,
wherein
accessing the obfuscated data comprises, in the protected enclave,
checking whether the data as requested in the request received is already available in the second database,
if the data as requested in the request received is already available in the second database, then
obtaining, from the second database, encrypted obfuscated data corresponding to the requested data, and
decrypting the encrypted, obfuscated data obtained, so as to be able to subsequently provide the decrypted obfuscated data to the user,
else, obtaining, from the first database, encrypted data corresponding to data as requested in the request received,
decrypting the encrypted data obtained, and
obfuscating the decrypted data using said obfuscation algorithm.
2. The method according to claim 1, wherein the method further comprises
prior to providing the obfuscated data, encrypting the obfuscated data accessed with a user key, in the protected enclave, and
providing the user key to the user, in addition to the encrypted obfuscated data.
3. The method according to claim 2, wherein
the method further comprises providing, from the protected enclave, an encrypted version of the user key to the user, in addition to a plain version of the user key.
4. The method according to claim 2, wherein
the protected enclave is in data communication with a key management system and the method further comprises generating, at said key management system, the user key used to subsequently encrypt the obfuscated data.
5. The method according to claim 1, wherein
the method further comprises continually encrypting data, in a protected enclave, and continually storing the resulting encrypted data on the first database.
6. The method according to claim 5, wherein
the first database is a data lake.
7. The method according to claim 1, wherein
the method further comprises encrypting, in the protected enclave, the obfuscated data with a management key, and storing the accordingly encrypted, obfuscated data on the second database.
8. The method according to claim 7, wherein
the protected enclave is in data communication with a key management system and the method further comprises generating, at said key management system, the management key used to encrypt the obfuscated data.
9. The method according to claim 1, wherein
the request received specifies a given level of obfuscation; and
said obfuscated data are accessed only if said given level of obfuscation is compatible with the authorization level identified.
10. The method according to claim 1, wherein
the request received further specifies a goal to be achieved with the data referred to in the request; and
the obfuscated data accessed comprises data that has been obfuscated with an obfuscation algorithm selected in accordance with said goal, provided that the resulting level of obfuscation is compatible with the authorization level identified.
11. The method according to claim 1, wherein the request received further specifies an obfuscation algorithm; and the obfuscated data accessed comprises data obfuscated with the obfuscation algorithm specified, and the method further comprises selecting the level of obfuscation produced by the algorithm, so as for this level of obfuscation to be compatible with the authorization level identified.
12. The method according to claim 1, wherein
said obfuscation algorithm relies on one or more of: a naive anonymization, a K-anonymity, a differential privacy, a homomorphic-encryption, data aggregation, and data sampling.
13. The method according to claim 1, wherein
the method further comprises, after having provided the obfuscated data accessed to the user, performing analytics based on the obfuscated data provided.
14. A computerized system comprising:
a request processing module;
a first database storing non-obfuscated data, in encrypted form;
a second database storing non-obfuscated data, in encrypted form; and
a protected enclave, which is in data communication with the first database and with the second database,
wherein
the request processing module is configured to:
receive a user request to access data;
identify an authorization level associated with a user request received;
in response to the user request, cause the protected enclave to:
obfuscate data with one or more obfuscation algorithms, the one or more obfuscation algorithms yielding different levels of obfuscation, and
access obfuscated data corresponding to a user request, wherein the data are obfuscated with one or more of the obfuscation algorithms, so as to yield a level of obfuscation that is compatible with an authorization level identified,
wherein accessing the obfuscated data comprises:
checking whether the data as requested in the request received is already available in the second database,
if the data as requested in the request received is already available in the second database, then
obtaining, from the second database, encrypted obfuscated data corresponding to the requested data, and
decrypting the encrypted obfuscated data obtained, so as to be able to subsequently provide the decrypted obfuscated data to the user,
else,
obtaining, from the first database, encrypted data corresponding to data as requested in the request received,
decrypting the encrypted data obtained, and
obfuscating the decrypted data using said obfuscation algorithm; and
in response to the user request, provide to the user the obfuscated data accessed via the protected enclave.
15. The computerized system according to claim 14, wherein
the request processing module is further configured to
cause the protected enclave to encrypt obfuscated data that the protected enclave accesses with a user key, and to
provide, in response to a user request, such a user key to the user in addition to encrypted obfuscated data.
16. The computerized system according to claim 15, wherein
the system further comprises a key management system adapted to generate such a user key.
17. A computer program product for providing obfuscated data to users, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by one or more processors, to cause said one or more processors to:
receive a request to access data from a user;
identify an authorization level associated with the request received;
via a protected enclave, access obfuscated data corresponding to the request received, wherein the data accessed have been obfuscated with an obfuscation algorithm yielding a level of obfuscation that is compatible with the authorization level identified,
wherein accessing the obfuscated data comprises
checking whether the data as requested in the request received is already available in the second database,
if the data as requested in the request received is already available in the second database, then
obtaining, from the second database, encrypted obfuscated data corresponding to the requested data, and
decrypting the encrypted, obfuscated data obtained, so as to be able to subsequently provide the decrypted obfuscated data to the user,
else, obtaining, from the first database, encrypted data corresponding to data as requested in the request received,
decrypting the encrypted data obtained, and
obfuscating the decrypted data using said obfuscation algorithm; and
provide, from the protected enclave, the obfuscated data accessed to the user.
US16/278,028 2019-02-15 2019-02-15 Secure, multi-level access to obfuscated data for analytics Active 2041-04-25 US11416633B2 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US16/278,028 US11416633B2 (en) 2019-02-15 2019-02-15 Secure, multi-level access to obfuscated data for analytics
CN202080012938.9A CN113396415A (en) 2019-02-15 2020-02-11 Secure, multi-level access to obfuscated data for analysis
JP2021539099A JP2022520323A (en) 2019-02-15 2020-02-11 Secure multi-level access to obfuscated data for analytics
PCT/IB2020/051074 WO2020165756A1 (en) 2019-02-15 2020-02-11 Secure, multi-level access to obfuscated data for analytics
DE112020000134.2T DE112020000134T5 (en) 2019-02-15 2020-02-11 SECURE, MULTI-LEVEL ACCESS TO DISCOVERED DATA FOR ANALYZES
GB2111724.7A GB2595167A (en) 2019-02-15 2020-02-11 Secure, multi-level access to obfuscated data for analytics

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/278,028 US11416633B2 (en) 2019-02-15 2019-02-15 Secure, multi-level access to obfuscated data for analytics

Publications (2)

Publication Number Publication Date
US20200265159A1 US20200265159A1 (en) 2020-08-20
US11416633B2 true US11416633B2 (en) 2022-08-16

Family

ID=72040646

Family Applications (1)

Application Number Title Priority Date Filing Date
US16/278,028 Active 2041-04-25 US11416633B2 (en) 2019-02-15 2019-02-15 Secure, multi-level access to obfuscated data for analytics

Country Status (6)

Country Link
US (1) US11416633B2 (en)
JP (1) JP2022520323A (en)
CN (1) CN113396415A (en)
DE (1) DE112020000134T5 (en)
GB (1) GB2595167A (en)
WO (1) WO2020165756A1 (en)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11308234B1 (en) * 2020-04-02 2022-04-19 Wells Fargo Bank, N.A. Methods for protecting data
US20220166607A1 (en) * 2020-11-20 2022-05-26 International Business Machines Corporation Secure re-encryption of homomorphically encrypted data
US20220253541A1 (en) * 2021-02-10 2022-08-11 Bank Of America Corporation System for electronic data obfuscation through alteration of data format
US11580249B2 (en) 2021-02-10 2023-02-14 Bank Of America Corporation System for implementing multi-dimensional data obfuscation
US20220253464A1 (en) * 2021-02-10 2022-08-11 Bank Of America Corporation System for identification of obfuscated electronic data through placeholder indicators
US20220271914A1 (en) * 2021-02-24 2022-08-25 Govermment of the United of America as represented by the Secretary of the Navy System and Method for Providing a Secure, Collaborative, and Distributed Computing Environment as well as a Repository for Secure Data Storage and Sharing
US20230015412A1 (en) * 2021-07-16 2023-01-19 International Business Machines Corporation Dynamic Data Masking for Immutable Datastores

Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040199517A1 (en) * 2003-04-02 2004-10-07 Fabio Casati Method and system for operating a data warehouse for event management
US20070112869A1 (en) * 2005-11-15 2007-05-17 Solix, Inc. System and method for managing data in a database
US20090144829A1 (en) * 2007-11-30 2009-06-04 Grigsby Travis M Method and apparatus to protect sensitive content for human-only consumption
US20100161984A1 (en) * 2003-09-25 2010-06-24 Pauker Matthew J Secure message system with remote decryption service
US20110154061A1 (en) * 2009-12-21 2011-06-23 Babu Chilukuri Data secure memory/storage control
US20110277037A1 (en) * 2010-05-10 2011-11-10 International Business Machines Corporation Enforcement Of Data Privacy To Maintain Obfuscation Of Certain Data
US20110282862A1 (en) * 2010-05-14 2011-11-17 Telcordia Technologies, Inc. System and method for preventing nformation inferencing from document collections
US8543821B1 (en) 2011-10-28 2013-09-24 Amazon Technologies, Inc. Scalably displaying sensitive data to users with varying authorization levels
CN104679781A (en) 2013-12-02 2015-06-03 中国移动通信集团福建有限公司 Data fuzzy processing method and device
US20150213226A1 (en) * 2014-01-28 2015-07-30 3M Innovative Properties Company Perfoming analytics on protected health information
US20150379303A1 (en) 2013-11-01 2015-12-31 Anonos Inc. Systems And Methods For Contextualized Data Protection
US20160085996A1 (en) 2014-09-23 2016-03-24 FHOOSH, Inc. Secure high speed data storage, access, recovery, and transmission
US20160283731A1 (en) * 2015-03-23 2016-09-29 Intel Corporation Systems, methods, and apparatus to provide private information retrieval
US20160381054A1 (en) * 2015-06-26 2016-12-29 Board Of Regents, The University Of Texas System System and device for preventing attacks in real-time networked environments
US9584517B1 (en) * 2014-09-03 2017-02-28 Amazon Technologies, Inc. Transforms within secure execution environments
CN106611129A (en) 2016-12-27 2017-05-03 东华互联宜家数据服务有限公司 Data desensitization method, device and system
US20170124258A1 (en) 2015-11-04 2017-05-04 Mmodal Ip Llc Dynamic De-Identification of Healthcare Data
US20170132186A1 (en) 2014-07-02 2017-05-11 Document Corporation Ip Unit Trust Method and System for Selective Document Redaction
US20170222992A1 (en) * 2016-02-02 2017-08-03 Apple Inc. Method for Securing User Data with DRM Keys
US20180060612A1 (en) 2010-01-28 2018-03-01 International Business Machines Corporation Distributed storage with data obfuscation and method for use therewith
US10055601B1 (en) * 2014-07-31 2018-08-21 Larry Hamid Method and system for securing data
US20180248887A1 (en) * 2015-02-11 2018-08-30 J2 Global Ip Limited Method and Systems for Virtual File Storage and Encryption
US20190121998A1 (en) * 2017-10-20 2019-04-25 Dornerworks, Ltd. Computer system data guard
US20200036732A1 (en) * 2018-07-27 2020-01-30 The Boeing Company Machine learning data filtering in a cross-domain environment
US20200174990A1 (en) * 2018-11-29 2020-06-04 Anthony Turner Pratkanis Accountably Redactable Data Structures
US20200193057A1 (en) * 2018-12-13 2020-06-18 Amaris.Ai Pte. Ltd. Privacy enhanced data lake for a total customer view
EP3704619A1 (en) 2017-10-30 2020-09-09 Equifax, Inc. Data protection via aggregation-based obfuscation
US10803197B1 (en) * 2018-04-13 2020-10-13 Amazon Technologies, Inc. Masking sensitive information in records of filtered accesses to unstructured data
US20200327252A1 (en) * 2016-04-29 2020-10-15 Privitar Limited Computer-implemented privacy engineering system and method

Patent Citations (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040199517A1 (en) * 2003-04-02 2004-10-07 Fabio Casati Method and system for operating a data warehouse for event management
US20100161984A1 (en) * 2003-09-25 2010-06-24 Pauker Matthew J Secure message system with remote decryption service
US20070112869A1 (en) * 2005-11-15 2007-05-17 Solix, Inc. System and method for managing data in a database
US20090144829A1 (en) * 2007-11-30 2009-06-04 Grigsby Travis M Method and apparatus to protect sensitive content for human-only consumption
US20110154061A1 (en) * 2009-12-21 2011-06-23 Babu Chilukuri Data secure memory/storage control
US20180060612A1 (en) 2010-01-28 2018-03-01 International Business Machines Corporation Distributed storage with data obfuscation and method for use therewith
US20110277037A1 (en) * 2010-05-10 2011-11-10 International Business Machines Corporation Enforcement Of Data Privacy To Maintain Obfuscation Of Certain Data
US20110282862A1 (en) * 2010-05-14 2011-11-17 Telcordia Technologies, Inc. System and method for preventing nformation inferencing from document collections
US8543821B1 (en) 2011-10-28 2013-09-24 Amazon Technologies, Inc. Scalably displaying sensitive data to users with varying authorization levels
US20150379303A1 (en) 2013-11-01 2015-12-31 Anonos Inc. Systems And Methods For Contextualized Data Protection
CN104679781A (en) 2013-12-02 2015-06-03 中国移动通信集团福建有限公司 Data fuzzy processing method and device
US20150213226A1 (en) * 2014-01-28 2015-07-30 3M Innovative Properties Company Perfoming analytics on protected health information
US20170132186A1 (en) 2014-07-02 2017-05-11 Document Corporation Ip Unit Trust Method and System for Selective Document Redaction
US10055601B1 (en) * 2014-07-31 2018-08-21 Larry Hamid Method and system for securing data
US9584517B1 (en) * 2014-09-03 2017-02-28 Amazon Technologies, Inc. Transforms within secure execution environments
US20160085996A1 (en) 2014-09-23 2016-03-24 FHOOSH, Inc. Secure high speed data storage, access, recovery, and transmission
US20180248887A1 (en) * 2015-02-11 2018-08-30 J2 Global Ip Limited Method and Systems for Virtual File Storage and Encryption
US20160283731A1 (en) * 2015-03-23 2016-09-29 Intel Corporation Systems, methods, and apparatus to provide private information retrieval
US20160381054A1 (en) * 2015-06-26 2016-12-29 Board Of Regents, The University Of Texas System System and device for preventing attacks in real-time networked environments
US20170124258A1 (en) 2015-11-04 2017-05-04 Mmodal Ip Llc Dynamic De-Identification of Healthcare Data
US20170222992A1 (en) * 2016-02-02 2017-08-03 Apple Inc. Method for Securing User Data with DRM Keys
US20200327252A1 (en) * 2016-04-29 2020-10-15 Privitar Limited Computer-implemented privacy engineering system and method
CN106611129A (en) 2016-12-27 2017-05-03 东华互联宜家数据服务有限公司 Data desensitization method, device and system
US20190121998A1 (en) * 2017-10-20 2019-04-25 Dornerworks, Ltd. Computer system data guard
EP3704619A1 (en) 2017-10-30 2020-09-09 Equifax, Inc. Data protection via aggregation-based obfuscation
US10803197B1 (en) * 2018-04-13 2020-10-13 Amazon Technologies, Inc. Masking sensitive information in records of filtered accesses to unstructured data
US20200036732A1 (en) * 2018-07-27 2020-01-30 The Boeing Company Machine learning data filtering in a cross-domain environment
US20200174990A1 (en) * 2018-11-29 2020-06-04 Anthony Turner Pratkanis Accountably Redactable Data Structures
US20200193057A1 (en) * 2018-12-13 2020-06-18 Amaris.Ai Pte. Ltd. Privacy enhanced data lake for a total customer view

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Patents Act 1977: Examination Report under Section 18(3), Counterpart British Application GB2111724.7, dated Jun. 29, 2022, 7 pages.
Zi-Iou,Yanan, PRC(ISA/CN) as ISA, Patent Cooperation Treaty International Search Report, PCT/1B2020/051074, dated May 27, 2020, 6 pages.
Zi-Iou,Yanan, PRC(ISA/CN) as ISA, Patent Cooperation Treaty Written Opinion, PCT/1B2020/051074, dated May 27, 2020, 4 pages.

Also Published As

Publication number Publication date
WO2020165756A1 (en) 2020-08-20
CN113396415A (en) 2021-09-14
GB2595167A (en) 2021-11-17
JP2022520323A (en) 2022-03-30
DE112020000134T5 (en) 2021-07-29
US20200265159A1 (en) 2020-08-20
GB202111724D0 (en) 2021-09-29

Similar Documents

Publication Publication Date Title
US11416633B2 (en) Secure, multi-level access to obfuscated data for analytics
US11341281B2 (en) Providing differential privacy in an untrusted environment
Mehraeen et al. Security challenges in healthcare cloud computing: a systematic review
US9607177B2 (en) Method for securing content in dynamically allocated memory using different domain-specific keys
Thillaiarasu et al. RETRACTED ARTICLE: A novel scheme for safeguarding confidentiality in public clouds for service users of cloud computing
US11290446B2 (en) Access to data stored in a cloud
WO2017129138A1 (en) Data protection method and apparatus in data warehouse
AU2020369228B2 (en) Private transfer learning
US11520905B2 (en) Smart data protection
JP2022523770A (en) Secure execution guest owner control for secure interface control
US10546142B2 (en) Systems and methods for zero-knowledge enterprise collaboration
US10834060B2 (en) File sharing and policy control based on file link mechanism
Elmogazy et al. Securing Healthcare Records In The Cloud Using Attribute-Based Encryption.
Vijayakumar et al. RETRACTED ARTICLE: Protecting user profile based on attribute-based encryption using multilevel access security by restricting unauthorization in the cloud environment
JP2022511357A (en) Purpose-specific access control methods and devices based on data encryption
US20150269357A1 (en) Method and apparatus for digital rights management that is file type and viewer application agnostic
Solsol et al. Security mechanisms in NoSQL dbms’s: A technical review
Manimuthu et al. An enhanced approach on distributed accountability for shared data in cloud
Yadav et al. The recent trends, techniques and methods of cloud security
Dixit et al. Enhancement in Security for Intercloud Scenario with the Help of Role-Based Access Control Model
Hasti et al. Data security in cloud-based analytics
Alsubaih et al. Privacy preserving model in semi-trusted cloud environment
Beley et al. A Management of Keys of Data Sheet in Data Warehouse
JP2023530581A (en) system-generated dataset encryption key
Jiang et al. Research on the Key Technology of the Cloud Platform Data Security

Legal Events

Date Code Title Description
FEPP Fee payment procedure

Free format text: ENTITY STATUS SET TO UNDISCOUNTED (ORIGINAL EVENT CODE: BIG.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW YORK

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHMATZ, MARTIN;RAMESHAN, NAVANEETH;SAGMEISTER, PATRICIA M.;AND OTHERS;SIGNING DATES FROM 20190730 TO 20190807;REEL/FRAME:050106/0749

STPP Information on status: patent application and granting procedure in general

Free format text: NON FINAL ACTION MAILED

STPP Information on status: patent application and granting procedure in general

Free format text: NOTICE OF ALLOWANCE MAILED -- APPLICATION RECEIVED IN OFFICE OF PUBLICATIONS

STPP Information on status: patent application and granting procedure in general

Free format text: PUBLICATIONS -- ISSUE FEE PAYMENT RECEIVED

STCF Information on status: patent grant

Free format text: PATENTED CASE