CN110716724B

CN110716724B - Method and device for realizing privacy block chain based on FPGA

Info

Publication number: CN110716724B
Application number: CN201910913460.6A
Authority: CN
Inventors: 魏长征; 潘国振; 闫莺
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2019-09-25
Filing date: 2019-09-25
Publication date: 2021-01-08
Anticipated expiration: 2039-09-25
Also published as: WO2021057124A1; CN110716724A

Abstract

One or more embodiments of the present specification provide a method and an apparatus for implementing a privacy zone block chain based on an FPGA, where the method may include: a client deploys a circuit logic configuration file to an FPGA structure at a block chain node, wherein the circuit logic configuration file is used for enabling the FPGA structure to be a trusted execution environment of the block chain node; the client receives an authentication result returned by the FPGA structure, the authentication result is signed by an authentication root key deployed in the FPGA structure, and a public key corresponding to the authentication root key is disclosed; and the client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure under the condition that the authentication result passes signature verification and contains the content related to the circuit logic configuration file.

Description

Method and device for realizing privacy block chain based on FPGA

Technical Field

One or more embodiments of the present disclosure relate to the field of block chain technologies, and in particular, to a method and an apparatus for implementing a privacy block chain based on an FPGA.

Background

The blockchain technique is built on top of a transport network, such as a point-to-point network. Network nodes in a transport network utilize a chained data structure to validate and store data and employ a distributed node consensus algorithm to generate and update data.

The two biggest challenges in the current enterprise-level blockchain platform technology are privacy and performance, which are often difficult to solve simultaneously. Most solutions trade privacy for loss of performance or do not consider privacy much to pursue performance. Common encryption technologies for solving privacy problems, such as Homomorphic encryption (Homomorphic encryption) and Zero-knowledge proof (Zero-knowledge proof), have high complexity and poor universality, and may cause serious performance loss.

Trusted Execution Environment (TEE) is another way to address privacy concerns. The TEE can play a role of a black box in hardware, a code and data operating system layer executed in the TEE cannot be peeped, and the TEE can be operated only through an interface defined in advance in the code. In the aspect of efficiency, due to the black box property of the TEE, plaintext data is operated in the TEE instead of complex cryptography operation in homomorphic encryption, and the efficiency of the calculation process is not lost, so that the safety and privacy of a block chain can be improved to a great extent on the premise of small performance loss by combining with the TEE. The industry is concerned with TEE solutions, and almost all mainstream chip and Software consortiums have their own TEE solutions, including Software-oriented TPM (Trusted Platform Module) and hardware-oriented Intel SGX (Software Guard Extensions), ARM Trustzone (Trusted zone), and AMD PSP (Platform Security Processor).

Disclosure of Invention

In view of this, one or more embodiments of the present disclosure provide a method and an apparatus for implementing a privacy zone chain based on an FPGA.

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, a method for implementing a privacy zone block chain based on an FPGA is provided, including:

a client deploys a circuit logic configuration file to an FPGA structure at a block chain node, wherein the circuit logic configuration file is used for enabling the FPGA structure to be a trusted execution environment of the block chain node;

the client receives an authentication result returned by the FPGA structure, the authentication result is signed by an authentication root key deployed in the FPGA structure, and a public key corresponding to the authentication root key is disclosed;

and the client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure under the condition that the authentication result passes signature verification and contains the content related to the circuit logic configuration file.

According to a second aspect of one or more embodiments of the present specification, there is provided a method for implementing a privacy zone block chain based on an FPGA, including:

the FPGA structure deploys a circuit logic configuration file from a client, wherein the circuit logic configuration file is used for enabling the FPGA structure to be realized as a trusted execution environment on a block link point to which the FPGA structure belongs;

the FPGA structure signs an authentication result through a deployed authentication root key, wherein the authentication result comprises contents related to the circuit logic configuration file, and a public key corresponding to the authentication root key is disclosed;

and the FPGA structure returns the signed authentication result to the client so that the client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure under the condition that the authentication result passes signature verification and contains contents related to the circuit logic configuration file.

According to a third aspect of one or more embodiments of the present specification, an apparatus for implementing a privacy zone block chain based on an FPGA is provided, including:

a configuration file deployment unit, which enables a client to deploy a circuit logic configuration file to an FPGA structure at a block chain node, wherein the circuit logic configuration file is used for enabling the FPGA structure to be implemented as a trusted execution environment of the block chain node;

the authentication result receiving unit enables the client to receive an authentication result returned by the FPGA structure, the authentication result is signed by an authentication root key deployed in the FPGA structure, and a public key corresponding to the authentication root key is disclosed;

and the deployment confirming unit is used for confirming that the circuit logic configuration file is successfully deployed on the FPGA structure by the client under the condition that the authentication result passes signature verification and contains the content related to the circuit logic configuration file.

According to a fourth aspect of one or more embodiments of the present specification, an apparatus for implementing a privacy zone block chain based on an FPGA is provided, including:

the configuration file deployment unit is used for enabling the FPGA structure to deploy a circuit logic configuration file from a client, wherein the circuit logic configuration file is used for enabling the FPGA structure to be realized as a trusted execution environment on a block link point to which the FPGA structure belongs;

the authentication result signing unit enables the FPGA structure to sign an authentication result through a deployed authentication root key, wherein the authentication result comprises contents related to the circuit logic configuration file, and a public key corresponding to the authentication root key is disclosed;

and the authentication result returning unit is used for returning the signed authentication result to the client by the FPGA structure so as to ensure that the client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure under the condition that the authentication result passes signature verification and contains the content related to the circuit logic configuration file.

According to a fifth aspect of one or more embodiments herein, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of the first aspect by executing the executable instructions.

According to a sixth aspect of one or more embodiments of the present description, there is provided a computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first aspect.

According to a seventh aspect of one or more embodiments of the present specification, there is provided an electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method according to the second aspect by executing the executable instructions.

According to an eighth aspect of one or more embodiments of the present description, a computer-readable storage medium is proposed, on which computer instructions are stored, which instructions, when executed by a processor, implement the steps of the method according to the second aspect.

Drawings

Fig. 1 is a flowchart of a method for implementing a privacy blockchain based on an FPGA according to an exemplary embodiment.

