CN114172667A - Privacy evidence storing method and device based on contract - Google Patents

Privacy evidence storing method and device based on contract Download PDF

Info

Publication number
CN114172667A
CN114172667A CN202111611645.5A CN202111611645A CN114172667A CN 114172667 A CN114172667 A CN 114172667A CN 202111611645 A CN202111611645 A CN 202111611645A CN 114172667 A CN114172667 A CN 114172667A
Authority
CN
China
Prior art keywords
contract
private key
transaction
public
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111611645.5A
Other languages
Chinese (zh)
Inventor
郑小富
魏长征
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Priority to CN202111611645.5A priority Critical patent/CN114172667A/en
Publication of CN114172667A publication Critical patent/CN114172667A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]

Abstract

One or more embodiments of the present specification provide a method and an apparatus for contract-based privacy verification. The method is applied to the block chain link points in the block chain network and comprises the following steps: generating, in a trusted execution environment deployed at the block link point, a public-private key pair corresponding to a privacy-certified contract and disclosing a contract public key of the public-private key pair; responding to the received data evidence storing transaction, storing an evidence of a target data ciphertext contained in the data evidence storing transaction, wherein the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key; in response to a data acquisition transaction directed to the target data and invoking the privacy verification contract, decrypting, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair to obtain plaintext for the target data.

Description

