Trusted startup method and device for blockchain all-in-one machine

Abstract

One or more embodiments of the present specification provide a trusted startup method and device for a blockchain all-in-one machine; the method may include: the blockchain all-in-one machine, in response to a received startup instruction, initiates a signature verification request for a mirror file deployed on the blockchain all-in-one machine to a cryptographic acceleration card installed on the blockchain all-in-one machine, where the cryptographic acceleration card pre-stores the publisher public key of the publisher of the mirror file; the blockchain all-in-one machine receives a signature verification result returned by the cryptographic acceleration card, where the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the mirror file using the publisher public key; when the signature verification result indicates that the current signature passes the verification, the blockchain all-in-one machine executes the mirror file deployed on the blockchain all-in-one machine to form a blockchain node.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a trusted startup method and device for a blockchain all-in-one machine. Background Art

[0002] Blockchain technology (also known as distributed ledger technology) is a decentralized distributed database technology with many characteristics such as decentralization, openness, transparency, immutability, and trustworthiness. It is suitable for many application scenarios with high demands on data reliability. Summary of the Invention

[0003] In view of this, one or more embodiments of this specification provide a trusted startup method and device for a blockchain all-in-one machine.

[0004] To achieve the above objectives, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, a trusted startup method for a blockchain all-in-one machine is proposed, including:

[0006] The blockchain all-in-one machine, in response to the received startup instruction, initiates a signature verification request for the image file deployed on the blockchain all-in-one machine to a cryptographic acceleration card assembled on the blockchain all-in-one machine, wherein the cryptographic acceleration card pre-stores a publisher public key of the publisher of the image file;

[0007] The blockchain all-in-one machine receives the signature verification result returned by the cryptographic acceleration card, where the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the image file using the public key of the issuer;

[0008] When the signature verification result indicates that the current signature passes the verification, the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node.

[0009] According to a second aspect of one or more embodiments of this specification, a trusted startup method for a blockchain all-in-one machine is proposed, including:

[0010] The cryptographic acceleration card assembled on the blockchain all-in-one machine receives a signature verification request initiated by the blockchain all-in-one machine for the image file deployed on the blockchain all-in-one machine, and the cryptographic acceleration card pre-stores the publisher public key of the publisher of the image file;

[0011] The cryptographic acceleration card verifies the current signature of the image file through the public key of the issuer, and returns the obtained signature verification result to the blockchain all-in-one machine, so that the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node if the signature verification result indicates that the current signature passes the verification.

[0012] According to a third aspect of one or more embodiments of this specification, a trusted startup device for a blockchain all-in-one machine is proposed, comprising:

[0013] A request sending module causes the blockchain machine to respond to the received startup instruction and initiate a signature verification request for the image file deployed on the blockchain machine to a cryptographic acceleration card assembled on the blockchain machine, where the cryptographic acceleration card pre-stores the publisher public key of the publisher of the image file;

[0014] A result receiving module enables the blockchain all-in-one machine to receive the signature verification result returned by the cryptographic acceleration card, where the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the image file using the public key of the issuer;

[0015] The image execution module enables the blockchain all-in-one machine to execute the image file deployed on the blockchain all-in-one machine to form a blockchain node when the signature verification result indicates that the current signature has passed the verification.

[0016] According to a fourth aspect of one or more embodiments of this specification, a trusted startup device for a blockchain all-in-one machine is proposed, comprising:

[0017] A request receiving module enables a cryptographic acceleration card assembled on the blockchain all-in-one machine to receive a signature verification request initiated by the blockchain all-in-one machine for an image file deployed on the blockchain all-in-one machine, wherein the cryptographic acceleration card pre-stores a publisher public key of the publisher of the image file;

[0018] The image verification module enables the cryptographic acceleration card to verify the current signature of the image file through the public key of the issuer, and returns the obtained signature verification result to the blockchain all-in-one machine, so that the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node if the signature verification result indicates that the current signature passes the verification.

[0019] According to a fifth aspect of one or more embodiments of this specification, a blockchain all-in-one machine is proposed, including:

[0020] processor;

[0021] a memory for storing processor-executable instructions;

[0022] The processor implements the method described in the first aspect by running the executable instructions.

[0023] According to a sixth aspect of one or more embodiments of this specification, a cryptographic acceleration card is provided, comprising:

[0024] processor;

[0025] a memory for storing processor-executable instructions;

[0026] The processor implements the method described in the second aspect by running the executable instructions.

[0027] According to a seventh aspect of one or more embodiments of this specification, a computer-readable storage medium is provided, on which computer instructions are stored. When the instructions are executed by a processor, the steps of the method described in the first aspect or the second aspect are implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is a flowchart of a trusted startup method for a blockchain all-in-one machine provided by an exemplary embodiment.

[0029] Figure 2 This is a flowchart of another trusted startup method for a blockchain all-in-one machine provided by an exemplary embodiment.

[0030] Figure 3 This is an interactive flow chart of a trusted startup method for a blockchain all-in-one machine provided by an exemplary embodiment.

[0031] Figure 4 This is a structural diagram of a blockchain all-in-one machine provided by an exemplary embodiment.

[0032] Figure 5 This is a block diagram of a trusted startup device for a blockchain all-in-one machine provided by an exemplary embodiment.

[0033] Figure 6 This is a schematic structural diagram of a cryptographic acceleration card provided by an exemplary embodiment.

[0034] Figure 7 This is a block diagram of another trusted startup device of a blockchain all-in-one machine provided by an exemplary embodiment. DETAILED DESCRIPTION

[0035] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The implementations described in the following exemplary embodiments are not intended to represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with certain aspects of one or more embodiments of this specification, as detailed in the appended claims.

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

[0037] In the early days of blockchain technology, users typically joined blockchain networks using their own PCs and laptops, becoming nodes within them. This era can be considered the 1.0 architecture of blockchain networks. Joining a blockchain network was not only a user's initiative, but users also had to manage their own operations and maintenance, such as maintaining and configuring their PCs and other devices. With the continuous development of blockchain technology, and particularly the growing demand for high-performance, highly available infrastructure, blockchain networks have evolved into the 2.0 architecture era, based on cloud services. In this 2.0 architecture era, Blockchain-as-a-Service (BaaS) offers a fast and convenient solution for rapid blockchain deployment and technology implementation, supporting a wide range of blockchain service projects. BaaS services are typically built on public or private cloud infrastructure, offering powerful deployment capabilities but also introducing a heavy infrastructure dependency. However, as a typical distributed computing technology, not all nodes can be migrated to the cloud, requiring private deployment. The additional technical migration and operational costs associated with private deployments lead to inconsistent technical interfaces and high deployment and maintenance costs during actual implementation. Therefore, in order to meet users' needs in terms of privatization, security, etc. of blockchain networks, it is necessary to further upgrade the architecture of the blockchain network, so as to realize the 3.0 architecture era based on blockchain all-in-one machines.