Fig. 2 is a flowchart of another method for implementing a privacy blockchain based on an FPGA according to an example embodiment.

FIG. 3 is a schematic flow chart diagram illustrating a process for interaction between a client and an FPGA fabric in accordance with an illustrative embodiment.

Fig. 4 is a block link point diagram for processing a transaction according to an exemplary embodiment.

Fig. 5 is a schematic structural diagram of an apparatus according to an exemplary embodiment.

Fig. 6 is a block diagram of an apparatus for implementing a privacy blockchain based on an FPGA according to an exemplary embodiment.

Fig. 7 is a schematic structural diagram of another apparatus provided in an exemplary embodiment.

Fig. 8 is a block diagram of another apparatus for implementing a privacy blockchain based on an FPGA according to an example embodiment.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.

It should be noted that: in other embodiments, the steps of the corresponding methods are not necessarily performed in the order shown and described herein. In some other embodiments, the method may include more or fewer steps than those described herein. Moreover, a single step described in this specification may be broken down into multiple steps for description in other embodiments; multiple steps described in this specification may be combined into a single step in other embodiments.

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.

Whether public, private, or alliance, nodes in a blockchain network may perform received transactions within a TEE (Trusted Execution Environment) for privacy protection purposes through a solution in which the blockchain is combined with the TEE. The TEE is a trusted execution environment that is based on a secure extension of the CPU hardware and is completely isolated from the outside. TEE was originally proposed by Global Platform to address the secure isolation of resources on mobile devices, providing a trusted and secure execution environment for applications parallel to the operating system. The Trust Zone technology of ARM realizes the real commercial TEE technology at the earliest. Along with the rapid development of the internet, the security requirement is higher and higher, and more requirements are provided for the TEE by mobile equipment, cloud equipment and a data center. The concept of TEE has also been developed and expanded at a high rate. The concept now referred to as TEE has been a more generalized TEE than the concept originally proposed. For example, server chip manufacturers Intel, AMD, etc. have introduced hardware-assisted TEE in turn and enriched the concept and characteristics of TEE, which have gained wide acceptance in the industry. The mention of TEE now is more generally directed to such hardware assisted TEE techniques.

Taking the Intel SGX technology as an example, SGX provides an enclosure (also called enclave), that is, an encrypted trusted execution area in memory, and a CPU protects data from being stolen. Taking the example that the first block link point adopts a CPU supporting SGX, a part of an area EPC (enclosure Page Cache, Enclave Page Cache, or Enclave Page Cache) may be allocated in the memory by using a newly added processor instruction, and data therein is encrypted by an Encryption engine mee (memory Encryption engine) in the CPU. The encrypted content in the EPC is decrypted into plaintext only after entering the CPU. Therefore, in the SGX, a user may not trust an operating System, a VMM (Virtual Machine Monitor), or even a BIOS (Basic Input Output System), and only need to trust the CPU to ensure that private data is not leaked. The enclosure thus corresponds to the TEE produced under SGX technology.

Unlike the mobile terminal, the cloud access requires remote access, and the end user is not visible to the hardware platform, so the first step of using the TEE is to confirm the authenticity and credibility of the TEE. In the related art, a remote attestation mechanism is employed to confirm whether a TEE is authentic or not. Taking an Intel SGX technology as an example, when a challenger desires to verify a certain enclosure in a target device, the enclosure to be verified first generates a configuration file deployed by the challenger itself as a Report, for example, the Report may include a hash value of the configuration file deployed by the enclosure to be verified; then, the to-be-verified enclosure acquires a remote verifiable Quote by using a local authentication mechanism, specifically, a special enclosure called a Quoting Envelope (QE) on the target device signs the Report by using an asymmetric key deployed in a CPU of the target device, so as to generate the remote verifiable Quote, and the target device sends the Quote to the challenger. The asymmetric key is burned into the CPU in the production process, the asymmetric keys burned into different CPUs are completely different, and the public key corresponding to each asymmetric key is uniformly maintained at the ias (intel attentional server). Therefore, the challenger needs to further send the Quote provided by the target device to the IAS, and the IAS verifies a signature included in the Quote, so as to determine the validity of the SGX platform on the target device, and feed back the determination result to the challenger. If the judgment result indicates that the SGX platform on the target device is valid, the challenger may further verify the Report contained in the Quote, for example, compare the hash value contained in the Report with the hash value corresponding to the standard configuration file held by the challenger: if the hash values are consistent, the challenger may determine that the standard configuration file is correctly configured in the enclosure to be verified of the target device, that is, the enclosure to be verified passes the remote certification.

However, the remote attestation mechanism in the related art can prove that the correct configuration file is deployed in the TEE, but the operating environment on which the TEE itself is based cannot be verified; for example, on a blockchain node which needs to implement a privacy function, a virtual machine for executing an intelligent contract needs to be configured in the TEE, and the instruction executed by the virtual machine is not directly executed, but actually executes a corresponding number of X86 instructions (assuming that the target device adopts an X86 architecture), thereby posing a certain security risk.

The following describes, with reference to embodiments, a method for implementing a privacy blockchain based on an FPGA, so as to improve security.

Fig. 1 is a flowchart of a method for implementing a privacy blockchain based on an FPGA according to an exemplary embodiment. As shown in fig. 1, the method applied to the client may include the following steps:

step 102, a client deploys a circuit logic configuration file to an FPGA structure at a block chain node, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment of the block chain node.

The client may include any object that needs to perform a deployment operation to the FPGA fabric, so that the FPGA fabric can implement a corresponding service or function based on the deployed circuit logic configuration file. For example, the client may include a key Management server, that is, a KMS (key Management service) server, and after determining that a correct circuit logic configuration file is deployed on the FPGA structure, the KMS server may allocate a corresponding service key to the FPGA structure, so that the FPGA structure may be implemented as a TEE on a block link point, thereby implementing a block link node having a privacy function.

Therefore, the client deploys an appropriate circuit logic configuration file to the FPGA structure, so that the FPGA structure can be implemented as a TEE on a block link point after the circuit logic configuration file is correctly configured. For example, the circuit logic configuration file may include configuration information for implementing functions such as encryption and decryption, of a Virtual Machine (for example, the aforementioned Ethernet Virtual Machine (EVM) may be used as the ethernet Virtual Machine, and other types of Virtual machines may also be used in other block chains), and the configuration information may be specifically represented in a form of a bitstream so as to be conveniently burned to an FPGA structure, but the present specification does not limit the form adopted by the circuit logic configuration file.

