JP2021136686A - Data management method - Google Patents

Abstract

To safely manage data of high secrecy.SOLUTION: In a data management method, the contents of data to be managed by a distributed ledger are recorded in a trusted server including a trusted execution environment, encrypted data obtained by encrypting the data is recorded in the distributed ledger, and when the contents of data are updated in the trusted server, encrypted data obtained by encrypting the updated contents is added to the distributed ledger. When the encrypted data is added to the distributed ledger, the trusted server updates the contents of the data by decrypting the added encrypted data.SELECTED DRAWING: Figure 4

Description

The present invention relates to a data management method.

Patent Document 1 employs a secret calculation method in which encrypted data is recorded on a blockchain and can be calculated while being encrypted.

Japanese Unexamined Patent Publication No. 2020-021048

However, the technique described in Patent Document 1 can only use a special calculation method.
General processing cannot be performed.

The present invention has been made in view of such a background, and an object of the present invention is to provide a technique capable of safely managing highly confidential data.

The main invention of the present invention for solving the above problems is a data management method, in which the contents of data to be managed by the distributed ledger are recorded in a trusted server provided with a trusted execution environment, and the distributed ledger can be used. When the encrypted data obtained by encrypting the data is recorded and the contents of the data are updated by the trusted server, the encrypted data in which the updated contents are encrypted is added to the distributed ledger, and the distributed data is added. When the encrypted data is added to the ledger, the trusted server decrypts the added encrypted data and updates the contents of the data.

Other problems disclosed in the present application and solutions thereof will be clarified in the columns and drawings of the embodiments of the invention.

According to the present invention, highly confidential data can be safely managed.

It is a figure explaining the structure of a general computer. It is a figure explaining the trusted execution environment (TEE; Trusted Execution Environment). It is a figure explaining the threat which can be dealt with by TEE. It is a figure which shows the whole structure example of the data management system which concerns on one Embodiment of this invention. It is a figure which shows the hardware configuration example of the computer which realizes a user terminal 1, a TEE server 2 and BC node 3. It is a figure explaining the outline of the data management in the data management system of this embodiment. It is a figure explaining data access from a user. It is a figure explaining the sub-protocol related to the data management in the data management system of this embodiment. It is a figure explaining the attestation service. It is a figure which shows the main item of the REPORT structure which is replied from the attestation service. It is a figure explaining the verification process of REPORT. It is a figure explaining the operation when the TEE server 2 is added. It is a figure which shows the flow of the process of adding a TEE server 2. It is a figure explaining the group state of the TreeKEM format. It is a figure which shows the configuration example of the application key chain included in a group state. It is a figure explaining the detail of the handshake in the operation of FIG. It is a figure explaining the collision of writing. It is a figure explaining the block height in the blockchain network 30 at the time of a write conflict. It is a figure explaining the writing collision determination. It is a figure explaining the state transition of the secret information at the time of collision verification. It is a figure explaining the mechanism for the falsification detection of the state transition in the enclave 21.

