Data sharing device and data sharing method

Abstract

Connection units 200A, 200B connect to a data distribution platform and form a consensus on a contract including an asset and a policy shared among users. Execution units 230A, 230B start a secure isolated execution environment isolated by using an image of an execution environment including a policy execution program that operates according to the contract, and receive and process data according to the contract in the isolated execution environment. At least one of the isolated execution environment, the image of an execution environment, the contract inputted to the isolated execution environment, the data received in the isolated execution environment, and the processing result in the isolated execution environment is remotely attested.

Description

Data sharing device and data sharing method

[0001] The present disclosure relates to a data sharing device and a data sharing method.

[0002] In recent years, the spread of network services and the Internet of Things (IoT) has led to the collection of a wide variety of data. By sharing and analyzing the data collected by each company, it is possible to make effective use of the data. As a technology to promote data sharing between companies, a data distribution platform has been provided that allows for secure data sharing while ensuring data sovereignty. Data sovereignty refers to the right of data owners to control and manage their own data, as well as the right to make it subject to the laws and governance of the country in which the data is collected.

[0003] In the data distribution infrastructure of Non-Patent Document 1, once an agreement is formed between users, data is shared among the users in accordance with that agreement.

[0004] “IDS Reference Architecture Model Version 4”, International Data Spaces Association, https: / / docs.internationaldataspaces.org / knowledge-base / ids-ram-4.0

[0005] However, conventional data distribution platforms did not have a technical mechanism for controlling data usage, and there was a problem in that once data was in the hands of others, it could no longer be controlled.

[0006] Furthermore, if a user or system operator had malicious intent, they could change the programs and data managed by the user or system operator, rewrite the terms of use for data after agreement had been reached, or leak data to the outside.

[0007] The present disclosure has been made in light of the above and aims to fully protect users' data sovereignty.

[0008] A data sharing device of one embodiment of the present disclosure is a data sharing device that provides data sharing between users, and includes a connection unit that connects to a data distribution infrastructure and forms an agreement on sharing conditions, including data to be shared between users and terms of use, and an execution unit that launches a safe, isolated execution environment using an image of an execution environment that includes a program that operates in accordance with the sharing conditions, and receives and processes data within the isolated execution environment in accordance with the sharing conditions.

[0009] A data sharing method of one embodiment of the present disclosure is a data sharing method that provides data sharing between users, in which a computer connects to a data distribution infrastructure to form an agreement on sharing conditions including data to be shared between users and terms of use, launches an isolated and secure isolated execution environment using an image of an execution environment including a program that operates in accordance with the sharing conditions, and receives and processes data within the isolated execution environment in accordance with the sharing conditions.

[0010] According to the present disclosure, the data sovereignty of users can be fully protected.

[0011] FIG. 1 is a diagram showing an example of the configuration of a data distribution infrastructure. FIG. 2 is a diagram showing an example of the configuration of a connection unit. FIG. 3 is a sequence diagram showing an example of the flow of a data sharing process. FIG. 4 is a sequence diagram showing an example of the flow of a data sharing process. FIG. 5 is a diagram showing an example of the configuration of a data distribution infrastructure. FIG. 6 is a sequence diagram showing an example of the flow of a data sharing process. FIG. 7 is a sequence diagram showing an example of the flow of a data sharing process on the data provider side. FIG. 8 is a sequence diagram showing an example of the flow of a data transmission process between users. FIG. 9 is a sequence diagram showing an example of the flow of a data sharing process on the data user side. FIG. 10 is a diagram showing an example of the hardware configuration of each device and each unit of the data distribution infrastructure.

[0012] [Data Distribution Platform] An example of the configuration of a data distribution platform 100 will be described with reference to Fig. 1. The data distribution platform 100 in Fig. 1 is a centralized platform, but the data distribution platform may also be a decentralized platform.

[0013] User A is a person who belongs to Company A. User A uses connection unit 200A of data distribution infrastructure 100 to communicate with other users connected to data distribution infrastructure 100.

[0014] User B is a person who belongs to Company B. User B uses connection unit 200B of data distribution infrastructure 100 to communicate with other users connected to data distribution infrastructure 100.

[0015] Each user A and B is registered in advance as a user of the data distribution infrastructure 100. The connection units 200A and 200B hold an identification ID that enables mutual authentication in the data distribution infrastructure 100 and credentials that prove the ID. For example, if the data distribution infrastructure 100 uses a centralized authentication server, the connection units 200A and 200B use an identifier such as a URI as the identification ID and hold, as the credentials, a certificate issued by a Certificate Authority (CA) operated by an organization trusted by the data distribution infrastructure. If decentralized authentication is performed in the data distribution infrastructure, the connection units 200A and 200B hold a decentralized identifier (DID) and verifiable credentials (VC) signed by an organization trusted by the data distribution infrastructure.

[0016] Users A and B use the data distribution infrastructure 100 via the connection units 200A and 200B to form an agreement on data sharing. Once an agreement is formed between users A and B, the transmission / reception units 220A and 220B share the data between users A and B in accordance with policies managed by the connection units 200A and 200B. The transmission / reception unit 220A acquires user A's shared data from the data storage unit 300A and transmits it to the transmission / reception unit 220B, which then stores the shared data in the data storage unit 300B.

[0017] 2 is a diagram showing an example of the configuration of the connection units 200A and 200B. The connection units 200A and 200B include an asset definition management unit 201, a policy definition management unit 202, a contract definition management unit 203, a contract negotiation function unit 204, a contract agreement management unit 205, a policy application unit 206, and an authentication function unit 210. The connection units 200A and 200B can use the Eclipse Dataspace Component, which is an open source connector implementation. The connection units 200A and 200B may include transmission / reception units 220A and 220B, or may include execution units 230A and 230B, which will be described later.