The FPGA structure may be pre-deployed with an authentication root Key (attention Key), and the authentication root Key may be preset in the FPGA structure, or the authentication root Key may be deployed into the FPGA structure by a client or other object in an offline secure environment. The authentication root key belongs to an asymmetric key, and a public key corresponding to the authentication root key is disclosed, so that even if the authentication root key is not deployed by the client (deployed by a preset or other objects), the client can verify a signature generated by the authentication root key based on the disclosed public key.

The client can realize key agreement with the FPGA structure. Assuming that the SM2 (or other algorithm) algorithm is used to implement negotiation, the client and the FPGA structure need to perform at least one information interaction during the negotiation: when the FPGA structure sends negotiation information to the client, the authentication root key can be adopted to sign the negotiation information, so that the client can utilize the public key to carry out signature verification after receiving the signed negotiation information, thereby determining that the negotiation information is really sent by the FPGA structure and trusting the negotiation information; and when the signature is not verified, the client can choose not to trust the received negotiation information. Based on the above process, the client and the FPGA structure can complete key agreement, so that the client and the FPGA structure can obtain the same configuration file deployment key respectively. The configuration file deployment key can be directly obtained by the client and the FPGA structure through a key negotiation process, namely the configuration file deployment key can be a secret value (or called as a master key); or, the configuration file deployment Key may be derived from the secret value by the client and the FPGA structure through a Key Derivation Function (KDF for short). Based on the configuration file deployment key obtained by negotiation, the client can encrypt the circuit logic configuration file and send the encrypted circuit logic configuration file to the FPGA structure; correspondingly, after receiving the encrypted circuit logic configuration file, the FPGA structure may decrypt the encrypted circuit logic configuration file according to the configuration file deployment key to obtain a corresponding circuit logic configuration file, and deploy the circuit logic configuration file.

The FPGA structure may include an FPGA chip, and the FPGA structure may read the circuit logic configuration file directly into the FPGA chip when deploying the circuit logic configuration file. However, the FPGA chip is volatile, and the deployed circuit logic configuration file is lost after power is off, so that the client needs to re-deploy the circuit logic configuration file after power is re-powered on. Therefore, in order to reduce the number of times of deployment of the client, the FPGA structure may further include a memory, the memory being connected to the FPGA chip, so that the circuit logic configuration file is deployed in the memory, and the FPGA chip reads the circuit logic configuration file from the memory to implement the related function; the memory is nonvolatile, the circuit logic configuration file can be stored even if the power is off, and after the power is turned on again, the circuit logic configuration file only needs to be read into the FPGA chip from the memory again, and the client does not need to be redeployed. The memory may have various forms, such as a rewritable non-volatile memory, such as a flash memory (flash), and a non-rewritable memory, such as a fuse memory, and the description does not limit this.

The FPGA fabric may include a key management chip in which the aforementioned authentication root key may be stored for high security and high reliability. Of course, the authentication root key may also be stored in an FPGA chip or a memory, such as those described above, and this specification does not limit this.

And 104, the client receives an authentication result returned by the FPGA structure, the authentication result is signed by an authentication root key deployed in the FPGA structure, and a public key corresponding to the authentication root key is disclosed.

And 106, confirming that the circuit logic configuration file is successfully deployed on the FPGA structure by the client under the condition that the authentication result passes signature verification and contains the content related to the circuit logic configuration file.

As described above, since the authentication root key deployed in the FPGA structure is an asymmetric key and the public key corresponding to the authentication root key is disclosed, the client can obtain the public key in advance, perform signature verification on the authentication result returned by the FPGA structure according to the public key, and determine that the authentication result is provided by the FPGA structure and the authentication result is not tampered when the signature verification passes. The verification process can be completed locally by the client without the aid of a third party, so that on one hand, the interaction times can be reduced, the verification efficiency is improved, on the other hand, the intervention of the third party and the increase of the interaction times can be avoided, so that additional safety risks are avoided, and the reliability of the verification result is ensured to be independent of the self-control ability and the credibility of the third party.

The client can verify the content related to the circuit logic configuration file contained in the authentication result, so as to determine whether the content is consistent with the circuit logic configuration file deployed to the FPGA structure by the client. For example, the content related to the circuit logic configuration file may be a hash value of the circuit logic configuration file, or a value obtained by calculating the hash value of the circuit logic configuration file by using a predetermined algorithm (e.g., sm3 algorithm, etc.), so that the client may locally calculate the hash value of the circuit logic configuration file or further calculate the hash value by using the predetermined algorithm and compare the calculated hash value with the hash value or the value included in the authentication result, if the circuit logic configuration file already exists and the predetermined algorithm is known: if the configuration files are consistent with the configuration files, the FPGA structure is indicated to correctly deploy the circuit logic configuration files provided by the client, otherwise, the circuit logic configuration files are indicated to be unsuccessfully configured.

Further, the authentication result may further include content related to the configuration file deployment key. Accordingly, the client can verify the authentication result according to the configuration file deployment key derived by the client. For example, the authentication result may include a hash value of the configuration file deployment key, or a value obtained by calculating the configuration file deployment key or the hash value thereof by using a preset algorithm, and then, similar to the circuit logic configuration file, the client may calculate the hash value or the value related to the preset algorithm according to the configuration file deployment key derived by the client: if the content related to the circuit logic configuration file and the content related to the configuration file deployment key contained in the authentication result are verified, the fact that the configuration file deployment key is successfully negotiated between the FPGA structure and the client is indicated, the circuit logic configuration file provided by the client is correctly deployed by the FPGA structure, and otherwise, the fact that key negotiation fails or circuit logic configuration file deployment fails is indicated. For another example, the content related to the circuit logic configuration file and the content related to the configuration file deployment key in the authentication result may be generated as the same content, that is, the authentication result may include a content related to both the circuit logic configuration file and the configuration file deployment key; for example, the FPGA structure may calculate the deployed circuit logic configuration file (or the hash value thereof) and the negotiated configuration file deployment key (or the hash value thereof) by using a preset algorithm to obtain a value, which is used as the content related to the circuit logic configuration file and the configuration file deployment key in the authentication result, and the client may verify the value included in the authentication result according to the circuit logic configuration file, the configuration file deployment key and the known preset algorithm maintained by the client.