<Outline of the invention>
The contents of the embodiments of the present invention will be described in a list. The present invention includes, for example, the following configuration.
[Item 1]
The contents of the data to be managed by the distributed ledger are recorded on the trusted server equipped with the trusted execution environment, and
Cryptographic data obtained by encrypting the data is recorded in the distributed ledger.
When the content of the data is updated on the trusted server, the encrypted data obtained by encrypting the updated content is added to the distributed ledger.
When the encrypted data is added to the distributed ledger, the trusted server decrypts the added encrypted data and updates the contents of the data.
A data management method characterized by.
[Item 2]
The data management method described in item 1.
The user terminal sends an update request for the data to the trusted server, and the user terminal sends a request to update the data.
The trusted server transmits the encrypted data obtained by encrypting the updated contents to the nodes constituting the corresponding distributed ledger.
The node adds the encrypted data to the distributed ledger and propagates it to the other nodes.
Each of the nodes sends the added cryptographic data to the corresponding trusted server.
The trusted server decrypts the added encrypted data and updates the contents of the data recorded by itself.
A data management method characterized by.
[Item 3]
The data management method described in item 1.
The data including the signature with the private key created by the trusted server is transmitted to the attestation service to verify the validity, the attestation service signs the verification result, and the trusted server sends the verification result to the trusted. The public key created by the server is registered in the distributed ledger, and the node verifies the signature of the verification result.
When a transaction occurs in the distributed ledger, the trusted server verifies the signature included in the transaction using the registered public key.
A data management method characterized by.
[Item 4]
The data management method described in item 3
The verification result includes information that identifies the program that the trusted server is executing.
At the time of signature verification of the verification result, the trusted server verifies that the program executed by itself matches the program indicated by the information contained in the verification result.
A data management method characterized by.
[Item 5]
The data management method according to item 4.
Further, at the node, it is verified that the program indicated by the information included in the verification result and the program indicated by the information included in the verification result registered in the distributed ledger match. To do,
A data management method characterized by.
[Item 6]
The data management method described in item 3
The trusted server generates a pair of the private key and the public key, includes the public key in the verification result, and registers the public key in the distributed ledger.
A data management method characterized by.
[Item 7]
The data management method described in item 3
When adding the trusted server
The trusted server to be added
Have the attestation service verify the validity of its trusted execution environment
The verification result by the attestation service is transmitted to the existing trusted server, and the result is transmitted to the existing trusted server.
The existing trusted server
Have the attestation service verify the validity of its trusted execution environment
By collating the verification result by the attestation service with the verification result received from the added trusted server, it is determined whether or not the added trusted server can participate.
When it is determined that the added trusted server can participate, the participation of the added trusted server is determined by collating with the verification result received from the added trusted server.
A data management method characterized by.
[Item 8]
The data management method described in item 1.
The encryption is performed using a common group key,
Each of the trusted servers has its own private key, and the public keys of all the trusted servers are recorded in the distributed ledger.
The trusted server calculates a seed using all the public keys and its own private key so as to calculate the same group key, and calculates the group key based on the seed.
A data management method characterized by.
[Item 9]
The data management method described in item 1.
The trusted server calculates a first hash value of all data for each block managed by the distributed ledger, records the first hash value in the distributed ledger, and updates the contents of the data. In that case, the second hash value of the hash value before the update and the contents of all the blocks after the update is calculated, and the second hash value is recorded in the distributed ledger.
A data management method characterized by.

<Outline of this embodiment>
Hereinafter, a data management system according to an embodiment of the present invention will be described with reference to the drawings.
The data management system of the present embodiment makes it possible to manage data more safely when managing highly confidential data (for example, personal information). In the data management system of the present embodiment, data is managed in the blockchain to prevent data tampering, and encrypted data is managed in the blockchain to ensure data confidentiality or anonymity, and encryption is performed. A trusted execution environment (T) as an environment for decoding and processing the converted data.
By adopting EE (Trusted Execution Environment), confidentiality and safety are improved.

FIG. 1 is a diagram illustrating a general computer configuration. In a typical computer, the operating kernel allocates program code and data to memory dynamically during and after process creation, and user applications use a virtual address space to prevent memory fragmentation and access to purpose-built memory. I am using. The operating system calculates in the CPU based on the mapping memory in the page table of the kernel memory, reads the instruction from the memory, reads the data from the memory to the register based on the instruction, and performs the operation based on the data on the register. , The operation result is written back to the memory. A cache memory or the like may exist in the middle.

FIG. 2 is a diagram illustrating a Trusted Execution Environment (TEE). TEE is a type of secure hardware. TEE is, for example, an extended function of the CPU for executing a program while protecting highly confidential data by generating a cryptographically strictly protected area called an enclave in the memory. .. As shown in FIG. 2A, in TEE, the program and data for realizing enclave are stored in PRM (Processor Reserved Memory), which is a subset of DRAM. The PRM is an area that cannot be directly accessed by other software. Furthermore, the content of the enclave is EPC (Enclave Page Cache), which is a subset of PRM.
Recorded in. That is, the EPC on the DRAM is the actual protected area. The CPU restricts access from software from outside the enclave (all software including system software such as the operating system). The memory in the EPC is encrypted, and the CPU can decrypt and perform the calculation. The CPU also controls direct memory access to the EPC.

As shown in FIG. 2 (b), each enclave has an ELRANGE (Enclav).
A virtual address space called e Linear Address Range) is specified. ELRANGE is mapped to the EPC region. On the other hand, virtual address allocation is the role of the kernel (which TEE does not trust). All EPCs are statically assigned before the enclave initialization phase. The enclave contains a page table.