[0038] The blockchain all-in-one machine can achieve hardware and software integration. When the publisher releases the blockchain all-in-one machine, it not only provides users with the hardware equipment of the blockchain all-in-one machine, but also integrates the software configuration that is deeply optimized for the hardware equipment, thus achieving the above-mentioned hardware and software integration.

[0039] Hardware optimization can be achieved for the blockchain all-in-one machine. For example, a dedicated smart contract processing chip can be deployed on the blockchain all-in-one machine, such as an FPGA (Field Programmable Gate Array) chip or other types of chips, to improve the processing efficiency of smart contracts. The smart contract processing chip can be deployed with a hardware trust root key. For example, the hardware trust root key can be pre-burned into the smart contract processing chip by the publisher, and the publisher can obtain the public key corresponding to the hardware trust root key (for example, the public key is public). Therefore, the smart contract processing chip can send negotiation information to the publisher and sign the negotiation information with the hardware trust root key, so that the publisher can verify the signature based on the corresponding public key; and after the signature verification is successful, it can be ensured that the smart contract processing chip and the publisher have negotiated the same key based on the above negotiation information. The negotiated key can include a file deployment key. The publisher can encrypt and transmit the binary image file required by the blockchain node to the smart contract processing chip based on the file deployment key, and the smart contract processing chip can decrypt and deploy the binary image file based on the file deployment key. The negotiated keys may include a business secret deployment key. The issuing party can use this business secret deployment key to encrypt and transmit the blockchain node's node private key, business root key, and other information to the smart contract processing chip. The smart contract processing chip can then retrieve and deploy the node private key and business root key based on this business secret deployment key to meet the privacy requirements of blockchain transactions. For example, the node private key corresponds to the node public key. Clients can use the node public key to encrypt and transmit blockchain transactions, while blockchain nodes can decrypt them using the node private key. The business root key is a symmetric key that can be used to encrypt and store business data, such as contract code and contract status values. The business root key may not be used directly; the smart contract processing chip can use a derived key from the business root key for encryption and decryption, mitigating security risks associated with the business root key. By reliably managing node private keys and business root keys (or their derivative keys), and ensuring that data is encrypted except when being processed by the smart contract processing chip, the smart contract processing chip actually forms a hardware trusted execution environment (TEE) on the blockchain all-in-one machine, ensuring that data that requires privacy protection, such as transactions, contract codes, and contract status, will not be leaked.

[0040] For another example, a blockchain appliance can be deployed with a Smart NIC. In addition to performing the functions of a traditional NIC, a Smart NIC can also replace or assist the blockchain appliance's CPU in performing some functions, thereby offloading computational workloads from the CPU. Specifically, network I / O-intensive operations can be offloaded from the CPU to the Smart NIC, freeing the CPU to handle more computationally intensive operations, such as transaction processing and storage management. Because Smart NICs are physically and logically closer to the network than other components on the blockchain appliance (such as the CPU), they always receive priority access to data transmitted across the network. Therefore, in situations where little or no storage access is involved, processing this data using the Smart NIC can achieve significantly higher processing efficiency, lower latency, and higher throughput, thus achieving significantly higher performance gains at a relatively low cost. For example, in consensus algorithms, storage access is rarely required, except for changes in network status, node additions and deletions, or consensus configuration changes. Therefore, consensus operations can be performed by the Smart NIC, which only needs to communicate the consensus results to the CPU, eliminating the need for the CPU to directly participate in the consensus process, significantly improving consensus efficiency. Similarly, transactions forwarded by Smart NICs and block synchronization implemented by Smart NICs on newly added blockchain nodes can achieve similar results, and will not be further elaborated here. Furthermore, upon receiving a transaction, the Smart NIC can compare it with historical transactions, for example by comparing fields such as the sender information, destination address, timestamp, and hash value, thereby identifying and filtering out replayed transactions. The Smart NIC can also perform content analysis on received transactions to filter out illegal transactions or predefined unwanted transactions, complementing the Layer 2 or Layer 3 packet filtering implemented by the switch.

[0041] For example, a cryptographic accelerator card, also known as a high-speed cryptographic accelerator card, can be deployed on a blockchain appliance. This card can implement fully encrypted memory and, through hardware hardening, resist side-channel attacks. It can also provide physical protection against probes, lasers, and other means, offering extremely high security. For example, a cryptographic accelerator card used on a blockchain appliance can possess National Secret Level 2, National Secret Level 3, or other qualifications. When deployed, the hardware root of trust key described above can be maintained on the card. The card can then perform signing operations based on this hardware root of trust, replacing or assisting the smart contract processing chip in performing operations such as key negotiation. Similarly, the card can maintain public keys, enabling signature verification based on these public keys. In short, by offloading at least some operations related to key management, encryption and decryption, and signature verification on the blockchain appliance to the card, the card achieves both extremely high security and performance offload from the blockchain appliance's CPU or the aforementioned smart contract processing chip, improving processing efficiency.

[0042] Software optimizations can be implemented for blockchain all-in-one machines. For example, a built-in certificate authorization service can be implemented to automate certificate issuance and node identity authentication, as well as automatic chain establishment and blockchain node addition, making the blockchain all-in-one machine plug-and-play. This allows users to quickly deploy the blockchain all-in-one machine. In addition to enabling the rapid establishment of private blockchain networks across multiple blockchain all-in-one machines, the blockchain all-in-one machine can integrate standardized cloud service interfaces, allowing the machine to automatically connect to cloud services. This allows for hybrid deployment between the blockchain all-in-one machine and cloud-based blockchain nodes, creating a hybrid blockchain network. The blockchain all-in-one machine can also integrate standardized cross-chain service interfaces, enabling cross-chain services based on standardized cross-chain protocols or services. This significantly expands the application scenarios of the blockchain all-in-one machine and meets users' cross-chain needs, such as enabling cross-chain data exchange between different blockchain networks and between a blockchain network and off-chain computing nodes (for example, off-chain computing nodes offloading computing tasks to blockchain nodes).