Similar to the configuration file deployment key, the client and the FPGA structure may perform key negotiation therebetween, so that the client and the FPGA structure may derive the same service secret deployment key respectively, so as to deploy the service key provided by the client or another service secret to the FPGA structure. In the key agreement process, the client and the FPGA structure need to send agreement information to each other, and after the FPGA structure generates the agreement information, the client can sign through the authentication root key and send the signed agreement information to the client, and the client can sign and verify according to the public key: after the signature passes the verification, the client determines that the negotiation information comes from the FPGA structure, and further completes the negotiation process based on the negotiation information, otherwise, the client can terminate the key negotiation. Finally, after the client and the FPGA structure are negotiated, the same service secret deployment key can be obtained respectively. The service secret deployment key can be directly obtained by the client and the FPGA structure through a key negotiation process, namely, the service secret deployment key can be a secret value (or called as a master key); alternatively, the service secret deployment key can be derived from the secret value by the client and the FPGA structure through a key derivation function respectively.

Based on the service secret deployment key obtained by negotiation, the client can encrypt the service key to be deployed and send the encrypted service key to the FPGA structure; correspondingly, after receiving the encrypted service key, the FPGA structure may deploy the key according to the service secret to perform decryption to obtain a corresponding service key, and deploy the service key.

For example, the traffic key may include: a node private key, a node public key corresponding to the node private key being published; wherein the node public key is used for encrypting the transaction, or the node public key and a symmetric key provided by a transaction submitting party are jointly used for encrypting the transaction in a digital envelope mode. Taking privacy transaction under a blockchain scene as an example, assuming that a transaction submitting party wants to keep the submitted transaction contents secret, the transaction submitting party can encrypt the transaction through the node public key and then submit the encrypted transaction to a blockchain node, and the blockchain node can be decrypted in an FPGA structure by using a node private key, so that the transaction contents of a plaintext are obtained; or, the transaction submitting party may encrypt the transaction by using a symmetric key generated randomly (or obtained by other means), encrypt the symmetric key by using the node public key, submit the encrypted transaction and the encrypted symmetric key to the block link point, and the block link point may decrypt the encrypted symmetric key by using the node private key in the FPGA structure, and decrypt the encrypted transaction by using the symmetric key obtained by decryption, thereby obtaining the transaction content in the clear text.

As another example, the traffic key may include: and the service root key or a derivative key of the service root key is used for encrypting the private data generated in the trusted execution environment and then storing the encrypted private data in a database maintained by the block link node. For example, after a block chain node executes a transaction in a TEE formed by the FPGA structure, the private data having an encryption requirement may be generated, for example, the private data may include a value of a contract state generated by executing an intelligent contract, and then the FPGA structure may encrypt the private data by using the service root key or a derivative key thereof, and store the encrypted private data in a database maintained by the block chain node. Accordingly, when the private data needs to be read, the encrypted private data is read into the FPGA structure, so that the FPGA structure can decrypt based on the service root key or the derivative key thereof, and the private data of the corresponding plaintext can be obtained, so as to read or update the value of the private data, or use the value of the private data to participate in other calculation processes, and the like.

The client and the FPGA structure can respectively negotiate to obtain the configuration file deployment key and the service secret deployment key through two negotiation processes. Or, the client and the FPGA structure may negotiate to obtain the configuration file deployment key and the service secret deployment key through a negotiation process; for example, the client and the FPGA structure may negotiate to obtain the same secret value, and then derive the configuration file deployment key and the service secret deployment key through the key derivation function described above, for example, the key derivation function may derive 32 bytes of random numbers at a time, where the first 16 bytes may be used as the configuration file deployment key and the last 16 bytes may be used as the service secret deployment key.

Fig. 2 is a flowchart of another method for implementing a privacy blockchain based on an FPGA according to an example embodiment. As shown in fig. 2, the method applied to the FPGA structure may include the following steps:

step 202, the FPGA structure deploys a circuit logic configuration file from the client, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the block link point to which the FPGA structure belongs.

The client may include any object that needs to perform a deployment operation to the FPGA fabric, so that the FPGA fabric can implement a corresponding service or function based on the deployed circuit logic configuration file. For example, the client may include a key management server, that is, a KMS server, and after determining that the correct circuit logic configuration file is deployed on the FPGA structure, the KMS server may allocate a corresponding service key to the FPGA structure, so that the FPGA structure may be implemented as a TEE on a block link node, thereby implementing a block link node with a privacy function.

Therefore, the client deploys an appropriate circuit logic configuration file to the FPGA structure, so that the FPGA structure can be implemented as a TEE on a block link point after the circuit logic configuration file is correctly configured. For example, the circuit logic configuration file may include configuration information for implementing functions of a virtual machine (EVM or other types of virtual machines), encryption, decryption, and the like, and the configuration information may be specifically characterized in a form of a bitstream so as to be burned into an FPGA structure, although the description does not limit the form adopted by the circuit logic configuration file.

The FPGA structure can be pre-deployed with an authentication root key, the authentication root key can be preset in the FPGA structure, or the authentication root key can be deployed into the FPGA structure by a client or other objects under an offline security environment. The authentication root key belongs to an asymmetric key, and a public key corresponding to the authentication root key is disclosed, so that even if the authentication root key is not deployed by the client (deployed by a preset or other objects), the client can verify a signature generated by the authentication root key based on the disclosed public key.