[0018] An example of the flow of data sharing processing using the connection units 200A and 200B will be described below with reference to the sequence diagrams of FIGS.

[0019] In step S101, user A defines the identifier, address, credentials required to access the data, descriptive information and attribute information about the data, etc. of data (or data sets) that his company may share with other companies as assets, and registers them in the asset definition management unit 201 of the connection unit 200A.

[0020] In step S102, user A defines the data usage conditions for sharing their company's assets with other companies as a policy and registers it in the policy definition management unit 202 of the connection unit 200A. The data usage conditions can include the scope of asset disclosure (company name, required qualifications, country / region, etc.), whether the assets may be extracted from the system of the other company with which the data is shared, what conditions the other company may meet to analyze the assets using a program, the number of times, period, and type of execution environment the other company may perform analysis processing on the assets, and the period until the other company deletes the data.

[0021] In step S103, user A defines a contract that combines their company's assets and policies, and registers it in the contract definition management unit 203 of the connection unit 200A. The contract includes asset definitions and policy definitions, and is information for sharing with other companies information about which assets (data) can be used by other companies under what policies (data usage conditions). When disclosing a contract to other companies, it is possible to disclose only descriptive information and attribute information about the data, without disclosing the identifiers, addresses, and credentials required to access the data (or data sets) contained in the assets.

[0022] In step S104, user A publishes the contract as a contract proposal so that other companies can see it. User A can decide the scope of disclosure of the contract proposal. If the data distribution infrastructure is centralized, user A uses the function of the contract negotiation function unit 204 of the connection unit 200A to register the contract proposal in the catalog server 120 provided in the data distribution infrastructure 100, thereby making the contract visible to other companies' connection units 200B. If the data distribution infrastructure is decentralized, user A registers the contract proposal in a decentralized information sharing mechanism that allows contract proposals to be shared between the connection units 200A and 200B of each user, making the contract visible to other companies' connection units 200B.

[0023] In step S105, user B uses connection unit 200B to view the contract proposal published by user A. If the data distribution infrastructure is centralized, connection unit 200B views user A's contract proposal stored on catalog server 120. If the data distribution infrastructure is decentralized, connection unit 200B views user A's contract proposal using a mechanism for mutually exchanging and propagating catalogs between each user's connection unit 200A and 200B.

[0024] In step S106, user B initiates encrypted communication with user A's connection unit 200A using connection unit 200B to negotiate a contract in response to user A's contract proposal. Specifically, if the data distribution infrastructure 100 is a centralized system, the authentication function unit 210 of connection unit 200B requests a token from the authentication server 110 included in the data distribution infrastructure 100, and the authentication server 110 issues a token after confirming that connection unit 200B holds a valid certificate. Then, connection unit 200B transmits the token to the authentication function unit 210 of connection unit 200A. Connection unit 200A confirms the signature of the token and authenticates connection unit 200B. Similarly, the authentication function unit 210 of connection unit 200A requests a token from the authentication server 110, and the authentication server 110 issues a token after confirming that connection unit 200A holds a valid certificate. Then, the connecting unit 200A transmits the token to the authentication function unit 210 of the connecting unit 200B. The connecting unit 200B checks the signature of the token and authenticates the connecting unit 200A. If the data distribution infrastructure 100 is distributed, the connecting unit 200B transmits its own DID and VC to the connecting unit 200A. The connecting unit 200A uses the DID and VC to authenticate the connecting unit 200B. Similarly, the connecting unit 200A transmits its own DID and VC to the connecting unit 200B. The connecting unit 200B uses the DID and VC to authenticate the connecting unit 200A. Note that authentication may be performed using only the VC or only the Verifiable Presentation (VP).

[0025] In step S107, user B uses contract negotiation function unit 204 of connection unit 200B to request connection unit 200A of user A to negotiate a contract regarding the contract proposal made public by user A.

[0026] In step S108, contract negotiation function unit 204 of connection unit 200A confirms that the contents of the received contract negotiation request satisfy the conditions regarding the asset disclosure scope (company name, necessary qualifications, country / region, etc.) defined in the policy. If the conditions are satisfied, contract negotiation function unit 204 of connection unit 200A notifies contract negotiation function unit 204 of connection unit 200B of the establishment of negotiation and agreement.

[0027] In steps S109 and S110, the contract negotiation function unit 204 of each of the connection units 200A and 200B records the content of the agreed-upon contract in the contract agreement management unit 205 of each of the connection units 200A and 200B.

[0028] Once agreement is reached, the data is shared as per the process of FIG.

[0029] In step S111, the policy application unit 206 of the connection unit 200A instructs the transmission / reception unit 220A of user A to send and receive data based on the asset definition and policy definition included in the contract recorded in the contract agreement management unit 205 of the connection unit 200A.

[0030] In step S112, policy application unit 206 of connection unit 200B instructs user B's transmission / reception unit 220B to transmit and receive data based on the asset definition and policy definition included in the contract recorded in contract agreement management unit 205 of connection unit 200B. Note that the processing of step S111 may not be executed, and the processing of step S112 and subsequent steps may be started in response to an instruction to connection unit 200B from user B or a server owned by user B.

[0031] In step S113, the transmitting / receiving unit 220B of user B requests data from the transmitting / receiving unit 220A of user A.

[0032] In step S114, user A's transmitting / receiving unit 220A obtains data from user A's data storage unit 300A and transmits the data to user B's transmitting / receiving unit 220B.

[0033] In step S115, user B's transmitting / receiving unit 220B stores the data received from user A's transmitting / receiving unit 220A in user B's data storage unit 300B.

[0034] The transmission / reception units 220A and 220B can be configured as an API server or an API client. The data storage units 300A and 300B can be configured as a database, object storage, an API server of another system, or the like.