[0043] Based on unified software logic, the blockchain all-in-one machine described in this specification can implement a trusted boot process for its deployed image files. During this process, upon receiving the boot command, the machine first determines whether the image file meets the boot conditions—that is, whether the image file's current signature can be verified by the pre-stored publisher's public key. If the boot conditions are met, the image file is executed, achieving trusted boot of the image file in the machine. This process is described below with reference to the accompanying figures.

[0044] Figure 1 This is a flowchart of a trusted startup method for a blockchain all-in-one machine provided by an exemplary embodiment. This method is applied to the blockchain all-in-one machine. To distinguish it from the cryptographic accelerator card installed in the blockchain all-in-one machine, the execution subject of this method - the blockchain all-in-one machine can be understood as the CPU of the blockchain all-in-one machine or other components installed in the blockchain all-in-one machine except the cryptographic accelerator card. Figure 1 As shown, the method may include the following steps:

[0045] In step 102, the blockchain all-in-one machine responds to the received startup instruction and initiates a signature verification request for the image file deployed on the blockchain all-in-one machine to the cryptographic acceleration card installed on the blockchain all-in-one machine, and the cryptographic acceleration card pre-stores the publisher public key of the publisher of the image file.

[0046] In one embodiment, the startup instruction can take various forms, which are not limited in this specification. For example, the startup instruction can be a startup instruction issued by a user (such as a user of the blockchain machine) when the blockchain machine is turned on; or it can be a file execution instruction issued by a management device when the blockchain machine is in the startup state for the binary image file in the blockchain machine.

[0047] In this embodiment, the blockchain machine is pre-deployed with a (unexecuted) image file locally. This specification does not limit the specific form of the image file. For example, the image file can be an executable image file, such as an executable file in .exe format. In this case, the executable file can be pre-installed in the blockchain machine's own hard disk or other execution component. The image file can also be a binary image file, such as a binary file in .bin format. In this case, the binary file can be pre-stored in a suitable location in the blockchain machine's own hard disk or other execution component to be called and executed. Furthermore, the image file can be a binary image file corresponding to a blockchain node deployed on the blockchain machine. Accordingly, when the binary image file is executed, the blockchain machine is implemented as a blockchain node, such as implementing one or more functions such as blockchain visualization, contract creation and deployment, contract execution, key management, and privacy computing. The image file can also be a platform image file containing the above-mentioned binary image file corresponding to the blockchain node deployed on the blockchain machine. When the platform image file is executed, the blockchain machine is not only implemented as a blockchain node, but can also implement one or more other functions such as file processing, node monitoring, and service monitoring, which will not be repeated here.

[0048] In one embodiment, the above-mentioned current signature is generated by the publisher of the image file (hereinafter referred to as the publisher) using the publisher's private key to sign the image file, wherein the publisher's private key and the publisher's public key constitute a pair of asymmetric keys. For example, before publishing the image file, the publisher of the image file can calculate the file digest of the image file in the TEE, and then encrypt the digest using its own publisher's private key to obtain a signature corresponding to the image file. Among them, the TEE where the publisher signs the image file can be constructed using any technology in the relevant technology, and any encryption algorithm in the relevant technology can be used when signing, and this specification does not limit this. However, it should be noted that in the above-mentioned signing process, when the hash value (Hash) of the image file is used as the digest (hereinafter referred to as the signature digest), after receiving the startup request, the hash algorithm used by the blockchain all-in-one machine or the cryptographic acceleration card to calculate the current hash value of the image file should be the same as the hash algorithm used by the publisher to calculate the hash value when signing the image file, so as to ensure that there is a clear verification result when verifying the signature of the image file.

[0049] Furthermore, after receiving the image file sent by the publisher and the signature for the image file, the blockchain all-in-one machine can first verify the received signature to ensure the authenticity of the deployed image file. For example, the signature can be decrypted in the local TEE using the pre-acquired publisher public key to obtain the signature summary of the image file, and then the file summary of the received image file can be recalculated using the same summary calculation algorithm, and the file summary is compared with the above-mentioned signature summary obtained by decryption to see if they are the same. In the case where the file summary is the same as the above-mentioned signature summary, it is determined that the received image file is a credible image file (not tampered with) issued by the publisher, and then the image file can be deployed in the local execution component, and the received signature can be associated with the image file and saved in the local storage space. In addition, in the case of multiple image files, the blockchain all-in-one machine can establish an association relationship between each image file and its corresponding signature, and store each signature and image file according to the association relationship, so as to specifically determine the signature corresponding to the image file.

[0050] In one embodiment, after receiving the aforementioned startup instruction, the blockchain machine can determine the image file corresponding to the startup instruction based on the preset correspondence or information such as the file identifier carried by the startup instruction. It can then further determine the current signature of the image file and include the current signature in a signature verification request and send it to the cryptographic accelerator card, or send it to the cryptographic accelerator card in association with the signature verification request. Alternatively, the current signature can be sent to the blockchain machine by the issuing party in association with the image file, and the blockchain machine can store it locally in association with the image file.

[0051] In one embodiment, when the publisher uses the hash value of the image file as the digest when signing the image file, the blockchain all-in-one machine can also use the same hash algorithm as the publisher to calculate the current hash value of the image file in the locally deployed TEE after receiving the startup request, and include the current hash value in the signature verification request and send it to the cryptographic accelerator card, or associate the current hash value with the signature verification request and send it to the cryptographic accelerator card, so that the cryptographic accelerator card can directly use the current hash value to verify the current signature, reducing the efficiency reduction that may be caused by the cryptographic accelerator card calculating the hash value.

[0052] In step 104, the blockchain all-in-one machine receives the signature verification result returned by the cryptographic acceleration card, and the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the image file through the public key of the issuer.

[0053] In one embodiment, after the cryptographic accelerator card receives a signature verification request containing the current signature, it can extract the current signature from the signature verification request; or, after the cryptographic accelerator card receives a signature verification request sent in association with the current signature, it can directly determine the current signature. Furthermore, the corresponding mirror file can be determined based on the signature verification request or the current signature. For example, the corresponding mirror file can be determined based on the file identifier of the mirror file carried in the signature verification request. At this time, the cryptographic accelerator card can request the file digest of the mirror file from the blockchain all-in-one machine, or can calculate the file digest of the mirror file in the TEE, so as to use the file digest to verify the signature of the mirror file.

[0054] In another embodiment, after the cryptographic accelerator card receives a signature verification request containing the current signature and file digest, it can extract the current signature and file digest from the signature verification request; or, after the cryptographic accelerator card receives a signature verification request sent in association with the current signature and file digest, it can directly determine the current signature and file digest so as to use the file digest to verify the current signature.