The client can realize key agreement with the FPGA structure. Assuming that the SM2 (or other algorithm) algorithm is used to implement negotiation, the client and the FPGA structure need to perform at least one information interaction during the negotiation: when the FPGA structure sends negotiation information to the client, the authentication root key can be adopted to sign the negotiation information, so that the client can utilize the public key to carry out signature verification after receiving the signed negotiation information, thereby determining that the negotiation information is really sent by the FPGA structure and trusting the negotiation information; and when the signature is not verified, the client can choose not to trust the received negotiation information. Based on the above process, the client and the FPGA structure can complete key agreement, so that the client and the FPGA structure can obtain the same configuration file deployment key respectively. The configuration file deployment key can be directly obtained by the client and the FPGA structure through a key negotiation process, namely the configuration file deployment key can be a secret value (or called as a master key); alternatively, the configuration file deployment key may be derived from the secret value by the client and the FPGA structure through a key derivation function, respectively. Based on the configuration file deployment key obtained by negotiation, the client can encrypt the circuit logic configuration file and send the encrypted circuit logic configuration file to the FPGA structure; correspondingly, after receiving the encrypted circuit logic configuration file, the FPGA structure may decrypt the encrypted circuit logic configuration file according to the configuration file deployment key to obtain a corresponding circuit logic configuration file, and deploy the circuit logic configuration file.

The FPGA structure may include an FPGA chip, and the FPGA structure may read the circuit logic configuration file directly into the FPGA chip when deploying the circuit logic configuration file. However, the FPGA chip is volatile, and the deployed circuit logic configuration file is lost after power is off, so that the client needs to re-deploy the circuit logic configuration file after power is re-powered on. Therefore, in order to reduce the number of times of deployment of the client, the FPGA structure may further include a memory, the memory being connected to the FPGA chip, so that the circuit logic configuration file is deployed in the memory, and the FPGA chip reads the circuit logic configuration file from the memory to implement the related function; the memory is nonvolatile, the circuit logic configuration file can be stored even if the power is off, and after the power is turned on again, the circuit logic configuration file only needs to be read into the FPGA chip from the memory again, and the client does not need to be redeployed. The memory may have various forms, such as a rewritable non-volatile memory, such as a flash memory, and a non-rewritable memory, such as a fuse memory, and the description does not limit this.

Step 204, the FPGA structure signs an authentication result through the deployed authentication root key, where the authentication result includes content related to the circuit logic configuration file, and a public key corresponding to the authentication root key is disclosed.

Step 206, the FPGA structure returns the signed authentication result to the client, so that the client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure when the authentication result passes signature verification and the authentication result includes content related to the circuit logic configuration file.

FIG. 3 is a schematic flow chart diagram illustrating a process for interaction between a client and an FPGA fabric in accordance with an illustrative embodiment. Assuming that the client may be a KMS server, the FPGA structure is configured on the blockchain node, and the KMS server authenticates the FPGA structure, so that when the FPGA structure passes the authentication, a service key required by the blockchain node is deployed to the FPGA structure, so as to configure the blockchain node as having the privacy function, thereby implementing a blockchain network having the privacy function. As shown in fig. 3, the method may include the steps of:

step 301, the FPGA fabric deploys the authentication root key.

The root certificate key may be deployed by the producer during the production of the FPGA fabric, i.e., the producer deploys the root certificate key into the FPGA fabric, e.g., into a key management chip included in the FPGA fabric.

Of course, the authentication root key may also be deployed by the client. For example, a user corresponding to the client may deploy the authentication root key into the FPGA structure, such as into the key management chip described above, in a physical security environment in an offline state.

No matter what deployment method is adopted, the authentication root key deployed in the FPGA structure is an asymmetric key, that is, the authentication root key has a corresponding authentication public key, and the authentication public key is in a public state. For example, a website may be provided so that the client can download the authentication public key described above.

Step 302, the client and the FPGA structure negotiate a key remotely.

It is assumed that the client and FPGA fabric may implement key agreement using algorithms such as SM 2. In the negotiation process, the client and the FPGA structure need to generate negotiation information respectively, and the negotiation information generated by the client and the FPGA structure is remotely exchanged, so that the negotiation process is completed. After the FPGA structure generates the negotiation information, the negotiation information can be signed through the authentication root key, and then the signed negotiation information is sent to the client. Correspondingly, after receiving the negotiation information from the remote end, the client can perform signature verification on the negotiation information through the pre-obtained authentication public key: if the verification is successful, the negotiation information is shown to be from the FPGA structure, namely the negotiation information is credible, so that the subsequent negotiation process is completed based on the negotiation information, otherwise, the key negotiation is terminated. It can be seen that, because the authentication root key is built in the FPGA structure and the authentication public key corresponding to the authentication root key is in a public state, the client and the FPGA structure can implement remote key agreement accordingly, and the client can complete signature verification locally without a third party, so that the reduction of verification efficiency caused by interaction between the client and the third party can be avoided, and the reliability of the verification result is prevented from depending on the credibility of the third party, which is helpful for improving the security.

Step 303, the client and the FPGA structure derive a configuration file deployment key and a service secret deployment key, respectively.

Based on the key agreement operation, the client and the FPGA structure may generate the same secret value respectively, and further process the secret value through the KDF function, and may derive the configuration file deployment key and the service secret deployment key. For example, the KDF function may derive a set of 32-byte random numbers, and may use the first 16-byte random numbers as a configuration file deployment key and the last 16-byte random numbers as a service secret deployment key; of course, the KDF function may derive random numbers of other lengths, and each key may take on other lengths, respectively, which the present specification does not limit. The random number derived by the KDF function is not necessarily used for generating the service key, for example, the KDF function may derive a 64-byte random number, the first 16-byte random number may be selected as the configuration file deployment key, the last 16-byte random number may be selected as the service secret deployment key, and the remaining 32-byte random numbers are discarded.

And the client and the FPGA structure respectively maintain the derived configuration file deployment key and the service secret deployment key. The FPGA structure can comprise an FPGA chip and a key management chip, wherein a configuration file deployment key and a service secret deployment key can be maintained in the key management chip to ensure the security of the configuration file deployment key and the service secret deployment key.

And step 304, the client generates and encrypts a circuit logic configuration file, and then sends the encrypted circuit logic configuration file to the FPGA structure.

The client encrypts the circuit logic configuration file according to the configuration file deployment key exported in step 303, so that in the process of remotely transmitting the encrypted circuit logic configuration file to the FPGA structure, even if data leakage occurs, no loss is caused.

And 305, decrypting the FPGA structure to obtain a circuit logic configuration file and deploying.

After receiving the encrypted circuit logic configuration file sent by the client, the FPGA structure may decrypt the encrypted circuit logic configuration file by using the configuration file deployment key derived in step 303 to obtain a plain-text circuit logic configuration file; the FPGA fabric may then implement the deployment on the circuit logic configuration file in clear text.