[0035] [First Embodiment] In the data distribution infrastructure 100, user A, who provides data, can define data usage conditions as a policy and provide the data only after reaching an agreement with user B, the recipient of the data. When user B receives the data, policy application unit 206 of connection unit 200B instructs transmission / reception unit 220B to comply with the policy (data usage conditions). However, because user B's policy application unit 206 and transmission / reception unit 220B are systems managed by user B, a malicious user could modify the programs of policy application unit 206 or transmission / reception unit 220B so that the policy is not complied with. If this continues, after user A sends data to user B, user A will not be able to control the use of that data, and user A's data sovereignty will not be adequately protected.

[0036] 5, the transmitting / receiving units 220A and 220B connected to the connecting units 200A and 200B are configured as execution units 230A and 230B that provide an isolated execution environment. Only one of the transmitting / receiving units 220A and 220B may be configured as the execution unit 230A or 230B.

[0037] An isolated execution environment is an environment built using technology called Trusted Execution Environment (TEE), in which programs can be executed in a secure environment isolated from other programs running in the same system using memory encryption functions provided by hardware such as CPUs and GPUs.The use of an isolated execution environment protects the data and programs processed within the isolated execution environment from the users who manage the isolated execution environment and the system operators who operate it, and makes it possible to analyze data in a confidential state from users and system operators.

[0038] The execution units 230A and 230B start the isolated execution environment by directly executing an enclave image, a software container image, or a virtual machine image (hereinafter collectively referred to as "execution environment image") that has been restricted to prevent external communication, login, and command execution other than for input and output of predetermined information so that even the user managing the isolated execution environment or the system operator cannot view or tamper with the data in the isolated execution environment. When the isolated execution environment is started, the contents of the agreed-upon contract (such as asset and policy information and data usage conditions described in the policy) are input.

[0039] Within the isolated execution environment, a policy executor with pre-defined behavior exists as part of the image of the execution environment. The policy executor can obtain the necessary information by interpreting the asset definitions and policy definitions included in the contract, requesting data according to the asset definitions, and processing the data according to the policy definitions. The policy executor may monitor the behavior of other programs running within the isolated execution environment and restrict behavior that deviates from the asset and policy definitions. By running the policy executor within the isolated execution environment, the data usage conditions agreed upon in the contract negotiation are observed. Because the policy executor is protected by the isolated execution environment, it cannot be changed.

[0040] Furthermore, to prevent the user managing the isolated execution environment, the system operator, or other programs running in the same system from directly accessing the memory and tampering with the data, the TEE function of the hardware, such as the CPU and GPU, that operate as the execution units 230A and 230B is enabled. As a result, the isolated execution environment is started up in such a way that the information in the memory used by the isolated execution environment is always encrypted with an encryption key that can only be accessed by programs within the isolated execution environment.

[0041] Furthermore, the information required for processing in the isolated execution environment is added to the asset definitions and policy definitions used for contract negotiation and agreement in the data distribution platform. Examples of information required for processing in the isolated execution environment include hash values ​​required to verify assets (data, programs, parameters, etc.) acquired in the isolated execution environment, hash values ​​of decryption keys for decrypting acquired assets, and public keys for verifying signatures on acquired assets, which are previously included in the asset definitions or policy definitions in the data distribution platform. The specifications of the isolated execution environment and information on programs and applications to be executed in the isolated execution environment may also be included in the asset definitions and policy definitions.

[0042] By defining the specifications of the isolated execution environment in advance, users A and B can agree on the specifics of what data and what processing will actually be performed within the isolated execution environment that they have mutually agreed upon through contract negotiations in the data distribution platform. Furthermore, if the logs output by the isolated execution environment also include assets and policies in the same format, it becomes easy to verify afterward that the processing performed within the isolated execution environment is indeed based on the contract agreed upon by users A and B in advance.

[0043] Until now, the content and processing methods of assets and policies used in contract negotiation and contract agreement in the data distribution platform and the content and processing methods of assets and policies used in data processing by services or software providing an isolated execution environment built using a TEE were defined independently for each purpose. Therefore, the asset and policy information used in the data distribution platform had to be adapted to the asset and policy format used in the isolated execution environment when the isolated execution environment was executed. At the time of contract negotiation and contract agreement in the data distribution platform, it was difficult for users to specifically specify what data and what processing would be performed in the isolated execution environment based on the content described in the assets and policies. By adding the information required for processing in the isolated execution environment to the assets and policies of the data distribution platform, it is possible to specifically specify the processing in the isolated execution environment at the time of contract negotiation and contract agreement.

[0044] An example of the flow of data sharing processing after a contract agreement is described below with reference to the sequence diagram in Figure 6. In the following description, execution by the isolated execution environment means execution by a program running within the isolated execution environment, or execution by the hardware that constitutes the execution units 230A and 230B.

[0045] In step S201, when a new contract agreement is reached, the policy application unit 206 of user A's connection unit 200A instructs user A's execution unit 230A to start a new isolated execution environment and input information about the contract and the assets and policies contained in the contract into the isolated execution environment.

[0046] In step S202, execution unit 230A starts up an isolated execution environment. Inside the isolated execution environment, there exists a policy execution program whose operation is predetermined and is included in the image of the execution environment.

[0047] In step S203, when a new contract agreement is reached, the policy application unit 206 of user B's connection unit 200B instructs user B's execution unit 230B to start a new isolated execution environment and input information about the contract and the assets and policies contained in the contract into the isolated execution environment.

[0048] In step S204, execution unit 230B starts up the isolated execution environment. Inside the isolated execution environment, there exists a policy execution program whose operation is predetermined and is included in the image of the execution environment.

[0049] In step S205, the isolated execution environment of user B (e.g., a policy execution program) transmits a data request to the isolated execution environment of user A based on the asset information. The connection unit 200B of user B may transmit the data request at the time the contract agreement is concluded. The asset information may include not only data, but also a highly confidential data processing program possessed by user B that is necessary for processing the data, as well as additional data and parameters that are necessary to operate the data processing program.