FIG. 3 is a diagram illustrating threats that can be dealt with by TEE. TEE can prevent the leakage of confidential information (including private key, password, etc.) using malware or the like. Also, in TEE, the operating system is not trusted, only the CPU and the code in the enclave are trusted. As attacks, countermeasures against memory corruption (illegal memory rewriting, operation, etc.), attacks from system software (untrusted operating system), and call boot attacks (memory reading due to forced volatilization delay, etc.) are taken. There is. The explanation of the figure is "Graphene-SGX: A Practical Library".
OS for Unmodified Applications on SGX ", Chia-Che Tsai, Donald E. Porter, Mona
Vij. USENIX: https://www.usenix.org/system/files/conference/atc17/atc17-tsai.pdf
It is explained in.

In the present embodiment, highly confidential data to be managed (hereinafter referred to as confidential information) is referred to as TEE.
Stored in the enclave of, the user reads and writes confidential information to the TEE server. On the other hand, data in which confidential information is encrypted (hereinafter referred to as encrypted information) is registered in the blockchain, and operations such as reading and writing to the confidential information are generated as transactions on the blockchain. Confidential information and encrypted information are synchronized. This makes it possible to combine the difficulty of tampering with the blockchain and the confidentiality of the TEE.

<System overview>
FIG. 4 is a diagram showing an overall configuration example of a data management system according to an embodiment of the present invention.
The data management system of the present embodiment includes a TEE server 2 and a blockchain network 3. The blockchain network 30 is composed of a plurality of blockchain nodes (BC nodes 3). In the present embodiment, the BC node 3 is provided with the corresponding TEE server 2. The BC node 3 and the TEE server 2 are one-to-one.
It may be configured as a pair of, or one BC node 3 is supported by a plurality of TEE servers 2.
And / or, one or more TEE servers 2 may correspond to a plurality of BC nodes 3. Further, in the present embodiment, the TEE server 2 constitutes one tree.

The TEE server 2 is a computer provided with TEE. The TEE server 2 manages confidential information in response to a request from the user terminal 1. The BC node 3 constitutes the blockchain network 30 as described above. The encrypted information is registered in the distributed ledger in the BC node 3.

FIG. 5 is a diagram showing a hardware configuration example of a computer that realizes a user terminal 1, a TEE server 2, and a BC node 3. User terminal 1, TEE server 2 and BC node 3
For example, it may be a general-purpose computer such as a workstation or a personal computer, or it may be logically realized by cloud computing. The computer includes a CPU 01, a memory 102, a storage device 103, and a communication interface 104.
, An input device 105, and an output device 106. The storage device 103 stores various data and programs, such as a hard disk drive, a solid state drive, and a flash memory. The communication interface 104 is an interface for connecting to a communication network, for example, an adapter for connecting to Ethernet (registered trademark), a modem for connecting to a public telephone network, a wireless communication device for performing wireless communication, and the like. It is a USB (Universal Serial Bus) connector or RS232C connector for serial communication.
The input device 105 is, for example, a keyboard, a mouse, a touch panel, a button, a microphone, or the like for inputting data. The output device 106 is, for example, a display, a printer, a speaker, or the like that outputs data.

<Overview of data management>
FIG. 6 is a diagram illustrating an outline of data management in the data management system of the present embodiment. In the data management system of the present embodiment, the TEE server 2 records the secret information in plain text and encrypts the secret information in order to protect the confidentiality of the data when shared by the blockchain network 30. .. That is, highly confidential data is handled only inside the TEE protected area, and only encrypted data (ciphertext) is recorded on the blockchain network 30. The TEE server 2 is a computer having a protected area in which data cannot be viewed from the outside. Since the TEE guarantees that the data inside the protected area cannot be viewed from the outside without permission, the confidentiality of the confidential information can be ensured. Further, in TEE, it is possible to guarantee that the correct program is operating by the attestation service described later, so that the calculation completeness can be guaranteed.

