Patent Publication Number: US-10320757-B1

Title: Bounded access to critical data

Description:
BACKGROUND 
     The occurrence of high profile security breaches and stolen user data undermines confidence in electronic commerce. Each theft is a breach of trust that may violate the privacy and property interests of the user. Meanwhile, the study of user information by independent researchers can provide valuable insights, including market analytics and the identification of sociologic, demographic and economic trends. The continued viability of this research depends upon a statistically significant pool of users to continue to opt-in. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
       For a more complete understanding of the present disclosure, reference is now made to the following description taken in conjunction with the accompanying drawings. 
         FIG. 1  illustrates a system for managing the access of client computers to user data. 
         FIG. 2  is a block diagram conceptually illustrating example components of a secure repository which stores and manages access to user data. 
         FIG. 3  is a block diagram conceptually illustrating example components of a client computer and/or virtual machine array which may store a copy of the user data and process the user data. 
         FIG. 4  is a hybrid diagram illustrating examples of communication transactions and activities in a system where the client computer retains access to the user data. 
         FIG. 5  is a hybrid diagram illustrating examples of communication transactions and activities in a system where the client computer periodically renews access to the user data. 
     
    
    
     DETAILED DESCRIPTION 
     While data repositories for researchers may track which data is associated with which user, and what data is accessed by what researchers, that tracking typically does not extend to researcher&#39;s client computers. Once a researcher alters user data, the linkage back to the user breaks down. Thus if a user later requests deletion of their data, it may be deleted from the original repository, but copies of that data (either in its original form or in an altered form) may still exist with researchers. 
     Disclosed is a system that provides tracking of user data, associating both original and processed data with the user so that researchers&#39; client computers can comply with deletion requests from the originating user. The user data, although distributed across multiple devices, remains in a “closed” system. User data may be removed only after it has been rendered sufficiently anonymous by processing and/or aggregating so as to no longer convey the user&#39;s original data. 
       FIG. 1  illustrates a system  100  that includes a secure repository  120  that allows researchers to copy and process user data on client computer systems  140   a ,  140   b , while at the same time providing the user  10  the ability to have their data removed from the system  100 . Processing may also be performed on a “computational grid”  130 , which may be an array of virtual machines that may be connected to a client computer (e.g.,  140   b ) via a secure virtual private network tunnel  142 , providing researchers additional computational resources by processing the user data on a secure remote system. The virtual machine array  130  may be, for example, the system(s) associated with network-based “cloud” computing resources. A virtual machine of the computational grid  130  may be viewed as a processor linked to the client computer, and as such, actions attributed below to a client computer  140  include actions of a virtual machine on the computational grid  130  that is tasked to a client computer. 
     The secure repository  120  receives ( 122 ) user data from a user device  110  via a network  102 . At least some of the user data is confidential. “Confidential” data is data where a user has an expectation of privacy and/or the recipient has a duty to protect the data, such as data that identifies the user and/or contains personal or financial information, data that contains the user&#39;s voice or image, data that is defined as confidential by a privacy policy, terms-of-service and/or operation of law, etc. Although secret data is confidential, not all confidential data is necessarily secret (e.g., a recording of the user&#39;s voice or image may be confidential, but ordinarily would not be regarded as secret). Data may be designated as confidential by the user, by the software on the device transmitting the data, and/or by the receiving computer. If metadata tags are included with the user data that identifies the nature of the content, the receiving computer may apply rules to the metadata to determine whether content should be designated as confidential. 
     This data may arrive encrypted (e.g., encrypted by a software application on the user device  110 ), or be encrypted after it arrives at the secure repository  120 . The secure repository shares ( 124 ) the encrypted user data over a network  102  with trusted software on one or more of the client devices  140   a ,  140   b . The user data may be shared individually or as part of bundled data relating to multiple users, but in either case, the secure repository associates specific data with specific users, and this association continues to be maintained by the trusted software on the client devices, even after such data is altered by processing on the client device, until such time that the processed data is deemed “anonymized.” The decision as to whether user data has become sufficiently anonymous and devoid of confidential data, so as to permit breaking the association with the individual user, may be based on the researcher having run particular, designated transformations or processes on the data, may be the result of a pattern recognition algorithm comparing the original and processed data and determining that the correlation is below a particular threshold, and/or may be based on action by the researcher to certify that the processed data is anonymized. The association of processed data with individual user may be maintained using metadata tags, index tables, or the like. 
     If the secure repository  120  receives ( 126 ) a request to purge user data, it may proceed to do so in accordance with rules that specify how and when the purge will proceed. These rules may be shared in advance with the user  10  at the time they opt-in to data sharing, based on a terms-of-service agreement, or in a similar manner. For instance, the rules may allow researchers a fixed number of days following a purge request to permit them an opportunity to advance their research to a good “stopping” point. 
     After receiving ( 126 ) the purge request from the user  10 , the secure repository  120  deletes its copy of the user data, deletes encryption keys associated with the user data, and deletes and/or disables the user data across the system. The disabling of the data on the virtual machine/client device  140  may be accomplished, among other ways, by instructing the virtual machine/client devices  140  to delete the original and processed user data and/or to delete the key(s) used to decrypt access the user data. 
     The trusted software on the virtual machines/client devices  140  may periodically delete the key(s) used to decrypt the user data (original and processed), the key(s) may have a specified lifetime or end-date (at which time the virtual machine/client device  140  may automatically delete a respective key), and/or the client device&#39;s key may disabled by the secure repository  120  revoking a certificate linked to the key (the certificate being held by the secure repository  120  or another trusted authority separate from the virtual machines/client devices  140 ). If the software on the virtual machine/client device  140  must periodically renew its key(s) in order to access the original and processed user data, then the secure repository  120  may permanently disable the client device&#39;s access to the user data by declining the client&#39;s renewal after the user  10  asks for their data to be purged. 
     The network (of networks  102 ) by which the user  10  communicates with the secure repository  120  may be different than the network (of networks) used by the secure repository to communicate with the rest of the system  100 . For example, the client computers  140  and virtual machine array  130  may be on a same local area network as the secure repository  120 , whereas the user  10  may connect remotely over the Internet. 
       FIG. 2  illustrates a block diagram conceptually illustrating example components of the secure repository  120 . In operation, the components may include computer-readable and computer-executable instructions that reside in memory  206  and/or storage  208 , as will be discussed further below. 
     The secure repository  120  includes input/output device interfaces  202 . A variety of components may be connected through the input/output device interfaces  202 , such as a directly connected administrative terminal (not shown). The input/output device interfaces  202  may also include an interface for an external peripheral device connection such as universal serial bus (USB), Thunderbolt, or other connection protocol. The input/output device interfaces  202  may also include a connection to one or more networks  102  via an Ethernet port, a wireless local area network (WLAN) (such as WiFi) radio, Bluetooth, and/or wireless network radio, such as a radio capable of communication with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc. Through the network(s)  102 , components of secure repository  120  may be distributed across a networked environment. 
     The secure repository  120  may include an address/data bus  224  for conveying data among components of the secure repository  120 . Each component within the secure repository  120  may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus  224 . 
     The secure repository  120  may include one or more controllers/processors  204 , that may each include a central processing unit (CPU) for processing data and computer-readable instructions, and a memory  206  for storing data and instructions. The memory  206  may include volatile random access memory (RAM), non-volatile read only memory (ROM), non-volatile magnetoresistive (MRAM) and/or other types of memory. The secure repository  120  may also include a data storage component  208 , for storing data and controller/processor-executable instructions (e.g., instructions to perform the processes performed by the secure repository  120  in  FIGS. 5 and 6 ). The data storage component  208  may include one or more non-volatile storage types such as magnetic storage, optical storage, solid-state storage, etc. The secure repository  120  may also be connected to removable or external non-volatile memory and/or storage (such as a removable memory card, memory key drive, networked storage, etc.) through the input/output device interfaces  202 . 
     Computer instructions for operating the secure repository  120  and its various components may be executed by the controller(s)/processor(s)  204 , using the memory  206  as temporary “working” storage at runtime. The computer instructions may be stored in a non-transitory manner in non-volatile portions of memory  206 , storage  208 , or an external device. Alternatively, some or all of the executable instructions may be embedded in hardware or firmware in addition to or instead of software. 
     The secure repository  120  further includes a secure data module  230  that manages confidential user data. The secure data module  230  works in conjunction with secure data module  330  and/or trusted software a applications on the client devices  140   a ,  140   b  to maintain the integrity of the user data. 
     The secure data module  230  includes a user data management engine  232  which manages encryption, associating user data with the user  10 , issuance and revocation of keys, and deletion of user data from the system  100  after receiving a purge request from a user  10 . The user data management engine  232  operates in coordination with audit engine  236  that tracks when user data is accessed (and by whom), which client devices  140  have obtained copies of the user data, which client devices  140  have been issued keys to access the user data, when the key(s) expired or are set to expire, when user data was deleted by the secure repository  120 , and whether and when the original user data, processed user data, and/or key(s) were confirmed as deleted by the trusted software and/or secure data module  330  on the client devices  140 . 
     The data repository  238  of the secure data module  230  holds encrypted user data, stores the association of the user data with the user  10 , and stores the key or keys used to encrypt and/or decrypt the user data. If certificates are linked to keys, the data repository  238  may also store the certificates (with the user data management engine  232  or some other component fulfilling the role of certificate authority). The data repository  238  may be part of storage  208 , or may be one or more separate non-volatile storage systems. For example, different data held by the data repository may be divided across multiple storage components, including storage  208 . 
       FIG. 3  illustrates a block diagram conceptually illustrating example components of the client device  140  (likewise applying to the virtual machine array  130  in a distributed computing environment). In operation, the components may include computer-readable and computer-executable instructions that reside in memory  306  and/or storage  308 , as will be discussed further below. 
     The client device  140  includes input/output device interfaces  302 . A variety of components may be connected through the input/output device interfaces  302 , such as a display  312  and a keyboard  314 . The input/output device interfaces  302  may also include an interface for an external peripheral device connection such as universal serial bus (USB), Thunderbolt, or other connection protocol. The input/output device interfaces  302  may also include a connection to one or more networks  102  via an Ethernet port, a wireless local area network (WLAN) (such as WiFi) radio, Bluetooth, and/or wireless network radio, such as a radio capable of communication with a wireless communication network such as a Long Term Evolution (LTE) network, WiMAX network, 3G network, etc. Through the network(s)  102 , components of client device  140  may be distributed across a networked environment. 
     The client device  140  may include an address/data bus  324  for conveying data among components of the client device  140 . Each component within the client device  140  may also be directly connected to other components in addition to (or instead of) being connected to other components across the bus  324 . 
     The client device  140  may include one or more controllers/processors  304 , that may each include a central processing unit (CPU) for processing data and computer-readable instructions, and a memory  306  for storing data and instructions. The memory  306  may include volatile random access memory (RAM), non-volatile read only memory (ROM), non-volatile magnetoresistive (MRAM) and/or other types of memory. The client device  140  may also include a data storage component  308 , for storing data and controller/processor-executable instructions (e.g., instructions to perform the processes performed by the client device  140  in  FIGS. 5 and 6 ). The data storage component  308  may include one or more non-volatile storage types such as magnetic storage, optical storage, solid-state storage, etc. The client device  140  may also be connected to removable or external non-volatile memory and/or storage (such as a removable memory card, memory key drive, networked storage, etc.) through the input/output device interfaces  302 . 
     Computer instructions for operating the client device  140  and its various components may be executed by the controller(s)/processor(s)  304 , using the memory  306  as temporary “working” storage at runtime. The computer instructions may be stored in a non-transitory manner in non-volatile portions of memory  306 , storage  308 , or an external device. Alternatively, some or all of the executable instructions may be embedded in hardware or firmware in addition to or instead of software. 
     The client device  140  further includes a secure data module  330  that manages confidential user data. The secure data module  330  works in conjunction with trusted software applications on the client devices  140   a ,  140   b  and the secure data module  230  of the secure repository  120  to maintain the integrity of the user data. 
     The secure data module  230  includes a data integrity engine  332  which manages all interactions with the user data, including decryption and encryption of user data (original and processed), associating processed user data with the user  10 , maintaining the association of user data with the user  10 , deleting user data (original and processed), and reporting purge compliance to the secure repository  120 . The data integrity engine  332  may also perform pattern recognition to determine whether a comparison of original and processed user data is above or below a threshold, so as to determine whether processed data must be deleted in response to a user purge instruction from the secure repository  120 . The data integrity engine  332  may be, among other things, part of the operating system kernel on the virtual machine/client device  140 , and/or a software component of a “trusted” program or application. 
     The data integrity engine  332  works in coordination with a credentials manager  334 , which maintains and deletes keys, and requests renewed keys when a key has expired or been deleted. If keys are linked to certificates, the credentials manager  334  may query a certificate authority (which may be an aspect of the secure repository  140 ) to determine if the key is still valid prior to use. 
     A data repository  338  of the secure data module  330  holds encrypted user data, stores the association of the user data with the user  10 , and stores the key or keys used to encrypt and/or decrypt the user data. The data repository  338  may be part of storage  308 , or may be one or more separate non-volatile storage systems. For example, different data held by the data repository may be divided across multiple storage components, including storage  308 . Unencrypted copies of the original user data and the processed user data may be restricted to volatile portions of memory  206 , or if stored in a nonvolatile portion of memory  206 , storage  208 , or data repository  238 , may be periodically deleted by the data integrity engine  332  (e.g., deleted after an encrypted version of the processed user data is stored. 
       FIG. 4  illustrates an example of operation of the system  100  for managing user data. The user device  110  may send ( 402 ) user data to the secure repository  120 , or the secure repository  120  may receive the data from another source together with an association of the data with the user  10 . The secure repository  120  may check ( 404 ) to see if the user data is already encrypted, and if not, encrypts ( 406 ) the data prior to storage in the data repository  238 . 
     Thereafter, a client  140  requests ( 410 ) user data. This request may be, among other things, a batch request for data from multiple users, or a request for data from users meeting a specified criteria. The secure repository  120  then sends ( 412 ) a copy of the encrypted user data to the client  140 , after which the client  140  stores ( 414 ) the encrypted data. 
     Either together with the user data or as a separate transaction, the secure repository  120  may also provide the client  140  with a key or keys to decrypt and/or encrypt the user data. 
     When a researcher on the client device  140  goes to process the user data, the data integrity engine  332  unencrypts ( 428 ) the user data using a key provided by the credentials manager  334 . A software application executed by the controller(s)/processor(s)  304  and linked to the secure data module  330  then processes the unencrypted user data. The processing may include processing for research purposes or other processing as determined by the client. The data integrity engine  332  may tag ( 430 ) or otherwise track that the processed data includes user data so that there is a record of what processed data is associated with the proper users. After processing, the data integrity engine  332  re-encrypts ( 432 ) or deletes the unencrypted user data, and encrypts and stores the processed data along with the tags (or other data indicating the processed data includes user data). 
     After the secure repository  120  receives a purge request ( 440 ) from a user device  110 , the user management engine  232  deletes ( 442 ) the copy of the user data held by the data repository and one or more encryption keys ( 444 ), such as the encryption key associated with the user, an encryption key associated with a group of user including the user, or an encryption key for a batch of data for a plurality of users including the user. Groups may be defined by any criteria (e.g., first character of family name), whereas a “batch” of data may be aggregated without criteria (e.g., an entirety of the data sent in transaction  412 ). The user data management engine  232  may also issue delete commands ( 450 ) to clients  140 , if the audit engine  236  indicates that the client  140  may have copies of the user&#39;s data. 
     Thereafter, the data integrity engine  332  deletes ( 452 ) the original user data from the data repository  338 , and determines whether processed user data has been anonymized, eliminating the confidential aspects of the user data. This determination may be made by comparing processed data to user data (using techniques such as pattern recognition), or may be based on flag and tags generated by the processing application or researcher. If the processed data has not been anonymized, the data integrity engine  332  extracts and deletes ( 460 ) user-specific confidential data from the processed data. If the processed data is also based on user data from other users, data that is not based on the user  10  issuing the purge request ( 440 ) may be left intact. The credentials manager  334  may then delete ( 462 ) the key used to decrypt the user data. The credentials manager  334  will also delete ( 462 ) the key if the data is fully anonymized for user  10 , containing no confidential data. 
     If the user  10  requesting the data purge shares a key with a group or batch of users, deleting the raw data ( 452 ) and processed data ( 460 ) may include deleting data associated with other users associated with the same key, since once the key is deleted ( 462 ), their data will become inaccessible. 
       FIG. 5  illustrates another example of the system  100  managing user data. In this example, the credentials manager  334  of the client  140  periodically deletes the key or keys used to access user data. As referred to in the discussion of  FIG. 4 , a user may be associated with a unique key, may be associated with a group of users that is associated with a key, or may be part of a batch of user data that uses a single key for the entire batch. The client device  140  must periodically renew its key(s) in order to access the original and processed user data. 
     If prior to receiving a purge request  440  from the user device  110 , the secure repository  120  receives a request for a key ( 518 ) from the client  140 , the user data management engine  232  issues ( 520 ) a key. As noted above, this key may be time limited, such as sending the key with instructions to the credentials manager  334  to delete the key at a specified time. Keys may also be periodically replaced by the secure repository  120 , in which case the virtual machine/client device  140  decrypts data with the old key and re-encrypts it with the new key. 
     Having obtained a key, the client device  140  may then unencrypt ( 428 ), process and tag ( 430 ), and encrypt ( 432 ) and/or delete unencrypted the user data as described with  FIG. 4 . Thereafter, the credentials manager  334  deletes the client&#39;s key. 
     As in  FIG. 4 , the secure repository  120  receives a purge request  440  from the user and deletes the user&#39;s data from the data repository  228 . In this example, however, no delete command may be issued if the audit engine  236  indicates that the client&#39;s key is already deleted and/or expired. However, if the client device  140  thereafter requests a key renewal ( 578 ), the user data management engine  232  denies ( 580 ) the request, either ignoring it or sending ( 582 ) the client  140  an affirmative denial. Since the client  140  no longer has access to the user data, it is effectively purged. 
     The examples illustrated in  FIGS. 4 and 5  may be used together in a same system, with different clients adhering to different key maintenance policies. Moreover, if client  140  deletes a key but does not report the deletion to the audit engine  236 , the secure repository may issue a delete command  450  to the client  140 . Since the client  140  may be unable to extract user-specific processed data without a key, the result may be the data integrity engine either doing nothing (since access is disable, the data is effectively purged), or deleting all of the processed data associated with the user  10  (which if mixed with other users&#39; data may delete results based on the other users&#39; data as well). 
     The concepts disclosed herein may be applied within a number of different devices and computer systems, including, for example, general-purpose computing systems, server-client computing systems, mainframe computing systems, mobile computers, etc. 
     The above aspects of the present disclosure are meant to be illustrative. They were chosen to explain the principles and application of the disclosure and are not intended to be exhaustive or to limit the disclosure. Many modifications and variations of the disclosed aspects may be apparent to those of skill in the art. Persons having ordinary skill in the field of computers, data repository management, and data mining, should recognize that components and process steps described herein may be interchangeable with other components or steps, or combinations of components or steps, and still achieve the benefits and advantages of the present disclosure. Moreover, it should be apparent to one skilled in the art, that the disclosure may be practiced without some or all of the specific details and steps disclosed herein. 
     Aspects of the disclosed system may be implemented as a computer method or as an article of manufacture such as a memory device or non-transitory computer readable storage medium. The computer readable storage medium may be readable by a computer and may comprise instructions for causing a computer or other device to perform processes described in the present disclosure. The computer readable storage medium may be implemented by a volatile computer memory, non-volatile computer memory, hard drive, solid-state memory, flash drive, removable disk and/or other media. In addition, one or more engines of the critical data module  230  and the secure data module  330  may be implemented as firmware or as a state machine in hardware. For example, at least the audit engine  236  of the critical data module  230  and the credentials manager  334  of the secure data module  330  may be may be implemented as an application specific integrated circuit (ASIC), as a field programmable gate array (FPGA), or some combination thereof. In addition, the aspects of the critical data management engines  232  may be integrated into drive controllers used with data repositories  238  and  338 . 
     As used in this disclosure, the term “a” or “one” may include one or more items unless specifically stated otherwise. Further, the phrase “based on” is intended to mean “based at least in part on” unless specifically stated otherwise.