[0050] Note that the processes of steps S203, S204, and S205 may be executed before the processes of steps S201 and S202 are executed, and the process of step S202 may be executed in response to a data request in step S205.

[0051] In step S206, the isolated execution environment of user A (e.g., the policy execution program) acquires highly confidential data from the data storage unit 300A based on the asset information. The asset information may include not only the data, but also a highly confidential data processing program owned by user A that is necessary for processing the data, as well as additional data and parameters that are necessary for running the data processing program.

[0052] In step S207, User A's isolated execution environment processes the data in accordance with the policy (data usage conditions). The data usage conditions can include any necessary constraints, such as anonymizing the data, filtering it, or converting it into synthetic data, within User A's isolated execution environment. A constraint application program required to implement these constraints can be executed within the isolated execution environment.

[0053] In step S208, after confirming that the data usage conditions are met, the isolated execution environment of user A transmits the data to the isolated execution environment of user B. Note that, even without a request from user B, that is, even if no data request is received in step S205, after the contract is agreed upon, user A's isolated execution environment may execute the processing of steps S206 and S207 and transmit the data.

[0054] In step S209, User B's isolated execution environment processes the received data in accordance with the data usage conditions. The data usage conditions can include necessary constraints, such as anonymizing the data in User B's isolated execution environment, filtering it, converting it into synthetic data, limiting the data processing method or number of times it can be processed, or deleting the raw data before analysis when its retention period expires. A constraint application program required to implement these constraints can be executed in the isolated execution environment.

[0055] In step S210, the isolated execution environment of user B confirms that the data usage conditions are met, and then transmits the processed data to user B's data storage unit 300B.

[0056] After processing the data, the execution units 230A and 230B may discard the isolated execution environment including the received data.

[0057] Data processing may be shared between the isolated execution environments of users A and B, or all data processing may be performed in the isolated execution environment of user A, or all data processing may be performed in the isolated execution environment of user B. When all data processing is performed in either environment, the side not performing data processing may be equipped with transmitting / receiving units 220A and 220B instead of execution units 230A and 230B.

[0058] This embodiment can also be applied to a use case in which multiple users share different data with user B, and the data is processed using a single policy and in a single isolated execution environment.

[0059] As described above, according to this embodiment, by executing a policy execution program in an isolated execution environment that processes data in compliance with the asset definitions and policy definitions included in the agreed-upon contract, even if user B or the system operator has malicious intent, the policy execution program cannot be modified to not comply with the policy. This makes it possible for user A to control the use of data according to the policy even after user A has sent the data to user B, thereby protecting user A's data sovereignty.

[0060] Furthermore, by including the information necessary for processing in the isolated execution environment in the asset definitions and policy definitions included in the contract, users can specifically specify the content of data processing in the isolated execution environment.Furthermore, by having the isolated execution environment output a log containing assets and policies in the same format as the data distribution platform, it becomes easy to confirm that the content processed in the isolated execution environment is based on the agreed-upon contract.

[0061] [Second embodiment] In the first embodiment, the user cannot confirm whether the other party's isolated execution environment is created from an image of an execution environment that ensures data confidentiality, whether a policy execution program exists in the image of the execution environment, and whether the TEE function is enabled.

[0062] In the second embodiment, remote attestation is performed on an isolated execution environment. Before transmitting data from user A's isolated execution environment to user B's isolated execution environment, users A and B perform remote attestation on each other's isolated execution environment. Remote attestation may be performed by either user A or B alone, or by both users reciprocally. Furthermore, if the system operator is malicious, user A himself may perform remote attestation on user A's isolated execution environment, or user B himself may perform remote attestation on user B's isolated execution environment, to confirm that information has not been tampered with by the system operator.

[0063] There are two types of remote attestation for isolated execution environments: remote attestation for isolated execution units, and remote attestation for an image of an execution environment including a policy execution program.

[0064] Remote attestation related to isolated execution units refers to remote attestation related to isolated execution units protected by the TEE function, such as enclaves, software containers, and virtual machines. For example, in the case of a virtual machine, the TEE function verifies whether the hardware (CPU, GPU, etc.) on which the TEE function runs, the virtual machine firmware, the initial file system, the operating system (Linux kernel, etc.), and the program execution command first launched on the operating system are all previously agreed upon between users, for example, by comparing their hash values. The TEE function collects information to verify these items, creates an attestation report, and signs it with confidential information (such as a private key) held by the TEE function. The execution units 230A and 230B (isolated execution environments) provide the attestation report to the user who manages the isolated execution environment.

[0065] Remote attestation for an image in an execution environment refers to a remote attestation for an image that is launched immediately after the execution of firmware, an initial file system, an operating system (such as a Linux kernel), or the first program execution command launched on the operating system. The TEE function acquires a hash value for the image immediately before the image is launched, creates an attestation report including the hash value, and signs it with confidential information held by the TEE function. The execution units 230A and 230B (isolated execution environments) provide the attestation report to the user who manages the isolated execution environment.

[0066] A user can request the other user to present an attestation report and verify the signature and hash value included in the attestation report to confirm that the isolated execution environment and execution environment image agreed upon between the users are being used. The signature on the attestation report can be verified using information (such as a public key or certificate) released by the manufacturer of hardware such as a CPU or GPU. The connection units 200A and 200B or the execution units 230A and 230B may also verify the other user's attestation report.

[0067] Until now, remote attestation of isolated execution environments built using TEE has generally been performed by the user of the isolated execution environment. In this usage pattern, the user can verify that the isolated execution environment they use is an appropriately isolated environment, but the user cannot prove this to other users, and other users cannot verify it.