[0055] In the above two embodiments, the above file summary can be the file hash value of the image file, wherein the hash algorithm used by the blockchain all-in-one machine or the cryptographic acceleration card to calculate the hash value of the file should be the same as the hash algorithm used by the publisher when signing the image file.

[0056] In one embodiment, the cryptographic accelerator card can verify the current signature in the following manner: first, use the locally pre-stored publisher's publisher public key to decrypt the current signature to obtain a signature digest, and determine the corresponding file digest based on the signature verification request (such as the two embodiments mentioned above); then compare the above signature digest with the file digest to determine whether the two are the same: if the signature digest and the file digest are the same, the current signature is determined to have passed the verification; otherwise, if the signature digest and the file digest are different, the current signature is determined to have failed the verification; finally, a corresponding signature verification result is generated based on the above comparison result.

[0057] In step 106, when the signature verification result indicates that the current signature passes the verification, the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node.

[0058] In this embodiment, if the signature verification result indicates that the current signature has passed verification, then the image file locally deployed by the blockchain all-in-one machine is the image file published by the publisher, is an untampered image file, and has been successfully deployed. This image file is trustworthy, and therefore, the blockchain all-in-one machine can execute this image file to form a blockchain node. Conversely, if the signature verification result indicates that the current signature has failed verification, then the image file locally deployed by the blockchain all-in-one machine is not the standard image file published by the publisher, but may have been illegally tampered with or deployed incorrectly. This image file is untrustworthy, and in this case, the blockchain all-in-one machine can refuse to execute this image file.

[0059] In one embodiment, when the signature verification result indicates that the current signature has not passed the verification, the image file locally deployed by the blockchain all-in-one machine is not the standard image file released by the publisher, so the blockchain all-in-one machine can terminate the startup process of the blockchain all-in-one machine, that is, avoid executing an image file that is different from the standard image file. In another embodiment, the blockchain all-in-one machine can also send an alarm message to at least one of the management personnel, the management device of the blockchain all-in-one machine (such as a control host that controls multiple blockchain all-in-one machines at the same time), and the security service related to the blockchain all-in-one machine for the image file, so that the management personnel, the management device or the security service can perform corresponding processing on the image file. Furthermore, the image file can also be detected as illegal, and the detection result can be included in the above-mentioned alarm message so that the above-mentioned corresponding processing can be carried out in a targeted manner. The above-mentioned response processing can include recording an alarm message, recording the detection result of the image file, deleting the image file, etc.

[0060] In one embodiment, following the above-mentioned embodiment in which the current signature is generated by the publisher using the publisher's private key to sign the image file, further, if the signature verification result indicates that the current signature has failed verification, the blockchain all-in-one machine can request the publisher to re-obtain the image file and replace the currently deployed image file with the acquired image file to ensure the consistency of the image file deployed in the blockchain all-in-one machine with the image file published by the publisher. Furthermore, when requesting to obtain the image file, the blockchain all-in-one machine can also request to obtain the current signature of the image file generated by the publisher using its own publisher's private key to ensure that the current signature corresponds to the image file published by the publisher.

[0061] In one embodiment, because the signature verification result indicates that the current signature has passed verification, the deployed image file corresponding to the current signature is a trusted image file. Therefore, after the blockchain machine receives the signature verification result indicating that the current signature has passed verification for the first time, it can write the image file corresponding to the current signature (i.e., the trusted image file) into the TEE deployed locally on the blockchain machine as a backup image file. Then, if the signature verification result indicates that the current signature has failed verification, the blockchain machine can read the backup image file from the TEE, replace the image file with the backup image file, and respond to the startup instruction again. By ensuring that the standard image file is obtained and backing up the standard image file in the TEE, when the current image file is different from the standard image file, the currently deployed image file is replaced with the image file published by the publisher. This not only ensures the consistency of the image file deployed locally on the blockchain machine with the image file published by the publisher, but also uses the image file published by the publisher that has been saved and guaranteed to be trusted to replace the deployed (but untrusted) image file, avoiding the increase in network load caused by re-obtaining the standard image file from the publisher each time the signature verification result indicates that the current signature has failed verification.

[0062] Accordingly, Figure 2 This is a flowchart of another trusted startup method of a blockchain all-in-one machine provided by an exemplary embodiment, which is applied to a cryptographic acceleration card. Figure 2 As shown, the method may include the following steps:

[0063] In step 202, the cryptographic acceleration card installed on the blockchain all-in-one machine receives a signature verification request initiated by the blockchain all-in-one machine for the image file deployed on the blockchain all-in-one machine, and the cryptographic acceleration card pre-stores the publisher public key of the publisher of the image file.

[0064] In this embodiment, the blockchain machine is pre-deployed with a (unexecuted) image file locally. This specification does not limit the specific form of the image file. For example, the image file can be an executable image file, such as an executable file in .exe format. In this case, the executable file can be pre-installed in the blockchain machine's own hard disk or other execution component. The image file can also be a binary image file, such as a binary file in .bin format. In this case, the binary file can be pre-stored in a suitable location in the blockchain machine's own hard disk or other execution component to be called and executed. Furthermore, the image file can be a binary image file corresponding to a blockchain node deployed on the blockchain machine. Accordingly, when the binary image file is executed, the blockchain machine is implemented as a blockchain node, such as implementing one or more functions such as blockchain visualization, contract creation and deployment, contract execution, key management, and privacy computing. The image file can also be a platform image file containing the above-mentioned binary image file corresponding to the blockchain node deployed on the blockchain machine. When the platform image file is executed, the blockchain machine is not only implemented as a blockchain node, but can also implement one or more other functions such as file processing, node monitoring, and service monitoring, which will not be repeated here.

[0065] In one embodiment, the startup instruction can take various forms, which are not limited in this specification. For example, the startup instruction can be a startup instruction issued by a user (such as a user of the blockchain machine) when the blockchain machine is turned on; or it can be a file execution instruction issued by a management device when the blockchain machine is in the startup state for the binary image file in the blockchain machine.

[0066] In one embodiment, the above-mentioned current signature is generated by the publisher of the mirror file using the publisher's private key to sign the mirror file, wherein the publisher's private key and the publisher's public key constitute a pair of asymmetric keys. For example, before publishing the mirror file, the publisher of the mirror file can calculate the file summary of the mirror file in the TEE, and then encrypt the summary using its own publisher's private key to obtain a signature corresponding to the mirror file. Among them, the TEE where the publisher signs the mirror file can be constructed using any technology in the relevant technology, and any encryption algorithm in the relevant technology can be used when signing, and this specification does not limit this. However, it should be noted that in the case where the hash value of the mirror file is used as the signature summary in the above-mentioned signing process, after receiving the startup request, the hash algorithm used by the blockchain all-in-one machine or the cryptographic acceleration card to calculate the current hash value of the mirror file should be the same as the hash algorithm used by the publisher to calculate the hash value when signing the mirror file, so as to ensure that there is a clear verification result when verifying the signature of the mirror file.