FIG. 7 is a diagram illustrating data access from a user. In the data management system of the present embodiment, the blockchain network 30 is used to guarantee confidentiality or anonymity.
The ciphertext of each state is held above in a format that is not tied to the account. Unstructured data (ciphertext) is managed on-chain (distributed ledger managed by blockchain network 30) so that anonymity is guaranteed, and off-chain (places not managed by blockchain, that is, TEE server). In 2), structured data (confidential information in plain text) is managed so that state transitions can be made. The decrypted confidential information is the off-chain enclave 21.
It will temporarily exist only within. Therefore, it is possible to manage the decrypted confidential information in the protected area that cannot be freely accessed by the user. Further, in the data management system of the present embodiment, in response to the request from the user terminal 1, the TEE server 2 changes the state of the secret information in the enclave 21, encrypts the result, and broadcasts it to the blockchain network 30. be able to. Then, the other TEE server 2 can update the secret information in the enclave 21 by reading the ciphertext from the blockchain network 30 and decrypting it in the enclave 21. The encrypted information cannot be decrypted in the blockchain network 30, but can be decrypted only in the enclave 21. TEE server 2 by on-chain REPORT verification described later
The computational completeness of can be verified. The REPORT verification verifies whether the TEE server 2 is running the intended program. If the user terminal 1 wants to acquire the state of the secret information, it can be obtained from the TEE server 2.

The data management system of the present embodiment has the following five properties.
(1) Data usefulness: All confidential information can be restored from the data managed by the blockchain network 30.
(2) Blockchain compatibility: Operates on various existing blockchains.
(3) Asynchronous: Each TEE server 2 operates asynchronously.
(4) Confidentiality: Encrypted data is managed in the blockchain.
(5) Correct execution: It is executed without conflict.

FIG. 8 is a diagram illustrating a sub-protocol related to data management in the data management system of the present embodiment.

Challenge-response authentication is performed between the user terminal 1 and the TEE server 2 (S8).
01). This is data management accessible with a user key pair. Next, in the enclave 21, CGKA secure group encryption is performed (S802). That is, it means that a specific ciphertext decryption (secret key leakage) does not affect other ciphertexts. A transaction signature method for preventing a simulation attack of the TEE server 2 is adopted (S803). This means that the TEE server 2 verifies that the processing is correct only by signing. A lock method of write conflict is adopted (S804). That is, it is a measure against data conflict. Match verification of the state hash value in the enclave 21 for each block height is performed (S805).
.. This makes it possible to guarantee that all TEE servers 2 have the same internal state.

<Atestation service>
FIG. 9 is a diagram illustrating an attestation service. A service provider (SP) is a computer that does not have an enclave 21, and an independent software vendor (ISV) is an enclave 2.
It is a computer equipped with 1. The attestation service 4 authenticates that the SP is a legitimate enclave 21. It authenticates whether the CPU is manufactured by a specific manufacturer, whether it is vulnerable, and whether it is a comparison of MRENCLAVE (comparison of execution programs). The attestation service 4 is implemented by, for example, an open source DCAP. The QUATE generated by the enclave 21 is transmitted to the attestation service 4, and the REPORT signed with the private key of the attestation service 4 is returned. QUATE includes MRENCLAVE (enclave measurement value, hash value). ISV is C
Sign the QUATE with the private key in the PU. The private key is a unique key set when the CPU chip is manufactured, and functions as a so-called Root of Trust. The attestation service 4 verifies the signature with the corresponding public key. This makes it possible to guarantee that the QUATE is sent from a legitimate trusted execution environment. The attestation service 4 responds with a REPORT signed with a private key. For REPORT, M
RENCLAVE is included. Attestation service 4 is X.I. It can be authenticated with a 509 certificate.

FIG. 10 is a diagram showing the main items of the REPORT structure responded from the attestation service. id is a unique identifier and timestamp is REPORT.
This is the time stamp at the time of generation. version is the API version, isvE
nclaveQuoteStatus is the status for the EPID signature. CP
UCVN is the security version of the CPU and MISCSEKECT is Enc.
It is the processor state when an exception occurs in the love, and ATTRIBUTES is an attribute flag of the enclave 21. MRENCLAVE is an enclave measurement value. MR
SIGNER is a hash value of the RSA public key modulus of the enclave signing key. ISVPRODID is the product ID of the enclave and ISVSVN is the security version of the enclave. REPORTDATA is report data.

<REPORT verification>
FIG. 11 is a diagram illustrating a REPORT verification process. The verification process of REPORT is
It attempts to agree on-chain that the TEE servers 2 are all running the same program. Each TEE server 2 transmits QUATE to the attestation service 4 and undergoes verification as to whether or not it is a legitimate trusted execution environment. REPORT is returned from the attestation service 4. In the attestation service 4, as described above, the signature verification by the unique private key of the CPU, the security version check, and the like are performed. REPORT includes MRENCLAVE, X.I. Authenticated with 509 certificate.