[0068] As described above, according to this embodiment, by performing attestation of an isolated execution environment and providing an attestation report to the other party, the user can confirm whether the image of the execution environment for constructing the isolated execution environment is trustworthy, whether a policy execution program exists in the image of the execution environment, whether the policy execution program has not been modified, and whether the TEE function is enabled.

[0069] [Third Embodiment] In the first and second embodiments, a user cannot confirm whether the asset and policy information included in the contract entered into the other party's isolated execution environment, and the data usage conditions described in the policy, are the same as those included in the contract agreed upon between the users.

[0070] In the third embodiment, remote attestation is performed on a contract entered into an isolated execution environment. Before data is transmitted from user A's isolated execution environment to user B's isolated execution environment, users A and B perform remote attestation on the contents of the contract entered into each other's isolated execution environment (such as asset and policy information and data usage conditions described in the policy). Remote attestation may be performed by either user A or B alone, or by both users reciprocally. Furthermore, if the system operator is malicious, user A may perform remote attestation on user A's isolated execution environment, or user B may perform remote attestation on user B's isolated execution environment, to confirm that the system operator has not tampered with the information.

[0071] Users share each other's public keys or certificates in advance, mutually create signatures for the contents of the agreed-upon contract, and share them together with the agreed-upon contract. The user who receives the contract and signature then verifies the signature with the public key of the other user with whom the agreement was made. This allows the user to confirm that the contract, the asset and policy information contained in the contract, and the data usage conditions written in the policy are indeed what the other user agreed to.

[0072] Remote attestation of the contents of the contract entered into the isolated execution environment is performed within the isolated execution environment by verifying the hash value of the contents of the contract immediately before processing. A program that has already performed remote attestation within the isolated execution environment (such as a policy execution program) collects assets and policies and calculates the hash value. The TEE function creates an attestation report that includes the hash value and signs it with confidential information held by the TEE function. The isolated execution environment provides the attestation report to the user who manages the isolated execution environment.

[0073] A user can request the other user to present an attestation report and verify the signature and hash value included in the attestation report to confirm that the contents of the contract entered into the isolated execution environment are those previously agreed upon between the users. The signature on the attestation report can be verified using information (public keys, certificates, etc.) published by the manufacturers of hardware such as CPUs and GPUs.

[0074] As described above, according to this embodiment, by performing remote attestation on a contract entered into an isolated execution environment and providing an attestation report to the other party, the user can confirm whether the contract entered into the other party's isolated execution environment is the same as the one included in the contract agreement.

[0075] [Fourth embodiment] In the first to third embodiments, a user cannot confirm after the fact that the processing executed in the other party's isolated execution environment was performed on the assets included in the contract agreed upon between the users in accordance with the contents of the policies included in the agreed-upon contract.

[0076] In the fourth embodiment, remote attestation of execution history is performed. Users A and B perform remote attestation on highly confidential data processed in each other's isolated execution environment and the data output as a result of that processing. Remote attestation may be performed by either User A or User B alone, or both may perform it mutually.

[0077] Remote attestation of highly confidential data processed within the isolated execution environment and the data output as a result of that processing is confirmed by comparing the hash values ​​of the highly confidential data and the processing results within the isolated execution environment. A program that has already performed remote attestation within the isolated execution environment (such as a policy execution program) calculates the hash values ​​of the highly confidential data and the processing results. The TEE function creates an attestation report that includes the hash value and signs it with confidential information held by the TEE function. The isolated execution environment provides the attestation report to the user who manages the isolated execution environment.

[0078] A user can request the other user to present an attestation report and verify the signature and hash value included in the attestation report to confirm that the data processed in the isolated execution environment is the agreed-upon, highly confidential data and that the processing content was also the agreed-upon process. The signature on the attestation report can be verified using information (public keys, certificates, etc.) published by the manufacturers of hardware such as CPUs and GPUs.

[0079] Hash value calculations can be performed in several ways: by calculating a single hash value for the entire confidential data and the data output as a result of that processing; by calculating multiple hash values ​​for different types of data (e.g., input and output) and then combining or concatenating them; or by calculating hash values ​​for each data or file, then calculating a list of these hash values ​​and providing the list to the user along with the attestation report. By dividing the hash values ​​into multiple parts, even if the user performing the remote attestation only knows a portion of the data, it is possible to verify the hash values ​​for that portion. Furthermore, the generation of the hash value can also include the hash value of the constraint application program required to execute the constraints included in the data usage conditions. This allows for confirmation that the constraint application program has been agreed upon in advance between users A and B.

[0080] As described above, according to this embodiment, remote attestation is performed on highly confidential data and processing results in an isolated execution environment, and an attestation report is provided to the other party, allowing the user to confirm that the data processed in the other party's isolated execution environment is agreed-upon data and that the processing content is agreed-upon processing.

[0081] Fifth Embodiment Highly confidential data is input into the isolated execution environment of user A from the data storage unit 300A based on asset information. However, with a typical data input method, even if encrypted communication is performed using key exchange, if the system operator is malicious, there is a possibility that highly confidential data will be leaked along the communication path from the data storage unit 300A to the inside of the isolated execution environment. This is because user A's isolated execution environment is activated when a new contract agreement is concluded between users A and B, and the data storage unit 300A, which is the data sender, cannot confirm at the time of data transmission that the isolated execution environment is the correct isolated execution environment agreed upon by users A and B.

[0082] In the fifth embodiment, data input to the isolated execution environment is encrypted. A pair of a public key and a private key is generated in User A's isolated execution environment, and User A stores the data encrypted with the public key in the data storage unit 300A. As a result, the encrypted data stored in the data storage unit 300A can only be decrypted using the private key present in the isolated execution environment, and the data can be protected from leakage along the communication path from the data storage unit 300A to the isolated execution environment.