[0067] In step 204, the cryptographic acceleration card verifies the current signature of the image file through the public key of the issuer, and returns the obtained signature verification result to the blockchain all-in-one machine, so that the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node if the signature verification result indicates that the current signature passes the verification.

[0068] The specific process of the above-mentioned cryptographic acceleration card realizing the trusted startup of the blockchain all-in-one machine by matching it with the blockchain all-in-one machine can be found in the above Figure 1 The corresponding embodiments will not be described in detail here.

[0069] Through the above-mentioned embodiment of this specification, after receiving the startup instruction, the blockchain all-in-one machine uses the publisher's public key of the pre-stored image file to verify the current signature of the currently deployed image file in the blockchain all-in-one machine (for example, the signature digest contained in the current signature can be compared with the file digest of the image file to determine whether it is the same) to determine whether the current signature can pass the verification, and execute the image file when it is further determined that the currently deployed image file is indeed the image file released by the publisher, thereby realizing the startup of the blockchain all-in-one machine. Therefore, through the signature verification method, it is guaranteed that the executed image file must be the same as the image file released by the publisher, thereby ensuring the trusted execution of the image file, and then ensuring the trusted startup of the blockchain all-in-one machine.

[0070] The following combination Figure 3 The interactive flow chart of the trusted startup method of the blockchain all-in-one machine shown in FIG provides a detailed description of the process of implementing the trusted startup of the blockchain all-in-one machine through the cooperation between the publisher of the image file, the blockchain all-in-one machine and the cryptographic accelerator card. Figure 3 As shown, the process may include:

[0071] Step 302: The publisher of the image file signs the image file it publishes.

[0072] In step 304, the issuer sends the signature to the blockchain machine.

[0073] In one embodiment, the image file published by the publisher may be an executable image file, such as an executable file in .exe format; or a binary image file, such as a binary file in .bin format. Furthermore, in the case where the image file is a binary image file, the image file may be a binary image file corresponding to a blockchain node deployed on the blockchain machine, and the blockchain machine that executes the binary image file is implemented as a blockchain node; alternatively, the image file may be a platform image file corresponding to the blockchain machine that contains the aforementioned binary image file, and the blockchain machine that executes the platform image file is not only implemented as a blockchain node, but also can implement other functions as described above, which will not be repeated here.

[0074] In one embodiment, for a standard image file that has been published (or not yet published), the publisher can calculate its corresponding standard hash value in the TEE. The TEE can be built based on Intel SGX (Software Guard Extensions) or AMD TrustZone (Trust Zone) technology; the TEE can be deployed locally on the publisher, so that the publisher can directly calculate the standard hash value in the TEE, or the TEE can be deployed in other components related to the publisher, so that the publisher can control the calculation of the standard hash value in the TEE and then encrypt and transmit it to the cryptographic acceleration card. In addition, in the case where the above-mentioned file summary is the hash value of the image file, the publisher can use a hash algorithm such as SHA algorithm, MD4 algorithm, MD5 algorithm, ETHASH algorithm, SCRYPT algorithm, etc. to calculate the hash value. The construction process of the above-mentioned TEE and the calculation process of the hash value can be referred to the content disclosed in the relevant technology, which will not be repeated here.

[0075] After the publisher calculates the standard hash value, it can sign the image file based on the standard hash value. For example, the standard hash value can be encrypted, and the encrypted standard hash value is the signature. Of course, other signing methods are also possible, and this specification does not limit this.

[0076] In this embodiment, the sender can send the above-mentioned signature to the cryptographic acceleration card. Since the cryptographic acceleration card is assembled in the blockchain all-in-one machine, the issuer can forward the signature to the cryptographic acceleration card through the blockchain all-in-one machine (corresponding to step 306a), or directly send the signature to the cryptographic acceleration card (corresponding to step 306b).

[0077] Step 306a: forward the issuer's public key to the cryptographic acceleration card through the blockchain all-in-one machine.

[0078] The publisher can send the signature of the image file in the TEE (the signature summary of the encrypted state) to the blockchain all-in-one machine, and the blockchain all-in-one machine forwards the signature to the cryptographic accelerator card.

[0079] In step 306b, the publisher directly sends the publisher's public key to the cryptographic acceleration card.

[0080] The publisher can send the signature of the image file in the TEE directly to the cryptographic accelerator card.

[0081] Step 308: The cryptographic acceleration card locally stores the issuer's public key.

[0082] In one embodiment, after the cryptographic acceleration card receives the publisher's public key forwarded by the blockchain all-in-one machine or sent directly by the publisher, it can save the publisher's public key in the corresponding security key area in the TEE so that the publisher's public key can be directly called when used, thereby improving the speed of subsequent hash value comparisons.

[0083] In this embodiment, as an exemplary embodiment, the publisher may first send the signature corresponding to the image file to the blockchain machine, and then send the publisher's public key to the cryptographic accelerator card; or, as another exemplary embodiment, the publisher may first send the publisher's public key to the cryptographic accelerator card, and then send the signature corresponding to the image file to the blockchain machine. In other words, there is no necessary order for "sending the signature corresponding to the image file to the blockchain machine" in steps 302-304 and "sending the publisher's public key to the cryptographic accelerator card" in steps 306a-308, and these can be adjusted based on actual circumstances.

[0084] At this point, the pre-storage of the publisher's public key and the signature corresponding to the image file is complete. The blockchain all-in-one machine can accept the startup instruction at any time after step 308. That is, this specification does not limit the length of the interval between steps 308 and 310.

[0085] Step 310: The blockchain all-in-one machine receives a startup instruction.

[0086] In one embodiment, the startup instruction can take various forms, which are not limited in this specification. For example, the startup instruction can be a startup instruction issued by a user (such as a user of the blockchain machine) when the blockchain machine is turned on; or it can be a file execution instruction issued by a management device when the blockchain machine is in the startup state for the binary image file in the blockchain machine.

[0087] After receiving the startup instruction, the blockchain machine can determine the locally deployed image file corresponding to the startup instruction based on preset rules or the file identifier contained in the startup instruction. For example, if the startup instruction is a power-on instruction, the platform image file deployed in the blockchain machine can be determined as the image file to be executed; if the startup instruction includes a file identifier, the image file corresponding to the file identifier can be determined as the image file to be executed.

