KR20140090571A - Method and device for privacy-respecting data processing - Google Patents

Abstract

The user device 110 encrypts data and privacy attributes associated with the data. The processing device 140 receives the encrypted data and privacy attributes (S202), receives a signed script from the requestor (S204), and verifies the signature (S208). If successfully verified, the private key is opened (S210) and used to decrypt the privacy attributes (S212) and script attributes (S214), which are compared to determine if the script considers privacy attributes (S216). If so, the encrypted data is decrypted (S218), the script processes the private data (S220), generates a result of being encrypted using the requestor's key (S222), and then the encrypted result is output ). The device is preferably configured to inhibit the output of any information while the data is not encrypted. In this way, it can be ensured to the user that the processing of private data takes into account the privacy attributes set by the user.

Description

[0001] METHOD AND DEVICE FOR PRIVACY-RESPECTING DATA PROCESSING [0002]

The present invention relates generally to data processing, and more particularly to privacy-respecting processing.

This section is intended to introduce the reader to various aspects of the technology that may be related to the various aspects of the invention described and / or claimed below. This discussion is believed to be helpful in providing background information to the reader to facilitate a better understanding of the various aspects of the invention. Accordingly, it will be appreciated that these statements will be read in this light, and not as admissions of the prior art.

If the user is able to set a restriction that considers privacy for use by a third party, then the user is willing to provide private user data for analysis by a third party in a particular aggregation There are cases of An example of this case is network traffic in the user's home. It may occur that the service provider modifies the services to better suit the user's needs in analyzing the user data. Other examples include recommender systems and medical statistics.

However, those skilled in the art realize that security is an important issue. How can the privacy of the data be taken into account by the user?

One solution is described in US 2004/054918 wherein a first user device can send a signed request to a second user device, the request being a request for data stored by a second user device. If the signature is successfully authenticated, the second device provides the requested data to the first user device. However, the main disadvantage of the solution is that it does not process the data, but just returns the requested data. Thus, it can not be used for data processing or analysis.

Another existing solution is homomorphic encryption, which is often inadequate for many reasons. First, the script may require processing that is incompatible with perceptual encryption, for example, processing that is not apolynomial to the input data. Second, the input data can be very large, in which case the perturbed encryption is slow. Third, processing sometimes uses software (e.g., from a library) from a third party that can not be all adapted or rewritten for perturbative encryption.

Additional existing solutions to this problem include thorough parcel -based encryption and data management in the cloud ( End - to - End Policy - Based Encryption and Management of Data in the Cloud ) ; Is described by Siani Pearson, Marco Casassa Mont and Liqun Chen in the 2011 Third IEEE International Conference on Cloud Computing Technology and Science. These solutions bind the encrypted data to "sticky policies" that identify privacy preferences for the data, and claim voluntary fulfillment of customized sticky key parlories It relies on a cloud service provider (CSP). However, there is no additional guarantee that the CSP considers privacy and that the CSP has access to both symmetric keys and in the clear data used for encryption.

