WO2021057181A1

WO2021057181A1 - Fpga-based key negotiation method and device

Info

Publication number: WO2021057181A1
Application number: PCT/CN2020/100925
Authority: WO
Inventors: 魏长征; 潘国振; 闫莺
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2019-09-25
Filing date: 2020-07-08
Publication date: 2021-04-01
Also published as: CN110690963A; CN113285802B; CN113285802A; CN110690963B

Abstract

One or more embodiments of the present description provide an FPGA-based key negotiation method and device. Said method may comprise: an FPGA structure loading a deployed circuit logic configuration file onto an FPGA chip, so as to form a key negotiation module on the FPGA chip; the FPGA structure performing remote key negotiation with a client by means of the key negotiation module, so as to obtain a configuration file deployment key at the FPGA structure and the client respectively; the FPGA structure decrypting an encrypted new-version circuit logic configuration file from the client on the basis of the configuration file deployment key, and updating the deployed circuit logic configuration file on the basis of the obtained new-version circuit logic configuration file, so that the FPGA structure is implemented as a trusted execution environment on a block chain node to which the FPGA structure belongs.

Description

FPGA-based key agreement method and device

Technical field

One or more embodiments of this specification relate to the field of blockchain technology, and in particular to an FPGA-based key agreement method and device.

Background technique

Blockchain technology is built on a transmission network (such as a peer-to-peer network). The network nodes in the transmission network use chained data structures to verify and store data, and use distributed node consensus algorithms to generate and update data.

At present, the two biggest challenges in enterprise-level blockchain platform technology are privacy and performance. It is often difficult to solve these two challenges at the same time. Most of the solutions are to lose performance in exchange for privacy, or do not consider privacy to pursue performance. Common encryption technologies that solve privacy problems, such as Homomorphic encryption and Zero-knowledge proof, are highly complex, have poor versatility, and may also cause serious performance losses.

Trusted Execution Environment (TEE) is another way to solve privacy issues. TEE can play the role of a black box in the hardware. Neither the code executed in the TEE nor the data operating system layer can be peeped, and only the pre-defined interface in the code can operate on it. In terms of efficiency, due to the black box nature of TEE, plaintext data is calculated in TEE instead of complex cryptographic operations in homomorphic encryption. There is no loss of efficiency in the calculation process. Therefore, the combination with TEE can achieve less performance loss. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about the TEE solution. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (trust zone) and AMD PSP (Platform Security Processor, platform security processor).

Summary of the invention

In view of this, one or more embodiments of this specification provide an FPGA-based key agreement method and device.

To achieve the foregoing objectives, one or more embodiments of the present specification provide technical solutions as follows.

According to the first aspect of one or more embodiments of this specification, an FPGA-based key agreement method is proposed, which includes: the FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip, so that the FPGA chip A key agreement module is formed on the above; the FPGA structure performs remote key agreement with the client through the key agreement module to obtain configuration file deployment keys at the FPGA structure and the client respectively; the FPGA The structure decrypts the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key, and updates the deployed circuit logic configuration file based on the obtained new version of the circuit logic configuration file, so that the FPGA The structure is implemented as a trusted execution environment on the blockchain node to which it belongs.

According to the second aspect of one or more embodiments of this specification, an FPGA-based key agreement method is proposed, which includes: FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip, so that the FPGA chip A key agreement module is formed on the top; wherein the deployed circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs; the FPGA structure passes through the key agreement The module conducts remote key negotiation with the client to obtain the business secret deployment key at the FPGA structure and the client respectively; after the FPGA structure encrypts the secret from the client based on the business secret deployment key The service key is decrypted, and the service key obtained by the decryption is applied to the trusted execution environment.

According to the third aspect of one or more embodiments of this specification, an FPGA-based key agreement device is proposed, which includes: a loading unit, which enables the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip, so as to A key agreement module is formed on the FPGA chip; a negotiation unit that enables the FPGA structure to perform remote key agreement with the client through the key agreement module, so as to be configured at the FPGA structure and the client respectively A file deployment key; a decryption unit that enables the FPGA structure to decrypt the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key; an update unit that makes the FPGA structure based on the obtained new version of the circuit The logic configuration file updates the deployed circuit logic configuration file, so that the FPGA structure is implemented as a trusted execution environment on the blockchain node to which it belongs.

According to the fourth aspect of one or more embodiments of this specification, an FPGA-based key agreement device is proposed, which includes: a loading unit, which enables the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip, so as to A key agreement module is formed on the FPGA chip; wherein the deployed circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs; the negotiation unit enables the The FPGA structure performs remote key negotiation with the client through the key agreement module to obtain the business secret deployment key at the FPGA structure and the client respectively; the decryption unit makes the FPGA structure based on the business The secret deployment key decrypts the encrypted service key from the client, and the decrypted service key is applied to the trusted execution environment.

According to a fifth aspect of one or more embodiments of this specification, an electronic device is proposed, including: a processor;

A memory for storing executable instructions of a processor; wherein the processor executes the executable instructions to implement the method according to the first aspect or the second aspect.

According to the sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided, which stores computer instructions, which when executed by a processor, implements the method described in the first or second aspect A step of.

Description of the drawings

Fig. 1 is a flowchart of an FPGA-based key agreement method provided by an exemplary embodiment.

Fig. 2 is a flowchart of another FPGA-based key agreement method provided by an exemplary embodiment.

Fig. 3 is a schematic structural diagram of a blockchain node provided by an exemplary embodiment.

Fig. 4 is a schematic diagram of forming a functional module on an FPGA chip provided by an exemplary embodiment.

Fig. 5 is a schematic diagram of newly updateable FPGA board provided by an exemplary embodiment.

Fig. 6 is a block diagram of an FPGA-based key agreement device provided by an exemplary embodiment.

Fig. 7 is a block diagram of another FPGA-based key agreement device provided by an exemplary embodiment.

detailed description

The exemplary embodiments will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings indicate the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with one or more embodiments of this specification. Rather, they are merely examples of devices and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding method are not necessarily executed in the order shown and described in this specification. In some other embodiments, the method may include more or fewer steps than described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; and multiple steps described in this specification may also be combined into a single step in other embodiments. description.

Blockchain is generally divided into three types: Public Blockchain, Private Blockchain and Consortium Blockchain. In addition, there are many types of combinations, such as private chain + alliance chain, alliance chain + public chain and other different combinations. Among them, the most decentralized one is the public chain. The public chain is represented by Bitcoin and Ethereum. Participants who join the public chain can read the data records on the chain, participate in transactions, and compete for the accounting rights of new blocks. Moreover, each participant (ie, node) can freely join and exit the network, and perform related operations. The private chain is the opposite. The write permission of the network is controlled by an organization or institution, and the data read permission is regulated by the organization. In simple terms, the private chain can be a weakly centralized system with strict restrictions and few participating nodes. This type of blockchain is more suitable for internal use by specific institutions. Consortium chain is a block chain between public chain and private chain, which can realize "partial decentralization". Each node in the alliance chain usually has a corresponding entity or organization; participants are authorized to join the network and form a stakeholder alliance to jointly maintain the operation of the blockchain.

Regardless of whether it is a public chain, a private chain or a consortium chain, for the purpose of privacy protection, the nodes in the blockchain network may use a solution that combines the blockchain and the TEE (Trusted Execution Environment). Execute received transactions within TEE. TEE is a secure extension based on CPU hardware and a trusted execution environment that is completely isolated from the outside. TEE was first proposed by Global Platform to solve the security isolation of resources on mobile devices, and parallel to the operating system to provide a trusted and secure execution environment for applications. ARM's Trust Zone technology is the first to realize the real commercial TEE technology. With the rapid development of the Internet, security requirements are getting higher and higher. Not only mobile devices, cloud devices, and data centers have put forward more demands on TEE. The concept of TEE has also been rapidly developed and expanded. Compared with the originally proposed concept, the TEE referred to now is a more generalized TEE. For example, server chip manufacturers Intel and AMD have successively introduced hardware-assisted TEE and enriched the concepts and features of TEE, which has been widely recognized in the industry. The TEE mentioned now usually refers more to this kind of hardware-assisted TEE technology.

Taking Intel SGX technology as an example, SGX provides an enclave (also known as an enclave), which is an encrypted trusted execution area in the memory, and the CPU protects data from being stolen. Taking the first blockchain node using a CPU that supports SGX as an example, using the newly added processor instructions, a part of the area EPC (Enclave Page Cache, enclave page cache or enclave page cache) can be allocated in the memory, and through the CPU The encryption engine MEE (Memory Encryption Engine) encrypts the data in it. The encrypted content in EPC will be decrypted into plain text only after entering the CPU. Therefore, in SGX, users can distrust the operating system, VMM (Virtual Machine Monitor), and even BIOS (Basic Input Output System). They only need to trust the CPU to ensure that private data will not leakage. Therefore, the enclosure is equivalent to the TEE produced under SGX technology.

Different from the mobile terminal, cloud access requires remote access, and the end user is invisible to the hardware platform. Therefore, the first step in using TEE is to confirm the authenticity of TEE. For example, the related technology provides a remote certification mechanism for the above-mentioned SGX technology to prove that the SGX platform on the target device and the challenger have deployed the same configuration file. However, because the TEE technology in the related technology is implemented by software or a combination of software and hardware, even if the remote attestation method can indicate to a certain extent that the configuration file deployed in the TEE has not been tampered with, the TEE itself depends on the operation The environment cannot be verified. For example, on a blockchain node that needs to implement privacy functions, a virtual machine for executing smart contracts needs to be configured in the TEE. The instructions executed by the virtual machine are not directly executed, but actually executed corresponding X86 instructions (Assuming that the target device adopts the X86 architecture), which poses a certain degree of security risk.

To this end, this specification proposes a hardware TEE technology based on FPGA implementation. FPGA implements hardware TEE by loading circuit logic configuration files. Because the content of the circuit logic configuration file can be checked and verified in advance, and the FPGA is configured and operated completely based on the logic recorded in the circuit logic configuration file, it can be ensured that the hardware TEE implemented by the FPGA has relatively higher security. As one of the foundations for implementing TEE, FPGA needs to implement encryption operations based on the key maintained to ensure that data is only in plaintext form inside the TEE and in ciphertext form outside the TEE. The FPGA structure in this specification is equivalent to the slave device, and the blockchain node to which the FPGA structure belongs (equivalent to the Host host corresponding to the FPGA structure) is equivalent to the master device. For similar master-slave architectures in related technologies, the master device is usually After participating in key negotiation, deploy the negotiated key to the slave device. However, the above-mentioned processing mechanism adopted by the related technology will cause the key to be learned by the blockchain node, thereby causing the risk of key leakage.

The following describes an FPGA-based key agreement method provided in this specification in conjunction with embodiments to improve security.

Fig. 1 is a flowchart of an FPGA-based key agreement method provided by an exemplary embodiment. As shown in FIG. 1, the method is applied to the FPGA structure and may include step 102-step 106.

Step 102: The FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip to form a key agreement module on the FPGA chip.

The FPGA chip contains a number of editable hardware logic units. After these hardware logic units are configured via a circuit logic configuration file, they can be implemented as corresponding functional modules to implement corresponding logic functions. Specifically, the circuit logic configuration file can be burned to the FPGA structure based on the form of a bit stream. For example, the above-mentioned key agreement module is formed by the deployed circuit logic configuration file, and by further deploying to form a functional module for realizing encryption, virtual machine and other logic, the FPGA structure can be configured as a blockchain node Hardware TEE. Since these functional modules are completely configured by the circuit logic configuration file, it is possible to determine the logic and other aspects of the information realized by the functional module configured by checking the circuit logic configuration file to ensure that the functional module can be configured according to the complete user’s requirements. Needs to be formed and run.

Step 104: The FPGA structure performs remote key negotiation with the client through the key agreement module, so as to obtain configuration file deployment keys at the FPGA structure and the client respectively.

By forming the key agreement module on the FPGA chip, the FPGA structure can directly implement remote key agreement with the client based on the key agreement module, instead of performing key agreement with the client through the blockchain node, which can avoid The configuration file deployment key is known by the blockchain node to ensure that the configuration file deployment key is only maintained inside the FPGA structure to avoid the leakage of the configuration file deployment key and cause security risks.

The operation logic of the key agreement module is defined by the aforementioned circuit logic configuration file, so that the user can control the logic of the key agreement module through the circuit logic configuration file, including the key agreement method. Any key agreement method in the related technology can be configured in the above-mentioned key agreement module through a circuit logic configuration file, which is not limited in this specification.

For example, the key agreement process may include: the FPGA structure may generate first private information based on the key agreement module, and then generate first key agreement information based on the first private information, and send the first key agreement information to the client At the same time, the client can generate second private information, and then generate second key agreement information according to the second private information, and send the second key agreement information to the key agreement module in the FPGA structure. Then, the FPGA structure can calculate the first private information and the second key agreement information through the key agreement module to generate a secret value; at the same time, the client can calculate the second private information and the first key agreement information, To generate the same secret value. Then, the configuration file deployment key may be the above-mentioned secret value, or it may be derived from the above-mentioned secret value based on a key derivation function (Key Derivation Function, KDF for short).

An authentication root key may be pre-deployed on the FPGA structure, 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 the client or other objects in an offline security environment. The authentication root key is an asymmetric key. Then, in the process of remotely negotiating the above configuration file deployment key between the client and the FPGA structure, the FPGA structure can use the authentication root key to sign the first key agreement information sent by itself, and the client can verify the signature. Determine whether the received information actually comes from the FPGA structure and has not been tampered with during transmission, and the information that has not passed the signature verification will not be trusted and adopted by the client. Among them, the public key of the authentication root key can be managed by the authentication server and not made public, then the client can send the received information to the authentication server, and the authentication server can perform signature verification with the maintained public key; then, the authentication The server can provide the client with the verification result, the verification result is signed by the verification server, and the verification result contains the certificate of the verification server or the public key of the verification server can be made public, so that the client can verify the signature to determine the validity of the verification result Sex. Alternatively, the public key of the authentication root key can be made public, so that the client can perform signature verification on the information from the FPGA structure based on the public key without going through the authentication server, which can reduce the interactive links in the signature verification process. Thereby improving the efficiency of verification and reducing the security risks caused by more interactive links.

The aforementioned authentication root key can be deployed to the FPGA structure based on the aforementioned deployed circuit logic configuration file. The FPGA structure can avoid taking the authentication root key from the circuit logic configuration file, so that the FPGA structure can obtain the corresponding authentication root key after loading the circuit logic configuration file to the FPGA chip. Alternatively, the FPGA structure can include a key management chip independent of the FPGA chip, and the FPGA structure can take the authentication root key out of the circuit logic configuration file to which it belongs and maintain it in the key management chip, so that only the authentication root key exists In the key management chip, it will no longer appear in the circuit logic configuration file deployed on the FPGA structure to improve the security of the authentication root key.

The public key or preset certificate corresponding to the client can be deployed on the FPGA structure. The client can sign the aforementioned second key agreement information and then send it to the FPGA structure, so that the FPGA structure can perform signature verification on the received second key agreement information, and verify that the signature is based on the second key. Negotiation information is one of the conditions for generating a secret value. Wherein, the public key or certificate corresponding to the client can be deployed in the FPGA structure by the aforementioned circuit logic configuration file.

Step 106: The FPGA structure decrypts the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key, and updates the deployed circuit logic configuration file based on the obtained new version of the circuit logic configuration file , So that the FPGA structure is realized as a trusted execution environment on the blockchain node to which it belongs.

The configuration file deployment key is used to deploy the circuit logic configuration file on the FPGA structure. The FPGA structure can form a decryption module on the FPGA chip based on the deployed circuit logic configuration file. The decryption module is used to decrypt the encrypted new version of the circuit logic configuration file according to the configuration file deployment key, so that only the configuration file deployment key is known Only the users who have been able to update the deployed circuit logic configuration file on the FPGA structure ensure that the update operation implemented for the deployed circuit logic configuration file is a credible update operation.

The user can provide the encrypted new version of the circuit logic configuration file to the FPGA structure through the client. The user can be an individual or a group (such as an enterprise), and this manual does not limit this. Among them, the client can remotely send the encrypted new version of the circuit logic configuration file to the FPGA structure; or, the client can be located at the same place as the FPGA structure to realize the transmission of the encrypted new version of the circuit logic configuration file locally or in a local area network.

In the above-mentioned new version of the circuit logic configuration file, the "new version" is relative to the circuit logic configuration file that has been deployed on the FPGA structure, to indicate that the deployed circuit logic configuration file is configured in the FPGA structure relatively earlier, and It does not mean that the logic or function implemented by the corresponding circuit logic configuration file will necessarily achieve version iteration.

When the FPGA structure deploys the circuit logic configuration file, the circuit logic configuration file can be directly read and configured in the FPGA chip. However, the FPGA chip is volatile, and the circuit logic configuration file deployed after the power is off will be lost, so that the client needs to re-deploy the circuit logic configuration file after power on. Therefore, in order to reduce the number of deployments of the client, the FPGA structure can further include a memory, which is 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 related functions ; Among them, the memory is non-volatile, even if the power is off, the circuit logic configuration file can still be saved, and after the power is turned on, it is only necessary to read the FPGA chip from the memory again, without the client re-deployment. The memory may have various forms, such as a non-volatile memory that can be re-erasable, such as flash memory, and a non-re-erasable memory, such as a fuse memory, which is not limited in this specification. Therefore, when the deployed circuit logic configuration file is located in the memory, the FPGA structure can update and deploy the memory based on the new version of the circuit logic configuration file, so that the deployed circuit logic configuration file in the memory is updated to the new version of the circuit logic configuration file.

The FPGA structure can generate an authentication result for the new version of the circuit logic configuration file that is updated and deployed, and the authentication result includes content related to the new version of the circuit logic configuration file. For example, the above-mentioned content related to the new version of the circuit logic configuration file may be the hash value of the new version of the circuit logic configuration file or a derived value of the hash value; and the client can generate the hash value or the hash value based on the new version of the circuit logic configuration file maintained by itself. If the client receives and generates the same hash value (or its derived value), the client can determine that the new version of the circuit logic file has been successfully deployed to the FPGA structure. Of course, the FPGA structure can sign the authentication result with the authentication root key and send it to the client, so that the client can determine that the received authentication result comes from the FPGA structure and has not been tampered with. Among them, the authentication root key used in the FPGA structure can be provided by the previously deployed circuit logic configuration file; or, when the new version of the circuit logic configuration file contains the new version of the authentication root key, the FPGA structure can be based on the new version of the authentication root key Sign the authentication result.

In addition to the hash value (or its derivative value) of the above-mentioned new version of the circuit logic file, the authentication result may also be related to other information. For example, after the FPGA structure deploys the new version of the circuit logic configuration file, the new version of the circuit logic configuration file can be loaded on the FPGA chip to form a new version of the key agreement module, and based on the new version of the key agreement module, the key agreement module can be negotiated with the client. If the new version configuration file deployment key is obtained, the other information mentioned above can be the hash value (or its derivative value) of the new version configuration file deployment key. When the new version key agreement module negotiates the deployment key of the new version of the configuration file with the client, the authentication root key recently deployed on the FPGA structure is used. The authentication root key can come from the previously deployed circuit logic configuration file or the new version of the circuit. Logical configuration file. Among them, when the foregoing deployed circuit logic configuration file and the new version of the circuit logic configuration file on the FPGA structure are not generated and deployed by the same user, the foregoing deployed circuit logic configuration file may be viewed by other users before being burned to the FPGA structure Or check, causing the authentication root key contained in the deployed circuit logic configuration file to be known by other users, which poses a certain security risk. Therefore, deploying a new version of the authentication root key through the new version of the circuit logic configuration file can effectively improve security. For example, the FPGA structure can respectively generate the hash value of the new version of the circuit logic configuration file and the hash value of the new version of the configuration file deployment key, and calculate the two hash values through such as sm3 algorithm or other algorithms. The calculation result can be used as the above-mentioned content related to the new version of the circuit logic configuration file; accordingly, based on the authentication result, the client can determine that the new version of the circuit logic configuration file is successfully deployed on the FPGA structure, and the client and the FPGA structure are successfully negotiated Get the new version of the configuration file deployment key.

When the FPGA structure derives the configuration file deployment key through the aforementioned secret value, the secret value can also be used to derive the business secret deployment key. The business secret deployment key can be used by the client to deploy the business key on the FPGA structure. The client can encrypt the business key with the business secret deployment key and send the encrypted business key to the FPGA structure, and the FPGA structure can decrypt the encrypted business key from the client based on the business secret deployment key. Thus, the service key obtained by decryption is applied to the formed trusted execution environment.

For example, the service key may include: the node private key, the node public key corresponding to the node private key is disclosed; where the node public key is used to encrypt the transaction, or the node public key is symmetrical with the transaction submitting party The key is commonly used to encrypt transactions through digital envelopes. Take the privacy transaction in the blockchain scenario as an example. Assuming that the transaction submitting party wants to keep the content of the submitted transaction confidential, the transaction submitting party can encrypt the transaction with the above-mentioned node public key and submit it to the blockchain node. The node can use the node's private key to decrypt in the FPGA structure to obtain the transaction content in plain text; or, the transaction submitting party can use a randomly generated (or obtained by other means) symmetric key to encrypt the transaction, and then pass through the above-mentioned node The public key encrypts the symmetric key, and submits the encrypted transaction and the encrypted symmetric key to the blockchain node, and the blockchain node can use the node private key in the FPGA structure to decrypt the encrypted symmetric key , And decrypt the encrypted transaction with the symmetric key obtained by decryption, so as to obtain the transaction content in plain text.

For another example, the business key may include: the business root key, the business root key or the derived key of the business root key is used to encrypt the private data generated in the trusted execution environment and store it to the blockchain node Maintained in the database. For example, after a blockchain node executes a transaction in the TEE formed by the FPGA structure, the above-mentioned private data with encryption requirements may be generated. For example, the private data may include the value of the contract state generated by the execution of the smart contract, then the FPGA structure can The private data is encrypted by the business root key or its derived key, and the encrypted private data is stored in the database maintained by the blockchain node. Correspondingly, when the private data needs to be read, by reading the encrypted private data into the FPGA structure, the FPGA structure can be decrypted based on the business root key or its derivative key, and the corresponding plaintext can be obtained. Private data, 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, etc.

Fig. 2 is a flowchart of another FPGA-based key agreement method provided by an exemplary embodiment. As shown in Figure 2, the method is applied to the FPGA structure and may include steps 202-206.

Step 202: The FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip to form a key agreement module on the FPGA chip; wherein the deployed circuit logic configuration file is used to use the FPGA structure Realized as a trusted execution environment on the blockchain node to which it belongs.

Step 204: The FPGA structure performs remote key agreement with the client through the key agreement module, so as to obtain the business secret deployment key at the FPGA structure and the client respectively.

By forming the key agreement module on the FPGA chip, the FPGA structure can directly implement remote key agreement with the client based on the key agreement module, instead of performing key agreement with the client through the blockchain node, which can avoid The business secret deployment key is learned by the blockchain node to ensure that the business secret deployment key is only maintained within the FPGA structure, and to avoid the leakage of the business secret deployment key and cause security risks.

The operation logic of the key agreement module is defined by the aforementioned circuit logic configuration file, so that the user can control the logic of the key agreement module through the circuit logic configuration file, including the key agreement method. Any key agreement method in the related technology can be configured in the above-mentioned key agreement module through a business secret configuration file, which is not limited in this specification.

For example, the key agreement process may include: the FPGA structure may generate first private information based on the key agreement module, and then generate first key agreement information based on the first private information, and send the first key agreement information to the client At the same time, the client can generate second private information, and then generate second key agreement information according to the second private information, and send the second key agreement information to the key agreement module in the FPGA structure. Then, the FPGA structure can calculate the first private information and the second key agreement information through the key agreement module to generate a secret value; at the same time, the client can calculate the second private information and the first key agreement information, To generate the same secret value. Then, the business secret deployment key can be the above-mentioned secret value, or derived from the above-mentioned secret value based on a key derivation function.

An authentication root key can be pre-deployed on the FPGA structure, and the authentication root key can be pre-placed in the FPGA structure, or the authentication root key can be deployed to the FPGA structure in an offline secure environment by the client or other objects, or The authentication root key can be remotely deployed into the FPGA structure by the client or other objects. The authentication root key is an asymmetric key. Then, in the process of remotely negotiating the above-mentioned business secret deployment key between the client and the FPGA structure, the FPGA structure can use the authentication root key to sign the first key agreement information sent by itself, and the client can verify the signature. Determine whether the received information actually comes from the FPGA structure and has not been tampered with during transmission, and the information that has not passed the signature verification will not be trusted and adopted by the client. Among them, the public key of the authentication root key can be managed by the authentication server and not made public, then the client can send the received information to the authentication server, and the authentication server can perform signature verification with the maintained public key; then, the authentication The server can provide the client with the verification result, the verification result is signed by the verification server, and the verification result contains the certificate of the verification server or the public key of the verification server can be made public, so that the client can verify the signature to determine the validity of the verification result Sex. Alternatively, the public key of the authentication root key can be made public, so that the client can perform signature verification on the information from the FPGA structure based on the public key without going through the authentication server, which can reduce the interactive links in the signature verification process. Thereby improving the efficiency of verification and reducing the security risks caused by more interactive links.

The public key or preset certificate corresponding to the client can be deployed on the FPGA structure. The client can sign the aforementioned second key agreement information and then send it to the FPGA structure, so that the FPGA structure can perform signature verification on the received second key agreement information, and verify that the signature is based on the second key. Negotiation information is one of the conditions for generating secret values. Wherein, the public key or certificate corresponding to the client can be deployed in the FPGA structure by the aforementioned circuit logic configuration file.

Step 206: The FPGA structure decrypts the encrypted service key from the client based on the service secret deployment key, and the decrypted service key is applied to the trusted execution environment.

The FPGA structure can form a decryption module on the FPGA chip based on the deployed circuit logic configuration file. The decryption module is used to decrypt the encrypted business secret deployment key according to the business secret deployment key, so that only the business secret deployment key is known Only those users can deploy service keys for the FPGA structure or update the deployed service keys to ensure that the deployment operation or update operation implemented for the service key is a credible operation.

When the FPGA structure derives the business secret deployment key through the aforementioned secret value, the secret value can also be used to derive the configuration file deployment key. The configuration file deployment key is used to deploy the circuit logic configuration file on the FPGA structure. The FPGA structure can receive the encrypted new version of the circuit logic configuration file obtained after encryption with the configuration file deployment key, and the decryption module formed on the FPGA chip based on the deployed circuit logic configuration file and the aforementioned configuration file deployment key, After the above-mentioned encryption, the new version of the circuit logic configuration file is decrypted to obtain the new version of the circuit logic configuration file. Based on the above process, only users who know the deployment key of the configuration file can update the deployed circuit logic configuration file on the FPGA structure to ensure that the update operation implemented on the deployed circuit logic configuration file is available. Letter update operation.

Fig. 3 is a schematic structural diagram of a blockchain node provided by an exemplary embodiment. Based on the technical solution in this specification, an FPGA structure can be added to the blockchain node to implement hardware TEE. For example, the FPGA structure can be an FPGA board as shown in FIG. 3. The FPGA board can be connected to the blockchain node through the PCIE interface to realize the data interaction between the FPGA board and the blockchain node. FPGA boards can include FPGA chips, Flash (flash memory) chips, and dense tube chips; of course, in addition to FPGA chips in some embodiments, they may only include parts of the remaining Flash chips and dense tube chips. , Or may contain more structures, here are just examples.

In the initial stage, no user-defined logic is programmed on the FPGA chip, which is equivalent to the FPGA chip in a blank state. Users can burn circuit logic configuration files on the FPGA chip to form corresponding functions or logic on the FPGA chip. When programming the circuit logic configuration file for the first time, the FPGA board does not have the capability of security protection, so it usually needs to provide an external security environment. For example, users can implement the programming of the circuit logic configuration file in an offline environment to achieve physical security isolation. Instead of implementing remote programming online.

For the functions or logic required by the user, the corresponding logic code can be formed through the FPGA hardware language, and then the logic code can be mirrored to obtain the above-mentioned circuit logic configuration file. Before programming to the FPGA board, the user can check the above-mentioned logic code. Especially, when multiple users are involved at the same time, multiple users can check the above logic code separately to ensure that the FPGA board can finally meet the needs of all users and prevent security risks, logic errors, fraud and other abnormalities. problem.

After confirming that the code is correct, the user can burn the circuit logic configuration file to the FPGA board in the above-mentioned offline environment. Specifically, the circuit logic configuration file is transferred from the blockchain node to the FPGA board, and then deployed to the Flash chip as shown in Figure 3, so that even if the FPGA board is powered off, the Flash chip can still save the above-mentioned circuit logic. Configuration file.

Fig. 4 is a schematic diagram of forming a functional module on an FPGA chip provided by an exemplary embodiment. By loading the circuit logic configuration file deployed in the Flash chip to the FPGA chip, the hardware logic unit contained in the FPGA chip can be configured to form corresponding functional modules on the FPGA chip. For example, the formed functional modules can include such The key agreement module, decryption and signature verification module, encryption and decryption module, plaintext calculation module, etc. shown in Figure 4. At the same time, the circuit logic configuration file can also be used to transmit the information that needs to be stored to the FPGA board. For example, the preset certificate can be stored on the FPGA chip, and the authentication root key can be stored in the secret tube chip (the authentication root key can also be Stored on the FPGA chip) and so on.

Based on the key agreement module formed on the FPGA chip and the authentication root key deployed on the FPGA board, the FPGA board can realize remote key agreement with the user. The key agreement process can use related technologies. Any algorithm or standard can be implemented, and this specification does not limit it. For example, the key agreement process can include: the user can generate a key Ka-1 at the local client, the key agreement module can generate a key Kb-1 locally, and the client can generate a key Kb-1 based on the key Ka- 1 Calculate the key agreement information Ka-2, the key agreement module can calculate the key agreement information Kb-2 based on the key Kb-1, and then the client sends the key agreement information Ka-2 to the key agreement module, The key agreement module sends the key agreement information Kb-2 to the client, so that the client can generate a secret value based on the key Ka-1 and the key agreement information Kb-2, and the key agreement module can be based on the key Kb -1 generates the same secret value as the key agreement information Ka-2, and finally the client and the key agreement module respectively derive the same configuration file deployment key from the same secret value based on the key derivation function, and the configuration file deployment The key can be stored in the FPGA chip or the secret management chip. In the above process, although the key agreement information Ka-2 and key agreement information Kb-2 are transmitted between the client and the key agreement module via the blockchain node, the key Ka-1 is controlled by the client , The key Kb-1 is controlled by the key agreement module, so it can ensure that the blockchain node cannot know the final secret value and the configuration file deployment key, so as to avoid possible security risks.

In addition to the configuration file deployment key, the secret value is also used to derive the business secret deployment key; for example, the secret value can be derived as a 32-bit value, the first 16 bits can be used as the configuration file deployment key, and the last 16 bits can be used as the business secret deployment Key. The user can deploy the service key to the FPGA board through the service secret deployment key. For example, the service key may include the node private key and the service root key. For example, the user can use the business secret deployment key on the client to sign, encrypt the node private key or the business root key, and send it to the FPGA board, so that after the FPGA board is decrypted and verified through the decryption verification module, Deploy the obtained node private key or service root key.

Based on the deployed node key, service root key, encryption and decryption module and plaintext calculation module on the FPGA chip, the FPGA board can be implemented as a TEE on the blockchain node to meet privacy requirements. For example, when a blockchain node receives a transaction, if the transaction is a plaintext transaction, the blockchain node can directly process the plaintext transaction, if the transaction is a private transaction, the blockchain node transmits the private transaction to the FPGA The board is processed.

The transaction content of a plaintext transaction is in plaintext form, and the contract status generated after the transaction is executed is also stored in plaintext form. The transaction content of a private transaction is in the form of cipher text, which is obtained by encrypting the content of the transaction in plain text by the transaction initiator, and the contract state generated after the transaction is executed needs to be stored in the form of cipher text to ensure the protection of transaction privacy. For example, the transaction initiator can generate a symmetric key randomly or based on other methods. Similarly, the business public key corresponding to the above-mentioned business private key is disclosed, then the transaction initiator can perform transaction content in plaintext based on the symmetric key and the business public key. Digital Envelope Encryption: The transaction initiator encrypts the plaintext transaction content with a symmetric key, and encrypts the symmetric key with the business public key. The two parts obtained are included in the above-mentioned private transaction; in other words, the private transaction includes Two parts of content: the content of the transaction in plaintext encrypted with a symmetric key, and the symmetric key encrypted with the business public key.

Therefore, after the FPGA board receives the private transaction from the blockchain node, the encryption and decryption module can use the business private key to decrypt the symmetric key encrypted with the business public key to obtain the symmetric key, and then the encryption and decryption module The symmetric key is used to decrypt the plaintext transaction content encrypted with the symmetric key to obtain the plaintext transaction content. Private transactions can be used to deploy smart contracts, then the data field of the plaintext transaction content can contain the contract code of the smart contract to be deployed; or, the privacy transaction can be used to call the smart contract, then the to field of the plaintext transaction content can contain the called The contract address of the smart contract, and the FPGA board can retrieve the corresponding contract code based on the contract address.

The plaintext calculation module formed on the FPGA chip is used to implement virtual machine logic in related technologies, that is, the plaintext calculation module is equivalent to the "hardware virtual machine" on the FPGA board. Therefore, after the contract code is determined based on the foregoing plaintext transaction content, the contract code can be passed into the plaintext calculation module, so that the plaintext calculation module executes the contract code. After the execution is completed, the state of the contract involved in the contract code may be updated. If the contract state needs to be stored outside the FPGA chip, the encryption and decryption module can encrypt the updated contract state through the aforementioned business root key or its derivative key, and store the encrypted contract state to ensure privacy The transaction-related data is only in the plaintext state in the FPGA chip and in the ciphertext state outside the FPGA chip, so as to ensure the security of the data.

For some reasons, the user may want to update the version of the circuit logic configuration file deployed on the FPGA board. For example, the authentication root key contained in the circuit logic configuration file may be known by risky users, or the user wants to update the version on the FPGA board. The deployed functional modules are upgraded, etc. This manual does not limit this. In order to facilitate the distinction, the circuit logic configuration file that has been deployed in the above process can be referred to as the old version of the circuit logic configuration file, and the circuit logic configuration file that needs to be deployed is referred to as the new version of the circuit logic configuration file.

Similar to the old version of the circuit logic configuration file, the user can generate a new version of the circuit logic configuration file through the process of writing code and mirroring. Further, the user can sign the new version of the circuit logic configuration file with his own private key, and then encrypt the signed new version of the circuit logic configuration file with the configuration file deployment key negotiated above to obtain the encrypted new version of the circuit Logical configuration file. In some cases, there may be multiple users at the same time, so the old version of the circuit logic configuration file needs to deploy the preset certificates corresponding to these users to the FPGA board, and these users need to use their own private keys to pair the new version of the circuit. Sign the logical configuration file.

The user can remotely send the encrypted new version of the circuit logic configuration file to the blockchain node through the client, and the blockchain node will further transfer it to the FPGA board. Fig. 5 is a schematic diagram of newly updateable FPGA board provided by an exemplary embodiment. As shown in Figure 5, the decryption verification module formed on the FPGA chip in the foregoing process is located on the transmission path between the PCIE interface and the Flash chip, so that the new version of the circuit logic configuration file after encryption must first go through the decryption verification module. After processing, it can be transferred to the Flash chip to achieve a credible update, and the Flash chip cannot be updated directly without bypassing the decryption and verification process.

After the decryption verification module receives the encrypted new version of the circuit logic configuration file, it first decrypts it with the configuration file deployment key deployed on the FPGA board. If the decryption is successful, the decryption verification module is further based on the preset certificate deployed on the FPGA chip , To perform signature verification on the decrypted new version of the circuit logic configuration file. If the decryption fails or the signature verification fails, it means that the received file is not from the above-mentioned user or has been tampered with, and the decryption and signature verification module will trigger the termination of the update operation; and if the decryption is successful and the signature verification is passed, you can It is determined that the obtained new version of the circuit logic configuration file is from the aforementioned user and has not been tampered with during the transmission process. The new version of the circuit logic configuration file can be further transmitted to the Flash chip to update and deploy the old version of the circuit logic configuration file in the Flash chip.

After the new version of the circuit logic configuration file is loaded into the FPGA chip, the above-mentioned key agreement module, decryption and verification module can also be formed on the FPGA chip, and the pre-set certificate and authentication can be stored in the FPGA chip. Root key and other information. Among them, the formed key agreement module, decryption verification module, etc., the implemented functional logic can be changed and upgraded, and the information stored in the deployed preset certificate, authentication root key and other information may also be different from the information before the update . Then, the FPGA board can remotely negotiate with the user to obtain a new configuration file deployment key based on the updated key agreement module, authentication root key, etc., and the configuration file deployment key can be used for the next renewal Update process. Similarly, a reliable update operation for FPGA boards can be continuously implemented accordingly.

After completing the update deployment, the FPGA board can generate certification results for the new version of the circuit logic configuration file. For example, the above-mentioned key agreement module can calculate the hash value of the new version of the circuit logic configuration file and the hash value of the configuration file deployment key negotiated based on the new version of the circuit logic configuration file through an algorithm such as sm3 or other algorithms. The calculation result can be used as the above-mentioned authentication result, and the key agreement module sends the authentication result to the user. Correspondingly, the user can verify the authentication result on the client based on the maintained new version of the circuit logic configuration file and the configuration file deployment key negotiated accordingly. If the verification is successful, it indicates that the new version of the circuit logic configuration file is successful on the FPGA board. Deployed, and the user and the FPGA board successfully negotiated accordingly to obtain a consistent configuration file deployment key, thereby confirming the successful completion of the circuit logic configuration file update deployment.

Fig. 6 is a schematic structural diagram of an FPGA-based key agreement device provided by an exemplary embodiment. Please refer to FIG. 6, in the software implementation, the FPGA-based key agreement device may include: a loading unit 601, which enables the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip, so that the FPGA chip A key agreement module is formed; the negotiation unit 602 enables the FPGA structure to perform remote key agreement with the client through the key agreement module to obtain configuration file deployment keys at the FPGA structure and the client respectively The first decryption unit 603 enables the FPGA structure to decrypt the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key; the update unit 604 enables the FPGA structure to be based on the obtained new version of the circuit The logic configuration file updates the deployed circuit logic configuration file, so that the FPGA structure is implemented as a trusted execution environment on the blockchain node to which it belongs.

Optionally, the negotiation unit 602 is specifically configured to: enable the FPGA structure to send first key agreement information to the client through the key agreement module, and receive a second key agreement from the client Information; wherein, the first key agreement information is generated by the FPGA structure based on the first private information generated by the key agreement module, and the second key agreement information is generated by the client based on itself Second private information;

Enabling the FPGA structure to calculate the first private information and the second key agreement information through the key agreement module to generate a secret value and derive the configuration file deployment key based on the secret value; Wherein, the second private information and the first key agreement information are used by the client to calculate and generate the secret value to derive the configuration file deployment key.

Optionally, the first key agreement information is signed by an authentication root key deployed on the FPGA structure.

Optionally, the public key corresponding to the authentication root key is managed by the authentication server, or the public key corresponding to the authentication root key is made public.

Optionally, it further includes: a signature verification unit 605 for enabling the FPGA structure to perform signature verification on the second key agreement information, wherein a preset certificate corresponding to the client has been deployed on the FPGA structure; wherein, The FPGA structure generates the secret value based on the second key agreement information when the signature verification is successful.

Optionally, the secret value is also used to derive a business secret deployment key; the device further includes: a second decryption unit 606, which enables the FPGA structure to encrypt data from the client based on the business secret deployment key After the service key is decrypted, the service key obtained by the decryption is applied to the trusted execution environment.

Optionally, the FPGA structure includes a memory other than the FPGA chip, and both the deployed circuit logic configuration file and the new version of the circuit logic configuration file are deployed on the memory.

Fig. 7 is a schematic structural diagram of another FPGA-based key agreement device provided by an exemplary embodiment. Referring to FIG. 7, in a software implementation, the FPGA-based key agreement device may include: a loading unit 701, which enables the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip, so as to load the FPGA chip on the FPGA chip. A key agreement module is formed; wherein the deployed circuit logic configuration file is used to implement the FPGA structure as a trusted execution environment on the blockchain node to which it belongs; the negotiation unit 702 makes the FPGA structure pass all The key agreement module performs remote key agreement with the client to obtain the business secret deployment key at the FPGA structure and the client respectively; the decryption unit 703 makes the FPGA structure based on the business secret deployment key The key decrypts the encrypted service key from the client, and the decrypted service key is applied to the trusted execution environment.

Optionally, the negotiation unit 702 is specifically configured to: enable the FPGA structure to send first key agreement information to the client through the key agreement module, and receive a second key agreement from the client Information; wherein, the first key agreement information is generated by the FPGA structure based on the first private information generated by the key agreement module, and the second key agreement information is generated by the client based on itself The second private information is generated; the FPGA structure is used to calculate the first private information and the second key agreement information through the key agreement module to generate a secret value and to derive a secret value based on the secret value. The configuration file deployment key; wherein the second private information and the first key agreement information are used by the client to calculate and generate the secret value to derive the business secret deployment key.

Optionally, it further includes: a signature verification unit 704 for enabling the FPGA structure to perform signature verification on the second key agreement information, wherein a preset certificate corresponding to the client has been deployed on the FPGA structure; wherein, The FPGA structure generates the secret value based on the second key agreement information when the signature verification is successful.

Optionally, the secret value is also used to derive a configuration file deployment key; the device further includes: an update unit 705 that enables the FPGA structure to perform an encrypted new version from the client terminal based on the configuration file deployment key The circuit logic configuration file is decrypted, and the deployed circuit logic configuration file is updated based on the obtained new version of the circuit logic configuration file.

Optionally, the service key includes: a node private key, and the node public key corresponding to the node private key is disclosed; wherein the node public key is used to encrypt transactions; or, the node public key The symmetric key provided by the party submitting the transaction is used together to encrypt the transaction by means of a digital envelope.

Optionally, the service key includes: a service root key, and the service root key or a derived key of the service root key is used to encrypt private data generated in the trusted execution environment storage.

Optionally, the FPGA structure includes a memory outside the FPGA chip, and the deployed circuit logic configuration file is deployed on the memory.

The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control A console, a tablet computer, a wearable device, or a combination of any of these devices.

In a typical configuration, the computer includes one or more processors (CPU), input/output interfaces, network interfaces, and memory.

The memory may include non-permanent 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 computer readable media.

Computer-readable media include permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. The information can be computer-readable instructions, data structures, program modules, 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, CD-ROM, digital versatile disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or they also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more associated listed items.

It should be understood that, although the terms first, second, third, etc. may be used to describe various information in one or more embodiments of this specification, the information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determination".

The foregoing descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. All within the spirit and principle of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. made should be included in the protection scope of one or more embodiments of this specification.

Claims

An FPGA-based key agreement method, including:

The FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip to form a key agreement module on the FPGA chip;

The FPGA structure performs remote key negotiation with the client through the key agreement module, so as to obtain configuration file deployment keys at the FPGA structure and the client respectively;

The FPGA structure decrypts the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key, and updates the deployed circuit logic configuration file based on the obtained new version of the circuit logic configuration file, so that The FPGA structure is implemented as a trusted execution environment on the blockchain node to which it belongs.
The method according to claim 1, wherein the FPGA structure performs remote key agreement with the client through the key agreement module, comprising:

The FPGA structure sends first key agreement information to the client through the key agreement module, and receives second key agreement information from the client; wherein, the first key agreement information is provided by the client The FPGA structure is generated based on the first private information generated by the key agreement module, and the second key agreement information is generated by the client based on the second private information generated by itself;

The FPGA structure calculates the first private information and the second key agreement information through the key agreement module to generate a secret value and derive the configuration file deployment key based on the secret value; wherein The second private information and the first key agreement information are used by the client to calculate and generate the secret value to derive the configuration file deployment key.
According to the method of claim 2, the first key agreement information is signed by an authentication root key deployed on the FPGA structure.
According to the method of claim 3, the public key corresponding to the authentication root key is managed by the authentication server, or the public key corresponding to the authentication root key is disclosed.
The method according to claim 2, further comprising:

The FPGA structure performs signature verification on the second key agreement information, wherein a preset certificate corresponding to the client has been deployed on the FPGA structure;

Wherein, the FPGA structure generates the secret value based on the second key agreement information when the signature verification is successful.
The method according to claim 2, wherein the secret value is also used to derive a business secret deployment key; the method further comprises:

The FPGA structure decrypts the encrypted service key from the client based on the service secret deployment key, and the decrypted service key is applied to the trusted execution environment.
The method according to claim 1, wherein the FPGA structure includes a memory outside the FPGA chip, and the deployed circuit logic configuration file and the new version of the circuit logic configuration file are both deployed on the memory.
An FPGA-based key agreement method, including:

The FPGA structure loads the deployed circuit logic configuration file onto the FPGA chip to form a key agreement module on the FPGA chip; wherein the deployed circuit logic configuration file is used to implement the FPGA structure as belonging Trusted execution environment on the blockchain node of

The FPGA structure performs remote key agreement with the client through the key agreement module, so as to obtain the business secret deployment key at the FPGA structure and the client respectively;

The FPGA structure decrypts the encrypted service key from the client based on the service secret deployment key, and the decrypted service key is applied to the trusted execution environment.
The method according to claim 8, wherein the FPGA structure performs remote key agreement with the client through the key agreement module, comprising:

The FPGA structure sends first key agreement information to the client through the key agreement module, and receives second key agreement information from the client; wherein, the first key agreement information is provided by the client The FPGA structure is generated based on the first private information generated by the key agreement module, and the second key agreement information is generated by the client based on the second private information generated by itself;

The FPGA structure calculates the first private information and the second key agreement information through the key agreement module to generate a secret value and derive the configuration file deployment key based on the secret value; wherein , The second private information and the first key agreement information are used by the client to calculate and generate the secret value to derive the business secret deployment key.
According to the method of claim 9, the first key agreement information is signed by an authentication root key deployed on the FPGA structure.
According to the method of claim 10, the public key corresponding to the authentication root key is managed by the authentication server, or the public key corresponding to the authentication root key is disclosed.
The method according to claim 9, further comprising:

The FPGA structure performs signature verification on the second key agreement information, wherein a preset certificate corresponding to the client has been deployed on the FPGA structure;

Wherein, the FPGA structure generates the secret value based on the second key agreement information when the signature verification is successful.
The method according to claim 9, wherein the secret value is also used to derive a configuration file deployment key; the method further comprises:

The FPGA structure decrypts the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key, and updates the deployed circuit logic configuration file based on the obtained new version of the circuit logic configuration file.
The method according to claim 8, wherein the service key comprises: a node private key, and the node public key corresponding to the node private key is disclosed;

Wherein, the node public key is used to encrypt the transaction; or, the node public key and the symmetric key provided by the transaction submitting party are jointly used to encrypt the transaction through a digital envelope.
The method according to claim 8, wherein the service key comprises: a service root key, and the service root key or a derivative key of the service root key is used to verify data generated in the trusted execution environment Private data is stored after being encrypted.
The method according to claim 8, wherein the FPGA structure includes a memory outside the FPGA chip, and the deployed circuit logic configuration file is deployed on the memory.
An FPGA-based key agreement device, including:

A loading unit, enabling the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip to form a key agreement module on the FPGA chip;

A negotiation unit, enabling the FPGA structure to perform remote key negotiation with the client through the key agreement module, so as to obtain configuration file deployment keys at the FPGA structure and the client respectively;

A decryption unit, enabling the FPGA structure to decrypt the encrypted new version of the circuit logic configuration file from the client based on the configuration file deployment key;

The update unit causes the FPGA structure to update the deployed circuit logic configuration file based on the obtained new version of the circuit logic configuration file, so that the FPGA structure is implemented as a trusted execution environment on the blockchain node to which it belongs.
An FPGA-based key agreement device, including:

The loading unit causes the FPGA structure to load the deployed circuit logic configuration file onto the FPGA chip to form a key agreement module on the FPGA chip; wherein the deployed circuit logic configuration file is used to load the FPGA chip The structure is implemented as a trusted execution environment on the blockchain node to which it belongs;

A negotiation unit, enabling the FPGA structure to perform remote key negotiation with the client through the key agreement module, so as to obtain the business secret deployment key at the FPGA structure and the client respectively;

The decryption unit causes the FPGA structure to decrypt the encrypted service key from the client based on the service secret deployment key, and the decrypted service key is applied to the trusted execution environment.
An electronic device including:

processor;

A memory for storing processor executable instructions;

Wherein, the processor implements the method according to any one of claims 1-16 by running the executable instruction.
A computer-readable storage medium with computer instructions stored thereon, which, when executed by a processor, implements the steps of the method according to any one of claims 1-16.