[0088] Step 312: The blockchain machine calculates the current hash of the image file.

[0089] In step 314, the blockchain all-in-one machine sends a signature verification request to the cryptographic acceleration card.

[0090] In one embodiment, after determining the image file corresponding to the startup instruction deployed on the blockchain machine (i.e., the aforementioned image file to be executed), the blockchain machine can further determine the current signature of the image file and include the current signature in a signature verification request and send it to the cryptographic accelerator card, or associate the current signature with the signature verification request and send it to the cryptographic accelerator card. The aforementioned current signature can be sent to the blockchain machine in advance by the issuer, and the blockchain machine can associate it with the image file and store it locally.

[0091] Accordingly, after the cryptographic accelerator card receives a signature verification request containing the current signature, it can extract the current signature from the signature verification request; or, after the cryptographic accelerator card receives a signature verification request sent in association with the current signature, it can directly determine the current signature. Furthermore, the corresponding mirror file can be determined based on the signature verification request or the current signature. For example, the corresponding mirror file can be determined based on the file identifier of the mirror file carried in the signature verification request. At this time, the cryptographic accelerator card can request the file hash value of the mirror file from the blockchain all-in-one machine, or it can calculate the file hash value of the mirror file in the TEE corresponding to the cryptographic accelerator card, so as to use the file hash value to verify the signature of the mirror file.

[0092] In one embodiment, the blockchain all-in-one machine can calculate the current hash value of the determined image file before sending the signature verification request to the cryptographic accelerator card. The hash algorithm used to calculate the current hash value should be consistent with the hash algorithm used by the publisher to calculate the signature hash value when signing the image file, to ensure that there is a clear signature verification result between the current hash value and the signature hash value (if the hash algorithms are inconsistent, the hash value comparison is meaningless).

[0093] Furthermore, the blockchain all-in-one machine can also include the above-mentioned current signature and file hash value in the signature verification request and send it to the cryptographic acceleration card, or associate the current signature and file hash value with the signature verification request and send it to the cryptographic acceleration card, so that the cryptographic acceleration card can directly use the file hash value to verify the current signature, reducing the efficiency loss that may be caused by the cryptographic acceleration card calculating the hash value.

[0094] Correspondingly, after the cryptographic accelerator card receives a signature verification request containing the current signature and file hash value, it can extract the current signature and file hash value from the signature verification request; or, after the cryptographic accelerator card receives a signature verification request sent in association with the current signature and file hash value, it can directly determine the current signature and file hash value so as to use the file hash value to verify the current signature.

[0095] Step 316: The cryptographic accelerator card verifies the current signature.

[0096] In step 318, the cryptographic acceleration card returns the signature verification result to the blockchain all-in-one machine.

[0097] In one embodiment, the cryptographic accelerator card can use the pre-acquired public key of the issuer in the TEE to decrypt the above signature to obtain the signature hash value, and then compare the plaintext signature hash value and the file hash value in the TEE. The above comparison can adopt a full-text bit-by-bit comparison method, that is, compare the current hash value and the standard hash value bit by bit according to the preset direction: if the values ​​of all bits of the signature hash value and all bits of the file hash value are equal, then the signature hash value is determined to be the same as the file hash value; conversely, if the value of any bit of the signature hash value is not equal to the value of the corresponding bit of the file hash value, then the signature hash value is determined to be different from the file hash value. After the above comparison is completed, the cryptographic accelerator card can return the corresponding comparison result to the blockchain all-in-one machine.

[0098] In step 320, the blockchain all-in-one machine determines to execute the image file or terminate the startup of the blockchain all-in-one machine based on the signature verification result.

[0099] Because the file hash value is calculated based on the image file locally deployed by the blockchain all-in-one machine, and the signature hash value is obtained based on the signature corresponding to the standard image file published by the publisher, if the signature verification result indicates that the current signature passes verification, it means that the locally deployed image file is the standard image file published by the publisher, and therefore the image file is trustworthy (the image file has not been tampered with during transmission or deployment); if the signature verification result indicates that the current signature fails verification, it means that the locally deployed image file is not the standard image file published by the publisher, that is, the image file is untrustworthy (the image file may have been illegally tampered with during transmission or deployment). The blockchain all-in-one machine can perform subsequent processing based on the comparison results.

[0100] In one embodiment, when the signature verification result indicates that the current signature has passed verification, the blockchain all-in-one machine can execute the above-mentioned locally deployed image file, thereby realizing the startup of the blockchain all-in-one machine. At this time, the locally deployed image file is a trusted standard image file, so the image file can be directly executed to realize the startup of the blockchain all-in-one machine. Continuing from the above embodiment, when the image file is a binary image file corresponding to the blockchain node deployed on the blockchain all-in-one machine, when the binary image file is executed, the blockchain all-in-one machine can be implemented as a blockchain node, such as realizing blockchain visualization, contract creation, deployment and execution, key management and / or privacy computing and other functions; when the image file is a platform image file corresponding to the blockchain all-in-one machine and containing the above-mentioned binary image file, when the platform image file is executed, the blockchain all-in-one machine is not only implemented as a blockchain node, but can also realize other functions in addition to blockchain functions, such as file processing, node monitoring and / or service monitoring, which will not be repeated here.

[0101] In one embodiment, following the embodiment described above in which the signature is obtained by the publisher signing the image file it publishes in the TEE, further, if the signature verification result indicates that the current signature has failed verification, the blockchain all-in-one machine can request the publisher to re-obtain the standard image file and replace the current image file with the obtained standard image file to ensure the consistency between the image file deployed in the blockchain all-in-one machine and the standard image file. Moreover, the blockchain all-in-one machine can request the current signature of the standard image file at the same time as requesting the standard image file, or request the current signature of the standard image file from the publisher after the standard image file obtained from the publisher passes the trusted verification to ensure that the current signature corresponds to the standard image file.

[0102] In one embodiment, the blockchain all-in-one machine can pre-store an image file in a locally deployed TEE as a backup image file. Thus, when the signature verification result shows that the current signature fails the verification, the blockchain all-in-one machine can read the backup image file from the above TEE, and then replace the locally deployed image file with the backup image file, and re-respond to the above startup instruction to ensure the consistency of the image file locally deployed by the blockchain all-in-one machine and the image file published by the publisher, so that even if the locally deployed image file is untrustworthy, the trusted startup of the blockchain all-in-one machine can still be achieved as much as possible.