The FPGA structure can comprise an FPGA chip and a flash chip, and the circuit logic configuration file can be deployed in the flash chip, so that the FPGA chip can read and load the circuit logic configuration file from the flash chip after being powered on every time, and the circuit logic configuration file deployed in the flash chip cannot be lost after being powered off, and the client side is not required to be deployed repeatedly.

Step 306, the FPGA structure generates an authentication result and signs, and then returns the signed authentication result to the client.

After the deployment of the circuit logic configuration file is completed, the FPGA fabric may generate an authentication result. For example, the FPGA structure may generate a hash value corresponding to the circuit logic configuration file, for example, represented by user _ bitstream _ hash; meanwhile, the FPGA structure may generate a corresponding hash value for the configuration file deployment key, for example, represented by userbikey _ hash; then, the FPGA structure may perform calculation using an algorithm such as sm3, for example, the calculation result is msg, and msg is sm3(user _ bitstream _ hash | | | user basis _ hash), and the msg information is added to the authentication result.

The FPGA structure further signs the generated authentication result according to the authentication root key, so that the signed authentication result is sent to the client.

Step 307, after receiving the signed authentication result, the client verifies the signature and the authentication content.

As described above, the client may obtain the authentication public key corresponding to the authentication root key in advance, so that the client may perform signature verification based on the authentication public key after receiving the signed authentication result.

After the signature passes the verification, the client may further verify the authentication content included in the authentication result, and the authentication content may include the msg information. The client can calculate msg ' ═ sm3(user _ bitstream _ hash ' | | userbuty _ hash ') using sm3 algorithm, where: the user _ bitstream _ hash 'represents a circuit logic configuration file locally maintained by the client, and the userbitkey _ hash' represents a configuration file deployment key locally maintained by the client. Then, if msg' is calculated, it indicates that the client and the FPGA structure successfully negotiate a configuration file deployment key in step 303, and indicates that the FPGA structure successfully deploys the circuit logic configuration file provided by the client; since the configuration file deployment key and the service secret deployment key are derived based on the same secret value, it is also indicated that the configuration file deployment key and the service secret deployment key successfully negotiate the service secret deployment key.

Therefore, the client can locally complete the verification of the authentication result without depending on a third party, so that the interaction can be reduced, and the safety can be improved.

And 308, the client determines and encrypts the node private key and the service root key, and then sends the encrypted node private key and the encrypted service root key to the FPGA structure.

And 309, decrypting the FPGA structure to obtain a node private key and a service root key.

After the client encrypts the service keys such as the node private key, the service root key and the like by using the service secret deployment key obtained in the step 303, the client can safely and remotely transmit the node private key and the service root key to the FPGA structure; correspondingly, the FPGA structure may decrypt based on the service secret deployment key obtained in step 303, to obtain the node private key and the service root key, and deploy the node private key and the service root key.

Based on a node private key and a service root key deployed on the FPGA structure, the block link nodes can realize the privacy transaction function based on the FPGA structure. For example, fig. 4 is a block link point diagram for processing transactions according to an exemplary embodiment. As shown in fig. 4, the block chain node includes a conventional execution environment on the left side and a TEE formed by an FPGA structure on the right side, a transaction submitted by a user first enters a "transaction scheduling" interface in the conventional execution environment for type identification, the identified plaintext transaction is left in the conventional execution environment for processing (corresponding to the "transaction execution" section on the left side), and the identified private transaction is transferred to the TEE for processing (corresponding to the "transaction execution" section on the right side).

The private transaction is encrypted by the user and then submitted to the block chain node. For example, a user may randomly generate a symmetric key, and a public node key exists as a private node key deployed on the FPGA fabric, so that the user may implement digital envelope encryption on transaction contents based on the symmetric key and the public node key: the user encrypts the transaction content of the plaintext by using the symmetric key to generate encrypted transaction content, encrypts the symmetric key by using the node public key to generate an encrypted symmetric key, and submits the encrypted transaction content and the encrypted symmetric key to the block link point as the privacy transaction at the same time. Correspondingly, the block link point reads the private transaction into the FPGA structure, the encrypted symmetric key is decrypted through a node private key deployed in the FPGA structure to obtain the symmetric key, the encrypted transaction content is further decrypted based on the symmetric key to obtain the transaction content of a plaintext, and then the transaction content is processed on the FPGA structure.

Wherein, the privacy transaction can be understood as a transaction with a privacy requirement; in addition to private transactions, blockchain nodes may receive clear text transactions, which are transactions without privacy requirements. The privacy requirements may be expressed in a number of ways and this description is not intended to be limiting. For example, each transaction may contain a type field that is used to mark whether the corresponding transaction belongs to a private transaction or a clear text transaction. As previously described, the block link points may identify the transaction type at a "transaction scheduling" interface in a conventional execution environment such as that shown in fig. 1. In the related art, such as in an ethernet network, transactions typically include fields to, value, data, etc.; on the basis of the related technology, the present embodiment adds a type field, for example, characterized as a type field, to the transaction, and indicates the type of the related transaction based on the value of the type field: for example, when the type field is the first value, it indicates that the related transaction is a plaintext transaction, and when the type field is the second value, it indicates that the related transaction is a privacy transaction. As another example, the user may add an encrypted identification within the transaction during the process of creating the transaction to express the privacy requirements described above. Then, when the encrypted identifier is detected to be included in the transaction, the block chain node can determine that the transaction is a private transaction, otherwise, the transaction is determined to be a clear text transaction. For another example, the block nodes may identify the type of the smart contract that needs to be invoked for the transaction, and when the invoked smart contract belongs to a privacy type (for example, the smart contract includes a privacy identifier, or a contract state that includes a privacy identifier tag in the code of the smart contract, etc.), it may be determined that the transaction belongs to a privacy transaction, otherwise, it is determined that the transaction is a plaintext transaction.

The transactions in this specification may be used to implement relatively simple processing logic, such as transfer logic similar to that of the related art. In this case, the clear text transaction or the privacy transaction can be independent of the intelligent contract.