[0083] An example of the flow of processing in which the isolated execution environment of user A acquires data after the contract is agreed upon will be described with reference to the sequence diagram of FIG.

[0084] In step S301, execution unit 230A starts up an isolated execution environment based on an instruction from policy application unit 206 of connection unit 200A.

[0085] In step S302, the isolated execution environment performs attestation.

[0086] In step S303, the attested program (such as a policy enforcement program) generates a pair of a public key and a private key in the isolated execution environment.

[0087] In step S304, the isolated execution environment sends an attestation report including the public key to user A. Specifically, the TEE function creates an attestation report including the public key and signs it with confidential information (such as a private key) held by the TEE function. The isolated execution environment then sends the attestation report including the public key to user A. By verifying the signature on the attestation report, user A can confirm that the public key is a public key generated within the isolated execution environment. The signature on the attestation report can be verified using information (such as a public key or certificate) made public by the manufacturer of hardware such as a CPU or GPU. User A may obtain the public key from the isolated execution environment separately from the attestation report. In this case, by including a hash value of the public key in the attestation report, it can be confirmed that the public key is a public key generated within the isolated execution environment.

[0088] In step S305, user A stores the data encrypted using the public key in data storage unit 300A.

[0089] In step S306, the isolated execution environment obtains the encrypted data from data storage unit 300A.

[0090] In step S307, the isolated execution environment decrypts the encrypted data with the private key it holds. After decrypting the encrypted data, the isolated execution environment processes the data and transmits it to user B.

[0091] Although the amount of data that can be encrypted with a public key may be limited, data encryption and decryption can be performed using the following procedure. User A generates a new common key and encrypts data using the common key, while encrypting only the common key with the public key. User A stores both the data encrypted with the common key and the common key encrypted with the public key in data storage unit 300A. The isolated execution environment obtains both the data encrypted with the common key and the common key encrypted with the public key, decrypts the common key with the private key, and decrypts the data with the decrypted common key. This makes it impossible to decrypt the data without using the private key present in the isolated execution environment.

[0092] As described above, according to this embodiment, a pair of a public key and a private key is generated within the isolated execution environment, and data encrypted with the public key is stored in the data storage unit 300A, thereby protecting highly confidential data from leakage on the communication path from the data storage unit 300A to the isolated execution environment of user A. Furthermore, since the attestation report of user A's isolated execution environment includes information about the public key, user A can verify the validity of the public key.

[0093] [Sixth Embodiment] Highly confidential data is input into the isolated execution environment of user B from the isolated execution environment of user A based on asset information. However, with a normal data input method, even if encrypted communication is performed using key exchange, if the system operator is malicious, there is a possibility that highly confidential data will be leaked along the communication path from the isolated execution environment of user A to the isolated execution environment of user B. This is because the isolated execution environment of user B is activated when a new contract agreement is concluded between users A and B, and the isolated execution environment of user A, which is the data sender, cannot confirm at the time of data transmission that the isolated execution environment is the correct isolated execution environment agreed upon by users A and B.

[0094] In the sixth embodiment, data transmitted between users is encrypted. A pair of a public key and a private key is generated in the isolated execution environment of user B, and user A's isolated execution environment transmits data encrypted with the public key. As a result, the encrypted data transmitted from user A's isolated execution environment can only be decrypted with the private key present in user B's isolated execution environment, thereby protecting the data from leakage along the communication path from user A's isolated execution environment to user B's isolated execution environment.

[0095] An example of processing for transmitting data from the isolated execution environment of user A to the isolated execution environment of user B after a contract is agreed upon will be described with reference to the sequence diagram of FIG.

[0096] In step S401, execution unit 230A starts up an isolated execution environment based on an instruction from policy application unit 206 of connection unit 200A.

[0097] In step S402, the isolated execution environment performs attestation.

[0098] Similarly, on the user B side, in step S403, the execution unit 230B starts up an isolated execution environment based on an instruction from the policy application unit 206 of the connection unit 200B.

[0099] In step S404, the isolated execution environment performs attestation.

[0100] In step S405, the attested program (such as a policy enforcement program) generates a pair of public and private keys in the isolated execution environment of user B.

[0101] In step S406, user B's isolated execution environment sends an attestation report including the public key to user A's isolated execution environment. Specifically, the TEE function creates an attestation report including the public key and signs it with confidential information (such as a private key) held by the TEE function. User B's isolated execution environment sends the attestation report including the public key to user A's isolated execution environment. A program in user A's isolated execution environment can verify the signature on the attestation report to confirm that the public key is a public key generated in the isolated execution environment. The signature on the attestation report can be verified using information (such as a public key or certificate) published by the manufacturer of hardware such as a CPU or GPU. User A may obtain the public key from user B's isolated execution environment separately from the attestation report. In this case, including the hash value of the public key in the attestation report can confirm that the public key is a public key generated in the isolated execution environment.

[0102] In step S407, the isolated execution environment of user A acquires the data from data storage unit 300 A. The isolated execution environment of user A may process the data in accordance with the data usage conditions.

[0103] In steps S408 and S409, when user A's isolated execution environment transmits data to user B's isolated execution environment, it encrypts the data using the public key and transmits the encrypted data to user B's isolated execution environment.

[0104] In step S410, the isolated execution environment of user B decrypts the encrypted data with the private key it holds. After decrypting the encrypted data, the isolated execution environment processes the data and stores the processed data in data storage unit 300B.

[0105] Although the amount of data that can be encrypted with a public key may be limited, data encryption and decryption can be performed as follows: User A's isolated execution environment generates a new common key and encrypts the data using the common key, while encrypting only the common key with the public key. User A's isolated execution environment sends both the data encrypted with the common key and the common key encrypted with the public key to User B's isolated execution environment. User B's isolated execution environment receives both the data encrypted with the common key and the common key encrypted with the public key, decrypts the common key with the private key, and decrypts the data with the decrypted common key. This makes it impossible to decrypt the data without using the private key present in User B's isolated execution environment.