[0103] Furthermore, after receiving the signature verification result indicating that the current signature has been verified for the first time, the blockchain machine can write the image file corresponding to the current hash value (i.e., the locally deployed trusted image file) into the TEE locally deployed on the blockchain machine as a backup image file. Alternatively, the blockchain machine can also proactively request the publisher to obtain the image file corresponding to the above signature before receiving the startup instruction. Alternatively, corresponding to the aforementioned embodiment, when the publisher's public key is forwarded through the blockchain machine, the publisher can also encrypt the image file and associate it with the public key and transmit it to the blockchain machine so that the blockchain machine can write the image file into the locally deployed TEE as a backup image file.

[0104] In one embodiment, when the signature verification result indicates that the current signature has not passed the verification, the image file locally deployed by the blockchain all-in-one machine is not the standard image file released by the publisher. Therefore, the blockchain all-in-one machine can terminate the startup process of the blockchain all-in-one machine, that is, avoid executing an image file that is different from the standard image file.

[0105] In another embodiment, when the signature verification result indicates that the current signature has not passed the verification, the blockchain all-in-one machine can also issue an alarm for the currently deployed image file. For example, an alarm in the form of sound, light, visual pop-up window, etc. can be issued to the user so that the user can know the image file in time and give the standard image file; further, the image file can also be tested for illegality, and the test results can be displayed to the user so that the user can know more detailed illegal information of the image file, so as to carry out corresponding processing in a targeted manner. An alarm message can also be sent to the management device of the blockchain all-in-one machine (such as a control host that notifies and controls multiple blockchain all-in-one machines) or a security service related to the blockchain all-in-one machine so that the management device or security service can carry out corresponding processing on the image file; similarly, the image file can also be tested for illegality, and the test results can be included in the above-mentioned alarm message so as to carry out the above-mentioned corresponding processing in a targeted manner. Among them, the above-mentioned response processing can include at least one of recording the alarm message, recording the test results of the image file, deleting the image file, etc.

[0106] Figure 4 This is a schematic diagram of the structure of a blockchain all-in-one machine provided by an exemplary embodiment. Please refer to Figure 4At the hardware level, the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410. Of course, it may also include hardware required for other services. The processor 402 reads the corresponding computer program from the non-volatile memory 410 into the memory 408 and then runs it, forming a trusted startup device for the blockchain all-in-one machine at the logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logical devices or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logical unit, but can also be hardware or logical devices.

[0107] Please refer to Figure 5 In a software implementation, the trusted startup device of the blockchain all-in-one machine may include:

[0108] The request sending module 501 enables the blockchain machine to respond to the received startup instruction and initiate a signature verification request for the image file deployed on the blockchain machine to a cryptographic acceleration card installed on the blockchain machine, wherein the cryptographic acceleration card pre-stores the publisher public key of the publisher of the image file;

[0109] The result receiving module 502 enables the blockchain all-in-one machine to receive the signature verification result returned by the cryptographic acceleration card, where the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the image file using the public key of the issuer;

[0110] The image execution module 503 enables the blockchain all-in-one machine to execute the image file deployed on the blockchain all-in-one machine to form a blockchain node when the signature verification result indicates that the current signature has passed the verification.

[0111] Optionally, the image file deployed on the blockchain all-in-one machine includes:

[0112] The binary image file corresponding to the blockchain node deployed on the blockchain all-in-one machine; or

[0113] The platform image file deployed on the blockchain all-in-one machine includes the binary image file.

[0114] Optionally, the current signature is generated by the publisher of the image file using a publisher's private key to sign the image file, and the publisher's private key and the publisher's public key form a pair of asymmetric keys.

[0115] Optionally, also include:

[0116] The signature acquisition module 504 enables the blockchain all-in-one machine to request the publisher to re-acquire the image file and its corresponding current signature when the signature verification result indicates that the current signature has not passed the verification.

[0117] Optionally, also include:

[0118] The startup termination module 505 causes the blockchain machine to terminate the startup process of the blockchain machine if the signature verification result indicates that the current signature has not passed the verification; and / or

[0119] The alarm module 506 causes the blockchain all-in-one machine to issue an alarm for the image file when the signature verification result indicates that the current signature has not passed the verification.

[0120] Optionally, also include:

[0121] The file reading module 507 enables the blockchain all-in-one machine to read the backup image file from the locally deployed trusted execution environment when the signature verification result indicates that the current signature has not passed the verification;

[0122] The file replacement module 508 enables the blockchain all-in-one machine to replace the image file with the backup image file and respond to the startup instruction again.

[0123] Optionally, also include:

[0124] The file backup module 509 enables the blockchain all-in-one machine to write the image file corresponding to the current signature into the trusted execution environment locally deployed by the blockchain all-in-one machine as the backup image file after receiving the signature verification result indicating that the current signature has passed the verification for the first time.

[0125] Figure 6 This is a schematic diagram of the structure of a password acceleration card provided by an exemplary embodiment. Figure 6At the hardware level, the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, a non-volatile memory 610, a cryptographic operation unit 612, and a secure key area 614. Of course, it may also include hardware required for other services. The cryptographic operation unit 612 stores the relevant keys received or generated in the secure key area 614 so that the processor 602 can call them to implement related functions such as encryption, decryption, signing, and / or signature verification. The processor 602 reads the corresponding computer program from the non-volatile memory 610 into the memory 608 and then runs it, forming a trusted startup device for the blockchain all-in-one machine at the logical level. Of course, in addition to software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logical devices or a combination of software and hardware. In other words, the execution subject of the following processing flow is not limited to each logical unit, but can also be hardware or logical devices.

[0126] Please refer to Figure 7 In a software implementation, the trusted startup device of the blockchain all-in-one machine may include:

[0127] The request receiving module 701 enables the cryptographic acceleration card installed on the blockchain all-in-one machine to receive a signature verification request initiated by the blockchain all-in-one machine for the image file deployed on the blockchain all-in-one machine, and the cryptographic acceleration card pre-stores the publisher public key of the publisher of the image file;

[0128] The image verification module 702 enables the cryptographic acceleration card to verify the current signature of the image file through the public key of the issuer, and returns the obtained signature verification result to the blockchain all-in-one machine, so that the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node when the signature verification result indicates that the current signature passes the verification.

[0129] Optionally, the image file deployed on the blockchain all-in-one machine includes:

[0130] The binary image file corresponding to the blockchain node deployed on the blockchain all-in-one machine; or

[0131] The platform image file deployed on the blockchain all-in-one machine includes the binary image file.