Another traditional solution is to know where your data is located on HotOS 2011 and 2011 (P. Maniatis et al.). Secure data capsules for deployable data protection (Secure Data Capsules for Deployable Data Protection). The solution allows users to continuously track and control all their derivatives of data and data (copied and modified data), and supports any untrusted legacy binaries that manipulate the data. In summary, authors introduce the concept of "data encapsulation", a container that is cryptographically protected consisting of data, associated parcels, and the history of the container. Organizers that manipulate data capsules require a Trusted Computing Base (TCB). The TCB decapsulates the data encapsulation, verifies the associated parcels, executes untrusted binaries, and generates new data capsules as output. During execution of untrusted binaries, the TCB intercepts system calls and implements information flow tracking. Indeed, the information flow tracking adds a prohibitive overhead and is also called a "data-in-the-clear" (also known as side channels or "analog holes" hole "to attack powerful attackers. As pointed out by the authors, it is also difficult to support extensible policy semantics through information flow tracking.

Thus, it will be appreciated that solutions are needed that overcome at least some of the disadvantages of prior art solutions.

In a first aspect, the invention relates to a data processing method. A device is a device that encrypts data to be processed, privacy attributes associated with the encrypted data, the data processing task defining processing requirements to be considered to be processed to process the encrypted data or to output the result of data processing of the encrypted data Obtaining a signature for the privacy attributes, the script, and the script; Verify the signature; If the signature is successfully verified: decrypt the encrypted data to obtain decrypted data; Execute a script to process the decrypted data to obtain a result; Print the result. The device also compares the processing attributes of the script with the privacy attributes, where the processing attributes define the processing requirements considered by the script to determine if the script considers privacy attributes.

In a first preferred embodiment, the comparison is performed prior to the decryption step if the signature is successfully verified, and decryption is performed when determining that the script considers privacy attributes.

In a second preferred embodiment, the comparison is performed after processing, and the output is performed when determining that the script considers privacy attributes.

In a third preferred embodiment, the private key is sealed within the device, and the device opens the private key when it decides that the script considers privacy attributes.

In a fourth preferred embodiment, the device deletes at least one of the privacy attributes and the processing attributes after the comparison.

In a fifth preferred embodiment, the script is obtained from the requester, and the device encrypts the result using the requestor's key such that the result is output in an encrypted form.

In a second aspect, the invention relates to a device for data processing. The device comprising at least one interface configured to obtain encrypted data for processing; Obtaining privacy attributes associated with the encrypted data, wherein the privacy attributes define processing requirements to be considered to be allowed to process the encrypted data or to output the result of data processing of the encrypted data; Obtain signatures for scripts and scripts; Print the result. The device: verifies the signature; Comparing the processing attributes of the privacy attributes and the script if the signature is successfully verified, wherein the processing attributes define processing requirements considered by the script to determine if the script considers privacy attributes; Decrypting the encrypted data to obtain decrypted data; And a processor configured to execute the script to process the decrypted data to obtain a result.

In a first preferred embodiment, the private key is sealed in the device, and the processor is further configured to open the private key when determining that the script considers privacy attributes.

In a second preferred embodiment, the processor is further configured to delete at least one of the privacy attributes and the processing attributes after a comparison of the processing requirements and the processing attributes.

In a third preferred embodiment, the interface is configured to obtain a script from a requestor, and is further configured to obtain a requestor's key, and the processor uses the requestor's key to encrypt the result so that the result is output in an encrypted form Lt; / RTI >

In a fourth preferred embodiment, the device is configured to prohibit the output of any information while the data is decrypted.

In a fifth preferred embodiment, the device is implemented using a Trusted Platform Module. It is advantageous for the trusted platform module to rely on a trusted computing base that is released using late-launch trusted platform module capabilities.

In a sixth preferred embodiment, the processor is further configured to decrypt the encrypted data and to process the decrypted data only when the script successfully determines that it considers the privacy attributes.

In a seventh preferred embodiment, the processor is further configured to output the result only when the script successfully determines that it considers the privacy attributes.

Preferred features of the present invention will now be described by way of non-limiting example with reference to the accompanying drawings.

Through the use of the present invention, data owners can be assured of processing, storage, and security of the network.

1 illustrates a system for data processing in accordance with a preferred embodiment of the present invention.
Figure 2 illustrates a method for processing private data in accordance with a preferred embodiment of the present invention.

Figure 1 illustrates a system for data processing in accordance with a preferred embodiment of the present invention. The system 100 preferably includes the following entities:

Ratio (bee): Each user has an application 110 calls the "ratio". The ratio 110 is advantageously performed at the end-user's gateway, but may also be performed at another network device or in a dedicated box. The ratio is configured to collect the private data ( ClearBeeData ⁱ ) (i is the index of the ratio), e.g., information about the network traffic, and encrypt the collected data using its public key ( K ⁱ _bee ).

The ratio 110 may also store a user-defined privacy parlor containing privacy attributes ( priv ~ attr ⁱ ), or otherwise access a user-defined privacy parlor. The privacy attributes represent constraints on privacy characteristics to be considered by the analysis script processing the private data in a predefined format. The attributes may limit, for example, the type of operation that may be performed on the private data, or may identify the portion (s) of data that may be used.

Attributes may be viewed as a collection of Boolean conditions and keywords that the owner of the private data can identify to limit the use of the data. The privacy attributes may be matched to the processing attributes of the script to allow or disallow the script to process the data. When an attribute is a condition, the condition can also be matched after execution of the script: if the output of the script satisfies the condition, the output can be used as a result. Otherwise, there are at least two possible cases where owner preferences and expressions depend on the expressiveness: rejection and automatic correction of the output until it matches the condition. A known example of automatic correction is the addition of noise until an anonymity condition is met.

A non-limiting list of possible privacy attributes is:

No-payload: The script ignores any payload data: everything after the IP / UDP, IP / TCP header, for example.

Aggregate-output-only: The script outputs only global statistics, such as means or quantiles, rather than plain data from the input data.

● j-join: The output of the script is at least one combination of j distinct sets of data.

K-join: the output of the script is a combination of at least k unique data sets; The additional attribute data value is suppressed until the values of the remaining set of attributes are equal to the values of at least k-1 other data sets.

● K-anonymous: (2007, information The output of the script is usually "the release of each of the data is the value of the quasi-identifiers,""k-anonymity" by security advances , Springer US, page 4, V.Ciriani et al. All associations should be made unclearly matched to at least k responders ". K-anonymity is a stronger characteristic than the k-combination. Strictive-obfuscation (k-combination.strict- | -obfuscation): any answer to a query must include at least | records.

 • Upper-case: if the query succeeds and the data contains at least | records, the records contain records, or 0 otherwise.

.

Ratio 110, for example, h is a hash function (hash function) {or other suitable one-way function (one-way function)} yoke (cryptographicbind) of the password: attr ⁱ = (priv _ attr ^i, h (clearBeeData ⁱ⁾ ) To associate the parcels with private data. The bound policy ( attr ⁱ ) is preferably stored with the private data.

The ratio 110 encrypts the constrained parity attr ⁱ and private data ClearBeeData ⁱ using a bee's encryption key K ⁱ _bee and stores the 'hive' ({ ClearBeeData ⁱ } K ⁱ _{bee ,} { attr ⁱ } K ⁱ _bee }) to the storage device,

Only the owner of the private key associated with the key K ⁱ _bee can decrypt the encrypted data. To allow for flexibility in the system, ratio 110 is also a proxy re-generate the encryption key (proxy re-encryption key) (K ⁱ _{bee → Bk).} This key is encrypted through the public key of the so-called bee-keeper 140, instead of being passed through the plain text (plaintext), instead of being encrypted via the public key K ⁱ _{bee of the} non- Encryption of the encrypted data. Further details on proxy re-encryption are described in G. Ateniese et al., Improved Proxy Re-encryption Schemes with Applications to Secure Distributed Storage, ACM Transactions of Information and System Security , 9 (1): 1-30, Fe. It can be found in 2006. A suitable proxy re-encryption scheme based on ElGamal encryption is described in " Divertible protocols and atomic proxy cryptography "by M. Braze et al. Accordingly, re-encryption can be performed by an untrusted third party. In an embodiment that is preferred, the re-encryption key (K ⁱ _{bee → Bk)} is output to the hive 120.

Hives (hive): hive 120 stores the encrypted data received from the non-110, and the encrypted data proxy re-encrypts and re-encrypted data ({clearBeeData ^i} K ⁱ _Bk, {attr ⁱ } K ⁱ _Bk }. Thus, it will be appreciated that the trust requirement for hive 120 is very low, especially since hive 120 can not access unencrypted data during proxy re-encryption. The hive 120 is advantageously implemented using well-known cloud storage and processing.

Script proof authority ( Script Certification Authority): proof of authorization script 130 is responsible for evaluation (assessing) the ratio (bee), the received data processing tasks from requesters 150 is executed to process the private data ( "scripts"). The script proof authority 130 verifies that a given script violates or meets its claimed processing attributes. Upon successful validation of the script 135, the script proof authority 130 issues a digital certificate for the script 135 containing the processing attributes to which the script 135 is compliant. More formally, the output of the script proves rights (130) than _{is: {script, priv _ attr script} , K script} K CA -1, that is (over) key (K _CA for the data within the brackets (brackets) ^-1 ), where K _script is the public key of the requestor 150 and K _CA ^{- 1} is the public key of the script proof authority 130.

How the script proof authority 130 verifies the compliance of the script to the claimed processing attributes goes beyond the scope of the present invention. In the simplest form, authority can consist of a technical committee that manually examines scripts before attaching a signature. Members of the TCs need to be physically summoned because it is possible to use a signature scheme that each member signs using a partial key. Those skilled in the art will appreciate that the script analysis can also be performed automatically by the script proof right device 130 executing a suitable prior art script analysis program.

Non-keeper : The non-keeper 140 is a device that receives one or more scripts from the requestor 150 for execution of encrypted or re-encrypted data after downloading from the hive 120. The non-keeper 140 is preferably implemented using a Trusted Platform Module (TPM). The TPM enables secure storage of non-keeper private keys ( K ^-1 _Bk ) using the secure execution environment for the script and sealed storage.

The secure execution environment for the scripts is provided in the Intel ^® Trusted Execution Technology (Intel ^® TXT), Software Development Guide Measured Launched Environment Developer's Guide, March 2011, section 1.8, page 12 preferably obtained, depending on the market (late-launch) a trusted computing base (TCB) released by the TPM performance ^{- AMD Platform for Trustworthy computing ® 2003} Advanced Micro Devices, Inc., check page 17}, respectively, the so-called date. The latest-release (skinit or senter) resets the value of PCR17 to 0 and expands the value of PCR17 through the measurement (hash) of TCB: PCR ₁₇ ← H (0 || H (TCB) The measurement allows Unkealer 's private key unpacking: Unseal ( C ) K ^-1 _{Bk if this} is true (more specifically, Jonathan M. McCune et al., "Flicker: An Execution Infrastructure for TCB Minimization" , see section 2.4.) The key-pair of a non-keeper has been previously created and sealed (eg, at the time of non-keeper setup).

The TCB is configured to perform at least the following actions in a method for processing the private data shown in Figure 2:

(I) receiving encrypted private data and parcels { clearBeeData ⁱ } K ⁱ _bee , { attr ⁱ } K ⁱ _bee ( S 202 );

(Ⅱ) receiving (S204) the signature of the script and the signature property _{{(script, priv _ attr script} ) K CA};

(Iii) receiving (S206) the public key of the requester 150 (perhaps separate from the script);

(Iv) Verifying the script signature using the public key of the script proof authority 130 (S208). It will be noted that if the signature is not successfully verified, the method is discontinued.

( V ) opening the private key ( K- ¹ _Bk ) of the non-keepers (S210);

(Vi) extracting and decrypting the privacy properties of the parity, i.e., bee's private data (step S212), and extracting and decrypting the script attributes (step S214) S216), and deleting the decrypted privacy attributes;

(Iii) decrypt private data of non-use only (S218) only when the script considers privacy parcels bound to non-data;

(Iii) execution of a script on decrypted data (S220);

( C ) encrypting the result of using the public key (Kscript) of the requester 150 included in the _script (S222); And

(X) output of the encrypted result (S224)

While any data is in-clear, it is desirable that the TCB does not allow any system interaction. System interaction includes displaying a data portion on the screen, writing a different resource than the output file, and accessing the network. Powerful attackers that compromise an operating system that even implements a data processing task in this way (and using the latest run-time safe execution environment), or attackers attempting to replace or update data processing tasks Even private data can not be accessed. This can be done by several means, including checking by the proof authority that the script does not allow any system interaction, or by using external mechanisms such as SECCOMP included in Linux 2.6.23, It strictly limits the system interaction performance of the process. Further details on these mechanisms can be found in the description of PR_SET_SECCOMP in the man page of the Linux prctlcommand.

The private data is too large to be stored in the non-keeper's central memory and in this case the symmetric session key for use by the TCB to temporarily store session encrypted chunks in untrusted external storage ≪ RTI ID = 0.0 > and / or < / RTI > This can be done by encryption / decryption routines in the TCB, or by TPM_Seal and TPM_unseal operations using the store key.

The following algorithm is an example of a pseudocode for a non-keeper TCB:

procedure V ERIFY A ND R UN S CRIPT ((script, priv _ attr script, K script), signature script, {(data i; attr i), 0≤ i <n})

//스크립트에 의해 프로세싱될 데이터. 초기에는 비어있음(Empty) scriptInputData =

// The data to be processed by the script. Initially Empty

if ! _{Verify KCA (signature script, (script} , priv _ attr script, K script)) then

// Validate script signature using K _CA

return // End if signature is invalid

end if

Unseal ( C ) → ^-1 _Bk . // Unlock the private key of the non-keeper

for all i = 0 → n do // iterate over all the bee data

_{(Priv _ attr data, hash)} = {attr i} K -1 Bk // reading non-data privacy attributes

if priv _ attr _data _ priv _ attr _script then

// validate data privacy attributes vs script privacy attributes

clearBeeData ⁱ = { data ⁱ } K ^-1 _Bk

// If the attributes are compatible, decrypt the non-data

if hash ! = h ( clearBeeData ⁱ ) then

// Verify that the attributes belong to the data

return // end if the attributes do not belong to the data

end if

scriptInputData = scriptInputData ∪ clearBeeData ⁱ

// Add the decrypted data to the script's input data

end if

end for

out = Run ( script ; scriptInputData ) // Run the script for the aggregated data

out = { out } K _script // Encrypt script output through K _script

end procedure

Although not shown for purposes of clarity, a device of the present system may include the necessary hardware and software components required for proper functionality, such as, for example, processors, memory, user interfaces, communication interfaces, and operating systems &Lt; / RTI &gt;

Thus, it should be understood that the present invention can be used to maintain data confidential, except in trusted environments where capacity is verified and limited, and when data privacy attributes and script privacy attributes are compatible, and in this case only data processing It will be confirmed that it proposes.

Through the use of the present invention, data owners can be assured of processing, storage, and security of the network. Processing security means that the data is processed only in a manner allowed by the owner; This is accomplished using privacy attributes. Storage and network security means that data can not be accessed anywhere in the system except for the trusted part that executes the authorized scripts.

It will be appreciated by those skilled in the art that the present invention can provide a solution to increase the assurance of what the privacy parcels are being considered.

Each feature described in this description, and (where appropriate) the claims and drawings may be provided independently or in any suitable combination. Features described as being implemented in hardware may also be implemented in software, and vice versa. The reference signs in the claims are for illustrative purposes only and are not to be construed as limiting the scope of the claims.

110: Bee 120: Hive
130: Script Proof Authorization 140: Non-Keeper
150: Requestor

Claims (15)

CLAIMS 1. A data processing method comprising:
The method includes, in a device (140) comprising a processor,
Obtaining encrypted data (S202) to be processed,
Obtaining privacy attributes associated with the encrypted data (S202), the privacy attributes indicating that the data processing task is allowed to process the encrypted data or to output the result of the data processing of the encrypted data Obtaining (S202) privacy attributes that define processing requirements to respect,
Acquiring a signature for the script and the script (S204)
(S206) of verifying the signature,
If the signature is successfully verified,
Decrypting the encrypted data (S218) to obtain decrypted data,
Executing a script to process the decrypted data to obtain a result (S220)
The step of outputting the result (S224)
Lt; / RTI &gt;
The method further comprises comparing (S216) the processing attributes of the script with the privacy attributes, wherein the processing attributes define the processing requirements considered by the script to determine if the script considers privacy attributes, Way. 2. The method of claim 1, wherein the comparing is performed prior to the decryption step if the signature is successfully verified, and wherein the decrypting step is performed when determining that the script considers privacy attributes. 2. The method of claim 1, wherein the comparing step is performed after the processing step, and the outputting step is performed when determining that the script considers privacy attributes. The method of claim 1, further comprising: unsealing the private key (S210) when the private key is sealed within the device and the script determines that it considers privacy attributes. 2. The method of claim 1, further comprising: after step (S216), deleting at least one of the privacy attributes and the processing attributes. 3. The method of claim 1, wherein the script further comprises: (S222) encrypting the result using the requestor's key so that the result is obtained from the requestor and output to the encrypted form. A device (140) for data processing,
At least one interface,
Acquiring encrypted data to be processed,
Privacy attributes associated with the encrypted data are obtained, the privacy attributes defining the processing requirements to be considered to be allowed to process encrypted data or to output the result of data processing of the encrypted data. To obtain privacy attributes,
Obtain signatures for scripts and scripts,
At least one interface configured to output a result,
A processor,
Verifying the signature,
Comparing the privacy attributes and the processing attributes of the script when the signature is successfully verified, wherein the processing attributes define the processing requirements considered by the script to determine if the script considers the privacy attributes, Lt; RTI ID = 0.0 &gt;
Decrypting the encrypted data to obtain decrypted data,
A processor configured to execute the script to process the decrypted data to obtain a result,
/ RTI &gt; A device for data processing, comprising: 8. The device of claim 7, wherein the private key is sealed in the device and the processor is further configured to open the private key when the script determines that the script considers privacy attributes. 8. The device of claim 7, wherein the processor is further configured to delete at least one of the privacy attributes and the processing attributes after a comparison of the processing requirements and the processing attributes. 8. The method of claim 7,
Wherein the at least one interface is configured to obtain a script from a requestor and is further configured to obtain a requestor's key and wherein the processor is further configured to encrypt the result using the requestor's key such that the result is output in an encrypted form, Devices for processing. 8. The device of claim 7, wherein the device (140) is configured to inhibit output of any information while the data is decrypted. 8. The device of claim 7, wherein the device (140) is implemented using a Trusted Platform Module. 13. The device of claim 12, wherein the trusted platform module relies on a Trusted Computing Base launched using late-launch trusted platform module capabilities. 8. The device of claim 7, wherein the processor is further configured to decrypt the encrypted data and to process the decrypted data only when the script successfully determines that it considers the privacy attributes. 8. The device of claim 7, wherein the processor is further configured to output the result only when the script successfully determines that it considers privacy attributes.

Images