[0106] To prevent data sent from user A's isolated execution environment to user B's isolated execution environment from being tampered with, a pair of public and private keys is generated in user A's isolated execution environment, the public key is sent to user B's isolated execution environment, and user A's isolated execution environment signs the data to be sent to user B's isolated execution environment with the private key. User B's isolated execution environment can verify the signature using the public key to confirm that the received data has not been tampered with. The authenticity of the public key can be verified by including this public key information in the attestation report.

[0107] As a variation of this implementation method, user B may generate a public key and private key pair outside the isolated execution environment, send the private key or both the public key and private key to user B's isolated execution environment, and then send the public key to user A's isolated execution environment. Even if user B does not have an isolated execution environment, by sending the public key to user A's isolated execution environment, encrypted data received from user A's isolated execution environment can be decrypted with the private key held by user B and stored in data storage unit 300B. Note that because the environment in which the public key and private key pair is generated is not within the isolated execution environment, depending on the required security requirements, a mechanism may be required to protect the public key and private key pair from tampering by malicious system operators.

[0108] As described above, according to this embodiment, a pair of a public key and a private key is generated in the isolated execution environment of user B, and the isolated execution environment of user A encrypts data with the public key and transmits the encrypted data to the isolated execution environment of user B, thereby protecting highly confidential data from leakage along the communication path from the isolated execution environment of user A to the isolated execution environment of user B. Furthermore, since the attestation report of user B's isolated execution environment includes information about the public key, user A can verify the authenticity of the public key.

[0109] [Seventh Embodiment] Highly confidential data transmitted from user A's isolated execution environment is output from within user B's isolated execution environment based on asset information. However, with a typical data input method, even if encrypted communication is performed using key exchange, if the system operator is malicious, there is a possibility that highly confidential data will be leaked along the communication path from user B's isolated execution environment to user B's data storage unit 300B. This is because user B's isolated execution environment is activated when a new contract agreement is concluded between users A and B, and user B's isolated execution environment, which is the data sender, cannot confirm at the time of data transmission that the data sender is the correct user B's data storage unit 300B.

[0110] In the seventh embodiment, data output from the isolated execution environment is encrypted. A pair of a public key and a private key is generated in the data storage unit 300B of user B, and the isolated execution environment of user B transmits data encrypted with the public key. As a result, the encrypted data transmitted from the isolated execution environment can only be decrypted using the private key held by the data storage unit 300B, and therefore the data can be protected from leakage along the communication path from the isolated execution environment to the data storage unit 300B.

[0111] An example of processing for transmitting data from the isolated execution environment of user B to the data storage unit 300B after the contract is agreed upon will be described with reference to the sequence diagram of FIG.

[0112] In step S501, execution unit 230B starts up an isolated execution environment based on an instruction from policy application unit 206 of connection unit 200B.

[0113] In step S502, the isolated execution environment performs attestation.

[0114] In step S503, the data storage unit 300B generates a pair of a public key and a private key. The pair of a public key and a private key may be generated by a device other than the data storage unit 300B, and the private key may be stored in the data storage unit 300B.

[0115] In step S504, data storage unit 300B transmits the public key to the isolated execution environment.

[0116] In steps S505 and S506, when transmitting data to data storage unit 300B, the program in the isolated execution environment encrypts the data using the public key and transmits the encrypted data to data storage unit 300B.

[0117] In step S507, data storage unit 300B decrypts the encrypted data with the private key it holds and stores the decrypted data.

[0118] Note that the public key and private key pair is generated in the data storage unit 300B, and the environment in which the public key and private key pair is generated is not within an isolated execution environment. Therefore, depending on the required security requirements, a mechanism may be required to protect the public key and private key pair from being tampered with by malicious system operators.

[0119] To prevent data sent from the isolated execution environment to the data storage unit 300B from being tampered with, a pair of a public key and a private key is generated within the isolated execution environment, the public key is sent to the data storage unit 300B, and the data to be sent to the data storage unit 300B is signed with the private key. The data storage unit 300B can verify the received data has not been tampered with by verifying the signature using the public key. The authenticity of the public key can be verified by including information about this public key in the attestation report.

[0120] As described above, according to this embodiment, a pair of a public key and a private key is generated in the data storage unit 300B, and the isolated execution environment of user B encrypts data using the public key and sends it to the data storage unit 300B, thereby protecting highly confidential data from leakage along the communication path from the isolated execution environment of user B to the data storage unit 300B.

[0121] The first embodiment may be freely combined with any of the second to seventh embodiments.

[0122] [Examples] The connection units 200A, 200B, transmission / reception units 220A, 220B, execution units 230A, 230B, and data storage units 300A, 300B used in the data distribution infrastructure 100 may be devices owned by each company, virtual machines on the cloud, or provided as a cloud application service (SaaS). A combination of devices, virtual machines on the cloud, and cloud application services may be used for each company or each unit. Several examples are described below.

[0123] The first embodiment is an embodiment in which data is transmitted and received between a factory of company A and a factory of company B based on an agreed contract.

[0124] User A's connection unit 200A, execution unit 230A, and data storage unit 300A are located in Company A's factory, while User B's connection unit 200B, execution unit 230B, and data storage unit 300B are located in Company B's factory. Data storage unit 300A may be a database that accumulates data collected from Company A's factory. Data storage unit 300B may be a database that allows data to be viewed from Company B's factory.

[0125] Data is sent from Company A's factory to Company B's factory. At that time, the data is sent and received based on the data usage conditions agreed upon in the contract negotiations.

[0126] The second embodiment is an embodiment in which data is transmitted and received between a cloud of company A and a cloud of company B based on an agreed contract.