[0132] Optionally, the current signature is generated by the publisher of the image file using a publisher's private key to sign the image file it publishes, and the publisher's private key and the publisher's public key form a pair of asymmetric keys.

[0133] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

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

[0135] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0136] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be used to store information using any method or technology. 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, compact disc read-only memory (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 that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0137] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0138] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0139] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "an," "the," 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 otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0140] 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, such 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, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when..." or "when..." or "in response to determining."

[0141] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included in the scope of protection of one or more embodiments of this specification.

Claims

1. A trusted startup method for a blockchain all-in-one machine, wherein the blockchain all-in-one machine is equipped with a cryptographic accelerator card and a smart contract processing chip, and integrated with a certificate authorization service, the method comprising: In response to the received startup instruction, the blockchain all-in-one machine initiates a signature verification request for the image file deployed on the blockchain all-in-one machine for forming a blockchain node to the cryptographic acceleration card, where the cryptographic acceleration card pre-stores a publisher public key of the publisher of the image file; The blockchain all-in-one machine receives the signature verification result returned by the cryptographic acceleration card, where the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the image file using the public key of the issuer; When the signature verification result indicates that the current signature passes the verification, the blockchain all-in-one machine executes the image file to form a blockchain node.

2. According to the method of claim 1, the image file deployed on the blockchain all-in-one machine includes: The binary image file corresponding to the blockchain node deployed on the blockchain all-in-one machine; or, The platform image file deployed on the blockchain all-in-one machine includes the binary image file.

3. The method according to claim 1, wherein the current signature is generated by the publisher of the image file using a publisher's private key to sign the image file, and the publisher's private key and the publisher's public key constitute a pair of asymmetric keys.

4. The method according to claim 3, further comprising: If the signature verification result indicates that the current signature has not passed the verification, the blockchain all-in-one machine requests the publisher to re-obtain the image file and its corresponding current signature.

5. The method according to claim 1, further comprising: The blockchain all-in-one machine terminates the startup process of the blockchain all-in-one machine; and / or, The blockchain all-in-one machine issues an alarm for the image file.

6. The method according to claim 1, further comprising: If the signature verification result indicates that the current signature fails the verification, the blockchain all-in-one machine reads the backup image file from the locally deployed trusted execution environment, and responds to the startup instruction again after replacing the image file with the backup image file.

7. The method according to claim 6, further comprising: After the blockchain all-in-one machine receives the signature verification result indicating that the current signature has passed the verification for the first time, the image file corresponding to the current signature is written into the trusted execution environment locally deployed by the blockchain all-in-one machine as the backup image file.

8. According to the method of claim 1, the blockchain all-in-one machine is also deployed with a smart network card and / or a smart contract processing chip.

9. The method according to claim 1, wherein the blockchain all-in-one machine integrates a certificate authorization service, a cloud service interface and / or a cross-chain service interface.

10. A trusted startup method for a blockchain all-in-one machine, wherein the blockchain all-in-one machine is equipped with a cryptographic acceleration card and a smart contract processing chip, and is integrated with a certificate authorization service, the method comprising: The cryptographic acceleration card receives a signature verification request initiated by the blockchain all-in-one machine, wherein the signature verification request is initiated by the blockchain all-in-one machine in response to a received startup instruction for an image file deployed on the blockchain all-in-one machine for forming a blockchain node, and the cryptographic acceleration card pre-stores a publisher public key of a publisher of the image file; The cryptographic acceleration card verifies the current signature of the image file through the public key of the issuer, and returns the obtained signature verification result to the blockchain all-in-one machine, so that the blockchain all-in-one machine executes the image file to form a blockchain node if the signature verification result indicates that the current signature passes the verification.

11. According to the method of claim 10, the image file deployed on the blockchain all-in-one machine includes: The binary image file corresponding to the blockchain node deployed on the blockchain all-in-one machine; or, The platform image file deployed on the blockchain all-in-one machine includes the binary image file.

12. The method according to claim 10, wherein the current signature is generated by the publisher of the image file using a publisher private key to sign the image file it publishes, and the publisher private key and the publisher public key form an asymmetric key pair.

13. According to the method according to claim 10, the signature verification result returned by the cryptographic acceleration card to the blockchain all-in-one machine is also used to enable the blockchain all-in-one machine to read the backup image file from the locally deployed trusted execution environment when the signature verification result indicates that the current signature fails to pass the verification, and after replacing the image file with the backup image file, re-respond to the startup instruction.

14. The method according to claim 10, wherein the issuer public key is pre-stored by the cryptographic acceleration card in a locally deployed trusted execution environment.

15. A trusted startup device for a blockchain all-in-one machine, the blockchain all-in-one machine being equipped with a cryptographic accelerator card and a smart contract processing chip, and integrated with a certificate authorization service, the device comprising: A request sending module causes the blockchain machine to initiate, in response to the received startup instruction, a signature verification request for an image file deployed on the blockchain machine for forming a blockchain node to the cryptographic acceleration card, wherein the cryptographic acceleration card pre-stores a publisher public key of a publisher of the image file; A result receiving module enables the blockchain all-in-one machine to receive the signature verification result returned by the cryptographic acceleration card, where the signature verification result is obtained by the cryptographic acceleration card verifying the current signature of the image file using the public key of the issuer; The image execution module enables the blockchain all-in-one machine to execute the image file to form a blockchain node if the signature verification result indicates that the current signature has passed the verification.

16. A trusted startup device for a blockchain all-in-one machine, the blockchain all-in-one machine being equipped with a cryptographic accelerator card and a smart contract processing chip, and integrated with a certificate authorization service, the device comprising: A request receiving module causes the cryptographic acceleration card to receive a signature verification request initiated by the blockchain all-in-one machine, wherein the signature verification request is initiated by the blockchain all-in-one machine in response to a received startup instruction for an image file deployed on the blockchain all-in-one machine for forming a blockchain node, and the cryptographic acceleration card is pre-stored with a publisher public key of the publisher of the image file; The image verification module enables the cryptographic acceleration card to verify the current signature of the image file through the public key of the issuer, and returns the obtained signature verification result to the blockchain all-in-one machine, so that the blockchain all-in-one machine executes the image file deployed on the blockchain all-in-one machine to form a blockchain node if the signature verification result indicates that the current signature passes the verification.

17. A blockchain all-in-one machine, comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 1 to 9 by running the executable instructions.

18. A password acceleration card, comprising: processor; a memory for storing processor-executable instructions; The processor implements the method according to any one of claims 10 to 14 by running the executable instructions.

19. A computer-readable storage medium having computer instructions stored thereon, wherein when the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 14 are implemented.

Images