The transactions in this specification may also be used to implement relatively complex processing logic, which may be implemented here by means of the smart contracts described above. Taking the ethernet house as an example, the support user creates and/or invokes some complex logic in the ethernet house network, which is the biggest challenge of the ethernet house to distinguish from the bitcoin blockchain technology. The core of the ethernet plant as a programmable blockchain is the ethernet plant virtual machine (EVM), each ethernet plant node can run the EVM. The EVM is a well-behaved virtual machine, which means that a variety of complex logic can be implemented through it. The user issuing and invoking smart contracts in the etherhouse is running on the EVM. As shown in fig. 4, by deploying the EVM in the conventional execution environment, the intelligent contract issued or called by the plaintext transaction can be executed through the EVM, so as to implement a "transaction execution" link in the conventional execution environment; and by deploying an EVM (the FPGA structure can implement the functions of the EVM or other virtual machines based on the deployed circuit logic configuration file) in the TEE, an intelligent contract issued or invoked by a private transaction can be executed through the EVM, so as to implement a "transaction execution" link in the TEE.

After the privacy transaction is processed in the FPGA structure, the value of the account balance of the related account or the contract state related to the intelligent contract may be changed, and the FPGA structure may encrypt the value based on the service root key or the derivative key thereof, and store the encrypted value in the database maintained by the block chain node.

Therefore, only the data in the FPGA structure can be presented in a plaintext state to realize efficient data processing, and the data outside the FPGA structure is in an encrypted state to ensure data security, so that the privacy protection function on the block chain can be realized.

FIG. 5 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 5, at the hardware level, the apparatus includes a processor 502, an internal bus 504, a network interface 506, a memory 508 and a non-volatile memory 510, but may also include hardware required for other services. The processor 502 reads a corresponding computer program from the non-volatile memory 510 into the memory 508 and runs it, forming a means for implementing a chain of privacy blocks based on an FPGA at a logical level. 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.

Referring to fig. 6, in a software implementation, the apparatus for implementing a privacy zone block chain based on an FPGA may include:

a configuration file deployment unit 61, configured to enable a client to deploy a circuit logic configuration file to an FPGA structure at a block chain node, where the circuit logic configuration file is used to enable the FPGA structure to be implemented as a trusted execution environment of the block chain node;

an authentication result receiving unit 62, configured to enable the client to receive an authentication result returned by the FPGA structure, where the authentication result is signed by an authentication root key deployed in the FPGA structure, and a public key corresponding to the authentication root key is disclosed;

and a deployment confirming unit 63, which is used for confirming that the circuit logic configuration file is successfully deployed on the FPGA structure when the authentication result passes signature verification and the authentication result contains the content related to the circuit logic configuration file.

Optionally, the authentication root key is preset in the FPGA structure; or the authentication root key is deployed into the FPGA structure by the client or other objects in an offline security environment.

Optionally, the configuration file deploying unit 61 is specifically configured to:

enabling the client to negotiate a configuration file deployment key with the FPGA structure according to negotiation information sent by the FPGA structure, and enabling the client and the FPGA structure to respectively determine the configuration file deployment key; wherein the negotiation information is signed by the authentication root key;

and enabling the client to encrypt the circuit logic configuration file through the configuration file deployment key, and sending the encrypted circuit logic configuration file to the FPGA structure, so that the FPGA structure decrypts the circuit logic configuration file according to the configuration file deployment key and deploys the circuit logic configuration file.

Optionally, the authentication result further includes content related to the configuration file deployment key.

Optionally, the method further includes:

a service key negotiation unit 64, which enables the client to negotiate a service secret deployment key with the FPGA structure according to negotiation information sent by the FPGA structure, so that the client and the FPGA structure respectively determine the service secret deployment key; wherein the negotiation information is signed by the authentication root key;

and the service key deployment unit 65 encrypts the service key by the client through the service secret deployment key, and sends the encrypted service key to the FPGA structure, so that the FPGA structure decrypts the service key according to the service secret deployment key and deploys the service key.

Optionally, the service key includes: a node private key, a node public key corresponding to the node private key being disclosed;

wherein the node public key is used to encrypt a transaction; or the node public key and a symmetric key provided by a transaction submitting party are jointly used for encrypting the transaction in a digital envelope mode.

The optional service key comprises: and the service root key or a derivative key of the service root key is used for encrypting the private data generated in the trusted execution environment and then storing the encrypted private data in a database maintained by the blockchain node.

Optionally, the client includes a key management server.

Fig. 7 is a schematic block diagram of an apparatus provided in an exemplary embodiment. Referring to fig. 7, at the hardware level, the apparatus includes a processor 702, an internal bus 704, a network interface 706, a memory 708, and a non-volatile storage 710, but may also include hardware required for other services. The processor 702 reads a corresponding computer program from the non-volatile memory 710 into the memory 708 and then runs the computer program to form a device for implementing a chain of privacy blocks based on an FPGA at a logic level. 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.

Referring to fig. 8, in a software implementation, the apparatus for implementing a privacy zone block chain based on an FPGA may include:

a configuration file deployment unit 81, configured to enable the FPGA structure to deploy a circuit logic configuration file from a client, where the circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on a block link point to which the FPGA structure belongs;

an authentication result signing unit 82, configured to enable the FPGA fabric to sign an authentication result through a deployed authentication root key, where the authentication result includes content related to the circuit logic configuration file, and a public key corresponding to the authentication root key is disclosed;

an authentication result returning unit 83, configured to return the signed authentication result to the client by the FPGA structure, so that the client confirms that the circuit logic configuration file is successfully deployed on the FPGA structure when the authentication result passes signature verification and the authentication result includes content related to the circuit logic configuration file.

Optionally, the FPGA structure includes a key management chip, and the authentication root key is stored in the key management chip.

Optionally, the FPGA structure includes an FPGA chip and a memory; wherein the circuit logic configuration file is deployed in the memory and the FPGA chip reads the circuit logic configuration file from the memory to implement the related function.

Optionally, the memory comprises a non-volatile memory or a fuse memory.

Optionally, the configuration file deployment unit 81 is specifically configured to:

the FPGA structure negotiates a configuration file deployment key with the client by sending negotiation information to the client, so that the client and the FPGA structure respectively determine the configuration file deployment key; wherein the negotiation information is signed by the authentication root key;