[0127] User A's connection unit 200A, execution unit 230A, and data storage unit 300A are located on the cloud subscribed to by Company A, while user B's connection unit 200B, execution unit 230B, and data storage unit 300B are located on the cloud subscribed to by Company B. Data storage unit 300A may be a database that accumulates data collected from Company A's factory. Data storage unit 300B may be a database that allows data to be viewed from Company B's factory.

[0128] Data is sent from Company A's cloud to Company B's cloud. At that time, data is sent and received based on the data usage conditions agreed upon in the contract negotiations.

[0129] The third embodiment is an embodiment in which data is transmitted and received between a factory of company A and a cloud application service of company B based on an agreed contract.

[0130] User A's connection unit 200A, execution unit 230A, and data storage unit 300A are located in Company A's factory, and User B's connection unit 200B, execution unit 230B, and data storage unit 300B are located on Company B's cloud application service. Data storage unit 300A may be a database that accumulates data collected from Company A's factory. Data storage unit 300B may be a database that allows data to be viewed from Company B's factory.

[0131] Data is sent from Company A's factory to Company B's cloud application service. At that time, data is sent and received based on the data usage conditions agreed upon in the contract negotiations.

[0132] The fourth embodiment is an embodiment in which data is transmitted and received between a cloud application service of company A and a cloud application service of company B based on an agreed contract.

[0133] User A's connection unit 200A, execution unit 230A, and data storage unit 300A are located on Company A's cloud application service, while User B's connection unit 200B, execution unit 230B, and data storage unit 300B are located on Company B's cloud application service. Data storage unit 300A may be a database that accumulates data collected from Company A's factory. Data storage unit 300B may be a database that allows data to be viewed from Company B's factory.

[0134] Data is sent from the cloud application service of Company A to the cloud application service of Company B. At that time, the data is sent and received based on the data usage conditions agreed upon in the contract negotiations.

[0135] In any of the embodiments, the technology disclosed herein is applied, and data is sent from user A's execution unit 230A to user B's execution unit 230B. When the execution unit 230B processes the data provided by user A, the data can be encrypted and kept confidential from the system operator and user B. User A can control data usage so that only pre-agreed processing is performed by the execution unit 230B. Furthermore, user A can verify that the isolated execution environment, data usage conditions, and execution history of the execution unit 230B have not been tampered with by performing remote attestation.

[0136] As a variation of the embodiment, a program for analyzing data may be sent in secret from user A, the data provider, to user B's execution unit 230B for use, or user B, the data user, may send it to execution unit 230B and use it.

[0137] Furthermore, with an agreement between users A and B, user B can obtain only the analysis results of user A's data by execution unit 230B, but cannot view the data sent by user A to execution unit 230B as is.

[0138] Furthermore, the devices, clouds, or cloud application services used by Company B may be connected to devices, clouds, or cloud application services used by multiple companies, not just Company A, and with the agreement of all companies, including Company A, data from multiple companies may be analyzed across the board, allowing User B to obtain the analysis results.

[0139] Each device and each unit of the data distribution infrastructure 100 described above can be, for example, a general-purpose computer system including a central processing unit (CPU) 901, memory 902, storage 903, communication device 904, input device 905, and output device 906, as shown in Fig. 10. In this computer system, each device and each unit of the data distribution infrastructure 100 is realized by the CPU 901 executing a predetermined program loaded onto the memory 902. This program can be recorded on a computer-readable non-transitory recording medium such as a magnetic disk, optical disk, or semiconductor memory, or can be distributed via a network.

[0140] DESCRIPTION OF SYMBOLS 100 Data distribution infrastructure 110 Authentication server 120 Catalog server 200A, 200B Connection unit 201 Asset definition management unit 202 Policy definition management unit 203 Contract definition management unit 204 Contract negotiation function unit 205 Contract agreement management unit 206 Policy application unit 210 Authentication function unit 220A, 220B Transmission / reception unit 230A, 230B Execution unit 300A, 300B Data storage unit

Claims

1. A data sharing device that provides data sharing between users, comprising: a connection unit that connects to a data distribution infrastructure and forms agreement between users on sharing conditions, including data to be shared and terms of use; and an execution unit that starts a safe, isolated execution environment using an image of the execution environment that includes a program that operates in accordance with the sharing conditions, and receives and processes data within the isolated execution environment in accordance with the sharing conditions.

2. A data sharing device according to claim 1, wherein the execution unit verifies the reliability of at least one of the isolated execution environment, the image of the execution environment, the sharing conditions, the data received within the isolated execution environment, and the processing results in the isolated execution environment.

3. A data sharing device according to claim 1, wherein a pair of a public key and a private key is generated within the isolated execution environment, and data encrypted with the public key is received and decrypted with the private key.

4. A data sharing device according to claim 1, wherein the data sharing device receives a public key within the isolated execution environment and transmits data encrypted with the public key.

5. A data sharing method for providing data sharing between users, comprising the steps of: connecting to a data distribution infrastructure, forming an agreement between users on sharing conditions including data to be shared and terms of use; starting up a safe, isolated execution environment using an image of the execution environment including a program that operates in accordance with the sharing conditions; and receiving and processing data in accordance with the sharing conditions within the isolated execution environment.

6. A data sharing method according to claim 5, further comprising verifying the reliability of at least one of the isolated execution environment, the image of the execution environment, the sharing conditions, the data received within the isolated execution environment, and the processing results in the isolated execution environment.

7. A data sharing method according to claim 5, comprising generating a pair of a public key and a private key within the isolated execution environment, receiving data encrypted with the public key, and decrypting the data with the private key.

8. A data sharing method according to claim 5, comprising receiving a public key in the isolated execution environment and transmitting data encrypted with the public key.

Images