Privacy evidence storing method and device based on contract
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a method and an apparatus for privacy certification based on contracts.
Background
The block chain technology, also called distributed ledger technology, is an emerging technology in which several computing devices participate in "accounting" together, and a complete distributed database is maintained together. Because the block chain technology has the characteristics of decentralization and openness, each computing device can participate in database recording, and data synchronization can be rapidly performed among the computing devices, a decentralization system is built by utilizing the block chain technology, and various execution programs are recorded in a distributed database of a block chain for automatic execution, so that the block chain technology is widely applied in numerous fields.
In addition, a Trusted Execution Environment (TEE) of hardware can be formed in the node device where the block link point is located, so that the block link point can be processed in the TEE, and privacy disclosure of data needing privacy protection, such as transactions, contract codes, contract states, service data and the like, can be avoided.
Disclosure of Invention
In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for contract-based privacy certification.
To achieve the above object, one or more embodiments of the present disclosure provide the following technical solutions:
according to a first aspect of one or more embodiments of the present specification, there is provided a contract-based privacy certification method applied to a blockchain node in a blockchain network, including:
generating, in a trusted execution environment deployed at the block link point, a public-private key pair corresponding to a privacy-certified contract and disclosing a contract public key of the public-private key pair;
responding to the received data evidence storing transaction, storing an evidence of a target data ciphertext contained in the data evidence storing transaction, wherein the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key;
in response to a data acquisition transaction directed to the target data and invoking the privacy verification contract, decrypting, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair to obtain plaintext for the target data.
According to a second aspect of one or more embodiments of the present specification, there is provided a contract-based privacy certification apparatus for a blockchain node in a blockchain network, including:
a key generation unit configured to generate a public-private key pair corresponding to a privacy certification contract in a trusted execution environment deployed at the block link point, and to disclose a contract public key in the public-private key pair;
the data evidence storing unit is used for responding to the received data evidence storing transaction and storing a target data ciphertext contained in the data evidence storing transaction, wherein the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key;
a data decryption unit, configured to decrypt, in the trusted execution environment, the target data ciphertext with a contract private key of the public and private key pair to obtain a plaintext of the target data, in response to a data acquisition transaction that targets the target data and invokes the privacy preserving contract.
According to a third aspect of the present specification, there is provided an electronic apparatus comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method as described in the embodiments of the first aspect above by executing the executable instructions.
According to a fourth aspect of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method as described in the embodiments of the first aspect above.
Drawings
FIG. 1 is a schematic diagram of creating an intelligent contract, provided by an exemplary embodiment.
FIG. 2 is a schematic diagram of a calling smart contract provided by an exemplary embodiment.
FIG. 3 is a schematic diagram of creating and invoking an intelligent contract according to an exemplary embodiment.
FIG. 4 is a flowchart of a contract-based privacy verification method provided by an exemplary embodiment.
Fig. 5 is a schematic diagram of a process for generating a public-private key pair according to an exemplary embodiment.
Fig. 6 is a schematic structural diagram of an apparatus according to an exemplary embodiment.
Fig. 7 is a block diagram of a contract-based privacy certification apparatus provided by an exemplary embodiment.
Detailed Description
Blockchains are generally divided into three types: public chain (Public Blockchain), Private chain (Private Blockchain) and alliance chain (Consortium Blockchain). In addition, there are various types of combinations, such as private chain + federation chain, federation chain + public chain, and other different combinations. The most decentralized of these is the public chain. The public chain is represented by bitcoin and ether house, and the participators joining the public chain can read the data record on the chain, participate in transaction, compete for accounting right of new blocks, and the like. Furthermore, each participant (i.e., node) is free to join and leave the network and perform related operations. Private chains are the opposite, with the network's write rights controlled by an organization or organization and the data read rights specified by the organization. Briefly, a private chain can be a weakly centralized system with strictly limited and few participating nodes. This type of blockchain is more suitable for use within a particular establishment. A federation chain is a block chain between a public chain and a private chain, and "partial decentralization" can be achieved. Each node in a federation chain typically has a physical organization or organization corresponding to it; participants jointly maintain blockchain operation by authorizing to join the network and forming a benefit-related alliance.
Based on the basic characteristics of a blockchain, a blockchain is usually composed of several blocks. The time stamps corresponding to the creation time of the block are recorded in the blocks respectively, and all the blocks form a time-ordered data chain according to the time stamps recorded in the blocks strictly.
For data generated outside the chain, it can be built into the standard transaction (transaction) format supported by the blockchain and then published to the blockchain. And carrying out validity verification and consensus on the transaction by the node equipment in the block chain, and after the consensus is achieved, packing the transaction into a block by the node equipment serving as an accounting node in the block chain, and carrying out persistent evidence storage in the block chain.
The validity verification of the blockchain transaction can be realized by verifying the validity of the signature. When the blockchain adopts an account model, the account to which the blockchain is applicable usually corresponds to one or more valid public-private key pairs, and the valid public keys are displayed in the corresponding account status or stored in a distributed database of the blockchain in other forms and can be obtained by any node device in the blockchain network; and the private key corresponding to the effective public key is stored in a local database or other hardware terminals of the account owner so as to allow the account owner to perform digital signature or encryption and decryption operations and the like. The blockchain transaction initiated by the initiator not only includes transaction content, but also includes a digital signature made by the initiator for the transaction content by using a private key corresponding to an account of the initiator. After receiving the blockchain transaction, the blockchain node may perform validity verification on the blockchain transaction based on a digital signature included in the blockchain transaction, which may generally include: verifying whether the public key of the signer of the digital signature is subordinate to the account of the transaction initiator, verifying whether the digital signature is obtained based on the transaction content of the blockchain transaction, and the like, so as to ensure that the blockchain transaction is indeed initiated by the user or other objects generating the digital signature and is not tampered in the transmission process. In another case, the public key of the initiator may also be carried in a CA certificate issued by the CA center to the initiator, when the initiator sends a blockchain transaction, the CA certificate signed by the CA center private key may be sent to the blockchain node together, the blockchain node verifies the signature of the CA certificate according to the public key of the CA center, and the initiator public key carried in the CA certificate is obtained when the verification is successful. The CA center is an authority mechanism which can be trusted by the block chain node by default, so that the public key in the certificate can be determined to be trusted as long as the public key of the CA center is used for verifying the certificate successfully, and the block chain node can verify the validity of the digital signature contained in the received block chain transaction through the public key.
The consensus algorithm supported in the blockchain may include:
the first kind of consensus algorithm, namely the consensus algorithm that the node device needs to contend for the accounting right of each round of accounting period; consensus algorithms such as Proof of Work (POW), Proof of equity (POS), Proof of commission rights (DPOS), etc.;
the second kind of consensus algorithm, namely the consensus algorithm which elects accounting nodes in advance for each accounting period (without competing for accounting right); for example, a consensus algorithm such as a Practical Byzantine Fault Tolerance (PBFT) is used.
In a blockchain network employing a first type of consensus algorithm, node devices competing for billing rights can execute a transaction upon receipt. One of the node devices competing for the accounting right may win in the process of competing for the accounting right in the current round, and become an accounting node. The accounting node may package the received transaction with other transactions to generate a candidate block and send the generated candidate block or a block header of the candidate block to other node devices for consensus.
In the block chain network adopting the second type of consensus algorithm, the node equipment with the accounting right is agreed before accounting in the current round. Thus, the node device, after receiving the transaction, may send the transaction to the accounting node if it is not the accounting node of its own round. For the accounting node of the current round, the transaction may be performed during or before packaging the transaction with other transactions to generate candidate blocks. After generating the candidate block, the accounting node may send the candidate block or a block header of the candidate block to other node devices for consensus.
As described above, regardless of which consensus algorithm is used by the blockchain, the accounting node of the current round may package the received transaction to generate a candidate block and send the generated candidate block or the block header of the candidate block to other node devices for consensus verification. If no problem is verified after the other node device receives the candidate block or the block header of the candidate block, the candidate block can be added to the end of the original block chain as the latest block, thereby completing the accounting process of the block chain. The transaction contained in the block may also be performed by other nodes in verifying the new block or block header sent by the accounting node.
Current blockchain systems typically include two mainstream transaction models; among them, one is a UTXO (un-spent Transaction Output) model represented by a bitcoin system; and the other is an account model represented by an etherhouse (Ethereum) system.
If the two types of block chains want to implement data storage, the following storage mode can be generally adopted:
for blockchains employing the UTXO model, the supported native transactions typically include only transfer transactions, and during transfer based transfer transactions, the user may deposit additional data on the blockchain by populating the additional data in the transaction epilogue (i.e., the transfer epilogue) in the transfer transaction.
For a blockchain adopting an account model, blockchain data which needs to be stored and maintained generally include blockchain data and account state data corresponding to blockchain accounts in the blockchain; the tile data may further include tile header data, tile transaction data in the tile, and a transaction Receipt (script) corresponding to the tile transaction data in the tile, etc. When storing the various blockchain data shown above, the various blockchain data can be organized into a Merkle tree to be stored in a database in the form of key-value key value pairs.
In such a blockchain model, an intelligent contract for data verification may be deployed on a blockchain, and a user may store data that needs to be verified as an account state of a contract account corresponding to the intelligent contract into a Merkle tree corresponding to the intelligent contract by calling the intelligent contract.
For example, in EtherFang, a special Merkle tree, called MPT tree, is typically used to store and maintain blockchain data; for the account state data, an MPT state tree (commonly called world state) can be organized and stored in the database; the MPT state tree stores key-value key value pairs with account addresses as keys and account state data as values. The data content stored in the contract account corresponding to the intelligent contract is further organized into a storage tree (an MPT storage tree for storing data) to be stored in the database; filling the hash value of the root node of the storage tree into the MPT state tree as a part of account state data corresponding to the contract account; the hash of the root node of the MPT state tree is used as the authentication root and is further filled into the block header. When a user needs to perform data storage, the data needing to be stored can be used as account state data of a contract account corresponding to the intelligent contract in a mode of calling the intelligent contract and stored in a storage tree corresponding to the intelligent contract.
In the field of blockchain, another important concept is Account (Account); taking an ether house as an example, the ether house generally divides an account into an external account and a contract account; the external account is an account directly controlled by the user and is also called as a user account; and the contract account is created by the user through an external account, the account containing the contract code (i.e. the smart contract).
Of course, for some blockchain models derived from the ethernet-based architecture (such as ant blockchains), account types supported by the blockchain may be further expanded, and are not particularly limited in this specification.
For accounts in a blockchain, the account status of the account is usually maintained through a structure. When a transaction in a block is executed, the status of the account associated with the transaction in the block chain is also typically changed.
In one example, the structure of an account typically includes fields such as Balance, Nonce, Code, and Storage. Wherein:
a Balance field for maintaining the current account Balance of the account;
a Nonce field for maintaining a number of transactions for the account; the counter is used for guaranteeing that each transaction can be processed only once, and replay attack is effectively avoided;
a Code field for maintaining a contract Code for the account; in practical applications, only the hash value of the contract Code is typically maintained in the Code field; thus, the Code field is also commonly referred to as the Codhash field.
A Storage field for maintaining the Storage contents of the account (default field value is null); for a contract account, a separate storage space is usually allocated to store the storage content of the contract account; this separate storage space is often referred to as the account storage of the contract account.
The storage content of the contract account is usually constructed into a data structure of an MPT (Merkle Patricia Trie) tree and stored in the independent storage space; in which, the Storage content based on the contract account is constructed into an MPT tree, which is also commonly referred to as a Storage tree. Whereas the Storage field typically maintains only the root node of the Storage tree; thus, the Storage field is also commonly referred to as the Storage root field.
Wherein, for the external account, the field values of the Code field and the Storage field shown above are both null values.
In practical applications, whether public, private, or alliance, it is possible to provide the functionality of a smart contract (smart contract). An intelligent contract on a blockchain is a contract on a blockchain that can be executed triggered by a transaction. An intelligent contract may be defined in the form of code.
Taking an Etherhouse as an example, a user is supported to create and call some complex logic in the Etherhouse network. The ethernet workshop is used as a programmable block chain, and the core of the ethernet workshop is an ethernet workshop virtual machine (EVM), and each ethernet workshop node can run the EVM. The EVM is a well-behaved virtual machine through which various complex logic can be implemented. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. In fact, the EVM directly runs virtual machine code (virtual machine bytecode, hereinafter referred to as "bytecode"), so the intelligent contract deployed on the blockchain may be bytecode.
After Bob sends a transaction (transaction) containing information to create a smart contract to the ethernet network, each node may perform the transaction in the EVM, as shown in fig. 1. In fig. 1, the From field of the transaction is used To record the address of the account initiating the creation of the intelligent contract, the contract code stored in the field value of the Data field of the transaction may be byte code, and the field value of the To field of the transaction is a null account. After the nodes reach the agreement through the consensus mechanism, the intelligent contract is successfully created, and the follow-up user can call the intelligent contract.
After the intelligent contract is established, a contract account corresponding to the intelligent contract appears on the block chain, and the block chain has a specific address; for example, "0 x68e12cf284 …" in each node in fig. 1 represents the address of the contract account created; the contract Code (Code) and account store (Storage) will be maintained in the account store for that contract account. The behavior of the intelligent contract is controlled by the contract code, while the account storage of the intelligent contract preserves the state of the contract. In other words, the intelligent contract causes a virtual account to be generated on the blockchain that contains the contract code and account storage.
As mentioned above, the Data field containing the transaction that created the intelligent contract may hold the byte code of the intelligent contract. A bytecode consists of a series of bytes, each of which can identify an operation. Based on the multiple considerations of development efficiency, readability and the like, a developer can select a high-level language to write intelligent contract codes instead of directly writing byte codes. For example, the high-level language may employ a language such as Solidity, Serpent, LLL, and the like. For intelligent contract code written in a high-level language, the intelligent contract code can be compiled by a compiler to generate byte codes which can be deployed on a blockchain.
Taking the Solidity language as an example, the contract code written by it is very similar to a Class (Class) in the object-oriented programming language, and various members including state variables, functions, function modifiers, events, etc. can be declared in one contract. A state variable is a value permanently stored in an account Storage (Storage) field of an intelligent contract to save the state of the contract.
As shown in FIG. 2, still taking the Etherhouse as an example, after Bob sends a transaction containing the information of the calling intelligent contract to the Etherhouse network, each node can execute the transaction in the EVM. In fig. 2, the From field of the transaction is used To record the address of the account initiating the intelligent contract invocation, the To field is used To record the address of the intelligent contract invocation, and the Data field of the transaction is used To record the method and parameters of the intelligent contract invocation. After invoking the smart contract, the account status of the contract account may change. Subsequently, a client may view the account status of the contract account through the accessed block link point (e.g., node 1 in fig. 2).
The intelligent contract can be independently executed at each node in the blockchain network in a specified mode, and all execution records and data are stored on the blockchain, so that after the transaction is executed, transaction certificates which cannot be tampered and lost are stored on the blockchain.
A schematic diagram of creating an intelligent contract and invoking the intelligent contract is shown in fig. 3. An intelligent contract is created in an Ethernet workshop and needs to be subjected to the processes of compiling the intelligent contract, changing the intelligent contract into byte codes, deploying the intelligent contract to a block chain and the like. The intelligent contract is called in the Ethernet workshop, a transaction pointing to the intelligent contract address is initiated, the EVM of each node can respectively execute the transaction, and the intelligent contract code is distributed and operated in the virtual machine of each node in the Ethernet workshop network.
It should be noted that, in addition to the creation of the smart contracts by the users, the smart contracts may also be set by the system in the creation block. Such contracts are generally referred to as foundational contracts. In general, the data structure, parameters, attributes and methods of some blockchain networks may be set in the startup contract. Further, an account with system administrator privileges may create a contract at the system level, or modify a contract at the system level (simply referred to as a system contract). In addition to EVM in the ethernet, different blockchain networks may employ various virtual machines, which is not limited herein.
As described above, the blockchain technology is based on basic characteristics such as a consensus mechanism and signature verification, and can ensure that data on the blockchain network is secure, transparent and not falsifiable. Based on the above, the data can be stored in the block chain, so as to achieve the purposes of tamper resistance, traceability, trustable data source and the like of the data, namely, the data evidence based on the block chain is realized.
In order to further ensure the privacy of the stored data, a privacy storing technology is provided in the related technology. For example, after the data is encrypted by using a private key of the depositor and then deposited on the blockchain, the data acquirer acquires the data in the ciphertext state from the blockchain, and then decrypts the data by using a public key of the depositor to acquire the data in the plaintext state. Or the evidence storing party signs the abstract of the data by using a private key of the evidence storing party and stores the signed abstract into the block chain, so that the data acquiring party acquires the data through a down-chain way and then calculates the first abstract, and after acquiring the data abstract of the ciphertext state from the block chain, the data acquiring party decrypts the data abstract by using a public key of the evidence storing party to obtain the second abstract, and then whether the stored data is trustable or not is determined by comparing whether the second abstract is the same as the second abstract. However, the above related technologies essentially adopt a centralized private key management manner, so that there are often problems of supervision and security supervision; and the uplink information can only be encrypted by using the own private key of the depositor, so that the management of the data access authority is not flexible.
In order to solve the problem, the present specification provides a privacy certification method based on a contract, in which a public and private key pair corresponding to a privacy certification contract is generated in a TEE deployed at a block link point and a contract public key therein is disclosed, so that a certification authority encrypts a plaintext of target data to be certified according to the contract public key to obtain a target data ciphertext, and after receiving a data certification transaction initiated by the certification authority, a block link node may decrypt the target data ciphertext using a contract private key in the TEE in response to the transaction. By the mode, different public and private key pairs can be generated by deploying the privacy certification storing contract in the block chain network, so that the contract level certification of the target data is realized, and the access authority aiming at the target data can be flexibly set by initiating the contract deployment transaction; moreover, as the target data is encrypted and decrypted in the TEE deployed at the chain node of the block, the privacy of a contract private key in a public and private key pair can be ensured, the problems of supervision, safety supervision and the like possibly existing in a centralized private key management mode are avoided, and the safety of privacy certification of the target data is improved. The contract-based privacy certification method proposed in the present specification is described below with reference to fig. 4 to 5.
Referring to fig. 4, fig. 4 is a flowchart illustrating a contract-based privacy verification method according to an exemplary embodiment. As shown in fig. 4, the method is applied to a blockchain node in a blockchain network, and may include the following steps 402 and 406.
Step 402, in a trusted execution environment deployed at the block chain node, generating a public-private key pair corresponding to a privacy certification contract, and disclosing a contract public key in the public-private key pair.
It should be noted that, the block link point described in this specification may be any node in a block link network. The node is deployed with a TEE, so that the node can use the TEE to realize encryption processing of the privacy key or the evidence data. It will be appreciated that the TEE is actually deployed in the node device where the block link point is located. The TEE may be constructed based on technologies such as Intel SGX (Software Guard Extensions) or AMD TrustZone (trusted zone), which is not limited in this specification. Taking the Intel SGX technology as an example, the technology is extended on the original Intel architecture, such as adding a new instruction set and a corresponding memory access mechanism, and the like, and these extensions allow an application program to implement a container called enclave, that is, a protected area is partitioned in an address space of the application program, and privacy and integrity protection is provided for code and data in the container through the protected area. The SGX allows the application program to specify the code and data parts needing protection, before enclave is created, the code and data do not need to be checked or analyzed, but the code and data loaded into the enclave need to be measured, and after the part needing protection of the application program is loaded into the enclave, the SGX protects the part needing protection from being accessed by external software. Specifically, the envelope and SGX data structures are stored in a protected physical memory area EPC (Enclave Page Cache) allocated in the system, so that an external entity is prevented from accessing data in the EPC through a memory protection mechanism for the EPC, thereby implementing privacy protection on internal data. In the following scheme, when the TEE is constructed by using the Intel SGX technology, the process of encrypting and decrypting the target data is performed in the EPC.
In addition, a privacy certification contract may be deployed in the blockchain node, so that the node may generate a public-private key pair corresponding to the contract in the TEE, wherein the public-private key pair includes a contract private key and a contract public key, and thus the blockchain node may further disclose the contract public key therein so that a target data to be certified is encrypted by a certifying party using the contract public key.
A blockchain network typically includes a plurality of blockchain nodes, and the blockchain nodes may deploy the privacy assurance contract in various ways. For example, the privacy certification contract may be an intelligent contract that requires consensus, such that the contract may be deployed in a blockchain network after consensus, i.e., at each blockchain link point in the blockchain network, respectively. Alternatively, the privacy verification contract may be a local contract that does not need to be identified, and in this case, the contract may be deployed only in a certain blockchain node in the blockchain network (the node is the blockchain node to which the privacy verification method described in this specification is applied).
In an embodiment, for a privacy certification contract deployed in a block-linked point, the block-linked point may generate a public-private key pair corresponding to the contract in a variety of ways. As an exemplary embodiment, a block-linked point may deploy a privacy-preserving contract at the block-linked point in response to a received contract deployment transaction, and generate a public-private key pair corresponding to the contract in the TEE during deployment. As another exemplary embodiment, the block-link point may also generate a public-private key pair corresponding to a privacy-certified contract in the TEE after deployment of the contract has been completed at the block-link point. For example, in the foregoing embodiment, whether the privacy certification contract is deployed at each blockchain link point in the blockchain network after passing consensus or is deployed only at a certain blockchain link point in the blockchain network without consensus, the blockchain link point where the contract is deployed may generate a public-private key pair corresponding to the contract in the locally-deployed TEE after the contract deployment is completed, so that the node where the contract is deployed acquires the corresponding public-private key pair.
Further, after generating the public-private key pair, the block link point may disclose the contract public key therein in various ways. For example, the contract public key may be disclosed by an event in a transaction receipt, such as in the case where a blockchain node generates the public-private key pair described above in the process of deploying a privacy-certified contract in response to a contract deployment transaction, the blockchain node may record the contract public key in the public-private key pair in an event contained in the transaction receipt of the transaction to obtain the contract public key by a preset object by listening to the event. In the event mechanism, it is equivalent to that a client with a monitoring function exists at a monitoring party (i.e. the preset object), for example, an SDK (Software Development Kit) or the like for implementing the monitoring function is run on the client, and the client monitors events generated by the blockchain node, and the blockchain node only needs to normally generate a receipt. Alternatively, the passage-out of the contract public key may be achieved by other means in addition to the event mechanism described above. For example, the blockchain link point may listen to the generated contract public key through listening logic included in the blockchain platform code that is executed by itself, and transmit the listened contract public key to the preset object. Specifically, by embedding a monitoring code in a blockchain platform code running at a blockchain link point, the monitoring code can monitor one or more data of transaction content of a contract deployment transaction, contract status of a privacy insurance contract, a receipt generated by the privacy insurance contract, and the like, and send the monitored data to the preset object (acquiring other predefined monitoring parties). Since the snoop code is deployed in the blockchain platform code, rather than at the snooper's client, this implementation based on snoop code is relatively more proactive than the event mechanism. The above monitoring code may be added by a developer of the blockchain platform in the development process, or may be embedded by the monitoring party based on the own requirement, which is not limited in this specification.
In one embodiment, the block chain node may generate the public-private Key pair by a Key Derivation Function (KDF). It will be appreciated that as a Hash function for changing a short password to a long password, a KDF requires two input parameters, password (password) and salt (salt). The block link point may use the secret value as the password, and in order to ensure that the generated public and private key pair can embody the specificity of the contract deployment transaction, the block link point may use the contract information of the privacy security contract as the salt value, that is, the block link point may first obtain the secret value and the contract information of the privacy security contract, and then calculate the secret value and the contract information through the KDF, so as to derive the public and private key pair. The detailed algorithm of the KDF may refer to the description in the related art, and is not described herein again. In addition, the contract information may be a contract address of the privacy insurance contract or information of a deployer of the contract, such as a user name, a node public key, an identity public key of a node member, and the like. Alternatively, the contract information may be obtained by combining a contract address and deployment party information, such as "9 c26cc0804d0ccd2297 eec" obtained by directly concatenating the contract address "9 c26cc0804d0 cc" and the node public key "d 2297 eec" as the contract information. Of course, in the practice of the solution, a specific combination mode may be flexibly selected to obtain the contract information, which is not limited in this specification.
It should be noted that, in any blockchain node, at least one deployer may deploy a plurality of different privacy certification contracts, so that a plurality of different public and private key pairs may be generated during the deployment or execution of each privacy certification contract, and thus, the certifier may use any public and private key pair to perform certification after encrypting any target data. Obviously, under the condition that the evidence storing party uses different public and private keys to encrypt the same target data, the contract level evidence storing of the target data can be realized, and more flexible and diversified data evidence storing is facilitated. Of course, the target data can be stored by the storing party according to the service requirement by using a proper public and private key, so that the access right of the target data is controlled by a corresponding contract private key.
Further, since the public-private key pair is generated in the TEE, the secret value can be maintained by the TEE to ensure the privacy of the secret value, and further ensure the privacy of the generated public-private key pair. As an independent hardware privacy environment, the TEE usually has its own root key, which can be used to derive multiple derived keys for implementing specific business functions. Therefore, the block chain node can use the root key of the TEE as the secret value, so as to generate a public and private key pair based on the related key of the TEE, and the public and private key pair can embody the specificity of the TEE. Alternatively, the block chain node may use a derivative key derived from the root key as the secret value to reduce the security risk of directly using the root key. The root key of the TEE may be calculated by the block chain node according to a preset key algorithm, or may be obtained from a preset key manager, which is not limited in this specification. For example, in a case where each blockchain node in the blockchain network is deployed with the privacy certification contract, each blockchain node may calculate the root Key using the same Key algorithm, or obtain the root Key from the same KMS (Key management Service).
Fig. 5 is a schematic diagram of a process for generating a public-private key pair according to an exemplary embodiment, which is described in conjunction with fig. 5. As shown in fig. 5, the block link point generates contract information as a salt value according to the contract address of the privacy certification contract and the deployment party information of the deployment party of the privacy certification contract, obtains the secret value of the TEE locally deployed by the block link point, calculates the salt value and the secret value through a KDF function to derive a contract private key, and further derives a contract public key based on a public key derivation algorithm. The public key derivation process may be implemented by using algorithms such as RSA, ECC (Elliptic curve Cryptography), IBC (Identity-Based Cryptography) and the like in the related art, and specific processes are not described again.
It is understood that the above-mentioned contract private key generated by the block chain node in the TEE is usually in a plain text form, so to ensure the privacy of the contract private key, the contract private key may be maintained in an encryption manner corresponding to the TEE. For example, the block chain node may encrypt the plaintext of the contract private key in the TEE, and output the encrypted ciphertext of the contract private key from the TEE and store the ciphertext in the local database of the block chain node. Accordingly, for the usage process of the encrypted contract private key, reference may be made to the following detailed description of the embodiments, which is not repeated herein. When the secret key is added to the TEE, a root key or a derivative key of the TEE may be used, and the key may be a symmetric key or an asymmetric key. In addition, the local database of the blockchain node may store the data by means of key value pair (key, value), such as a Contract address Contract of the privacy certification ContractaddrContract public Key Key corresponding to the contractpubPerforming a pair-wise store, i.e. storing key-value pairs (Contracts) in a local database of blockchain nodesaddr,Keypub)。
Step 404, in response to the received data evidence transaction, storing a target data ciphertext contained in the data evidence transaction, wherein the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key.
After the public and private key pair is generated at the block link point, the evidence storage party with data evidence storage requirements can encrypt target data to be subjected to evidence storage by using the contract public key disclosed by the block link node and store an encrypted target data ciphertext, wherein the block link point can store the target data ciphertext into an on-chain block or a world state. For example, in the case that the data credentialing transaction passes the consensus, the block chaining point may add the block containing the data credentialing transaction to the end of the block chain maintained by the block chain node (i.e. to link up the target data ciphertext), and of course, the block containing the data credentialing transaction should be linked up after passing the consensus of each node in the block chain network. Or, the data deposit transaction may call a privacy deposit contract to deposit the target data, that is, the privacy deposit contract includes uplink processing logic for the target data ciphertext, and at this time, the block link point may deposit the target data ciphertext in a world state corresponding to the privacy deposit contract, for example, record the target data ciphertext in a transaction receipt of the data deposit transaction. Specifically, the target data ciphertext may be stored in a local database of blockchain nodes (in fact, all blocks maintained by blockchain nodes may be stored in the database).
In addition, the evidence storing party (i.e. the initiator of the data evidence storing transaction) may be the initiator of the contract deployment transaction, that is, the initiator generates a public and private key pair through the contract deployment transaction deployed by itself, and encrypts the target data to be stored with the contract public key therein for evidence storing. The target data referred to in this specification may be service data generated during the process of implementing the service function by the depositor, data acquired by the depositor from other data providers, and the like, and this specification does not limit this.
Step 406, in response to a data acquisition transaction directed to the target data and invoking the privacy verification contract, decrypting the target data ciphertext in the TEE with a contract private key of the public-private key pair to obtain a plaintext of the target data.
After the block link point encrypts the target data by responding to the data evidence transaction and completes the evidence storage of the encrypted target data ciphertext, a demand party having an acquisition demand on the target data can initiate a data acquisition transaction (the demand party is an initiator of the data acquisition transaction) aiming at the target data and used for calling a deployed privacy evidence contract, so that the block link point can respond to the transaction and decrypt the target data ciphertext in the TEE through the contract private key to acquire the plaintext of the target data, and the acquisition demand of the demand party on the target data is met. Obviously, in order to respond to the data acquisition transaction, the block link point needs to acquire a target data ciphertext on one hand and a contract public key in a plaintext state on the other hand.
In one embodiment, the target data may be obtained in a variety of ways. For example, the data acquisition transaction may be a blockchain transaction requiring consensus, so that the transaction may be executed by each blockchain node in the blockchain network after the consensus is performed, so as to acquire the certified target data by each blockchain node. Alternatively, the data acquisition transaction may be a local blockchain transaction that does not need to be identified, and in this case, the node may perform only the blockchain node that receives the transaction, so as to acquire the certified target data. Specifically, because the target data is validated in response to the data validation transaction, the data acquisition transaction may include contract information of the data validation transaction, so that the block link point determines the data validation transaction according to the contract information, and further determines a storage location of a target data ciphertext corresponding to the data validation transaction. The contract information may be a contract address, a contract hash, a contract digest, or the like, and is not described in detail. Or, in order to determine the storage location of the target data ciphertext more directly, the data acquisition transaction may also include data information of the target data ciphertext, such as data hash of the data ciphertext or data hash of the target data, which is not described in detail again.
As described above, the block chain node may encrypt the plaintext of the contract private key in the TEE, and output the encrypted ciphertext of the contract private key from the TEE and store the ciphertext in the local database of the block chain node. Therefore, in another embodiment, in response to the received data acquisition transaction, the block link point may acquire the contract private key ciphertext from the local database, input the ciphertext into the TEE, decrypt the ciphertext in the TEE to obtain the plaintext of the contract private key, and decrypt the target data ciphertext through the plaintext to obtain the plaintext of the target data. Obviously, the process of generating the public and private key pair and the process of decrypting the ciphertext of the contract private key are all completed in the TEE, and the generated contract private key is encrypted in the TEE and then stored in the local database of the block link point, so that the contract private key only exists in the TEE in a plaintext form, and exists in a ciphertext form outside the TEE, thereby logically realizing the encryption storage effect that the contract private key does not exceed the TEE, and effectively ensuring the privacy of the contract private key.
In fact, because the contract public key that encrypts the target data and the contract private key that decrypts the target data are generated during deployment or execution of the privacy certification contract (i.e., the public-private key pair corresponds to the privacy certification contract), the block link node may obtain the target data ciphertext and the contract private key through a data interface function provided by the privacy certification contract. Specifically, the blockchain link point may call the data interface function through an intelligent contract engine provided by its own blockchain platform code. If the data interface function is GetContientialTransactionDepositData (), the block link point may be the Contract address Contract of the privacy-preserving ContractaddrTransaction hash Tx with data-crediting transactionshashAs a reference, the corresponding target data ciphertext Tx is obtained from the local database of the blockchain nodedataContract private Keypri(i.e., the output result of the function), or the function may contain corresponding data decoding logic, so that the blockchain node may complete using the contract private key when calling the functionpriDecryption target data ciphertext TxdataThereby outputting the plaintext of the target data as the output result of the function into the TEE.
In an embodiment, to satisfy an acquisition request of an initiator of a data acquisition transaction for target data or a processing result of the data, a block node may return corresponding target data or a corresponding processing result thereof to the initiator in response to the received data acquisition transaction. In the process, the privacy of the returned target data or the processing result thereof can also be ensured by means of data encryption, so as to meet the privacy requirement of the initiator or the aforementioned prover (such as an owner, a manager and the like of the target data) on the target data or the processing result thereof. For example, the initiator may only need to acquire the target data, and at this time, the block link point may encrypt the plaintext of the target data in the TEE within the TEE through the identity public key of the initiator of the data acquisition transaction, and provide the encrypted target data to the initiator of the data acquisition transaction, so that the initiator can acquire the target data encrypted by its own identity public key. Or, the initiator may specify processing that needs to be performed on the target data in the data acquisition transaction, such as performing privacy calculation, data analysis, and the like, so that the blockchain node may perform the processing on the plaintext of the target data in the TEE, encrypt a corresponding processing result by using the identity public key of the initiator of the data acquisition transaction, and provide the encrypted processing result to the initiator. Correspondingly, the initiator can decrypt the received encrypted target data or the processing result thereof by using the own node private key, thereby meeting the privacy processing requirement of the initiator on the target data.
According to the embodiments of the present description, the block chain node generates a public and private key pair corresponding to a private certification contract in the TEE deployed at the block chain node and discloses a contract public key therein, so that the certification authority encrypts the plaintext of the target data to be certified according to the contract public key to obtain a target data ciphertext, and thus, after receiving a data certification transaction initiated by the certification authority, the block chain node may decrypt the target data ciphertext in the TEE using the contract private key in response to the transaction. By the mode, different public and private key pairs can be generated by deploying the privacy certification storing contract in the block chain network, so that the contract level certification of the target data is realized, and the access authority aiming at the target data can be flexibly set by initiating the contract deployment transaction; moreover, as the target data is encrypted and decrypted in the TEE deployed at the chain node of the block, the privacy of a contract private key in a public and private key pair can be ensured, the possible problems of supervision, safety supervision and the like in a centralized private key management mode are avoided, the security of privacy certification of the target data is improved, and the technical problems in the related technology are effectively solved.
Fig. 6 is a schematic structural diagram of an apparatus according to an exemplary embodiment. Referring to fig. 6, at the hardware level, the apparatus includes a processor 602, an internal bus 604, a network interface 606, a memory 608 and a non-volatile memory 610, but may also include hardware required for other services. One or more embodiments of the present description may be implemented in software, such as by processor 602 reading corresponding computer programs from non-volatile memory 610 into memory 608 and then executing. Of course, besides software implementation, the one or more embodiments in this specification do not exclude other implementations, such as logic devices or combinations of software and hardware, and so on, that is, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or logic devices.
Fig. 7 is a block diagram of a contract-based privacy certification apparatus provided by an exemplary embodiment. Referring to fig. 7, the apparatus may be applied to the device shown in fig. 6 to implement the technical solution of the present specification. The contract-based privacy certification device is applied to a blockchain node in a blockchain network, and may include:
a key generation unit 701 configured to generate a public-private key pair corresponding to a privacy certification contract in a trusted execution environment deployed at the block link point, and disclose a contract public key in the public-private key pair;
a data evidence storing unit 702, configured to store, in response to a received data evidence storing transaction, a target data ciphertext included in the data evidence storing transaction, where the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key;
a data decryption unit 703, configured to, in response to the data acquisition transaction for the target data and invoking the privacy verification contract, decrypt, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair to obtain a plaintext of the target data.
Optionally, the key generating unit 701 is further configured to:
deploying a privacy credentialing contract at the block link point in response to the received contract deployment transaction, and generating a public-private key pair corresponding to the privacy credentialing contract in the trusted execution environment during deployment; alternatively, the first and second electrodes may be,
generating, in the trusted execution environment, a public-private key pair corresponding to a privacy attestation contract after deployment of the privacy attestation contract has been completed at the block link point.
Optionally, the key generating unit 701 is further configured to:
recording a contract public key in the public and private key pair in an event contained in a transaction receipt of the contract deployment transaction, so that the contract public key is acquired by a preset object by monitoring the event; alternatively, the first and second electrodes may be,
and monitoring the generated contract public key through monitoring logic contained in a block chain platform code operated by the block chain link point, and sending the monitored contract public key to a preset object.
Optionally, the key generating unit 701 is further configured to:
and acquiring a secret value and contract information of the privacy verification contract, and calculating the secret value and the contract information through a key derivation function to derive the public and private key pair. A data storage unit 702 for
Optionally, the secret value is maintained by the trusted execution environment.
Optionally, the secret value includes:
a root key of the trusted execution environment; alternatively, the first and second electrodes may be,
a derivative key derived based on a root key of the trusted execution environment.
Optionally, the contract information includes at least one of:
a contract address of the privacy certification contract;
the deployer information of the deployer of the privacy verification contract.
Optionally, the privacy certification contract is deployed in the blockchain network after being identified; alternatively, the privacy certification contract is deployed only at the block link points.
Optionally, the data storage unit 702 is further configured to:
adding a block containing the data credentialing transaction to the end of a block chain maintained by the block chain node if the data credentialing transaction passes consensus; alternatively, the first and second electrodes may be,
and under the condition that the privacy certification contract is called by the data certification transaction, the target data ciphertext is certified in the world state corresponding to the privacy certification contract.
Optionally, the data acquisition transaction is a consensus blockchain transaction, or the data acquisition transaction is a local blockchain transaction.
Optionally, the method further includes:
a private key saving unit 704, configured to encrypt a plaintext of the contract private key in the trusted execution environment, and output a ciphertext of the contract private key obtained by the encryption from the trusted execution environment and save the ciphertext in the local database of the blockchain node.
Optionally, the data decryption unit 703 is further configured to:
acquiring the contract private key ciphertext from the local database and inputting the contract private key ciphertext into the trusted execution environment;
and decrypting in the trusted execution environment to obtain the plaintext of the contract private key, and decrypting the target data ciphertext through the plaintext of the contract private key.
Optionally, the method further includes:
a data providing unit 705, configured to encrypt a plaintext of the target data in the trusted execution environment through an identity public key of an initiator of the data acquisition transaction, and provide the encrypted target data to the initiator; alternatively, the first and second electrodes may be,
a result providing unit 706, configured to process a plaintext of the target data in the trusted execution environment, encrypt a corresponding processing result through an identity public key of an initiator of the data acquisition transaction, and provide the encrypted processing result to the initiator.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.