The TEE server 2 uses smart contracts to be on-chain at deployment time and R
EPORT signature verification, MRENCLAVE registration, and parameter registration such as public key and endpoint are performed. The TEE server 2 is a REPORT DAT in REPORT.
Set the public key (RAK) and nonce generated in the enclave 21 in item A. TEE
The server 2 registers the public key on-chain. In the blockchain network 30, in a normal transaction, it is possible to verify whether or not a well-known public key is registered and to perform signature verification using the public key. Therefore, if the program code of the enclave 21 is changed, the signature private key in the memory is also lost, and the signature verification cannot be performed. Therefore, by verifying REPORT, it is possible to guarantee the authenticity of the program being executed by the enclave 21 (that the same program as the enclave 21 of the other TEE server 2 is being executed). Nonces can be set to prevent REPORT replay attacks.

The TEE server 2 shall perform REPORT verification only at the time of the first participation and the periodical refresh. This eliminates the need to communicate with the attention service 4 for each transaction.

<Participation in the network>
FIG. 12 is a diagram illustrating an operation when the TEE server 2 is added. In the example of FIG. 12, the TEE server 2 (2) is newly added, and the TEE server 2 (1) already exists.

The new TEE server 2 (2) transmits the signed QUATE structure data to the attestation service 4 (S121). From Ate Station Service 4, REPORT
The structure data is returned (S122). Existing TEE from new TEE server 2 (2)
Initkey is transmitted to the server 2 (1) (S123). The public key of initkey will be registered as a group state. The TEE server 2 (1) and the TEE server 2 (2) mutually verify REPORT. That is, the new TEE server 2 (2)
) And the existing TEE server 2 (1) to share the REPORT structure data and REPO.
While verifying RT signature, time stamp, status, etc., each other's MRENC
Verify whether the LAVEs match.

Next, the group state is transmitted from the existing TEE server 2 (1) to the new TEE server 2 (2) (S124). The group state is in the TreeKEM format, which will be described later. The new TEE server 2 (2) adds a private key (dhsecret) and extracts the group key used for encryption from the group state. Also, the new TEE server 2 (2)
) Creates an add handshake from the group state, and transmits the handshake and the signature mapping to the blockchain network 30 (S125). In addition, the new TEE server 2 (2) can transmit REPORT and designated parameters (TEE name, URL, time stamp, etc.) to the blockchain network 30 by a smart contract. In blockchain network 30, REPOR
T verification, MRENCLAVE match verification, nonce verification in REPORTDATA, RE
Public key registration, time stamp registration, etc. in PORTDATA can be performed.

FIG. 13 is a diagram showing a flow of processing for adding the TEE server 2.

The signature is transmitted from the user terminal 1 to the new TEE server 2 (S1301), and the TE
Signature verification is performed on the E server 2 (S1302). The new TEE server 2
QUATE is transmitted to the attestation service 4 (S1303), and REPORT is returned from the attestation service 4 (S1304). An initkey is transmitted from the new TEE server 2 to the existing TEE server 2 (S1305), and a welcome is returned from the existing TEE server 2 (S1306).

The new TEE server 2 broadcasts REPORT, public key, nonce, and additional handshake to blockchain network 30 (S1307). In the blockchain network 30, MRENCLAVE verification (S1308), REPORT signature verification (S1309), nonce verification (S1310), and public key verification (S1311).
, REPORT date and time verification (S1312) is performed and an additional handshake is performed (S1313).

A handshake is replied from the blockchain network 30 to the existing TEE server 2 (S1314), and the existing TEE server 2 updates the group state (S1315).
). A handshake is also responded to the new TEE server 2 from the blockchain network 30 (S1316), and the new TEE server 2 also updates the group state (S1).
317).

As described above, the new TEE server 2 is registered in the network.

<TreeKEM format>
FIG. 14 is a diagram illustrating a TreeKEM format group state. TreeKE
For more information on M (Tree-structured Key Encapsulation Method), see MLS.
(Messaging Layer Security) RFC standard draft of protocol (https://tools.ietf)
.org / html / draft-ietf-mls-protocol-08). Here, the delivery server (Delivering)
It is assumed that the blockchain network 30 performs the ordering of Server).
In addition, the order of handshakes and application messages shall be globally common. The existence of the master seed shared by the entire network of the TEE server 2 is deleted. Since the key can be freely changed for each TEE server 2, what to do after information leakage (P)
CS; Post-Compromise Security) is possible. You can also delete the master.

The tree-structured leaf is a node (public key DHP) generated from each member's initkey.
ubKey). Only the relevant member knows the private key DHSeclet of the member connected by the leaf and its direct path.

In the example of FIG. 14, route K is known to all members. KDF (Key Deriva)
statement Function) Can be used as a group key for the chain. Create
, Add, Update, Remove Handshake operation, TreeKEM
Changes. Epoch changes and becomes a countermeasure (PCS) after information leakage. On-chain, public key (signer_i) associated with epoch and signer's index
ndex => identity Pubkey) is retained. Thereby, when the operation is an update, it can be determined whether or not the signer_index exists, and when the operation is addition and deletion, it can be determined whether or not the signer_index exists. The signature of the handshake can be verified by the identity Pubkey.
At the time of handshake, it is possible to verify whether or not the previous index (prior_index) matches. Also, the epoch is incremented with each handshake. The TEE server 2 can verify the HMAC in the received handshake.

FIG. 15 is a diagram showing a configuration example of the application key chain included in the group state. This application keychain is the cornerstone of forward secrecy. In the data management system of this embodiment, the application chain is rotated for each TEE server 2. It can be identified by the signed public key. By using the KDF chain for each member index (roster idx) from the group key, it is possible to generate a key used for message encryption while obtaining forward secrecy. A ratchet can be used to decrypt the received message. In addition, ML
In S, a ratchet is also used for encryption. The generation for each user is held in the enclave 21. In order for the blockchain network 30 to globally order this generation and epoch changes, a common key can be used for common encrypted information in all TEE servers 2.

FIG. 16 is a diagram illustrating details of the handshake in the operation of FIG. New T
The group state generated from the welcome received by the EE server 2 (2) in step S124 includes the private key DHSecretKey only in its own node. Then, you can find the key of the node connected by the path directly from your own node. Only you know the private key. The leaf index of the new TEE server 2 (2) is determined by the existing member TEE server 2 (1). In step S125, the initk of the new TEE server 2 (2)
ey is recorded in the blockchain network 30, but the private key DHSecretKe
y is not included. The blockchain network 30 determines the member index (roster index) of the new TEE server 2 (2), and in the response step S126 of the handshake, the member index (roster index) of TreeKEM.
Add the public key DHPubKey to and determine the new group route.

Initkey includes user_init_key_id, supported_ve
rsion, cipher_suites, dhpubkey, credential,
Signature is included.

Welcome (group state) includes user_init_key_id, ci
Includes pehr_suite and enclosed_group_state.

For the Add handshake, preor_epoch, GroupAd, s
igner_index, signature, conf_mac are included. here,
GroupAdd includes roster_index, init_key, welcome
_Hash is included.

By sharing the TreeKEM format group state in the blockchain network in this way, it is possible to share the key more efficiently than sharing the private key between each pair of TEE servers 2. Even if the private key used for encryption (the secret key of the root node of TreeKEM) is leaked, other ciphertexts cannot be decrypted because they are encrypted with different private keys. Further, since the private key managed by each TEE server 2 can be used for encryption, the responsibility for leaking the private key can be divided for each subject.

<Updated handshake>
An example of updating the node F in the TreeKEM shown in FIG. 14 will be described. All member TEE servers 2 get the updated group route (K). When F is updated, its HKDF becomes the key of I, which is the parent node. Updated I and K are only communicated to their respective subgroups. That is, I encrypts with the key of E, and K encrypts with the key of J. For the update handshake, prior_epoch, Update
eOperation, signature_index, signature, conf_
Macintosh is included.

<Delete handshake>
In the TreeKEM shown in FIG. 14, when a handshake to remove D is performed, the handshake is broadcast by the blockchain network 30 to erase all the keys of the nodes that D knows. That is, the keys of D, H, J, and K from D to route K are deleted.

<Writing process>
FIG. 17 is a diagram illustrating a writing collision. For example, there is a possibility of competition that a state transition in which Alice sends 20 remittances to Bob occurs in one TEE server 2 and a state transition in which Charlie sends 30 remittances to Bob occurs in another TEE server 2. Since the TEE server 2 operates independently, collision detection (and lock control) is required so that anonymity is not lost on the chain.

FIG. 18 is a diagram for explaining the block height in the blockchain network 30 at the time of write conflict. When two blocks are added in one TEE server 2 (A) and one block is added in another TEE server 2 (B), the TEE server 2 (A)
), The block height is 5, and the block height is 6 in the TEE server 2 (B).
When the conflict exclusion control is performed, the block height should be 8 in each case.