enabling the FPGA structure to receive an encrypted circuit logic configuration file sent by the client, wherein the encrypted circuit logic configuration file is obtained by encrypting the circuit logic configuration file through the configuration file deployment key;

and enabling the FPGA structure to decrypt the encrypted circuit logic configuration file according to the file deployment key and deploy the decrypted circuit logic configuration file.

Optionally, the method further includes:

a negotiation unit 84, configured to negotiate a service secret deployment key with the client by sending negotiation information to the client by the FPGA structure, so that the client and the FPGA structure respectively determine the service secret deployment key; wherein the negotiation information is signed by the authentication root key;

a receiving unit 85, configured to enable the FPGA structure to receive an encrypted service key sent by the client, where the encrypted service key is obtained by encrypting the service key with the service secret deployment key;

and the decryption unit 86 is used for enabling the FPGA structure to decrypt the encrypted service key according to the service secret deployment key and deploy the decrypted service key.

Optionally, the service key includes: and the service root key or a derivative key of the service root key is used for encrypting the private data generated in the trusted execution environment and then storing the encrypted private data in a database maintained by the blockchain node.

Optionally, the client includes a key management server.

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

1. A method for realizing a privacy block chain based on an FPGA comprises the following steps:

the client receives an authentication result returned by the FPGA structure, the authentication result is signed by an authentication root key deployed in the FPGA structure, a public key corresponding to the authentication root key is disclosed, and the authentication root key is preset in the FPGA structure; or the authentication root key is deployed into the FPGA structure by the client or other objects under an offline security environment;

2. The method of claim 1, the client deploying a circuit logic configuration file to an FPGA fabric at a block link point, comprising:

the client negotiates a configuration file deployment key with the FPGA structure according to negotiation information sent by the FPGA structure, so that the client and the FPGA structure respectively determine the configuration file deployment key; wherein the negotiation information is signed by the authentication root key;

and the client encrypts the circuit logic configuration file through the configuration file deployment key and sends the encrypted circuit logic configuration file to the FPGA structure, so that the FPGA structure decrypts the circuit logic configuration file according to the configuration file deployment key and deploys the circuit logic configuration file.

3. The method of claim 2, wherein the authentication result further comprises content associated with the profile deployment key.

4. The method of claim 1, further comprising:

the client negotiates a service secret deployment key with the FPGA structure according to negotiation information sent by the FPGA structure, so that the client and the FPGA structure respectively determine the service secret deployment key; wherein the negotiation information is signed by the authentication root key;

and the client encrypts a service key through the service secret deployment key and sends the encrypted service key to the FPGA structure, so that the FPGA structure decrypts the service key according to the service secret deployment key and deploys the service key.

5. The method of claim 4, the traffic key comprising: a node private key, a node public key corresponding to the node private key being disclosed;

6. The method of claim 4, the traffic key comprising: and the service root key or a derivative key of the service root key is used for encrypting the private data generated in the trusted execution environment and then storing the encrypted private data in a database maintained by the blockchain node.

7. The method of claim 1, the client comprising a key management server.

8. A method for realizing a privacy block chain based on an FPGA comprises the following steps:

the FPGA structure signs an authentication result through a deployed authentication root key, wherein the authentication result comprises contents related to the circuit logic configuration file, a public key corresponding to the authentication root key is disclosed, and the authentication root key is preset in the FPGA structure; or the authentication root key is deployed into the FPGA structure by the client or other objects under an offline security environment;

9. The method of claim 8, the FPGA fabric comprising a key management chip, the authentication root key being stored in the key management chip.

10. The method of claim 8, the FPGA fabric comprising an FPGA chip and a memory; wherein the circuit logic configuration file is deployed in the memory and the FPGA chip reads the circuit logic configuration file from the memory to implement the related function.

11. The method of claim 10, the memory comprising a non-volatile memory or a fuse memory.

12. The method of claim 8, the FPGA fabric deploying a circuit logic configuration file from a client, comprising:

the FPGA structure receives an encrypted circuit logic configuration file sent by the client, and the encrypted circuit logic configuration file is obtained by encrypting the circuit logic configuration file by the configuration file deployment key;

and the FPGA structure decrypts the encrypted circuit logic configuration file according to the file deployment key and deploys the decrypted circuit logic configuration file.

13. The method of claim 12, wherein the authentication result further comprises content associated with the profile deployment key.

14. The method of claim 8, further comprising:

the FPGA structure negotiates with the client to configure a service secret deployment key by sending negotiation information to the client, so that the client and the FPGA structure respectively determine the service secret deployment key; wherein the negotiation information is signed by the authentication root key;

the FPGA structure receives an encrypted service key sent by the client, and the encrypted service key is obtained by encrypting the service key by the service secret deployment key;

and the FPGA structure decrypts the encrypted service key according to the service secret deployment key and deploys the decrypted service key.

15. The method of claim 14, the traffic key comprising: a node private key, a node public key corresponding to the node private key being disclosed;

16. The method of claim 14, the traffic key comprising: and the service root key or a derivative key of the service root key is used for encrypting the private data generated in the trusted execution environment and then storing the encrypted private data in a database maintained by the blockchain node.

17. The method of claim 8, the client comprising a key management server.

18. An apparatus for implementing a privacy blockchain based on an FPGA, comprising:

the authentication result receiving unit enables the client to receive an authentication result returned by the FPGA structure, the authentication result is signed by an authentication root key deployed in the FPGA structure, a public key corresponding to the authentication root key is disclosed, and the authentication root key is preset in the FPGA structure; or the authentication root key is deployed into the FPGA structure by the client or other objects under an offline security environment;

19. An apparatus for implementing a privacy blockchain based on an FPGA, comprising:

the authentication result signing unit enables the FPGA structure to sign an authentication result through a deployed authentication root key, wherein the authentication result comprises contents related to the circuit logic configuration file, a public key corresponding to the authentication root key is disclosed, and the authentication root key is preset in the FPGA structure; or the authentication root key is deployed into the FPGA structure by the client or other objects under an offline security environment;

20. 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-8 by executing the executable instructions.

21. 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 to 7.

22. An electronic device, comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor implements the method of any one of claims 8-17 by executing the executable instructions.

23. 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 8 to 17.