Claims (20)

1. A privacy certification method based on contracts is applied to block chain nodes in a block chain network and comprises the following steps:
generating, in a trusted execution environment deployed at the block link point, a public-private key pair corresponding to a privacy-certified contract and disclosing a contract public key of the public-private key pair;
responding to the received data evidence storing transaction, storing an evidence of a target data ciphertext contained in the data evidence storing transaction, wherein the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key;
in response to a data acquisition transaction directed to the target data and invoking the privacy verification contract, decrypting, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair to obtain plaintext for the target data.
2. The method of claim 1, the generating a public-private key pair corresponding to a privacy certification contract, comprising:
deploying a privacy credentialing contract at the block link point in response to the received contract deployment transaction, and generating a public-private key pair corresponding to the privacy credentialing contract in the trusted execution environment during deployment; alternatively, the first and second electrodes may be,
generating, in the trusted execution environment, a public-private key pair corresponding to a privacy attestation contract after deployment of the privacy attestation contract has been completed at the block link point.
3. The method of claim 2, the disclosing a contract public key in the public-private key pair, comprising:
recording a contract public key in the public and private key pair in an event contained in a transaction receipt of the contract deployment transaction, so that the contract public key is acquired by a preset object by monitoring the event; alternatively, the first and second electrodes may be,
and monitoring the generated contract public key through monitoring logic contained in a block chain platform code operated by the block chain link point, and sending the monitored contract public key to a preset object.
4. The method of claim 1, the generating a public-private key pair corresponding to a privacy certification contract, comprising:
and acquiring a secret value and contract information of the privacy verification contract, and calculating the secret value and the contract information through a key derivation function to derive the public and private key pair.
5. The method of claim 4, the secret value maintained by the trusted execution environment.
6. The method of claim 5, the secret value comprising:
a root key of the trusted execution environment; alternatively, the first and second electrodes may be,
a derivative key derived based on a root key of the trusted execution environment.
7. The method of claim 6, the secret value comprising:
the root key is obtained by the block chain node through calculation according to a key algorithm; alternatively, the first and second electrodes may be,
and the root key is acquired by the block chain node from a preset key manager.
8. The method of claim 4, the contract information comprising at least one of:
a contract address of the privacy certification contract;
the deployer information of the deployer of the privacy verification contract.
9. The method of claim 1, wherein the privacy certification contract is deployed on the blockchain network after consensus; alternatively, the privacy certification contract is deployed only at the block link points.
10. The method of claim 1, wherein the validating a target data cryptogram included in the data validation transaction comprises:
adding a block containing the data credentialing transaction to the end of a block chain maintained by the block chain node if the data credentialing transaction passes consensus; alternatively, the first and second electrodes may be,
and under the condition that the privacy certification contract is called by the data certification transaction, the target data ciphertext is certified in the world state corresponding to the privacy certification contract.
11. The method of claim 1, wherein the data acquisition transaction is performed separately by each blockchain link point in the blockchain network after consensus; alternatively, the data acquisition transaction is performed only by the blockchain node.
12. The method of claim 1, wherein the data acquisition transaction comprises transaction information of the data credentialing transaction and/or data information of the target data ciphertext.
13. The method of claim 1, the data acquisition transaction being a consensus blockchain transaction or the data acquisition transaction being a local blockchain transaction.
14. The method of claim 1, further comprising:
and responding to the data acquisition transaction, and acquiring the target data ciphertext and the contract private key through a data interface function provided by the privacy insurance contract.
15. The method of claim 1, wherein the first and second light sources are selected from the group consisting of,
further comprising: encrypting the plaintext of the contract private key in the trusted execution environment, and outputting a cipher text of the contract private key obtained by encryption from the trusted execution environment and storing the cipher text in a local database of the block chain node;
the decrypting, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair, comprising: decrypting, in the trusted execution environment, the contract private key ciphertext obtained from the local database to obtain the contract private key, and decrypting, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair.
16. The method of claim 1, the decrypting, in the trusted execution environment, the target data ciphertext with a contract private key of the public-private key pair, comprising:
acquiring the contract private key ciphertext from a local database and inputting the contract private key ciphertext into the trusted execution environment;
and decrypting in the trusted execution environment to obtain the plaintext of the contract private key, and decrypting the target data ciphertext through the plaintext of the contract private key.
17. The method of claim 1, further comprising:
acquiring an identity public key of an initiator of the transaction through the data, encrypting a plaintext of the target data in the trusted execution environment, and providing the encrypted target data to the initiator; alternatively, the first and second electrodes may be,
and processing the plaintext of the target data in the trusted execution environment, encrypting a corresponding processing result through the identity public key of the initiator of the data acquisition transaction, and providing the encrypted processing result to the initiator.
18. A privacy certification device based on contracts is applied to block chain nodes in a block chain network and comprises the following components:
a key generation unit configured to generate a public-private key pair corresponding to a privacy certification contract in a trusted execution environment deployed at the block link point, and to disclose a contract public key in the public-private key pair;
the data evidence storing unit is used for responding to the received data evidence storing transaction and storing a target data ciphertext contained in the data evidence storing transaction, wherein the target data ciphertext is obtained by encrypting a plaintext of target data by the contract public key;
a data decryption unit, configured to, in response to a data acquisition transaction that is directed to the target data and invokes the privacy preserving contract, decrypt, in the trusted execution environment, the target data ciphertext with the contract private key of a public-private key pair to obtain a plaintext of the target data.
19. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1-17 by executing the executable instructions.
20. A computer-readable storage medium having stored thereon computer instructions, which, when executed by a processor, carry out the steps of the method according to any one of claims 1-17.
CN202111611645.5A 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract Pending CN114172667A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111611645.5A CN114172667A (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111611645.5A CN114172667A (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract
CN202110658359.8A CN113114476B (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202110658359.8A Division CN113114476B (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract

Publications (1)

Publication Number Publication Date
CN114172667A true CN114172667A (en) 2022-03-11

Family

ID=76723503

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202111611645.5A Pending CN114172667A (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract
CN202110658359.8A Active CN113114476B (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202110658359.8A Active CN113114476B (en) 2021-06-15 2021-06-15 Privacy evidence storing method and device based on contract

Country Status (1)

Country Link
CN (2) CN114172667A (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114499866A (en) * 2022-04-08 2022-05-13 深圳致星科技有限公司 Key hierarchical management method and device for federal learning and privacy calculation
CN116260662A (en) * 2023-05-15 2023-06-13 成都信息工程大学 Tracing storage method, tracing storage system and tracing system

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113609219A (en) * 2021-07-21 2021-11-05 微易签(杭州)科技有限公司 Method, system, device and storage medium for verifying file based on block chain
CN114244851B (en) * 2021-12-24 2023-07-07 四川启睿克科技有限公司 Block chain-based data distribution method
CN114584293B (en) * 2022-02-28 2024-03-26 同济大学 Blockchain intelligent contract execution system and method based on TrustZone
CN115549906B (en) * 2022-11-24 2023-04-11 富算科技(上海)有限公司 Privacy calculation method, system, device and medium based on block chain

Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110033267A (en) * 2019-02-19 2019-07-19 阿里巴巴集团控股有限公司 Method, node, system and the storage medium of secret protection are realized in block chain
CN110580245A (en) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 private data sharing method and device
CN110580414A (en) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 private data query method and device based on block chain account
CN110580262A (en) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 Private data query method and device based on intelligent contract
CN110766550A (en) * 2019-09-05 2020-02-07 阿里巴巴集团控股有限公司 Asset query method and device based on block chain and electronic equipment
CN111008228A (en) * 2020-03-09 2020-04-14 支付宝(杭州)信息技术有限公司 Method and device for inquiring account privacy information in block chain
WO2020108138A1 (en) * 2018-11-30 2020-06-04 阿里巴巴集团控股有限公司 Method for implementing privacy protection in blockchain
CN111427663A (en) * 2020-03-24 2020-07-17 杭州溪塔科技有限公司 Virtual machine system based on intelligent contract and operation method thereof
CN111814198A (en) * 2020-09-11 2020-10-23 支付宝(杭州)信息技术有限公司 Block chain-based user privacy data providing method and device
WO2020233423A1 (en) * 2019-05-20 2020-11-26 创新先进技术有限公司 Receipt storage method and node based on transaction type
CN112016924A (en) * 2020-10-21 2020-12-01 支付宝(杭州)信息技术有限公司 Data evidence storage method, device and equipment based on block chain
WO2021103794A1 (en) * 2019-11-29 2021-06-03 支付宝(杭州)信息技术有限公司 Method for realizing highly efficient privacy-preserving transaction in blockchain, and device

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10621510B2 (en) * 2016-11-09 2020-04-14 Cognitive Scale, Inc. Hybrid blockchain data architecture for use within a cognitive environment
US10691793B2 (en) * 2017-02-20 2020-06-23 AlphaPoint Performance of distributed system functions using a trusted execution environment
CN110032884B (en) * 2019-01-31 2020-04-17 阿里巴巴集团控股有限公司 Method for realizing privacy protection in block chain, node and storage medium
CN110008736A (en) * 2019-01-31 2019-07-12 阿里巴巴集团控股有限公司 The method and node, storage medium of secret protection are realized in block chain
SG11202103081RA (en) * 2020-06-08 2021-04-29 Alipay Labs Singapore Pte Ltd Distributed storage of custom clearance data

Patent Citations (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020108138A1 (en) * 2018-11-30 2020-06-04 阿里巴巴集团控股有限公司 Method for implementing privacy protection in blockchain
CN110033267A (en) * 2019-02-19 2019-07-19 阿里巴巴集团控股有限公司 Method, node, system and the storage medium of secret protection are realized in block chain
WO2020233423A1 (en) * 2019-05-20 2020-11-26 创新先进技术有限公司 Receipt storage method and node based on transaction type
CN110766550A (en) * 2019-09-05 2020-02-07 阿里巴巴集团控股有限公司 Asset query method and device based on block chain and electronic equipment
CN110580245A (en) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 private data sharing method and device
CN110580414A (en) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 private data query method and device based on block chain account
CN110580262A (en) * 2019-11-08 2019-12-17 支付宝(杭州)信息技术有限公司 Private data query method and device based on intelligent contract
WO2021103794A1 (en) * 2019-11-29 2021-06-03 支付宝(杭州)信息技术有限公司 Method for realizing highly efficient privacy-preserving transaction in blockchain, and device
CN111008228A (en) * 2020-03-09 2020-04-14 支付宝(杭州)信息技术有限公司 Method and device for inquiring account privacy information in block chain
CN111427663A (en) * 2020-03-24 2020-07-17 杭州溪塔科技有限公司 Virtual machine system based on intelligent contract and operation method thereof
CN111814198A (en) * 2020-09-11 2020-10-23 支付宝(杭州)信息技术有限公司 Block chain-based user privacy data providing method and device
CN112016924A (en) * 2020-10-21 2020-12-01 支付宝(杭州)信息技术有限公司 Data evidence storage method, device and equipment based on block chain

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114499866A (en) * 2022-04-08 2022-05-13 深圳致星科技有限公司 Key hierarchical management method and device for federal learning and privacy calculation
CN114499866B (en) * 2022-04-08 2022-07-26 深圳致星科技有限公司 Key hierarchical management method and device for federal learning and privacy calculation
CN116260662A (en) * 2023-05-15 2023-06-13 成都信息工程大学 Tracing storage method, tracing storage system and tracing system
CN116260662B (en) * 2023-05-15 2023-07-18 成都信息工程大学 Tracing storage method, tracing storage system and tracing system

Also Published As

Publication number Publication date
CN113114476A (en) 2021-07-13
CN113114476B (en) 2021-11-16

Similar Documents

Publication Publication Date Title
CN110245506B (en) Intelligent contract management method and device based on block chain and electronic equipment
CN113114476B (en) Privacy evidence storing method and device based on contract
CN111475849B (en) Private data query method and device based on blockchain account
CN110580413B (en) Private data query method and device based on down-link authorization
CN110032884B (en) Method for realizing privacy protection in block chain, node and storage medium
CN111523110B (en) Authority query configuration method and device based on chain codes
CN110266467B (en) Method and device for realizing dynamic encryption based on block height
CN110580245B (en) Private data sharing method and device
CN111475829A (en) Private data query method and device based on block chain account
CN110263544B (en) Receipt storage method and node combining transaction type and judgment condition
CN110580262A (en) Private data query method and device based on intelligent contract
CN110245947B (en) Receipt storage method and node combining conditional restrictions of transaction and user types
CN111475850B (en) Intelligent contract-based privacy data query method and device
CN110580411B (en) Permission query configuration method and device based on intelligent contract
CN110245942B (en) Receipt storage method and node combining user type and judgment condition
CN110264192B (en) Receipt storage method and node based on transaction type
CN111127021B (en) Service request method and device based on block chain
CN111241557B (en) Service request method and device based on block chain
CN110276610B (en) Method and device for realizing dynamic encryption based on transaction offset
WO2020238958A1 (en) Method and device for realizing dynamic encryption based on order of modification of contract state
CN113536384B (en) Block chain-based private data mapping method, block chain-based private data mapping device, block chain-based private data mapping medium and electronic equipment
WO2020238878A1 (en) Dynamic encryption method and device
CN114756903A (en) Homote advice processing method and device based on block chain intelligent contract and computing equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination