CN110717203B

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

Info

Publication number: CN110717203B
Application number: CN201910914116.9A
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-04-27
Anticipated expiration: 2039-09-25
Also published as: CN110717203A; WO2021057180A1

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: the FPGA structure loads the deployed circuit logic configuration file onto an FPGA chip to form an encryption and decryption module on the FPGA chip; the FPGA structure transmits the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption to obtain plaintext data; the FPGA structure processes the plaintext data through a computing module on the FPGA chip, and the computing module is formed by the FPGA structure on the FPGA chip based on the deployed circuit logic configuration file; and the FPGA structure encrypts a plaintext result generated by the calculation module through the encryption and decryption module to obtain a ciphertext result.

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:

the FPGA structure loads the deployed circuit logic configuration file onto an FPGA chip to form an encryption and decryption module on the FPGA chip;

the FPGA structure transmits the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption to obtain plaintext data;

the FPGA structure processes the plaintext data through a computing module on the FPGA chip, and the computing module is formed by the FPGA structure on the FPGA chip based on the deployed circuit logic configuration file;

and the FPGA structure encrypts a plaintext result generated by the calculation module through the encryption and decryption module to obtain a ciphertext result.

According to a second 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 loading unit is used for loading the deployed circuit logic configuration file to an FPGA chip by the FPGA structure so as to form an encryption and decryption module on the FPGA chip;

the decryption unit is used for enabling the FPGA structure to transmit the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption so as to obtain plaintext data;

the processing unit is used for enabling the FPGA structure to process the plaintext data through a calculation module on the FPGA chip, and the calculation module is formed by the FPGA structure on the FPGA chip based on the deployed circuit logic configuration file;

and the encryption unit enables the FPGA structure to encrypt the plaintext result generated by the calculation module through the encryption and decryption module so as to obtain a ciphertext result.

According to a third aspect of one or more embodiments of the present specification, there is provided an electronic apparatus including:

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 fourth aspect of one or more embodiments of the present description, a computer-readable storage medium is presented, having stored thereon computer instructions which, when executed by a processor, implement the steps of the method according to the first 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 schematic structural diagram of a blockchain node according to an exemplary embodiment.

Fig. 3 is a schematic diagram of forming a functional module on an FPGA chip according to an exemplary embodiment.

Fig. 4 is a schematic diagram of performing a new update on an FPGA board according to an exemplary embodiment.

Fig. 5 is a block diagram of an apparatus for implementing a privacy blockchain based on an FPGA according to an exemplary 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.

One of the bases for implementing TEE technology includes encryption and decryption mechanisms to ensure that data is only in plaintext form inside the TEE and in ciphertext form outside the TEE. However, the encryption and decryption mechanisms used in the related art are all provided by default, and a user cannot control the encryption and decryption mechanisms used, and cannot ensure that the security isolation for the TEE can meet the actual requirements of the user.

The following describes a key agreement method based on FPGA provided in this specification with reference to an embodiment, 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 FPGA structure may include the following steps:

step 102, the FPGA structure loads the deployed circuit logic configuration file onto an FPGA chip to form an encryption and decryption module on the FPGA chip.

The FPGA chip comprises a plurality of editable hardware logic units, and the hardware logic units can be realized as corresponding functional modules after being configured by a circuit logic configuration file so as to realize corresponding logic functions. Specifically, the circuit logic configuration file may be burned into the FPGA fabric based on the form of the bit stream. For example, the encryption and decryption module is formed by a deployed circuit logic configuration file, and by further deploying a functional module for implementing logic such as a virtual machine, the FPGA structure may be configured as a hardware TEE on a blockchain node. Since the functional modules are completely configured by the circuit logic configuration file, the information of all aspects such as logic and the like realized by the configured functional modules can be determined by checking the circuit logic configuration file, and the functional modules can be ensured to be formed and operated according to the requirements of complete users.

After the user generates the circuit logic configuration file, if the circuit logic configuration file is located at the site of the FPGA structure, the circuit logic configuration file may be locally deployed to the FPGA structure, for example, the deployment operation may be performed in an offline environment to ensure security. Or, in a case that the FPGA structure is in an online environment, a user may remotely deploy the circuit logic configuration file to the FPGA structure, and the remote deployment process will be described below with reference to update deployment of the circuit logic configuration file, which is not described herein for the sake of detail.

And 104, the FPGA structure transmits the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption to obtain plaintext data.

The FPGA structure can configure itself as a TEE of a block chain node based on the circuit logic configuration file. Data with privacy protection requirements are stored on the block chain nodes in an encryption mode, so that the safety problem cannot be caused even if data leakage occurs on the block chain nodes, and the data stored in the encryption mode can be decrypted in the encryption and decryption module only after entering the FPGA structure, so that corresponding plaintext data can be obtained.

The encryption and decryption mechanisms referred to in this specification may be applied to any type of data without relevant limitations. For example, the above-mentioned ciphertext data may include at least one of: the block chain node receives the private transaction, the ciphertext state stored by the block chain link point, the ciphertext contract code stored by the block chain link point, the ciphertext receipt stored by the block chain link point and the like. For the privacy transaction received by the block chain node, the privacy transaction is obtained by encrypting the plaintext transaction content by the transaction initiator, so that the plaintext transaction content can be ensured not to be leaked. For the ciphertext state stored by the block chain link point, the ciphertext state can be obtained by encrypting the contract state of the plaintext by an encryption and decryption module on the FPGA structure. For the ciphertext contract codes stored in the block chain nodes, the ciphertext contract codes can be obtained by encrypting the plaintext contract codes through an encryption and decryption module on the FPGA structure. For the ciphertext receipts stored by the block chain nodes, the ciphertext receipts can be obtained by encrypting the plaintext transaction receipts generated after the transaction is executed by an encryption and decryption module on the FPGA structure.

As described above, the ciphertext data may exist in various types. Taking the private transaction that the ciphertext data is received as the block link point as an example: the FPGA structure can maintain a node private key, and a node public key corresponding to the node private key is published, so that a transaction initiator can encrypt plaintext transaction contents through the node public key to obtain the privacy transaction, after the privacy transaction is submitted to a blockchain network by the transaction initiator, the blockchain nodes can obtain the privacy transaction and transmit the privacy transaction to the FPGA structure, an encryption and decryption module on the FPGA structure decrypts the transaction contents based on the node private key, and the obtained plaintext data is the corresponding plaintext transaction contents. Or, the transaction initiator may maintain a symmetric key (for example, may be used for a long time, or may randomly generate for each transaction), and may encrypt the plaintext transaction content in a digital envelope manner based on the symmetric key and the node public key, for example, encrypt the plaintext transaction content by using the symmetric key to obtain ciphertext transaction content, and encrypt the symmetric key by using the node public key to obtain an encrypted symmetric key, so that the privacy transaction may include the ciphertext transaction content and the encrypted symmetric key; correspondingly, after the private transaction is submitted to the blockchain network by the transaction initiator, the blockchain nodes can acquire the private transaction and transmit the private transaction to the FPGA structure, and the encryption and decryption module on the FPGA structure firstly decrypts the encrypted symmetric key contained in the private transaction based on the node private key to obtain the symmetric key, and then decrypts the ciphertext transaction content based on the symmetric key to obtain the plaintext transaction content.

For another example, the ciphertext data may include a ciphertext state, a ciphertext contract code, and/or a ciphertext receipt stored at a block link point. For ciphertext contract codes, when a user initiates a transaction for contract deployment to a block chain network for the first time, if the privacy transaction is deployed, the privacy transaction is encrypted in a manner such as described above to protect the contract codes included in the data field of the privacy transaction, and the FPGA structure can decrypt the privacy transaction through the encryption and decryption module to obtain corresponding plaintext contract codes, and then the encryption and decryption module encrypts the plaintext contract codes based on a service root key or a derived key of the service root key maintained on the FPGA structure to obtain corresponding ciphertext contract codes, and transmits the ciphertext contract codes to block chain nodes for storage. For the ciphertext state and the ciphertext receipt, after a plaintext contract code is executed by a following calculation module formed on an FPGA chip, the plaintext contract state and the plaintext transaction receipt can be generated, and the plaintext contract state or the plaintext transaction receipt is encrypted by an encryption and decryption module based on a service root key or a derivative key of the service root key which is structurally maintained by the FPGA chip, so that the corresponding ciphertext state or the ciphertext receipt is obtained. Correspondingly, the FPGA structure can obtain the ciphertext contract code, the ciphertext state or the ciphertext receipt from the block chain node, and the encryption and decryption module decrypts the ciphertext contract code, the ciphertext state or the ciphertext receipt based on the service root key or the derived key of the service root key maintained on the FPGA structure to obtain the corresponding plaintext contract code, the plaintext contract state or the plaintext transaction receipt and the like.

The user can perform remote key negotiation with the FPGA structure through the client to deploy the node key, the service root key and the like to the FPGA structure. The FPGA structure can form a key negotiation module on the FPGA chip through the deployed circuit logic configuration file, and key negotiation is realized between the key negotiation module and the client based on the key negotiation module. The client may include an electronic device used by a user, or the client may include a Key Management Service (KMS). Any remote key agreement scheme in the related art can be adopted between the client and the FPGA structure, which is not limited in this specification. For example, the remote negotiation process may employ, for example, SM2 or other algorithms, which the present specification is not limited to. The client and the FPGA structure need to implement at least one information interaction in the negotiation process, for example: the client can locally generate a key Ka-1, the FPGA structure can locally generate a key Kb-1, the client can calculate to obtain key negotiation information Ka-2 based on the key Ka-1, the FPGA structure can calculate to obtain key negotiation information Kb-2 based on the key Kb-1, then the client sends the key negotiation information Ka-2 to the FPGA structure, and the FPGA structure sends the key negotiation information Kb-2 to the client, so that the client can generate a secret value (or called as a master key) based on the key Ka-1 and the key negotiation information Kb-2, and the FPGA structure can generate the same secret value based on the key Kb-1 and the key negotiation information Ka-2. Then, the secret value can be used as a service secret deployment key; or, the service secret deployment Key may be derived from the secret value by the client and the FPGA structure through a Key Derivation Function (KDF for short).

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. Then, in the process of the client and the FPGA structure negotiating the service secret deployment key remotely, the FPGA structure may sign the information (such as the key negotiation information Kb-2 described above) sent by itself by using the authentication root key, and the client may determine whether the received information really comes from the FPGA structure by verifying the signature and does not tamper in the transmission process, and the information that does not pass the signature verification will not be trusted and adopted by the client. The public key of the authentication root key can be managed by the authentication server and is not public, so that the client side can send the received information to the authentication server, and the authentication server performs signature verification through the maintained public key; the authentication server may then provide the client with a verification result, which is signed by the authentication server and which contains the certificate of the authentication server or whose public key may be published, so that the client can verify the signature to determine the validity of the verification result. Or the public key of the authentication root key can be published, so that the client can perform signature verification on the information from the FPGA structure based on the public key without passing through an authentication server, and thus, the interaction links in the signature verification process can be reduced, the verification efficiency is improved, and the security risk caused by more interaction links is reduced.

The client can encrypt the node private key, the service root key and the like based on the service secret deployment key and transmit the encrypted node private key, the service root key and the like to the FPGA structure, and the FPGA structure can decrypt the encrypted node private key or the service root key based on the service secret deployment key to obtain the corresponding node private key or the service root key and deploy the node private key, the service root key and the like.

And 106, processing the plaintext data by the FPGA structure through a calculation module on the FPGA chip, wherein the calculation module is formed on the FPGA chip by the FPGA structure based on the deployed circuit logic configuration file.

Based on the encryption and decryption module and the calculation module, the calculation module can directly process plaintext data, namely plaintext calculation is adopted. Compared with security processing modes such as homomorphic calculation in the related art, the data processing efficiency can be remarkably improved through plaintext calculation.

And step 108, the FPGA structure encrypts the plaintext result generated by the calculation module through the encryption and decryption module to obtain a ciphertext result.

The plaintext result is encrypted through encryption and decryption to obtain a corresponding ciphertext result, so that data (such as the plaintext result) can be ensured not to leave the FPGA chip in a plaintext form, a block chain node can only obtain the ciphertext result, and leakage of the plaintext result is avoided.

When encrypting a plaintext result, such as the contract code, the plaintext contract status, the plaintext transaction receipt, etc., the encryption/decryption module may implement encryption by using a service root key or a derivative key thereof maintained on the FPGA structure. For some data which needs to be fed back to the user, such as transaction receipts, etc., when the aforementioned private transaction is encrypted in a digital envelope manner, the encryption and decryption module can encrypt the data by using a symmetric key used by the digital envelope for returning to the user, so that it can be ensured that only the user as a transaction initiator can decrypt the data to obtain the required transaction receipts, etc., and other users can only obtain the encrypted data and cannot decrypt the data even if the data is stolen during transmission. The encrypted data can be directly sent to the user through the block link points, or the encrypted data can be added into the transaction log, so that the user can monitor the transaction log and obtain the encrypted data through a callback mechanism.

The FPGA fabric may transmit the ciphertext result to the block chaining point for storage at the block chaining point, such as described above for the ciphertext contract code, the ciphertext state, the ciphertext receipt, etc. stored at the block chaining node. Alternatively, the FPGA fabric may also store the ciphertext result locally to reduce data interaction with the block chain nodes. For example, a memory module may be formed on an FPGA chip; for another example, the FPGA structure may include a storage module externally connected to the FPGA chip, and may be configured to store the ciphertext result.

And a user can update the version of the circuit logic configuration file deployed on the FPGA structure. For example, the FPGA structure may receive the encrypted new circuit logic configuration file from the client, and decrypt the encrypted new circuit logic configuration file, so as to perform update deployment based on the decrypted new circuit logic configuration file. For example, a circuit logic configuration file already deployed on the FPGA structure may form a decryption module on the FPGA chip, and the decryption module decrypts the encrypted new circuit logic configuration file.

Wherein, the user can encrypt the new version of the circuit logic configuration file at the client to obtain the encrypted circuit logic configuration file. The key used by the client may include a configuration file deployment key, which may be a symmetric key negotiated between the FPGA structure and the client. For example, after the foregoing secret value is obtained by negotiation between the FPGA structure and the client, the service secret deployment key and the configuration file deployment key may be derived through the KDF at the same time; for example, the KDF may derive a 32-bit string, and the first 16 bits and the last 16 bits (or other means) may be used as the service secret deployment key and the profile deployment key, respectively, as described above.

The "new version" of the new version of circuit logic configuration file refers to a circuit logic configuration file already deployed on the FPGA structure, and indicates that the time when the new version of circuit logic configuration file is deployed to the FPGA structure is relatively late, rather than indicating that version iteration is necessarily implemented on the logic or function implemented by the corresponding circuit logic configuration file.

The FPGA structure can be deployed with a public key or a preset certificate corresponding to the client. The client can sign the new circuit logic configuration file and then send the new circuit logic configuration file to the FPGA structure, so that the FPGA structure can verify the signature of the received new circuit logic configuration file, and the signature passing verification is used as one of conditions for allowing the new circuit logic configuration file to be deployed. And the public key or the certificate corresponding to the client can be deployed in the FPGA structure by the deployed circuit logic configuration file. Therefore, based on signature verification of the new circuit logic configuration file, the reliability of the new circuit logic configuration file can be further improved, so that the reliable updating of the circuit logic configuration file on the FPGA structure is ensured. The FPGA structure can read the encrypted new circuit logic configuration file into a signature verification module on the FPGA chip for signature verification. Similar to the decryption module described above, the signature verification module may be formed by an FPGA chip based on a deployed circuit logic configuration file.

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 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. Therefore, when the deployed circuit logic configuration file is deployed in the memory, the FPGA fabric may perform update deployment on 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 aiming at the updated and deployed new circuit logic configuration file, and the authentication result contains the content related to the new circuit logic configuration file. Then, the FPGA structure may sign the authentication result based on the updated and deployed new version authentication root key, and return the signed authentication result to the client. The client can perform signature verification on the received authentication result, and the client can generate related content based on the new version of circuit logic file maintained by the client, then: and under the condition that the authentication result passes signature verification and the content related to the new version of circuit logic configuration file contained in the authentication result is consistent with the content generated by the client, the client can confirm that the new version of circuit logic configuration file is successfully deployed on the FPGA structure. The content related to the new version of circuit logic configuration file may be a hash value of the new version of circuit logic configuration file or a derivative of the hash value. For example, the FPGA structure may renegotiate with the client based on the new version authentication root key to obtain a new version configuration file deployment key, and the FPGA structure may generate a hash value of the new version circuit logic configuration file and a hash value of the new version configuration file deployment key, respectively, and calculate the two hash values by using, for example, sm3 algorithm or other algorithms, and the obtained calculation result may be used as the content related to the new version circuit logic configuration file; accordingly, based on the authentication result, the client may be caused to determine: the new version of circuit logic configuration file is successfully deployed on the FPGA structure, and a new version of configuration file deployment key is obtained through successful negotiation between the client and the FPGA structure.

Fig. 2 is a schematic structural diagram of a blockchain node according to an exemplary embodiment. Based on the technical solution of the present specification, an FPGA structure may be added to a block chain node to implement the hardware TEE, for example, the FPGA structure may be an FPGA board card as shown in fig. 2. The FPGA board card can be connected to the block link nodes through the PCIE interface so as to realize data interaction between the FPGA board card and the block link nodes. The FPGA board card can comprise structures such as an FPGA chip, a Flash chip, a close-pipe chip and the like; of course, in some embodiments, only a portion of the remaining Flash chips, the crypto-chips, and the like may be included, or more structures may be included, in addition to the FPGA chip, which is only used for example.

In the initial stage, no logic defined by a user is burned on the FPGA chip, which is equivalent to that the FPGA chip is in a blank state. A user can form corresponding functions or logics on the FPGA chip by burning a circuit logic configuration file on the FPGA chip. When a circuit logic configuration file is burned for the first time, the FPGA board card does not have a safety protection capability, so that a safety environment is usually provided externally, for example, a user can burn the circuit logic configuration file in an offline environment to realize physical safety isolation, rather than remotely burn on line.

And aiming at the functions or logics required to be realized by the user, corresponding logic codes can be formed through an FPGA hardware language, and the logic codes are subjected to mirroring treatment, so that the circuit logic configuration file can be obtained. Before burning the logic codes to the FPGA board card, a user can check the logic codes. Particularly, when a plurality of users are involved at the same time, the logic codes can be checked by the plurality of users respectively, so that the FPGA board card can meet the requirements of all the users finally, and abnormal problems such as security risk, logic errors and fraud are prevented.

After determining that the code is correct, the user can burn the circuit logic configuration file to the FPGA board card in the off-line environment. Specifically, the circuit logic configuration file is transmitted from the block link point to the FPGA board, and is further deployed in the Flash chip shown in fig. 2, so that even if the FPGA board is powered off, the Flash chip can still store the circuit logic configuration file.

Fig. 3 is a schematic diagram of forming a functional module on an FPGA chip according to an exemplary embodiment. By loading the circuit logic configuration file deployed in the Flash chip to the FPGA chip, the hardware logic unit included in the FPGA chip can be configured, so that a corresponding function module is formed on the FPGA chip, for example, the formed function module may include a key negotiation module, a decryption and signature verification module, an encryption and decryption module, a plaintext calculation module, and the like shown in fig. 3. Meanwhile, the circuit logic configuration file can also be used for transmitting information to be stored to the FPGA board card, for example, a preset certificate can be stored on the FPGA chip, an authentication root key can be stored in the crypto-tube chip (the authentication root key can also be stored on the FPGA chip), and the like.

Based on a key agreement module formed on the FPGA chip and an authentication root key deployed on the FPGA board, the FPGA board can implement remote key agreement with a user, and the key agreement process can be implemented by using any algorithm or standard in the related art, which is not limited in this specification. By way of example, the key agreement procedure may include: the user can generate a key Ka-1 at a local client, the key negotiation module can generate a key Kb-1 at the local client, the client can calculate key negotiation information Ka-2 based on the key Ka-1, the key negotiation module can calculate key negotiation information Kb-2 based on the key Kb-1, then the client sends the key negotiation information Ka-2 to the key negotiation module, the key negotiation module sends the key negotiation information Kb-2 to the client, so that the client can generate a secret value based on the key Ka-1 and the key negotiation information Kb-2, the key negotiation module can generate the same secret value based on the key Kb-1 and the key negotiation information Ka-2, and finally the client and the key negotiation module derive the same configuration file deployment key from the same secret value based on a key derivation function respectively, the configuration file deployment key can be stored in an FPGA chip or a close-pipe chip. In the above process, although the key agreement information Ka-2 and the key agreement information Kb-2 are transmitted between the client and the key agreement module via the block chain node, since the key Ka-1 is grasped by the client and the key Kb-1 is grasped by the key agreement module, it can be ensured that the block chain node cannot acquire the finally obtained secret value and the configuration file deployment key, thereby avoiding the security risk that may be caused.

In addition to the configuration file deployment key, the secret value is used to derive a business secret deployment key; for example, the secret value may derive a 32-bit value, and the first 16 bits may be used as a configuration file deployment key and the last 16 bits may be used as a service secret deployment key. The user can deploy the service key to the FPGA card through the service secret deployment key, for example, the service key may include a node private key and a service root key. For example, a user can sign and encrypt the node private key or the service root key by using the service secret deployment key on the client, and send the signed and encrypted service root key to the FPGA board, so that the FPGA board deploys the obtained node private key or the service root key after decrypting and verifying the signature by the decryption and verification module.

Based on the deployed node key, the service root key, the encryption and decryption module on the FPGA chip and the plaintext calculation module, the FPGA board card can be realized as TEE on block chain link points to meet privacy requirements. For example, when a block link point receives a transaction, if the transaction is a plaintext transaction, the block link point may directly process the plaintext transaction, and if the transaction is a privacy transaction, the block link point may transmit the privacy transaction to the FPGA board for processing.

The transaction content of the clear text transaction is in a clear text form, and the contract state and the like generated after the transaction is executed are stored in a clear text form. The transaction content of the privacy transaction is in a ciphertext form, the transaction initiator encrypts the plaintext transaction content to obtain the encrypted plaintext transaction content, and contract states and the like generated after the transaction is executed need to be stored in the ciphertext form, so that the transaction privacy protection is ensured. For example, the transaction initiator may generate a symmetric key randomly or based on other manners, and similarly, the service public key corresponding to the service private key is disclosed, then the transaction initiator may perform digital envelope encryption on the plaintext transaction content based on the symmetric key and the service public key: the transaction initiator encrypts plaintext transaction content through a symmetric key, and encrypts the symmetric key through a service public key to obtain two parts of content which are both contained in the privacy transaction; in other words, the privacy transaction includes two parts: the clear text transaction content encrypted by adopting the symmetric key and the symmetric key encrypted by adopting the service public key.

Therefore, after receiving the private transaction transmitted by the block chain link point, the FPGA board can decrypt the symmetric key encrypted by the service public key through the service private key by the encryption and decryption module to obtain the symmetric key, and then decrypt the plaintext transaction content encrypted by the symmetric key through the symmetric key by the encryption and decryption module to obtain the plaintext transaction content. The private transaction may be used to deploy an intelligent contract, and then the data field of the content of the clear text transaction may contain the contract code of the intelligent contract to be deployed; alternatively, the private transaction may be used to invoke an intelligent contract, and then the to field of the plaintext transaction content may contain a contract address of the invoked intelligent contract, and the FPGA board may invoke a corresponding contract code based on the contract address.

The plaintext calculation module formed on the FPGA chip is used for realizing the logic of the virtual machine in the related technology, namely the plaintext calculation module is equivalent to a hardware virtual machine on the FPGA board card. Thus, after the contract code is determined based on the plaintext transaction content, the contract code may be passed into a plaintext calculation module for execution by the plaintext calculation module. After execution, the contract state referred to by the contract code may be updated. If the contract state needs to be stored outside the FPGA chip, the encryption and decryption module encrypts the updated contract state through the service root key or the derivative key thereof and stores the encrypted contract state so as to ensure that the data related to the privacy transaction is only in a plaintext state in the FPGA chip and is in a ciphertext state outside the FPGA chip, thereby ensuring the security of the data.

For some reasons, a user may wish to perform version update on a circuit logic configuration file deployed on an FPGA board, for example, an authentication root key included in the circuit logic configuration file may be known by a risky user, and for example, the user may wish to upgrade a functional module deployed on the FPGA board, which is not limited in this specification. For the sake of distinction, the circuit logic configuration file already deployed in the above process may be referred to as an old version of circuit logic configuration file, and the circuit logic configuration file to be deployed may be referred to as a new version of circuit logic configuration file.

Similar to the old version of the circuit logic configuration file, a user can generate a new version of the circuit logic configuration file through the processes of writing codes, mirroring and the like. Furthermore, a user can sign the new circuit logic configuration file through a private key owned by the user, and then encrypt the signed new circuit logic configuration file through a configuration file deployment key issued by the above-mentioned assistant, so as to obtain the encrypted new circuit logic configuration file. In some cases, multiple users may exist at the same time, and then the preset certificates corresponding to the users need to be deployed to the FPGA board card for the old version of circuit logic configuration file, and the users need to sign the new version of circuit logic configuration file by using their own private keys.

The user can remotely send the encrypted new circuit logic configuration file to the block chain nodes through the client, and the encrypted new circuit logic configuration file is further transmitted to the FPGA board card through the block chain nodes. Fig. 4 is a schematic diagram of performing a new update on an FPGA board according to an exemplary embodiment. As shown in fig. 4, the decryption and signature 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 encrypted new version of circuit logic configuration file must be successfully processed by the decryption and signature verification module before being transmitted to the Flash chip to implement trusted update, and the Flash chip cannot be directly updated by bypassing the decryption and signature verification process.

After receiving the encrypted new version circuit logic configuration file, the decryption and signature verification module decrypts the encrypted new version circuit logic configuration file by using the configuration file deployment key deployed on the FPGA board card, and if the decryption is successful, the decryption and signature verification module further performs signature verification on the decrypted new version circuit logic configuration file based on a preset certificate deployed on the FPGA chip. If the decryption fails or the signature verification fails, the received file is not from the user or is tampered, and the decryption signature verification module triggers to terminate the current updating operation; and under the conditions that decryption is successful and the verification passes, the obtained new version of circuit logic configuration file can be determined to come from the user and is not tampered in the transmission process, and the new version of circuit logic configuration file can be further transmitted to the Flash chip so as to update and deploy the old version of circuit logic configuration file in the Flash chip.

After the new circuit logic configuration file is loaded to the FPGA chip, the key agreement module and the decryption signature verification module can be formed on the FPGA chip, and information such as the preset certificate is stored in the FPGA chip, and the authentication root key is stored in the crypto-tube chip. The formed key negotiation module, the decryption and signature verification module and the like can change and upgrade the realized function logic, and the stored information such as the deployed preset certificate, the authentication root key and the like can be different from the information before updating. Then, the FPGA board may perform remote negotiation with the user based on the updated key negotiation module, the authentication root key, and the like to obtain a new configuration file deployment key, and the configuration file deployment key may be used in a next updateable process. Similarly, trusted update operations for the FPGA board can be continuously implemented accordingly.

After the updating and the deployment are completed, the FPGA board card can generate an authentication result aiming at the new version circuit logic configuration file. For example, the key agreement module may calculate, by using an algorithm such as sm3 or another algorithm, a hash value of the new version of circuit logic configuration file, a hash value of the configuration file deployment key negotiated based on the new version of circuit logic configuration file, and the obtained calculation result may be used as the 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 circuit logic configuration file and the configuration file deployment key negotiated according to the new version circuit logic configuration file, if the verification is successful, the new version circuit logic configuration file is successfully deployed on the FPGA board card, and the user and the FPGA board card successfully negotiate according to the configuration file deployment key to obtain the consistent configuration file deployment key, so that the successful completion of the updating and the deployment aiming at the circuit logic configuration file is confirmed.

Fig. 5 is a schematic block diagram of an apparatus for implementing a privacy blockchain based on an FPGA according to an exemplary embodiment. Referring to fig. 5, in a software implementation, the apparatus for implementing a privacy zone block chain based on an FPGA may include:

a loading unit 501, configured to load the deployed circuit logic configuration file onto an FPGA chip by using the FPGA structure, so as to form an encryption/decryption module on the FPGA chip;

a decryption unit 502, which enables the FPGA structure to transmit the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption to obtain plaintext data;

a processing unit 503, configured to enable the FPGA structure to process the plaintext data through a computation module on the FPGA chip, where the computation module is formed by the FPGA structure on the FPGA chip based on the deployed circuit logic configuration file;

the encryption unit 504 is configured to encrypt the plaintext result generated by the computation module by the FPGA structure through the encryption and decryption module to obtain a ciphertext result.

Optionally, the ciphertext data includes at least one of: the block chain node receives the private transaction, the ciphertext state stored by the block chain link point, the ciphertext contract code stored by the block chain link point and the ciphertext receipt stored by the block chain link point.

Optionally, the ciphertext data is a private transaction received by the block chain node; the decryption unit 502 is specifically configured to:

enabling the FPGA structure to decrypt the private transaction in the encryption and decryption module through the maintained node private key, and obtaining plaintext data as plaintext transaction content;

the privacy transaction is obtained by encrypting the plaintext transaction content through the node public key by the transaction initiator; or, the private transaction is obtained by encrypting the plaintext transaction content by the transaction initiator through a symmetric key maintained by the transaction initiator and the node public key.

Optionally, the method further includes:

a first negotiation unit 505, configured to enable the FPGA structure to negotiate a secret service deployment key with a client by sending negotiation information to the client, so that the client and the FPGA structure determine the secret service deployment key respectively; the negotiation information is signed by an authentication root key deployed on the FPGA structure;

and the node private key is encrypted by the client through the service secret deployment key, transmitted and deployed to the FPGA structure.

Optionally, in a case that the private transaction is encrypted in a digital envelope manner, the encryption unit 504 is specifically configured to:

and enabling the FPGA structure to encrypt the plaintext result in the encryption and decryption module through a symmetric key adopted by a digital envelope.

Optionally, the ciphertext data is a ciphertext state, a ciphertext contract code and/or a ciphertext receipt stored by the block link point; the decryption unit 502 is specifically configured to:

and enabling the FPGA structure to decrypt the ciphertext data in the encryption and decryption module through the maintained service root key or the derivative key of the service root key to obtain corresponding plaintext data.

Optionally, the method further includes:

a second negotiation unit 506, configured to enable the FPGA structure to negotiate a secret service deployment key with a client by sending negotiation information to the client, so that the client and the FPGA structure determine the secret service deployment key respectively; the negotiation information is signed by an authentication root key deployed on the FPGA structure;

and the service root key is encrypted by the client through the service secret deployment key, and then is transmitted and deployed to the FPGA structure.

Optionally, the deployed circuit logic configuration file is deployed to the FPGA fabric locally or remotely by a user.

Optionally, the method further includes:

a receiving unit 507, which enables the FPGA structure to receive the encrypted new circuit logic configuration file from the client;

the updating unit 508 decrypts the encrypted new version circuit logic configuration file by using the FPGA structure, and performs updating and deployment based on the decrypted new version circuit logic configuration file.

Optionally, the method further includes:

a third negotiation unit 509, configured to negotiate a configuration file deployment key with a client by sending negotiation information to the client by the FPGA structure, so that the client and the FPGA structure determine the configuration file deployment key respectively; the negotiation information is signed by an authentication root key deployed on the FPGA structure;

and the new version circuit logic configuration file is encrypted by the client through the configuration file deployment key, then is transmitted and is deployed to the FPGA structure.

Optionally, at least one of the following is also included:

a returning unit 510, configured to return the ciphertext result to the blockchain node by using the FPGA structure;

and the storage unit 511 is used for storing the ciphertext result by the FPGA structure.

Optionally, the FPGA structure further includes a memory outside the FPGA chip; wherein the circuit logic configuration file is disposed on the memory.

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 FPGA structure transmits the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption to obtain plaintext data, and the method comprises the following steps: under the condition that the ciphertext data is the private transaction received by the block chain node, the FPGA structure decrypts the private transaction in the encryption and decryption module through a maintained node private key to obtain plaintext data as plaintext transaction content, wherein the private transaction is obtained by performing digital envelope encryption on the plaintext transaction content through a symmetric key maintained by a transaction initiator and a node public key corresponding to the node private key by the transaction initiator;

2. The method of claim 1, the ciphertext data comprising at least one of: the block chain node receives the private transaction, the ciphertext state stored by the block chain link point, the ciphertext contract code stored by the block chain link point and the ciphertext receipt stored by the block chain link point.

3. The method of claim 1, further comprising:

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

4. The method according to claim 1, wherein in a case where the private transaction is encrypted by means of a digital envelope, the FPGA structure encrypts, by the encryption/decryption module, a plaintext result generated by the computation module, and includes:

and the FPGA structure encrypts the plaintext result in the encryption and decryption module through a symmetric key adopted by the digital envelope.

5. The method of claim 1, the ciphertext data being a ciphertext state, ciphertext contract code, and/or ciphertext receipt stored by the block link point; the FPGA structure transmits ciphertext data from the affiliated block chain node to the encryption and decryption module for decryption, and the decryption method comprises the following steps:

and the FPGA structure decrypts the ciphertext data in the encryption and decryption module through the maintained service root key or the derivative key of the service root key to obtain corresponding plaintext data.

6. The method of claim 5, further comprising:

7. The method of claim 1, the deployed circuit logic configuration file being deployed to the FPGA fabric locally or remotely by a user.

8. The method of claim 1, further comprising:

the FPGA structure receives an encrypted new circuit logic configuration file from a client;

and the FPGA structure decrypts the encrypted new-version circuit logic configuration file and updates and deploys the new-version circuit logic configuration file based on the decrypted new-version circuit logic configuration file.

9. The method of claim 8, further comprising:

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; the negotiation information is signed by an authentication root key deployed on the FPGA structure;

10. The method of claim 8, further comprising:

the FPGA structure returns the ciphertext result to the blockchain node;

or the FPGA structure stores the ciphertext result.

11. The method of claim 1, the FPGA fabric further comprising memory external to the FPGA chip; wherein the circuit logic configuration file is disposed on the memory.

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

the decryption unit, which enables the FPGA structure to transmit the ciphertext data from the affiliated block chain node into the encryption and decryption module for decryption to obtain plaintext data, includes: under the condition that the ciphertext data is the private transaction received by the block chain node, the FPGA structure decrypts the private transaction in the encryption and decryption module through a maintained node private key to obtain plaintext data as plaintext transaction content, wherein the privacy transaction is obtained by a transaction initiator by performing digital envelope encryption on the plaintext transaction content through a symmetric key maintained by the transaction initiator and the node public key;

13. 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-11 by executing the executable instructions.

14. 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 11.