FIG. 19 is a diagram illustrating a write collision determination. Supplement the pre-occurrence relationship so that write operations are not performed in parallel. That is, the TEE server 2 adds a random number r having a fixed byte length to the encryption information transmitted to the blockchain network 30. That is, Enc (pubke) given to the encryption function Enc including the public key pubkey, the state information state, and the current random number (hash value in this embodiment) r_i.
y || state || r_i) is transmitted. In Enclave 21, the public key pubke
Record the state information state and the hash value r_i in association with y (pubkey => (
state, r_i)).

The TEE server 2 adds a nonce set of r to the on-chain storage for lock control. Also, the transaction should include the immediately preceding hash r_ {i-1}. In the blockchain network 30, after confirming that r_ {i-1} does not exist in the noncet, r_i is added to the noncet. Transaction processing in the blockchain network 30 is ordered globally. Therefore, if the transaction captured in the block uses r_ {i-1}, it will be rejected by the nonce verification in the next transaction.

In the example of FIG. 19, the TEE server 2 (A) registers Bob's balance with 70 and has a block height of 7.
After becoming, the TEE server 2 (B) reads this state and r of the TEE server 2 (B).
Since _i is repelled by the nonce verification, transaction processing is performed at a block height of 8 by performing a new retry process.

The state transition by the same user (TEE server 2) is limited to once per block.

FIG. 20 is a diagram for explaining the state transition of the secret information when the collision verification is performed. TE
Data synchronization between the E server 2 and the blockchain network 30 is performed independently by each TEE server 2 at best effort. When the TEE server 2 (A) whose synchronization is delayed broadcasts a transaction that rewrites Bob's state to the blockchain network 30, the random number portion must be r_2.
Here, r_0 = 0, and r_1 is a hash value including r_0. For example, the transition target account and the transition state are set_0, and r_1 = Hash (a).
It can be obtained as ccount, state_0, r_0). Similarly, r_2 =
Hash (account, state_1, r_1), generalized to r_ {i} =
Hash (account, state_ {i-1}, r_ {i-1}). FIG. 20
In the example of, r_2 = Hash (Bob, 30, r_1). In this way, collision detection can be performed by performing encryption including the hash value at the time of the immediately preceding state transition.

Note that the state transition for the transition target (account) for which collision verification is not performed may broadcast the encrypted data without locking. For example, the state transition of the recipient in remittance is applicable. Where the sender needs to verify the balance, in the use case of "remittance", it is considered that the sender does not straddle multiple TEE servers 2, so the state transition is substantially performed without locking. be able to. It is also possible to lock using a flag.

FIG. 21 is a diagram illustrating a mechanism for detecting falsification of state transitions in the enclave 21. All enclaves 21 must have the same state for each block height, at least for the part that maps the state of the user (account).
It is preferable to verify that the hash values match on-chain. Therefore, in the data management system of the present embodiment, the block height and the state hash value at that time are included in all transactions in the blockchain network 30. That is, the RPC handler 22 sends the transaction index (t) to the enclave 21.
x_index) is cached so that it is sequential. Then, a hash chain of the state (enclave_state) managed by the enclave 21 is created so that the state change can be efficiently hash-calculated and the order can be verified. That is, using the hash function H, HASH_i = H (state_i, H (state)), where the i-th hash value is HASH_i and the i-th state is state_i.
Calculate the hash value by _ {i-1})). As a result, even if the state of a certain enclave 21 is tampered with, the tampering can be carried out by the blockchain network 3
It can be detected at 0 or another TEE server 2. Further, in the present embodiment, the encrypted information can be verified at all BC nodes 3 in the blockchain network 30 that manages the encrypted information. Therefore, the security can be improved in addition to the method of verifying the validity of transaction data only by a single authentication server as in the prior art.

Although the present embodiment has been described above, the above embodiment is for facilitating the understanding of the present invention, and is not for limiting and interpreting the present invention. The present invention can be modified and improved without departing from the spirit thereof, and the present invention also includes an equivalent thereof.

For example, in the present embodiment, TEE (Trusted Execution Environment) is assumed, but it is not limited to TEE, and any computing environment with high confidentiality may be used. For example, it is possible to use services such as AWS Enclaves.

Further, in the present embodiment, the TEE server 2 and the BC node 3 are separated from each other.
As a whole, the BC node 3 may include an enclave 21 to realize the function of the TEE server 2.

Further, in the present embodiment, the group state is assumed to be in the TreeKEM format.
Not limited to this, for example, Asynchronous Ratcheting Tree (AR)
It may be in the T) format. That is, in the group state, the group participants (in this embodiment, all TEE servers 2) can share the public key with all the participants, and the public keys of all the participants and their own private keys are used. It is possible to calculate the group seed according to the tree structure or the like, and any structure may be used as long as it is possible to calculate the data calculated from the group seed by hash calculation or the like as a common group key. By encrypting the secret information using this group key, all TEE servers 2 can perform encryption using a common key, and the addition, update, and deletion of the public key to the group state can be performed. , Can be associated with adding, updating, and deleting members to a group.

Further, in the present embodiment, the blockchain network 30 manages the encrypted information, but the present invention is not limited to this, and any distributed ledger mechanism that guarantees the prevention of data tampering is managed by a method other than the blockchain. You may try to do it. The distributed ledger is a distributed database that securely shares the ledger data to be handled among a plurality of nodes. Blockchain is also included in the distributed ledger.

1 User terminal 2 TEE server 3 Blockchain node 4 Attestation service 21 Enclave 30 Blockchain network

Claims (9)

The contents of the data to be managed by the distributed ledger are recorded on the trusted server equipped with the trusted execution environment, and
Cryptographic data obtained by encrypting the data is recorded in the distributed ledger.
When the content of the data is updated on the trusted server, the encrypted data obtained by encrypting the updated content is added to the distributed ledger.
When the encrypted data is added to the distributed ledger, the trusted server decrypts the added encrypted data and updates the contents of the data.
A data management method characterized by. The data management method according to claim 1.
The user terminal sends an update request for the data to the trusted server, and the user terminal sends a request to update the data.
The trusted server transmits the encrypted data obtained by encrypting the updated contents to the nodes constituting the corresponding distributed ledger.
The node adds the encrypted data to the distributed ledger and propagates it to the other nodes.
Each of the nodes sends the added cryptographic data to the corresponding trusted server.
The trusted server decrypts the added encrypted data and updates the contents of the data recorded by itself.
A data management method characterized by. The data management method according to claim 1.
The data including the signature with the private key created by the trusted server is transmitted to the attestation service to verify the validity, the attestation service signs the verification result, and the trusted server sends the verification result to the trusted. The public key created by the server is registered in the distributed ledger, and the node verifies the signature of the verification result.
When a transaction occurs in the distributed ledger, the trusted server verifies the signature included in the transaction using the registered public key.
A data management method characterized by. The data management method according to claim 3.
The verification result includes information that identifies the program that the trusted server is executing.
At the time of signature verification of the verification result, the trusted server verifies that the program executed by itself matches the program indicated by the information contained in the verification result.
A data management method characterized by. The data management method according to claim 4.
Further, at the node, it is verified that the program indicated by the information included in the verification result and the program indicated by the information included in the verification result registered in the distributed ledger match. To do,
A data management method characterized by. The data management method according to claim 3.
The trusted server generates a pair of the private key and the public key, includes the public key in the verification result, and registers the public key in the distributed ledger.
A data management method characterized by. The data management method according to claim 3.
When adding the trusted server
The trusted server to be added
Have the attestation service verify the validity of its trusted execution environment
The verification result by the attestation service is transmitted to the existing trusted server, and the result is transmitted to the existing trusted server.
The existing trusted server
Have the attestation service verify the validity of its trusted execution environment
By collating the verification result by the attestation service with the verification result received from the added trusted server, it is determined whether or not the added trusted server can participate.
When it is determined that the added trusted server can participate, the participation of the added trusted server is determined by collating with the verification result received from the added trusted server.
A data management method characterized by. The data management method according to claim 1.
The encryption is performed using a common group key,
Each of the trusted servers has its own private key, and the public keys of all the trusted servers are recorded in the distributed ledger.
The trusted server calculates a seed using all the public keys and its own private key so as to calculate the same group key, and calculates the group key based on the seed.
A data management method characterized by. The data management method according to claim 1.
The trusted server calculates a first hash value of all data for each block managed by the distributed ledger, records the first hash value in the distributed ledger, and updates the contents of the data. In that case, the second hash value of the hash value before the update and the contents of all the blocks after the update is calculated, and the second hash value is recorded in the distributed ledger.
A data management method characterized by.

Images