EP3937041A1 - Trusted startup methods and apparatuses of dedicated blockchain node device - Google Patents

Trusted startup methods and apparatuses of dedicated blockchain node device Download PDF

Info

Publication number
EP3937041A1
EP3937041A1 EP21179695.8A EP21179695A EP3937041A1 EP 3937041 A1 EP3937041 A1 EP 3937041A1 EP 21179695 A EP21179695 A EP 21179695A EP 3937041 A1 EP3937041 A1 EP 3937041A1
Authority
EP
European Patent Office
Prior art keywords
blockchain node
node device
disk image
dedicated
dedicated blockchain
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP21179695.8A
Other languages
German (de)
French (fr)
Other versions
EP3937041B1 (en
Inventor
Changzheng WEI
Ying Yan
Hui Zhang
Lei Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alipay Hangzhou Information Technology Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Publication of EP3937041A1 publication Critical patent/EP3937041A1/en
Application granted granted Critical
Publication of EP3937041B1 publication Critical patent/EP3937041B1/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • G06F8/61Installation
    • G06F8/63Image based installation; Cloning; Build to order
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2365Ensuring data consistency and integrity
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44Program or device authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245Protecting personal data, e.g. for financial or medical purposes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/64Protecting data integrity, e.g. using checksums, certificates or signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/104Peer-to-peer [P2P] networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575Secure boot
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/602Providing cryptographic facilities or services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00Business processing using cryptography
    • G06Q2220/10Usage protection of distributed data files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • G06Q30/018Certifying business or products
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the present disclosure relates to the field of blockchain technologies, and in particular to trusted startup methods and apparatuses of a dedicated blockchain node device.
  • Blockchain technology (also called distributed ledger technology) is a decentralized distributed database technology having many characteristics such as decentralization, openness, transparency, immutability and trustability and the like, and thus it is applicable to many application scenarios with high demands for data reliability.
  • one or more embodiments of the present disclosure provide trusted startup methods and apparatuses of a dedicated blockchain node device.
  • one or more embodiments of the present disclosure provide the following technical solution:
  • a trusted startup method of a dedicated blockchain node device including:
  • a trusted startup method of a dedicated blockchain node device including:
  • a trusted startup apparatus of a dedicated blockchain node device including:
  • a trusted startup apparatus of a dedicated blockchain node device including:
  • a dedicated blockchain node device including:
  • a cryptographic acceleration card including:
  • a seventh aspect of one or more embodiments of the present disclosure provided is a computer readable storage medium having computer instructions stored thereon, wherein the instructions are executed by a processor to implement steps in the method according to the first or second aspect.
  • steps of corresponding method are not necessarily performed according to the sequence shown in the present disclosure in other embodiments.
  • the steps included in the corresponding method can be more or less than described in the specification.
  • a single step described in the specification may be divided into several steps for descriptions in other embodiments while several steps described in the specification can be combined into a single step for descriptions in other embodiments.
  • the stage can be called 1.0 architecture era of blockchain network, in which the behaviors of users to participate in the blockchain network are autonomous and the users also need to perform autonomous maintenance, for example, perform maintenance and configuration and so on for their devices (for example, PC) participating in the blockchain network.
  • autonomous maintenance for example, perform maintenance and configuration and so on for their devices (for example, PC) participating in the blockchain network.
  • the blockchain network develops into 2.0 architecture era based on cloud service.
  • Blockchain-as-a-Service provides fast and convenient solutions for fast blockchain deployment and technical implementation and supports a large number of blockchain service projects.
  • BaaS is built on infrastructures such as public cloud or private cloud, which introduces heavy dependence on infrastructure as well as providing strong deployment capability.
  • blockchain is a typical distributed computing technology, not all nodes can be migrated to clouds but privatization deployment is needed.
  • the additional technical migration and maintenance costs brought by the privatization deployment cause inconsistent technical interfaces and high deployment and maintenance costs during an actual implementation. Therefore, to satisfy the needs of users for privatization and security and the like of the blockchain network, it is necessary to perform further architecture upgrade to the blockchain network, thereby realizing 3.0 architecture era based on dedicated blockchain node device (blockchain all-in-one machine).
  • Software and hardware integration can be realized for the dedicated blockchain node device.
  • a provider When providing a dedicated blockchain node device, a provider will not only provide hardware devices of the dedicated blockchain node device to users but also provide software configurations for realizing deep optimizations of the hardware devices integrated into the dedicated blockchain node device, thereby realizing the software-hardware integration.
  • Hardware optimization can be realized for the dedicated blockchain node device.
  • a dedicated smart contract processing chip can be deployed on the dedicated blockchain node device.
  • the smart contract processing chip can be Field Programmable Gate Array (FPGA) chip, or another type of chip to increase the processing efficiency for a smart contract.
  • FPGA Field Programmable Gate Array
  • a hardware root-of-trust key can be deployed on the smart contract processing chip, for example, the hardware root-of-trust key can be pre-programmed by the provider into the smart contract processing chip and the provider can also know a public key corresponding to the hardware root-of-trust key (for example, the key is disclosed).
  • the smart contract processing chip can send negotiation information to the provider and sign the negotiation information by using the hardware root-of-trust key, so that the provider can verify the signature based on the corresponding public key; and, after successful signature verification, it is ensured that the smart contract processing chip and the provider obtain the same key through negotiation based on the negotiation information.
  • the negotiated key can include an image deployment key, and thus the provider can encrypt and transmit a binary disk image needed by the blockchain node to the smart contract processing chip based on the image deployment key, and the smart contract processing chip can decrypt and deploy the binary disk image based on the image deployment key.
  • the negotiated key can include a service secret deployment key, and thus the provider can encrypt and transmit a node private key of the blockchain node, a service root key of the blockchain node, etc., to the smart contract processing chip based on the service secret deployment key, and the smart contract processing chip can obtain and deploy the node private key and the service root key and the like based on the service secret deployment key to satisfy the privacy transaction needs in a blockchain scenario.
  • the node private key corresponds to a node public key, and thus a client device can perform encryption and transmission for a blockchain transaction by using the node public key, and the blockchain node can perform decryption by using the node private key.
  • the service root key is a symmetric key which can be used to perform encrypted storage for service data such as contract codes and value of contract status and the like.
  • the service root key may not be directly used, and the smart contract processing chip can perform encryption and decryption through a derivation key of the service root key to reduce the security risk of the service root key.
  • TEE Trusted Execution Environment
  • an intelligent network card can be deployed on the dedicated blockchain node device.
  • the intelligent network card also can replace or assist a CPU of the dedicated blockchain node device to perform partial functions so as to offload computation of the CPU.
  • the operations with intensive network I/O can be transferred from CPU to the intelligent network card to perform, so that the CPU can process more computation-intensive operations, for example, transaction processing, and storage processing and the like.
  • the intelligent network card is closer to the network regardless of physical level or logical level, so the intelligent network card can always fetch data transmitted in the network preferentially.
  • the intelligent network card can process these data with a relatively higher processing efficiency and a relatively smaller delay, and a relatively larger throughput, so as to achieve a higher performance benefit with a lower cost.
  • consensus algorithm there is almost no need to access storage except in the cases of change of network status, addition and deletion of node, change of consensus configuration and the like. Therefore, the consensus operation can be completed by the intelligent network card and only need to inform the CPU of a consensus result. Therefore, the CPU is not required to directly participate in the consensus process, thereby significantly improving the consensus efficiency.
  • the intelligent network card can identify or filter out a replay transaction by comparing the received transaction with historical transactions, for example, comparing data fields of sender information of transaction, destination address, time stamp, and hash value and the like.
  • the intelligent network card can also perform content analysis for those received transactions, so as to filter out illegal transactions or predefined undesired transactions and the like as a supplementation to layer-2 or layer-3 packet filtering implemented by a switch.
  • a cryptographic acceleration card which is also called a high-speed cryptographic acceleration card can be deployed on the dedicated blockchain node device.
  • the cryptographic acceleration card can realize total encrypted memory, defend against side-channel attacks by hardware reinforcement, and also realize physical protection against approaches such as probe, laser and the like, having very high security.
  • the cryptographic acceleration card used on the dedicated blockchain node device can have level-2 qualification from the State Cryptography Administration, level-3 qualification from the State Cryptography Administration and the like.
  • the cryptographic acceleration card When the cryptographic acceleration card is deployed, the hardware roof-of-trust key as described above can be maintained in the cryptographic acceleration card, and the cryptographic acceleration card can perform signature operation based on the hardware roof-of-trust key and replace or assist the smart contract processing chip to complete the operations such as the key negotiation as described above.
  • the cryptographic acceleration card can be used to maintain a public key so that the cryptographic acceleration card can realize signature verification operation based on the maintained public key.
  • at least part of operations relating to key management, encryption and decryption, and signature verification and the like on the dedicated blockchain node device can be handed over to the cryptographic acceleration card, so that very high security can be realized and task offloading can be realized for the CPU of the dedicated blockchain node device or the smart contract processing chip, thereby improving the processing efficiency.
  • a certificate authority service can be built in the dedicated blockchain node device to realize automatic certificate issuing, node identity authentication, automatic blockchain construction, and automatic adding of blockchain node, thereby realizing the plug and play of the dedicated blockchain node device.
  • a user can realize fast deployment of the dedicated blockchain node device.
  • the dedicated blockchain node device can integrate a standardized on-cloud service interface to enable the dedicated blockchain node device to automatically connect to on-cloud service, thereby realizing hybrid deployment between the dedicated blockchain node device and the cloud-deployed blockchain node to construct a hybrid blockchain network.
  • the dedicated blockchain node device can also integrate a standardized cross-chain service interface to enable the dedicated blockchain node device to realize cross-chain services based on a standardized cross-chain protocol or standardized cross-chain service, thereby greatly expanding the application scenarios of the dedicated blockchain node device, and satisfying the cross-chain needs of users.
  • cross-chain data interaction between different blockchain networks is achieved, and for another example, cross-chain data interaction between the blockchain network and an off-chain computing node and the like is achieved (for example, the off-chain computing node shares computation task for the blockchain node and the like).
  • the dedicated blockchain node device in the present disclosure can realize a trusted startup process for a disk image deployed in itself.
  • the dedicated blockchain node device first determines whether the disk image satisfies a startup condition that a current signature of the disk image is successfully verified by a pre-stored provider public key after receiving a startup instruction, and then executes the disk image in a case of satisfying the startup condition, thereby realizing trusted startup of the disk image in the dedicated blockchain node device.
  • FIG. 1 is a flowchart of a trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure.
  • the method is applied to a dedicated blockchain node device.
  • the executing subject of the method i.e. the dedicated blockchain node device can be understood as a CPU of the dedicated blockchain node device, or another component other than the cryptographic acceleration card assembled in the dedicated blockchain node device.
  • the method can include the following steps:
  • the dedicated blockchain node device initiates a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card.
  • the startup instruction can be in several forms which are not limited herein.
  • the startup instruction can be a machine startup instruction sent when a user (for example, a user of the dedicated blockchain node device) performs a machine startup operation for the dedicated blockchain node device; or an image execution instruction sent by a management device for the binary disk image in the dedicated blockchain node device under the startup state of the dedicated blockchain node device or the like.
  • a disk image (that has not been executed yet) is locally pre-deployed in the dedicated blockchain node device.
  • the specific form of the disk image is not limited herein in the present disclosure.
  • the disk image can be an executable disk image, for example, an executable file of . exe format.
  • the executable file can be pre-installed in an execution component of the dedicated blockchain node device, such as a hard disk drive.
  • the disk image can also be a binary disk image, for example, a binary image of .bin format. At this time, the binary image can be pre-stored at a proper position of an execution component of the dedicated blockchain node device, such as a hard disk drive to be invoked and executed.
  • the disk image can be a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device.
  • the dedicated blockchain node device when the binary disk image is executed, the dedicated blockchain node device is implemented as a blockchain node to, for example, realize one or more functions of blockchain visualization, contract creation and deployment, contract execution, key management and privacy computing and the like.
  • the disk image can also be a platform disk image including the binary disk image corresponding to the blockchain node and deployed in the dedicated blockchain node device.
  • the dedicated blockchain node device is implemented as a blockchain node, and also configured to realize one or more other functions such as image processing, node monitoring and service monitoring, which will not be redundantly described herein.
  • the current signature is generated by the provider of the disk image (referred to as provider for short) signing the disk image using the provider private key, where the provider private key and the provider public key are a pair of asymmetric keys.
  • the provider of the disk image can compute an image digest of the disk image in a Trusted Execution Environment (TEE), and then encrypt the image digest using its own provider private key to obtain a signature corresponding to the disk image.
  • TEE Trusted Execution Environment
  • the TEE in which the provider signs the disk image can be constructed by adopting any technique of related technologies and any encryption algorithm of related technologies can be adopted for signature, which is not limited herein.
  • signature digest a hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute a current hash value of the disk image after receiving a startup request
  • signature digest a hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute a current hash value of the disk image after receiving a startup request
  • the dedicated blockchain node device can first verify the received signature in order to ensure the authenticity of the deployed disk image. For example, the dedicated blockchain node device can decrypt the signature in the local TEE by using the pre-obtained provider public key to obtain the signature digest of the disk image, and then re-compute the image digest of the received disk image using the same digest computation algorithm, and then determine whether the image digest and the signature digest obtained by decryption are the same.
  • the dedicated blockchain node device determines that the received disk image is a trusted disk image (not tampered) provided by the provider, and further deploys the disk image in a local execution component and stores the received signature and the disk image in a local storage space in an associated manner.
  • the dedicated blockchain node device can establish an association between each disk image and a corresponding signature, and store the signatures and the disk images based on the association.
  • the signature corresponding to the disk image can be specifically determined.
  • the dedicated blockchain node device can determine a disk image corresponding to the startup instruction according to information such as the predetermined corresponding relationship or a file identifier included in the startup instruction, and then determine a current signature of the disk image and send a signature verification request including the current signature to the cryptographic acceleration card, or send a signature verification request in association with the current signature to the cryptographic acceleration card.
  • the current signature and the disk image can also be associated and sent to the dedicated blockchain node device by the provider and then locally stored by the dedicated blockchain node device in an associated manner.
  • the dedicated blockchain node device in a case that the provider takes the hash value of the disk image as a digest for signing the disk image, can also use the same hash algorithm as the provider to compute the current hash value of the disk image in the TEE locally deployed after receiving the startup request, and send a signature verification request including the current hash value to the cryptographic acceleration card or send a signature verification request in association with the current hash value to the cryptographic acceleration card, so that the cryptographic acceleration card can directly use the current hash value to verify the current signature, thereby avoiding the possible decreased efficiency caused by computation of the cryptographic acceleration card for the hash value.
  • the dedicated blockchain node device 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 disk image using the provider public key.
  • the cryptographic acceleration card can extract the current signature from the signature verification request; or the cryptographic acceleration card can directly determine the current signature after receiving a signature verification request in association with the current signature. Further, a corresponding disk image can be determined according to the signature verification request or the current signature, for example, a corresponding disk image can be determined according to a file identifier of disk image included in the signature verification request. At this time, the cryptographic acceleration card can request an image digest of the disk image from the dedicated blockchain node device or compute the image digest of the disk image in the TEE, so as to use the image digest to verify the signature of the disk image.
  • the cryptographic acceleration card after receiving a signature verification request including the current signature and the image digest, can extract the current signature and the image digest from the signature verification request; or, the cryptographic acceleration card can directly determine the current signature and the image digest after receiving a signature verification request in association with the current signature and the image digest, so as to use the image digest to verify the current signature.
  • the image digest can be an image hash value of the disk image.
  • a hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute the image hash value should be identical to a hash algorithm adopted by the provider to sign the disk image.
  • the cryptographic acceleration card can verify the current signature in the following manner: firstly, a signature digest is obtained by decrypting the current signature using the locally pre-stored provider public key of the provider and then a corresponding image digest is determined according to the signature verification request (as in the above-mentioned two embodiments); then, whether the signature digest and the image digest are the same is determined by comparing the signature digest and the image digest, in a case that the signature digest and the image digest are the same, it is determined that the current signature passes verification; or, in a case that the signature digest and the image digest are not the same, it is determined the current signature does not pass verification; finally, a corresponding signature verification result is generated according to the comparison result.
  • the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node.
  • the dedicated blockchain node device can execute the disk image to form a blockchain node.
  • the signature verification result indicates the current signature does not pass verification, it indicates that the disk image locally deployed in the dedicated blockchain node device is not a standard disk image provided by the provider but a disk image that may be illegally tampered or erroneously deployed, and therefore the disk image is un-trustable.
  • the dedicated blockchain node device can refuse to execute the disk image.
  • the disk image locally deployed in the dedicated blockchain node device is not a standard disk image provided by the provider.
  • the dedicated blockchain node device can terminate the startup process of the dedicated blockchain node device, thereby avoiding executing a disk image different from the standard disk image.
  • the dedicated blockchain node device can also send a warning message for the disk image to at least one of a management personnel, a management device of the dedicated blockchain node device (for example, a control host for controlling a plurality of dedicated blockchain node devices at the same time), and a security service relating to the dedicated blockchain node device and the like, so that the management personnel, the management device or the security service performs corresponding processing for the disk image.
  • the dedicated blockchain node device can also perform illegality detection for the disk image with a detection result included in the warning message, so that specific processing can be performed for the disk image.
  • the response processing can include at least one of recording warning message, recording detection result of disk image and deleting disk image and the like.
  • the dedicated blockchain node device can request a disk image from the provider again, and replace the currently-deployed disk image with the obtained disk image, thus ensuring the disk image deployed in the dedicated blockchain node device is consistent with the disk image provided by the provider. Furthermore, when requesting a disk image from the provider, the dedicated blockchain node device can also request a current signature performed for the disk image by the provider using its provider private key at the same time, thus ensuring the current signature corresponds to the disk image provided by the provider.
  • the dedicated blockchain node device can write the disk image corresponding to the current signature (i.e. the trusted disk image) into the TEE locally deployed in the dedicated blockchain node device as a backup disk image the first time it received a signature verification result indicating the current signature passes verification. Afterwards, in a case that the signature verification result indicates that the current signature does not pass verification, the dedicated blockchain node device can read the backup disk image from the TEE, and then replace the disk image with the backup disk image and respond to the startup instruction again.
  • a standard disk image is obtained and backed up in the TEE, so that the currently-deployed disk image is replaced with the disk image provided by the provider in a case that the current disk image is different from the standard disk image. In this way, it is guaranteed that the disk image locally deployed in the dedicated blockchain node device is consistent with the disk image provided by the provider. Further, and by using pre-stored and trusted standard disk file to replace deployed (but not trusted) disk file avoids possible increase of network load caused by requesting a standard disk image again from the provider every time that the signature verification result indicates that the current signature does not pass verification.
  • FIG. 2 is a flowchart of another trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure.
  • the method is applied to a cryptographic acceleration card.
  • the method can include the following steps.
  • a cryptographic acceleration card assembled on the dedicated blockchain node device receives a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, where a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card.
  • a disk image (that has not been executed yet) is locally pre-deployed in the dedicated blockchain node device.
  • the specific form of the disk image is not limited herein in the present disclosure.
  • the disk image can be an executable disk image, for example, an executable file of . exe format.
  • the executable file can be pre-installed in an execution component of the dedicated blockchain node device, such as a hard disk drive.
  • the disk image can also be a binary disk image, for example, a binary image of .bin format. At this time, the binary image can be pre-stored at a proper position of an execution component of the dedicated blockchain node device, such as a hard disk drive to be invoked and executed.
  • the disk image can be a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device.
  • the dedicated blockchain node device when the binary disk image is executed, the dedicated blockchain node device is implemented as a blockchain node, for example, to realize one or more functions of blockchain visualization, contract creation and deployment, contract execution, key management and privacy computing and the like.
  • the disk image can also be a platform disk image including the binary disk image corresponding to the blockchain node and deployed in the dedicated blockchain node device.
  • the dedicated blockchain node device is not only implemented as a blockchain node, but also can realize one or more functions such as image processing, node monitoring and service monitoring, which will not be redundantly described herein.
  • the startup instruction can be in several forms which are not limited herein.
  • the startup instruction can be a machine startup instruction sent when a user (for example, a user of the dedicated blockchain node device) performs a machine startup operation for the dedicated blockchain node device; or an image execution instruction sent by a management device for the binary disk image in the dedicated blockchain node device under the startup state of the dedicated blockchain node device or the like.
  • the current signature is generated by the provider of the disk image signing the disk image using the provider private key, where the provider private key and the provider public key are a pair of asymmetric keys.
  • the provider of the disk image can compute an image digest of the disk image in a Trusted Execution Environment (TEE), and then encrypt the image digest using its own provider private key to obtain a signature corresponding to the disk image.
  • TEE Trusted Execution Environment
  • the TEE in which the provider signs the disk image can be constructed by adopting any technique of related technologies and any encryption algorithm of related technologies can be adopted for signature, which is not limited herein.
  • a hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute a current hash value of the disk image after receiving a startup request should be identical to a hash algorithm adopted by the provider to compute a hash value for signing the disk image. In this way, it is ensured that a definite verification result will be obtained when verification is performed for the signature of the disk image.
  • the cryptographic acceleration card verifies a current signature of the disk image using the provider public key and returns an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • the cryptographic acceleration card verifies the current signature of the currently-deployed disk image in the dedicated blockchain node device using the pre-stored provider public key of the provider of the disk image (for example, whether the signature digest included in the current signature and the image digest of the disk image are the same is determined by comparing the signature digest included in the current signature and the image digest of the disk image), such that the dedicated blockchain node device determines whether the current signature passes verification and executes the disk image in a case of further determining the currently-deployed disk image is indeed a disk image provided by the provider, thereby realizing the startup of the dedicated blockchain node device.
  • signature verification it is guaranteed that the executed disk image is the same as the disk image provided by the provider.
  • the trusted execution of the disk image is ensured, thus ensuring the trusted startup of the dedicated blockchain node device.
  • the process can include the following steps.
  • a provider of a disk image signs the disk image provided by the provider.
  • the provider sends the signature to a dedicated blockchain node device.
  • the disk image provided by the provider can be an executable disk image, for example, an executable file of .exe format, or a binary disk image, for example, an executable file of .bin format.
  • the disk image can be a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device, and the dedicated blockchain node device executing the binary disk image can be implemented as a blockchain node; or, the disk image can also be a platform disk image including the binary disk image in the dedicated blockchain node device, and the dedicated blockchain node device executing the platform disk image can not only be implemented as a blockchain node but also configured to realize other functions as above, which will not be repeated herein.
  • the provider can compute a corresponding standard hash value in the TEE.
  • the TEE can be constructed based on Intel Software Guard Extensions (SGX) or AMD TrustZone technique.
  • the TEE can be locally deployed in the provider such that the provider can directly compute the standard hash value in the TEE; or, the TEE can be deployed in another component relating to the provider such that the provider can control the standard hash value to be encrypted and transmitted to the cryptographic acceleration card after computing the standard hash value in the TEE.
  • the provider can compute the hash value by adopting a hash algorithm such as SHA algorithm, MD4 algorithm, MD5 algorithm, ETHASH algorithm, and SCRYPT algorithm.
  • SHA algorithm SHA algorithm
  • MD4 algorithm MD4 algorithm
  • MD5 algorithm MD5 algorithm
  • SCRYPT algorithm SCRYPT algorithm
  • the provider can sign the disk image based on the standard hash value.
  • the standard hash value can be encrypted and the encrypted standard hash value is the signature.
  • signature can also be performed in another manner and will not be limited herein.
  • the provider can send the signature to the cryptographic acceleration card. Because the cryptographic acceleration card is assembled on the dedicated blockchain node device, the provider can forward the signature to the cryptographic acceleration card through dedicated blockchain node device (corresponding to the step 306a), or send the signature directly to the cryptographic acceleration card (corresponding to step 306b).
  • the provider public key is forwarded by the dedicated blockchain node device to the cryptographic acceleration card.
  • the provider can send the signature performed for the disk image in the TEE (encrypted signature digest) to the dedicated blockchain node device which forwards the signature to the cryptographic acceleration card.
  • the provider sends the provider public key directly to the cryptographic acceleration card.
  • the provider can send the signature performed for the disk image in the TEE directly to the cryptographic acceleration card.
  • the cryptographic acceleration card stores the provider public key locally.
  • the cryptographic acceleration card can store the provider public key in a corresponding secure key zone in the TEE, such that the provider public key is directly invoked, thereby speeding up subsequent hash values comparison.
  • the provider can first send the signature corresponding to the disk image to the dedicated blockchain node device and then send the provider public key to the cryptographic acceleration card; or, as another example embodiment, the provider can first send the provider public key to the cryptographic acceleration card and then send the signature corresponding to the disk image to the dedicated blockchain node device.
  • steps 302-304 the signature corresponding to the disk image is sent to the dedicated blockchain node device
  • steps 306a-308 the provider public key is sent to the cryptographic acceleration card
  • the dedicated blockchain node device can receive a startup instruction at any moment after step 308, that is, no limitation is made to a time interval between the step 308 and the step 310.
  • the dedicated blockchain node device receives a startup instruction.
  • the startup instruction can be in several forms which are not limited in the present disclosure.
  • the startup instruction can be a machine startup instruction sent when a user (for example, a user of the dedicated blockchain node device) performs a machine startup operation for the dedicated blockchain node device; or an image execution instruction sent by a management device for the binary disk image in the dedicated blockchain node device under the startup state of the dedicated blockchain node device or the like.
  • the dedicated blockchain node device can determine a locally deployed disk image corresponding to the startup instruction according to a predetermined rule or a file identifier included in the startup instruction. For example, in a case that the startup instruction is a machine startup instruction, a platform disk image deployed in the dedicated blockchain node device is determined as a to-be-executed disk image; in a case that the startup instruction includes a file identifier, a disk image corresponding to the file identifier is determined as a to-be-executed disk image.
  • the dedicated blockchain node device computes a current hash of the disk image.
  • the dedicated blockchain node device sends a signature verification request to the cryptographic acceleration card.
  • the dedicated blockchain node device can further determine a current signature of the disk image, and send a signature verification request including the current signature to the cryptographic acceleration card, or send a signature verification request in association with the current signature to the cryptographic acceleration card.
  • the current signature can be sent in advance by the provider to the dedicated blockchain node device which stores the current signature and the disk image locally in an associated manner.
  • the cryptographic acceleration card can extract the current signature from the signature verification request; or, the cryptographic acceleration card can directly determine the current signature after receiving a signature verification request in association with the current signature.
  • a corresponding disk image can be determined according to the signature verification request or the current signature, for example, a corresponding disk image can be determined according to a file identifier of disk image included in the signature verification request.
  • the cryptographic acceleration card can request an image hash value of the disk image from the dedicated blockchain node device or compute the image hash value of the disk image in the TEE corresponding to the cryptographic acceleration card, so as to use the image hash value to verify the signature of the disk image.
  • the dedicated blockchain node device before sending a signature verification request to the cryptographic acceleration card, can compute the current hash value of the determined disk image.
  • a hash algorithm adopted to compute the current hash value should be identical to a hash algorithm adopted by the provider to compute a signature hash value for signing the disk image to ensure that a definite verification result will be present between the current hash value and the signature hash value (hash values comparison will be meaningless if hash algorithms are inconsistent).
  • the dedicated blockchain node device can also send a signature verification request including the current signature and the image hash value to the cryptographic acceleration card, or send a signature verification request in association with the current signature and the image hash value to the cryptographic acceleration card, so that the cryptographic acceleration card can directly use the image hash value to verify the current signature, thereby avoiding possible decreased efficiency caused by computation of the cryptographic acceleration card for the hash value.
  • the cryptographic acceleration card can extract the current signature and the image hash value from the signature verification request; or, the cryptographic acceleration card can directly determine the current signature and the image hash value after receiving a signature verification request in association with the current signature and the image hash value, so as to use the image hash value to verify the current signature.
  • the cryptographic acceleration card verifies the current signature.
  • the cryptographic acceleration card returns a signature verification result to the dedicated blockchain node device.
  • the cryptographic acceleration card can obtain a signature hash value by decrypting the signature using the pre-obtained provider public key in the TEE, and then compare the signature hash value of plaintext and the image hash value in the TEE.
  • the comparison can be performed in a full text bit-by-bit comparison manner, that is, the bits of the current hash value and the standard hash value are compared bit by bit along a predetermined direction: if the values of all bits of the signature hash value are equal to the values of all bits of the image hash value, it is determined that the signature hash value and the image hash value are the same; on the contrary, if the value of any bit of the signature hash value is unequal to the value of the corresponding bit of the image hash value, it is determined that the signature hash value and the image hash value are not the same.
  • the cryptographic acceleration card can return the corresponding comparison result to the dedicated blockchain node device.
  • the dedicated blockchain node device determines to execute the disk image or terminate the startup of the dedicated blockchain node device according to the signature verification result.
  • the image hash value is computed based on the disk image locally deployed in the dedicated blockchain node device, and the signature hash value is computed based on the signature corresponding to the standard disk image provided by the provider. Therefore, if the signature verification result indicates that the current signature passes verification, it indicates that the locally deployed disk image is a standard disk image provided by the provider and thus the disk image is trustable (the disk image is not tampered during transmission and deployment processes); if the signature verification result indicates that the current signature does not pass verification, it indicates that the locally deployed disk image is not a standard disk image provided by the provider and thus the disk image is un-trustable (the disk image can be illegally tampered during transmission and deployment processes).
  • the dedicated blockchain node device can perform subsequent processing respectively according to the comparison result.
  • the dedicated blockchain node device in a case that the signature verification result indicates that the current signature passes verification, can execute the locally deployed disk image, so as to realize startup of the dedicated blockchain node device.
  • the locally-deployed disk image is a trusted standard disk image. Therefore, the disk image can be directly executed to realize the startup of the dedicated blockchain node device.
  • the dedicated blockchain node device can be implemented as a blockchain node to, for example, realize blockchain visualization, contract creation, deployment and execution, key management and/or privacy computing and so on when the binary disk image is executed; in a case that the disk image is a platform disk image including the binary disk image in the dedicated blockchain node device, when the platform disk image is executed, the dedicated blockchain node device is not only implemented as a blockchain node but also configured to realize other functions such as image processing, node monitoring and/or service monitoring other than blockchain function, which will not be repeated herein.
  • the dedicated blockchain node device can request a standard disk image again from the provider, and replace the current disk image with the obtained standard disk image to ensure the disk image deployed in the dedicated blockchain node device is consistent with the standard disk image. Furthermore, the dedicated blockchain node device can request the current signature of the standard disk image at the same time when requesting the standard disk image, or request the current signature of the standard disk image from the provider after the standard disk image obtained from the provider passes trusted verification, so as to ensure the current signature corresponds to the standard disk image.
  • the dedicated blockchain node device can pre-store a disk image as a backup disk image in the TEE locally deployed.
  • the dedicated blockchain node device can read the backup disk image from the TEE, and then replace the locally-deployed disk image with the backup disk image, and respond to the startup instruction again.
  • the disk image locally deployed in the dedicated blockchain node device is consistent with the disk image provided by the provider, so that the trusted startup of the dedicated blockchain node device can be realized as possible even in a case that the locally-deployed disk image is un-trustable.
  • the dedicated blockchain node device can write the disk image corresponding to the current hash value (i.e. the locally-deployed trusted disk image) into the TEE locally deployed in the dedicated blockchain node device as a backup disk image the first time it received the signature verification result indicating the current signature passes verification.
  • the dedicated blockchain node device can also actively request the disk image corresponding to the signature from the provider before receiving the startup instruction.
  • the provider public key is forwarded by the dedicated blockchain node device
  • the provider can also send the disk image in association with the public key to the dedicated blockchain node device so that the dedicated blockchain node device writes the disk image into the locally-deployed TEE as a backup disk image.
  • the dedicated blockchain node device in a case that the signature verification result indicates the current signature does not pass verification, the disk image locally deployed in the dedicated blockchain node device is not a standard disk image provided by the provider. Therefore, the dedicated blockchain node device can terminate the startup process of the dedicated blockchain node device, thus avoiding executing a disk image different from the standard disk image.
  • the dedicated blockchain node device in a case that the signature verification result indicates that the current signature does not pass verification, can also send a warning for the currently-deployed disk image. For example, warnings, in the form of sound, light or visual popup window can be sent to a user so that the user can know the disk image is not a standard disk image. Further, an illegality detection can be performed for the disk image with a detection result displayed to the user, so that the user can know more detailed illegal information of the disk image and further perform specific corresponding processing.
  • a warning message can also be sent to a management device of the dedicated blockchain node device (for example, a control host controlling a plurality of dedicated blockchain node devices) or a security service relating to the dedicated blockchain node device so that the management device or the security service can perform corresponding processing for the disk image.
  • a management device of the dedicated blockchain node device for example, a control host controlling a plurality of dedicated blockchain node devices
  • a security service relating to the dedicated blockchain node device so that the management device or the security service can perform corresponding processing for the disk image.
  • an illegality detection can also be performed for the disk image with a detection result included in the warning message, so that the corresponding processing can be performed specifically.
  • the response processing can include at least one of recording warning message, recording detection result of disk image, and deleting disk image and the like.
  • FIG. 4 is a structural schematic diagram of a dedicated blockchain node device according to example embodiments of the present disclosure.
  • the device includes a processor 402, an internal bus 404, a network interface 406, a memory 408, and a non-volatile memory 410.
  • the device can further include hardware required for other services.
  • the processor 402 reads corresponding computer programs from the non-volatile memory 410 to the memory 408 for running, so as to logically form a trusted startup apparatus of a dedicated blockchain node device.
  • one or more embodiments of the present disclosure do not preclude other implementations, for example, logic device or a combination of software and hardware or the like. That is, the executing subject of the following processing is not limited to each logic unit and can also be hardware or logic device.
  • a trusted startup apparatus of a dedicated blockchain node device can include:
  • the disk image deployed in the dedicated blockchain node device includes:
  • the current signature is generated by the provider of the disk image signing the disk image using a provider private key, where the provider private key and the provider public key form a pair of asymmetric keys.
  • the apparatus further includes: a signature obtaining module 504, configured to enable the dedicated blockchain node device to request again a disk image and a current signature corresponding to the disk image from the provider in a case that the signature verification result indicates the current signature does not pass verification.
  • a signature obtaining module 504 configured to enable the dedicated blockchain node device to request again a disk image and a current signature corresponding to the disk image from the provider in a case that the signature verification result indicates the current signature does not pass verification.
  • the apparatus further includes:
  • the apparatus further includes:
  • the apparatus further includes: an image backing-up module 509, configured to enable the dedicated blockchain node device to write the disk image corresponding to the current signature into the trusted execution environment locally deployed by the dedicated blockchain node device as the backup disk image the first time it received a signature verification result indicating the current signature passes verification.
  • an image backing-up module 509 configured to enable the dedicated blockchain node device to write the disk image corresponding to the current signature into the trusted execution environment locally deployed by the dedicated blockchain node device as the backup disk image the first time it received a signature verification result indicating the current signature passes verification.
  • FIG. 6 is a structural schematic diagram of a cryptographic acceleration card according to example embodiments of the present disclosure.
  • the device includes a processor 602, an internal bus 604, a network interface 606, a memory 608, a non-volatile memory 610, a crypto-operation unit 612 and a secure key zone 614.
  • the device can further include hardware required for other services.
  • the crypto-operation unit 612 stores received or generated relevant keys in the secure key zone 614 so that the processor 602 invoke the keys to realize relevant functions such as encryption, decryption, signature and/or signature verification.
  • the processor 602 reads corresponding computer programs from the non-volatile memory 610 to the memory 608 for running, so as to logically form a trusted startup apparatus of a dedicated blockchain node device.
  • a dedicated blockchain node device e.g., a public or private blockchain network.
  • one or more embodiments of the present disclosure do not preclude other implementations, for example, logic device or a combination of software and hardware or the like. That is, the executing subject of the following processing is not limited to each logic unit and can also be hardware or logic device.
  • a trusted startup apparatus of a dedicated blockchain node device can include:
  • the disk image deployed in the dedicated blockchain node device includes:
  • the current signature is generated by the provider of the disk image signing the disk image using a provider private key, where the provider private key and the provider public key form a pair of asymmetric keys.
  • the systems, apparatuses, modules or units described in the above-mentioned embodiments can be specifically implemented by a computer chip or an entity or can be implemented by a product with a particular function.
  • a typical implementing device can be a computer and the computer can specifically be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device, or a combination of any several devices of the above-mentioned devices.
  • the computer can include one or more central processing units (CPU), one or more input/output interfaces, one or more network interfaces and one or more memories.
  • CPU central processing units
  • input/output interfaces one or more input/output interfaces
  • network interfaces one or more network interfaces
  • memories one or more memories.
  • the memory can include a non-permanent memory, a random access memory (RAM), and/or a non-volatile memory and the like in a computer readable medium, for example, read only memory (ROM), or flash RAM.
  • RAM random access memory
  • ROM read only memory
  • flash RAM flash random access memory
  • the computer readable medium includes permanent, non-permanent, mobile and non-mobile media, which can realize information storage by any method or technology.
  • the information can be computer readable instructions, data structures, program modules and other data.
  • the examples of the computer storage medium include but not limited to: a phase change random access memory (PRAM), a Static Random Access Memory (SRAM), a Dynamic Random Access Memory (DRAM), and other types of RAMs, Read-Only Memory (ROM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a Flash Memory, or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, cassette type magnetic tape, magnetic disk storage, quantum memory, storage medium based on graphene, or other magnetic storage device or other non-transmission medium for storing information accessible by computing devices.
  • the computer readable medium does not include transitory computer readable media, for example, modulated data signal and carriers.
  • first, second, third, and the like can be used in one or more embodiments of the present disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one category of information from another. For example, without departing from the scope of one or more embodiments of the present disclosure, first information can be referred as second information; and similarly, the second information can also be referred as the first information. Depending on the context, the term “if' as used herein can be interpreted as “when” or “upon” or “in response to determining”.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Medical Informatics (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

One or more embodiments of the present disclosure provide a trusted startup method and apparatus of a dedicated blockchain node device. The method includes: initiating, by the dedicated blockchain node device, a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card; receiving, by the dedicated blockchain node device, a signature verification result returned by the cryptographic acceleration card, wherein the signature verification result is obtained by the cryptographic acceleration card verifying a current signature of the disk image using the provider public key; executing, by the dedicated blockchain node device, the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.

Description

    TECHNICAL FIELD
  • The present disclosure relates to the field of blockchain technologies, and in particular to trusted startup methods and apparatuses of a dedicated blockchain node device.
  • BACKGROUND
  • Blockchain technology (also called distributed ledger technology) is a decentralized distributed database technology having many characteristics such as decentralization, openness, transparency, immutability and trustability and the like, and thus it is applicable to many application scenarios with high demands for data reliability.
  • SUMMARY
  • In view of this, one or more embodiments of the present disclosure provide trusted startup methods and apparatuses of a dedicated blockchain node device.
  • To achieve the above-mentioned object, one or more embodiments of the present disclosure provide the following technical solution:
  • According to a first aspect of one or more embodiments of the present disclosure, provided is a trusted startup method of a dedicated blockchain node device, including:
    • initiating, by the dedicated blockchain node device, a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    • receiving, by the dedicated blockchain node device, a signature verification result returned by the cryptographic acceleration card, wherein the signature verification result is obtained by the cryptographic acceleration card verifying a current signature of the disk image using the provider public key;
    • executing, by the dedicated blockchain node device, the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • According to a second aspect of one or more embodiments of the present disclosure, provided is a trusted startup method of a dedicated blockchain node device, including:
    • receiving, by a cryptographic acceleration card assembled on the dedicated blockchain node device, a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    • verifying, by the cryptographic acceleration card, a current signature of the disk image using the provider public key, and returning an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • According to a third aspect of one or more embodiments of the present disclosure, provided is a trusted startup apparatus of a dedicated blockchain node device, including:
    • a request sending module, configured to enable the dedicated blockchain node device to initiate a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    • a result receiving module, configured to enable the dedicated blockchain node device to receive a signature verification result returned by the cryptographic acceleration card, wherein the signature verification result is obtained by the cryptographic acceleration card verifying a current signature of the disk image using the provider public key;
    • an image executing module, configured to enable the dedicated blockchain node device to execute the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • According to a fourth aspect of one or more embodiments of the present disclosure, provided is a trusted startup apparatus of a dedicated blockchain node device, including:
    • a request receiving module, configured to enable a cryptographic acceleration card assembled on the dedicated blockchain node device to receive a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    • an image verifying module, configured to enable the cryptographic acceleration card to verify a current signature of the disk image using the provider public key, and return an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • According to a fifth aspect of one or more embodiments of the present disclosure, provided is a dedicated blockchain node device, including:
    • a processor;
    • a memory for storing processor executable instructions;
    • wherein the processor implements the method according to the first aspect by running the executable instructions.
  • According to a sixth aspect of one or more embodiments of the present disclosure, provided is a cryptographic acceleration card, including:
    • a processor;
    • a memory for storing processor executable instructions;
    • wherein the processor implements the method according to the second aspect by running the executable instructions.
  • According to a seventh aspect of one or more embodiments of the present disclosure, provided is a computer readable storage medium having computer instructions stored thereon, wherein the instructions are executed by a processor to implement steps in the method according to the first or second aspect.
  • BRIEF DESCRIPTION OF THE DRAWINGS
    • FIG. 1 is a flowchart of a trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure.
    • FIG. 2 is a flowchart of another trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure.
    • FIG. 3 is an interaction flowchart of a trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure.
    • FIG. 4 is a structural schematic diagram of a dedicated blockchain node device according to example embodiments of the present disclosure.
    • FIG. 5 is a block diagram of a trusted startup apparatus of a dedicated blockchain node device according to example embodiments of the present disclosure.
    • FIG. 6 is a structural schematic diagram of a cryptographic acceleration card according to example embodiments of the present disclosure.
    • FIG. 7 is a block diagram of another trusted startup apparatus of a dedicated blockchain node device according to example embodiments of the present disclosure.
    DETAILED DESCRIPTION OF THE EMBODIMENTS
  • Example embodiments will be described in detail herein with the example embodiments thereof expressed in the drawings. When the following descriptions involve the drawings, same numbers in different drawings represent same or similar elements unless stated otherwise. The implementations described in the following example embodiments do not represent all implementations consistent with one or more embodiments of the present disclosure. On the contrary, they are merely embodiments of apparatuses and methods consistent with some aspects of one or more embodiments of the present disclosure described in detail in the appended claims.
  • It should be noted that the steps of corresponding method are not necessarily performed according to the sequence shown in the present disclosure in other embodiments. In some other embodiments, the steps included in the corresponding method can be more or less than described in the specification. Further, a single step described in the specification may be divided into several steps for descriptions in other embodiments while several steps described in the specification can be combined into a single step for descriptions in other embodiments.
  • In the early stage of development of the blockchain technology, users mostly add their own personal computer (PC) and laptop computer and the like into a blockchain network to become a blockchain node in the blockchain network. At this time, the stage can be called 1.0 architecture era of blockchain network, in which the behaviors of users to participate in the blockchain network are autonomous and the users also need to perform autonomous maintenance, for example, perform maintenance and configuration and so on for their devices (for example, PC) participating in the blockchain network. Along with continuous development of the blockchain technology, especially along with increasing needs of users for infrastructures with high performance and high availability, the blockchain network develops into 2.0 architecture era based on cloud service. In the 2.0 architecture era, Blockchain-as-a-Service (BaaS) provides fast and convenient solutions for fast blockchain deployment and technical implementation and supports a large number of blockchain service projects. Generally, BaaS is built on infrastructures such as public cloud or private cloud, which introduces heavy dependence on infrastructure as well as providing strong deployment capability. However, because blockchain is a typical distributed computing technology, not all nodes can be migrated to clouds but privatization deployment is needed. The additional technical migration and maintenance costs brought by the privatization deployment cause inconsistent technical interfaces and high deployment and maintenance costs during an actual implementation. Therefore, to satisfy the needs of users for privatization and security and the like of the blockchain network, it is necessary to perform further architecture upgrade to the blockchain network, thereby realizing 3.0 architecture era based on dedicated blockchain node device (blockchain all-in-one machine).
  • Software and hardware integration can be realized for the dedicated blockchain node device. When providing a dedicated blockchain node device, a provider will not only provide hardware devices of the dedicated blockchain node device to users but also provide software configurations for realizing deep optimizations of the hardware devices integrated into the dedicated blockchain node device, thereby realizing the software-hardware integration.
  • Hardware optimization can be realized for the dedicated blockchain node device. For example, a dedicated smart contract processing chip can be deployed on the dedicated blockchain node device. For example, the smart contract processing chip can be Field Programmable Gate Array (FPGA) chip, or another type of chip to increase the processing efficiency for a smart contract. A hardware root-of-trust key can be deployed on the smart contract processing chip, for example, the hardware root-of-trust key can be pre-programmed by the provider into the smart contract processing chip and the provider can also know a public key corresponding to the hardware root-of-trust key (for example, the key is disclosed). Therefore, the smart contract processing chip can send negotiation information to the provider and sign the negotiation information by using the hardware root-of-trust key, so that the provider can verify the signature based on the corresponding public key; and, after successful signature verification, it is ensured that the smart contract processing chip and the provider obtain the same key through negotiation based on the negotiation information. The negotiated key can include an image deployment key, and thus the provider can encrypt and transmit a binary disk image needed by the blockchain node to the smart contract processing chip based on the image deployment key, and the smart contract processing chip can decrypt and deploy the binary disk image based on the image deployment key. The negotiated key can include a service secret deployment key, and thus the provider can encrypt and transmit a node private key of the blockchain node, a service root key of the blockchain node, etc., to the smart contract processing chip based on the service secret deployment key, and the smart contract processing chip can obtain and deploy the node private key and the service root key and the like based on the service secret deployment key to satisfy the privacy transaction needs in a blockchain scenario. For example, the node private key corresponds to a node public key, and thus a client device can perform encryption and transmission for a blockchain transaction by using the node public key, and the blockchain node can perform decryption by using the node private key. The service root key is a symmetric key which can be used to perform encrypted storage for service data such as contract codes and value of contract status and the like. The service root key may not be directly used, and the smart contract processing chip can perform encryption and decryption through a derivation key of the service root key to reduce the security risk of the service root key. Through reliable management for the node private key and the service root key (or its derivation key), data will be always in encrypted state unless processed by the smart contract processing chip. Therefore, the smart contract processing chip actually forms a Trusted Execution Environment (TEE) of hardware on the dedicated blockchain node device, so as to ensure the data requiring privacy protection such as transactions, contract codes, and contract statuses will not be leaked.
  • For another example, an intelligent network card can be deployed on the dedicated blockchain node device. In addition to realizing a traditional network card function, the intelligent network card also can replace or assist a CPU of the dedicated blockchain node device to perform partial functions so as to offload computation of the CPU. Especially, the operations with intensive network I/O can be transferred from CPU to the intelligent network card to perform, so that the CPU can process more computation-intensive operations, for example, transaction processing, and storage processing and the like. Compared with other components (for example, CPU) on the dedicated blockchain node device, the intelligent network card is closer to the network regardless of physical level or logical level, so the intelligent network card can always fetch data transmitted in the network preferentially. Therefore, with no storage access or a small amount of storage access is involved, the intelligent network card can process these data with a relatively higher processing efficiency and a relatively smaller delay, and a relatively larger throughput, so as to achieve a higher performance benefit with a lower cost. For example, in consensus algorithm, there is almost no need to access storage except in the cases of change of network status, addition and deletion of node, change of consensus configuration and the like. Therefore, the consensus operation can be completed by the intelligent network card and only need to inform the CPU of a consensus result. Therefore, the CPU is not required to directly participate in the consensus process, thereby significantly improving the consensus efficiency. Similarly, the same effect can be achieved in forwarding transactions by the intelligent network card and achieving block synchronization by the intelligent network card on a newly-added blockchain node and the like and will not be repeated herein. Furthermore, after receiving transactions, the intelligent network card can identify or filter out a replay transaction by comparing the received transaction with historical transactions, for example, comparing data fields of sender information of transaction, destination address, time stamp, and hash value and the like. The intelligent network card can also perform content analysis for those received transactions, so as to filter out illegal transactions or predefined undesired transactions and the like as a supplementation to layer-2 or layer-3 packet filtering implemented by a switch.
  • For another example, a cryptographic acceleration card which is also called a high-speed cryptographic acceleration card can be deployed on the dedicated blockchain node device. The cryptographic acceleration card can realize total encrypted memory, defend against side-channel attacks by hardware reinforcement, and also realize physical protection against approaches such as probe, laser and the like, having very high security. For example, the cryptographic acceleration card used on the dedicated blockchain node device can have level-2 qualification from the State Cryptography Administration, level-3 qualification from the State Cryptography Administration and the like. When the cryptographic acceleration card is deployed, the hardware roof-of-trust key as described above can be maintained in the cryptographic acceleration card, and the cryptographic acceleration card can perform signature operation based on the hardware roof-of-trust key and replace or assist the smart contract processing chip to complete the operations such as the key negotiation as described above. Similarly, the cryptographic acceleration card can be used to maintain a public key so that the cryptographic acceleration card can realize signature verification operation based on the maintained public key. In short, at least part of operations relating to key management, encryption and decryption, and signature verification and the like on the dedicated blockchain node device can be handed over to the cryptographic acceleration card, so that very high security can be realized and task offloading can be realized for the CPU of the dedicated blockchain node device or the smart contract processing chip, thereby improving the processing efficiency.
  • Software optimization can be realized for the dedicated blockchain node device. For example, a certificate authority service can be built in the dedicated blockchain node device to realize automatic certificate issuing, node identity authentication, automatic blockchain construction, and automatic adding of blockchain node, thereby realizing the plug and play of the dedicated blockchain node device. In this case, a user can realize fast deployment of the dedicated blockchain node device. In addition to quickly establishing a private blockchain network among a plurality of dedicated blockchain node devices, the dedicated blockchain node device can integrate a standardized on-cloud service interface to enable the dedicated blockchain node device to automatically connect to on-cloud service, thereby realizing hybrid deployment between the dedicated blockchain node device and the cloud-deployed blockchain node to construct a hybrid blockchain network. The dedicated blockchain node device can also integrate a standardized cross-chain service interface to enable the dedicated blockchain node device to realize cross-chain services based on a standardized cross-chain protocol or standardized cross-chain service, thereby greatly expanding the application scenarios of the dedicated blockchain node device, and satisfying the cross-chain needs of users. For example, cross-chain data interaction between different blockchain networks is achieved, and for another example, cross-chain data interaction between the blockchain network and an off-chain computing node and the like is achieved (for example, the off-chain computing node shares computation task for the blockchain node and the like).
  • Based on a unified software logic, the dedicated blockchain node device in the present disclosure can realize a trusted startup process for a disk image deployed in itself. In this process, the dedicated blockchain node device first determines whether the disk image satisfies a startup condition that a current signature of the disk image is successfully verified by a pre-stored provider public key after receiving a startup instruction, and then executes the disk image in a case of satisfying the startup condition, thereby realizing trusted startup of the disk image in the dedicated blockchain node device. The process will be described below in combination with accompanying drawings.
  • FIG. 1 is a flowchart of a trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure. The method is applied to a dedicated blockchain node device. In order to distinguish from a cryptographic acceleration card assembled in the dedicated blockchain node device, the executing subject of the method, i.e. the dedicated blockchain node device can be understood as a CPU of the dedicated blockchain node device, or another component other than the cryptographic acceleration card assembled in the dedicated blockchain node device. As shown in FIG. 1, the method can include the following steps:
  • At step 102, the dedicated blockchain node device initiates a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card.
  • In an embodiment, the startup instruction can be in several forms which are not limited herein. For example, the startup instruction can be a machine startup instruction sent when a user (for example, a user of the dedicated blockchain node device) performs a machine startup operation for the dedicated blockchain node device; or an image execution instruction sent by a management device for the binary disk image in the dedicated blockchain node device under the startup state of the dedicated blockchain node device or the like.
  • In this embodiment, a disk image (that has not been executed yet) is locally pre-deployed in the dedicated blockchain node device. The specific form of the disk image is not limited herein in the present disclosure. For example, the disk image can be an executable disk image, for example, an executable file of . exe format. At this time, the executable file can be pre-installed in an execution component of the dedicated blockchain node device, such as a hard disk drive. The disk image can also be a binary disk image, for example, a binary image of .bin format. At this time, the binary image can be pre-stored at a proper position of an execution component of the dedicated blockchain node device, such as a hard disk drive to be invoked and executed. Further, the disk image can be a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device. Correspondingly, when the binary disk image is executed, the dedicated blockchain node device is implemented as a blockchain node to, for example, realize one or more functions of blockchain visualization, contract creation and deployment, contract execution, key management and privacy computing and the like. The disk image can also be a platform disk image including the binary disk image corresponding to the blockchain node and deployed in the dedicated blockchain node device. When the platform disk image is executed, the dedicated blockchain node device is implemented as a blockchain node, and also configured to realize one or more other functions such as image processing, node monitoring and service monitoring, which will not be redundantly described herein.
  • In an embodiment, the current signature is generated by the provider of the disk image (referred to as provider for short) signing the disk image using the provider private key, where the provider private key and the provider public key are a pair of asymmetric keys. For example, before providing the disk image, the provider of the disk image can compute an image digest of the disk image in a Trusted Execution Environment (TEE), and then encrypt the image digest using its own provider private key to obtain a signature corresponding to the disk image. The TEE in which the provider signs the disk image can be constructed by adopting any technique of related technologies and any encryption algorithm of related technologies can be adopted for signature, which is not limited herein. It should be noted that in a case of taking a hash value of the disk image as a digest (hereinafter referred to as signature digest) in the signature process, a hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute a current hash value of the disk image after receiving a startup request should be identical to a hash algorithm adopted by the provider to compute a hash value for signing the disk image. In this way, it is ensured that a definite verification result will be obtained when verification is performed for the signature of the disk image.
  • Further, after receiving the disk image and the signature of the disk image from the provider, the dedicated blockchain node device can first verify the received signature in order to ensure the authenticity of the deployed disk image. For example, the dedicated blockchain node device can decrypt the signature in the local TEE by using the pre-obtained provider public key to obtain the signature digest of the disk image, and then re-compute the image digest of the received disk image using the same digest computation algorithm, and then determine whether the image digest and the signature digest obtained by decryption are the same. When the image digest and the signature digest obtained by decryption are the same, the dedicated blockchain node device determines that the received disk image is a trusted disk image (not tampered) provided by the provider, and further deploys the disk image in a local execution component and stores the received signature and the disk image in a local storage space in an associated manner. In a case of a plurality of disk images, the dedicated blockchain node device can establish an association between each disk image and a corresponding signature, and store the signatures and the disk images based on the association. Thus, the signature corresponding to the disk image can be specifically determined.
  • In an embodiment, after receiving the startup instruction, the dedicated blockchain node device can determine a disk image corresponding to the startup instruction according to information such as the predetermined corresponding relationship or a file identifier included in the startup instruction, and then determine a current signature of the disk image and send a signature verification request including the current signature to the cryptographic acceleration card, or send a signature verification request in association with the current signature to the cryptographic acceleration card. Alternatively, the current signature and the disk image can also be associated and sent to the dedicated blockchain node device by the provider and then locally stored by the dedicated blockchain node device in an associated manner.
  • In an embodiment, in a case that the provider takes the hash value of the disk image as a digest for signing the disk image, the dedicated blockchain node device can also use the same hash algorithm as the provider to compute the current hash value of the disk image in the TEE locally deployed after receiving the startup request, and send a signature verification request including the current hash value to the cryptographic acceleration card or send a signature verification request in association with the current hash value to the cryptographic acceleration card, so that the cryptographic acceleration card can directly use the current hash value to verify the current signature, thereby avoiding the possible decreased efficiency caused by computation of the cryptographic acceleration card for the hash value.
  • At step 104, the dedicated blockchain node device 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 disk image using the provider public key.
  • In an embodiment, after receiving a signature verification request including the current signature, the cryptographic acceleration card can extract the current signature from the signature verification request; or the cryptographic acceleration card can directly determine the current signature after receiving a signature verification request in association with the current signature. Further, a corresponding disk image can be determined according to the signature verification request or the current signature, for example, a corresponding disk image can be determined according to a file identifier of disk image included in the signature verification request. At this time, the cryptographic acceleration card can request an image digest of the disk image from the dedicated blockchain node device or compute the image digest of the disk image in the TEE, so as to use the image digest to verify the signature of the disk image.
  • In another embodiment, after receiving a signature verification request including the current signature and the image digest, the cryptographic acceleration card can extract the current signature and the image digest from the signature verification request; or, the cryptographic acceleration card can directly determine the current signature and the image digest after receiving a signature verification request in association with the current signature and the image digest, so as to use the image digest to verify the current signature.
  • In the above-mentioned two embodiments, the image digest can be an image hash value of the disk image. A hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute the image hash value should be identical to a hash algorithm adopted by the provider to sign the disk image.
  • In an embodiment, the cryptographic acceleration card can verify the current signature in the following manner: firstly, a signature digest is obtained by decrypting the current signature using the locally pre-stored provider public key of the provider and then a corresponding image digest is determined according to the signature verification request (as in the above-mentioned two embodiments); then, whether the signature digest and the image digest are the same is determined by comparing the signature digest and the image digest, in a case that the signature digest and the image digest are the same, it is determined that the current signature passes verification; or, in a case that the signature digest and the image digest are not the same, it is determined the current signature does not pass verification; finally, a corresponding signature verification result is generated according to the comparison result.
  • At step 106, in a case that the signature verification result indicates the current signature passes verification, the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node.
  • In this embodiment, if the signature verification result indicates the current signature passes verification, it indicates that the disk image locally deployed in the dedicated blockchain node device is a disk image provided by the provider, i.e. a disk image that is not tempered and is successfully deployed, and therefore the disk image is trustable. As a result, the dedicated blockchain node device can execute the disk image to form a blockchain node. Conversely, if the signature verification result indicates the current signature does not pass verification, it indicates that the disk image locally deployed in the dedicated blockchain node device is not a standard disk image provided by the provider but a disk image that may be illegally tampered or erroneously deployed, and therefore the disk image is un-trustable. At this time, the dedicated blockchain node device can refuse to execute the disk image.
  • In an embodiment, in a case that the signature verification result indicates that the current signature does not pass verification, the disk image locally deployed in the dedicated blockchain node device is not a standard disk image provided by the provider. As a result, the dedicated blockchain node device can terminate the startup process of the dedicated blockchain node device, thereby avoiding executing a disk image different from the standard disk image. In another embodiment, the dedicated blockchain node device can also send a warning message for the disk image to at least one of a management personnel, a management device of the dedicated blockchain node device (for example, a control host for controlling a plurality of dedicated blockchain node devices at the same time), and a security service relating to the dedicated blockchain node device and the like, so that the management personnel, the management device or the security service performs corresponding processing for the disk image. Furthermore, the dedicated blockchain node device can also perform illegality detection for the disk image with a detection result included in the warning message, so that specific processing can be performed for the disk image. The response processing can include at least one of recording warning message, recording detection result of disk image and deleting disk image and the like.
  • In an embodiment, further continued from the embodiment in which the current signature is generated by the provider signing the disk image using the provider private key, in a case that the signature verification result indicates that the current signature does not pass verification, the dedicated blockchain node device can request a disk image from the provider again, and replace the currently-deployed disk image with the obtained disk image, thus ensuring the disk image deployed in the dedicated blockchain node device is consistent with the disk image provided by the provider. Furthermore, when requesting a disk image from the provider, the dedicated blockchain node device can also request a current signature performed for the disk image by the provider using its provider private key at the same time, thus ensuring the current signature corresponds to the disk image provided by the provider.
  • In an embodiment, because the deployed disk image corresponding to the current signature is a trusted disk image in a case that the signature verification result indicates that the current signature passes verification, the dedicated blockchain node device can write the disk image corresponding to the current signature (i.e. the trusted disk image) into the TEE locally deployed in the dedicated blockchain node device as a backup disk image the first time it received a signature verification result indicating the current signature passes verification. Afterwards, in a case that the signature verification result indicates that the current signature does not pass verification, the dedicated blockchain node device can read the backup disk image from the TEE, and then replace the disk image with the backup disk image and respond to the startup instruction again. A standard disk image is obtained and backed up in the TEE, so that the currently-deployed disk image is replaced with the disk image provided by the provider in a case that the current disk image is different from the standard disk image. In this way, it is guaranteed that the disk image locally deployed in the dedicated blockchain node device is consistent with the disk image provided by the provider. Further, and by using pre-stored and trusted standard disk file to replace deployed (but not trusted) disk file avoids possible increase of network load caused by requesting a standard disk image again from the provider every time that the signature verification result indicates that the current signature does not pass verification.
  • Correspondingly, FIG. 2 is a flowchart of another trusted startup method of a dedicated blockchain node device according to example embodiments of the present disclosure. The method is applied to a cryptographic acceleration card. As shown in FIG. 2, the method can include the following steps.
  • At step 202, a cryptographic acceleration card assembled on the dedicated blockchain node device receives a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, where a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card.
  • In this embodiment, a disk image (that has not been executed yet) is locally pre-deployed in the dedicated blockchain node device. The specific form of the disk image is not limited herein in the present disclosure. For example, the disk image can be an executable disk image, for example, an executable file of . exe format. At this time, the executable file can be pre-installed in an execution component of the dedicated blockchain node device, such as a hard disk drive. The disk image can also be a binary disk image, for example, a binary image of .bin format. At this time, the binary image can be pre-stored at a proper position of an execution component of the dedicated blockchain node device, such as a hard disk drive to be invoked and executed. Further, the disk image can be a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device. Correspondingly, when the binary disk image is executed, the dedicated blockchain node device is implemented as a blockchain node, for example, to realize one or more functions of blockchain visualization, contract creation and deployment, contract execution, key management and privacy computing and the like. The disk image can also be a platform disk image including the binary disk image corresponding to the blockchain node and deployed in the dedicated blockchain node device. When the platform disk image is executed, the dedicated blockchain node device is not only implemented as a blockchain node, but also can realize one or more functions such as image processing, node monitoring and service monitoring, which will not be redundantly described herein.
  • In an embodiment, the startup instruction can be in several forms which are not limited herein. For example, the startup instruction can be a machine startup instruction sent when a user (for example, a user of the dedicated blockchain node device) performs a machine startup operation for the dedicated blockchain node device; or an image execution instruction sent by a management device for the binary disk image in the dedicated blockchain node device under the startup state of the dedicated blockchain node device or the like.
  • In an embodiment, the current signature is generated by the provider of the disk image signing the disk image using the provider private key, where the provider private key and the provider public key are a pair of asymmetric keys. For example, before providing the disk image, the provider of the disk image can compute an image digest of the disk image in a Trusted Execution Environment (TEE), and then encrypt the image digest using its own provider private key to obtain a signature corresponding to the disk image. The TEE in which the provider signs the disk image can be constructed by adopting any technique of related technologies and any encryption algorithm of related technologies can be adopted for signature, which is not limited herein. It should be noted that in a case of taking a hash value of the disk image as a signature digest in the signature process, a hash algorithm adopted by the dedicated blockchain node device or the cryptographic acceleration card to compute a current hash value of the disk image after receiving a startup request should be identical to a hash algorithm adopted by the provider to compute a hash value for signing the disk image. In this way, it is ensured that a definite verification result will be obtained when verification is performed for the signature of the disk image.
  • At step 204, the cryptographic acceleration card verifies a current signature of the disk image using the provider public key and returns an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • Reference can be made to various embodiments corresponding to FIG. 1 for the specific process in which the cryptographic acceleration card realizes the trusted startup of the dedicated blockchain node device through cooperation with the dedicated blockchain node device, and thus redundant descriptions will not be made herein.
  • In the above-mentioned embodiments of the present disclosure, after the dedicated blockchain node device receives the startup instruction, the cryptographic acceleration card verifies the current signature of the currently-deployed disk image in the dedicated blockchain node device using the pre-stored provider public key of the provider of the disk image (for example, whether the signature digest included in the current signature and the image digest of the disk image are the same is determined by comparing the signature digest included in the current signature and the image digest of the disk image), such that the dedicated blockchain node device determines whether the current signature passes verification and executes the disk image in a case of further determining the currently-deployed disk image is indeed a disk image provided by the provider, thereby realizing the startup of the dedicated blockchain node device. By signature verification, it is guaranteed that the executed disk image is the same as the disk image provided by the provider. Thus, the trusted execution of the disk image is ensured, thus ensuring the trusted startup of the dedicated blockchain node device.
  • In combination with the interaction flowchart of the trusted startup method of the dedicated blockchain node device shown in FIG. 3, a process in which a trusted startup of a dedicated blockchain node device is realized through cooperation among a provider of disk image, a dedicated blockchain node device and a cryptographic acceleration card will be described below. As shown in FIG. 3, the process can include the following steps.
  • At step 302, a provider of a disk image signs the disk image provided by the provider.
  • At step 304, the provider sends the signature to a dedicated blockchain node device.
  • In an embodiment, the disk image provided by the provider can be an executable disk image, for example, an executable file of .exe format, or a binary disk image, for example, an executable file of .bin format. Furthermore, when the disk image is a binary disk image, the disk image can a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device, and the dedicated blockchain node device executing the binary disk image can be implemented as a blockchain node; or, the disk image can also be a platform disk image including the binary disk image in the dedicated blockchain node device, and the dedicated blockchain node device executing the platform disk image can not only be implemented as a blockchain node but also configured to realize other functions as above, which will not be repeated herein.
  • In an embodiment, for a standard disk image provided (or not provided yet) by the provider, the provider can compute a corresponding standard hash value in the TEE. The TEE can be constructed based on Intel Software Guard Extensions (SGX) or AMD TrustZone technique. The TEE can be locally deployed in the provider such that the provider can directly compute the standard hash value in the TEE; or, the TEE can be deployed in another component relating to the provider such that the provider can control the standard hash value to be encrypted and transmitted to the cryptographic acceleration card after computing the standard hash value in the TEE. In addition, when the image digest is a hash value of the disk image, the provider can compute the hash value by adopting a hash algorithm such as SHA algorithm, MD4 algorithm, MD5 algorithm, ETHASH algorithm, and SCRYPT algorithm. Reference can be made to the contents of related technologies for the specific process of the TEE construction and the specific process of the hash value computation, and redundant descriptions will not be made herein.
  • After obtaining the standard hash value, the provider can sign the disk image 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, signature can also be performed in another manner and will not be limited herein.
  • In this embodiment, the provider can send the signature to the cryptographic acceleration card. Because the cryptographic acceleration card is assembled on the dedicated blockchain node device, the provider can forward the signature to the cryptographic acceleration card through dedicated blockchain node device (corresponding to the step 306a), or send the signature directly to the cryptographic acceleration card (corresponding to step 306b).
  • At step 306a, the provider public key is forwarded by the dedicated blockchain node device to the cryptographic acceleration card.
  • The provider can send the signature performed for the disk image in the TEE (encrypted signature digest) to the dedicated blockchain node device which forwards the signature to the cryptographic acceleration card.
  • At step 306b, the provider sends the provider public key directly to the cryptographic acceleration card.
  • The provider can send the signature performed for the disk image in the TEE directly to the cryptographic acceleration card.
  • At step 308, the cryptographic acceleration card stores the provider public key locally.
  • In an embodiment, after receiving the provider public key forwarded by the dedicated blockchain node device or directly sent by the provider, the cryptographic acceleration card can store the provider public key in a corresponding secure key zone in the TEE, such that the provider public key is directly invoked, thereby speeding up subsequent hash values comparison.
  • In this embodiment, as an example embodiment, the provider can first send the signature corresponding to the disk image to the dedicated blockchain node device and then send the provider public key to the cryptographic acceleration card; or, as another example embodiment, the provider can first send the provider public key to the cryptographic acceleration card and then send the signature corresponding to the disk image to the dedicated blockchain node device. In other words, there is no necessary precedence between steps 302-304 "the signature corresponding to the disk image is sent to the dedicated blockchain node device" and steps 306a-308 "the provider public key is sent to the cryptographic acceleration card", and thus adjustment can be made according to actual situations.
  • Thus, pre-storage of the provider public key and the signature corresponding to the disk image is completed. The dedicated blockchain node device can receive a startup instruction at any moment after step 308, that is, no limitation is made to a time interval between the step 308 and the step 310.
  • At step 310, the dedicated blockchain node device receives a startup instruction.
  • In an embodiment, the startup instruction can be in several forms which are not limited in the present disclosure. For example, the startup instruction can be a machine startup instruction sent when a user (for example, a user of the dedicated blockchain node device) performs a machine startup operation for the dedicated blockchain node device; or an image execution instruction sent by a management device for the binary disk image in the dedicated blockchain node device under the startup state of the dedicated blockchain node device or the like.
  • After receiving the startup instruction, the dedicated blockchain node device can determine a locally deployed disk image corresponding to the startup instruction according to a predetermined rule or a file identifier included in the startup instruction. For example, in a case that the startup instruction is a machine startup instruction, a platform disk image deployed in the dedicated blockchain node device is determined as a to-be-executed disk image; in a case that the startup instruction includes a file identifier, a disk image corresponding to the file identifier is determined as a to-be-executed disk image.
  • At step 312, the dedicated blockchain node device computes a current hash of the disk image.
  • At step 314, the dedicated blockchain node device sends a signature verification request to the cryptographic acceleration card.
  • In an embodiment, after determining the disk image corresponding to the startup instruction and deployed in the dedicated blockchain node device (the to-be-executed disk image), the dedicated blockchain node device can further determine a current signature of the disk image, and send a signature verification request including the current signature to the cryptographic acceleration card, or send a signature verification request in association with the current signature to the cryptographic acceleration card. The current signature can be sent in advance by the provider to the dedicated blockchain node device which stores the current signature and the disk image locally in an associated manner.
  • Correspondingly, after receiving the signature verification request including the current signature, the cryptographic acceleration card can extract the current signature from the signature verification request; or, the cryptographic acceleration card can directly determine the current signature after receiving a signature verification request in association with the current signature. Further, a corresponding disk image can be determined according to the signature verification request or the current signature, for example, a corresponding disk image can be determined according to a file identifier of disk image included in the signature verification request. At this time, the cryptographic acceleration card can request an image hash value of the disk image from the dedicated blockchain node device or compute the image hash value of the disk image in the TEE corresponding to the cryptographic acceleration card, so as to use the image hash value to verify the signature of the disk image.
  • In an embodiment, before sending a signature verification request to the cryptographic acceleration card, the dedicated blockchain node device can compute the current hash value of the determined disk image. A hash algorithm adopted to compute the current hash value should be identical to a hash algorithm adopted by the provider to compute a signature hash value for signing the disk image to ensure that a definite verification result will be present between the current hash value and the signature hash value (hash values comparison will be meaningless if hash algorithms are inconsistent).
  • Further, the dedicated blockchain node device can also send a signature verification request including the current signature and the image hash value to the cryptographic acceleration card, or send a signature verification request in association with the current signature and the image hash value to the cryptographic acceleration card, so that the cryptographic acceleration card can directly use the image hash value to verify the current signature, thereby avoiding possible decreased efficiency caused by computation of the cryptographic acceleration card for the hash value.
  • Correspondingly, after receiving a signature verification request including the current signature and the image hash value, the cryptographic acceleration card can extract the current signature and the image hash value from the signature verification request; or, the cryptographic acceleration card can directly determine the current signature and the image hash value after receiving a signature verification request in association with the current signature and the image hash value, so as to use the image hash value to verify the current signature.
  • At step 316, the cryptographic acceleration card verifies the current signature.
  • At step 318, the cryptographic acceleration card returns a signature verification result to the dedicated blockchain node device.
  • In an embodiment, the cryptographic acceleration card can obtain a signature hash value by decrypting the signature using the pre-obtained provider public key in the TEE, and then compare the signature hash value of plaintext and the image hash value in the TEE. The comparison can be performed in a full text bit-by-bit comparison manner, that is, the bits of the current hash value and the standard hash value are compared bit by bit along a predetermined direction: if the values of all bits of the signature hash value are equal to the values of all bits of the image hash value, it is determined that the signature hash value and the image hash value are the same; on the contrary, if the value of any bit of the signature hash value is unequal to the value of the corresponding bit of the image hash value, it is determined that the signature hash value and the image hash value are not the same. After the comparison is completed, the cryptographic acceleration card can return the corresponding comparison result to the dedicated blockchain node device.
  • At step 320, the dedicated blockchain node device determines to execute the disk image or terminate the startup of the dedicated blockchain node device according to the signature verification result.
  • The image hash value is computed based on the disk image locally deployed in the dedicated blockchain node device, and the signature hash value is computed based on the signature corresponding to the standard disk image provided by the provider. Therefore, if the signature verification result indicates that the current signature passes verification, it indicates that the locally deployed disk image is a standard disk image provided by the provider and thus the disk image is trustable (the disk image is not tampered during transmission and deployment processes); if the signature verification result indicates that the current signature does not pass verification, it indicates that the locally deployed disk image is not a standard disk image provided by the provider and thus the disk image is un-trustable (the disk image can be illegally tampered during transmission and deployment processes). The dedicated blockchain node device can perform subsequent processing respectively according to the comparison result.
  • In an embodiment, in a case that the signature verification result indicates that the current signature passes verification, the dedicated blockchain node device can execute the locally deployed disk image, so as to realize startup of the dedicated blockchain node device. At this time, the locally-deployed disk image is a trusted standard disk image. Therefore, the disk image can be directly executed to realize the startup of the dedicated blockchain node device. Continued from the previously mentioned embodiment, in a case that the disk image is a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device, the dedicated blockchain node device can be implemented as a blockchain node to, for example, realize blockchain visualization, contract creation, deployment and execution, key management and/or privacy computing and so on when the binary disk image is executed; in a case that the disk image is a platform disk image including the binary disk image in the dedicated blockchain node device, when the platform disk image is executed, the dedicated blockchain node device is not only implemented as a blockchain node but also configured to realize other functions such as image processing, node monitoring and/or service monitoring other than blockchain function, which will not be repeated herein.
  • In an embodiment, continued from the embodiment in which the signature is obtained by the provider signing the disk image provided by it in the TEE, in a case that the signature verification result indicates that the current signature does not pass verification, the dedicated blockchain node device can request a standard disk image again from the provider, and replace the current disk image with the obtained standard disk image to ensure the disk image deployed in the dedicated blockchain node device is consistent with the standard disk image. Furthermore, the dedicated blockchain node device can request the current signature of the standard disk image at the same time when requesting the standard disk image, or request the current signature of the standard disk image from the provider after the standard disk image obtained from the provider passes trusted verification, so as to ensure the current signature corresponds to the standard disk image.
  • In an embodiment, the dedicated blockchain node device can pre-store a disk image as a backup disk image in the TEE locally deployed. As a result, in a case that the signature verification result indicates that the current signature does not pass verification, the dedicated blockchain node device can read the backup disk image from the TEE, and then replace the locally-deployed disk image with the backup disk image, and respond to the startup instruction again. In this way, it is guaranteed that the disk image locally deployed in the dedicated blockchain node device is consistent with the disk image provided by the provider, so that the trusted startup of the dedicated blockchain node device can be realized as possible even in a case that the locally-deployed disk image is un-trustable.
  • Further, the dedicated blockchain node device can write the disk image corresponding to the current hash value (i.e. the locally-deployed trusted disk image) into the TEE locally deployed in the dedicated blockchain node device as a backup disk image the first time it received the signature verification result indicating the current signature passes verification. Alternatively, the dedicated blockchain node device can also actively request the disk image corresponding to the signature from the provider before receiving the startup instruction. Alternatively, corresponding to the previously mentioned embodiment in which the provider public key is forwarded by the dedicated blockchain node device, the provider can also send the disk image in association with the public key to the dedicated blockchain node device so that the dedicated blockchain node device writes the disk image into the locally-deployed TEE as a backup disk image.
  • In an embodiment, in a case that the signature verification result indicates the current signature does not pass verification, the disk image locally deployed in the dedicated blockchain node device is not a standard disk image provided by the provider. Therefore, the dedicated blockchain node device can terminate the startup process of the dedicated blockchain node device, thus avoiding executing a disk image different from the standard disk image.
  • In another embodiment, in a case that the signature verification result indicates that the current signature does not pass verification, the dedicated blockchain node device can also send a warning for the currently-deployed disk image. For example, warnings, in the form of sound, light or visual popup window can be sent to a user so that the user can know the disk image is not a standard disk image. Further, an illegality detection can be performed for the disk image with a detection result displayed to the user, so that the user can know more detailed illegal information of the disk image and further perform specific corresponding processing. A warning message can also be sent to a management device of the dedicated blockchain node device (for example, a control host controlling a plurality of dedicated blockchain node devices) or a security service relating to the dedicated blockchain node device so that the management device or the security service can perform corresponding processing for the disk image. Similarly, an illegality detection can also be performed for the disk image with a detection result included in the warning message, so that the corresponding processing can be performed specifically. The response processing can include at least one of recording warning message, recording detection result of disk image, and deleting disk image and the like.
  • FIG. 4 is a structural schematic diagram of a dedicated blockchain node device according to example embodiments of the present disclosure. As shown in FIG. 4, from 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, the device can further include hardware required for other services. The processor 402 reads corresponding computer programs from the non-volatile memory 410 to the memory 408 for running, so as to logically form a trusted startup apparatus of a dedicated blockchain node device. Of course, in addition to the software implementation, one or more embodiments of the present disclosure do not preclude other implementations, for example, logic device or a combination of software and hardware or the like. That is, the executing subject of the following processing is not limited to each logic unit and can also be hardware or logic device.
  • As shown in FIG. 5, in a software implementation, a trusted startup apparatus of a dedicated blockchain node device can include:
    • a request sending module 501, configured to enable the dedicated blockchain node device to initiate a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    • a result receiving module 502, configured to enable the dedicated blockchain node device to receive a signature verification result returned by the cryptographic acceleration card, wherein the signature verification result is obtained by the cryptographic acceleration card verifying a current signature of the disk image using the provider public key;
    • an image executing module 503, configured to enable the dedicated blockchain node device to execute the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • Optionally, the disk image deployed in the dedicated blockchain node device includes:
    • a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device; or
    • a platform disk image deployed in the dedicated blockchain node device, where the platform disk image includes the binary disk image.
  • Optionally, the current signature is generated by the provider of the disk image signing the disk image using a provider private key, where the provider private key and the provider public key form a pair of asymmetric keys.
  • Optionally, the apparatus further includes:
    a signature obtaining module 504, configured to enable the dedicated blockchain node device to request again a disk image and a current signature corresponding to the disk image from the provider in a case that the signature verification result indicates the current signature does not pass verification.
  • Optionally, the apparatus further includes:
    • a startup terminating module 505, configured to the dedicated blockchain node device to terminate a startup process of the dedicated blockchain node device in a case that the signature verification result indicates the current signature does not pass verification; and/or,
    • a warning module 506, configured to enable the dedicated blockchain node device to send a warning for the disk image in a case that the signature verification result indicates the current signature does not pass verification.
  • Optionally, the apparatus further includes:
    • an image reading module 507, configured to enable the dedicated blockchain node device to read a backup disk image from a locally-deployed trusted execution environment in a case that the signature verification result indicates the current signature does not pass verification;
    • an image replacing module 508, configured to enable the dedicated blockchain node device to replace the disk image with the backup disk image and respond to the startup instruction again.
  • Optionally, the apparatus further includes:
    an image backing-up module 509, configured to enable the dedicated blockchain node device to write the disk image corresponding to the current signature into the trusted execution environment locally deployed by the dedicated blockchain node device as the backup disk image the first time it received a signature verification result indicating the current signature passes verification.
  • FIG. 6 is a structural schematic diagram of a cryptographic acceleration card according to example embodiments of the present disclosure. As shown in FIG. 6, from 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 crypto-operation unit 612 and a secure key zone 614. Of course, the device can further include hardware required for other services. The crypto-operation unit 612 stores received or generated relevant keys in the secure key zone 614 so that the processor 602 invoke the keys to realize relevant functions such as encryption, decryption, signature and/or signature verification. The processor 602 reads corresponding computer programs from the non-volatile memory 610 to the memory 608 for running, so as to logically form a trusted startup apparatus of a dedicated blockchain node device. Of course, in addition to the software implementation, one or more embodiments of the present disclosure do not preclude other implementations, for example, logic device or a combination of software and hardware or the like. That is, the executing subject of the following processing is not limited to each logic unit and can also be hardware or logic device.
  • As shown in FIG. 7, in a software implementation, a trusted startup apparatus of a dedicated blockchain node device can include:
    • a request receiving module 701, configured to enable a cryptographic acceleration card assembled on the dedicated blockchain node device to receive a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    • an image verifying module 702, configured to enable the cryptographic acceleration card to verify a current signature of the disk image using the provider public key, and return an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  • Optionally, the disk image deployed in the dedicated blockchain node device includes:
    • a binary disk image corresponding to a blockchain node and deployed in the dedicated blockchain node device; or
    • a platform disk image deployed in the dedicated blockchain node device, where the platform disk image includes the binary disk image.
  • Optionally, the current signature is generated by the provider of the disk image signing the disk image using a provider private key, where the provider private key and the provider public key form a pair of asymmetric keys.
  • The systems, apparatuses, modules or units described in the above-mentioned embodiments can be specifically implemented by a computer chip or an entity or can be implemented by a product with a particular function. A typical implementing device can be a computer and the computer can specifically be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device, or a combination of any several devices of the above-mentioned devices.
  • In a typical configuration, the computer can include one or more central processing units (CPU), one or more input/output interfaces, one or more network interfaces and one or more memories.
  • The memory can include a non-permanent memory, a random access memory (RAM), and/or a non-volatile memory and the like in a computer readable medium, for example, read only memory (ROM), or flash RAM. The memory is one example of the computer readable medium.
  • The computer readable medium includes permanent, non-permanent, mobile and non-mobile media, which can realize information storage by any method or technology. The information can be computer readable instructions, data structures, program modules and other data. The examples of the computer storage medium include but not limited to: a phase change random access memory (PRAM), a Static Random Access Memory (SRAM), a Dynamic Random Access Memory (DRAM), and other types of RAMs, Read-Only Memory (ROM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a Flash Memory, or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical storage, cassette type magnetic tape, magnetic disk storage, quantum memory, storage medium based on graphene, or other magnetic storage device or other non-transmission medium for storing information accessible by computing devices. According to the definition of the specification, the computer readable medium does not include transitory computer readable media, for example, modulated data signal and carriers.
  • It should be noted that the term "including", "containing" or any variation thereof is intended to encompass non-exclusive inclusion, so that a process, method, product or device including a series of elements includes not only those elements but also other elements not listed explicitly or those elements inherent to such a process, method, product or device. Without more limitations, an element defined by the statement "including a..." shall not be precluded to include additional same elements in a process, method, product or device including the elements.
  • The specific embodiments are described as above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a sequence different from the embodiments to achieve the desired result. Further, the processes shown in drawings do not necessarily require a particular sequence or a continuous sequence shown to achieve the desired result. In some embodiments, a multi-task processing and parallel processing is possible and can also be advantageous.
  • The terms used in one or more embodiments of the present disclosure are for the purpose of describing particular embodiments only, and are not intended to limit the one or more embodiments of the present disclosure. Terms "a", "the" and "said" used in their singular forms in one or more embodiments of the present disclosure and the appended claims are also intended to include plurality, unless clearly indicated otherwise in the context. It should also be understood that the term "and/or" as used herein refers to and includes 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," and the like can be used in one or more embodiments of the present disclosure to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one category of information from another. For example, without departing from the scope of one or more embodiments of the present disclosure, first information can be referred as second information; and similarly, the second information can also be referred as the first information. Depending on the context, the term "if' as used herein can be interpreted as "when" or "upon" or "in response to determining".
  • The above-mentioned disclosure is merely illustrative of preferred embodiments of one or more embodiments of the present disclosure but not intended to limit the present disclosure, and any modifications, equivalent substitutions, adaptations thereof made within the spirit and principles of the disclosure shall be encompassed in the scope of protection of the present disclosure.

Claims (15)

  1. A trusted startup method of a dedicated blockchain node device, comprising:
    initiating, by the dedicated blockchain node device, a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    receiving, by the dedicated blockchain node device, a signature verification result returned by the cryptographic acceleration card, wherein the signature verification result is obtained by the cryptographic acceleration card verifying a current signature of the disk image using the provider public key;
    executing, by the dedicated blockchain node device, the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  2. The method according to claim 1, wherein the disk image deployed in the dedicated blockchain node device comprises:
    a binary disk image corresponding to the blockchain node and deployed in the dedicated blockchain node device; or
    a platform disk image deployed in the dedicated blockchain node device, wherein the platform disk image comprises the binary disk image.
  3. The method according to claim 1, wherein the current signature is generated by the provider of the disk image signing the disk image using a provider private key, wherein the provider private key and the provider public key form a pair of asymmetric keys.
  4. The method according to claim 3, further comprising:
    requesting, by the dedicated blockchain node device, a disk image and a corresponding current signature again from the provider in a case that the signature verification result indicates the current signature does not pass verification.
  5. The method according to claim 1, wherein in a case that the signature verification result indicates the current signature does not pass verification, the method further comprises:
    terminating, by the dedicated blockchain node device, a startup process of the dedicated blockchain node device; and/or,
    sending, by the dedicated blockchain node device, a warning for the disk image.
  6. The method according to claim 1, further comprising:
    in a case that the signature verification result indicates the current signature does not pass verification, reading, by the dedicated blockchain node device, a backup disk image from a trusted execution environment locally deployed;
    replacing, by the dedicated blockchain node device, the disk image with the backup disk image, and responding to the startup instruction again.
  7. The method according to claim 6, further comprising:
    after first receiving the signature verification result indicating the current signature passes verification, writing, by the dedicated blockchain node device, the disk image corresponding to the current signature into the trusted execution environment locally deployed by the dedicated blockchain node device as the backup disk image.
  8. A trusted startup method of a dedicated blockchain node device, comprising:
    receiving, by a cryptographic acceleration card assembled on the dedicated blockchain node device, a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    verifying, by the cryptographic acceleration card, a current signature of the disk image using the provider public key, and returning an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  9. The method according to claim 8, wherein the disk image deployed in the dedicated blockchain node device comprises:
    a binary disk image corresponding to the blockchain node and deployed in the dedicated blockchain node device; or
    a platform disk image deployed in the dedicated blockchain node device, wherein the platform disk image comprises the binary disk image.
  10. The method according to claim 8, wherein the current signature is generated by the provider of the disk image signing the disk image using a provider private key, wherein the provider private key and the provider public key form a pair of asymmetric keys.
  11. A trusted startup apparatus of a dedicated blockchain node device, comprising:
    a request sending module, configured to enable the dedicated blockchain node device to initiate a signature verification request for a disk image deployed in the dedicated blockchain node device to a cryptographic acceleration card assembled on the dedicated blockchain node device in response to receiving a startup instruction, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    a result receiving module, configured to enable the dedicated blockchain node device to receive a signature verification result returned by the cryptographic acceleration card, wherein the signature verification result is obtained by the cryptographic acceleration card verifying a current signature of the disk image using the provider public key;
    an image executing module, configured to enable the dedicated blockchain node device to execute the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  12. A trusted startup apparatus of a dedicated blockchain node device, comprising:
    a request receiving module, configured to enable a cryptographic acceleration card assembled on the dedicated blockchain node device to receive a signature verification request initiated by the dedicated blockchain node device for a disk image deployed in the dedicated blockchain node device, wherein a provider public key of a provider of the disk image is pre-stored in the cryptographic acceleration card;
    an image verifying module, configured to enable the cryptographic acceleration card to verify a current signature of the disk image using the provider public key, and return an obtained signature verification result to the dedicated blockchain node device, such that the dedicated blockchain node device executes the disk image deployed in the dedicated blockchain node device to form a blockchain node in a case that the signature verification result indicates the current signature passes verification.
  13. A dedicated blockchain node device, comprising:
    a processor;
    a memory for storing processor executable instructions;
    wherein the processor implements a method according to any of claims 1-7 by running the executable instructions.
  14. A cryptographic acceleration card, comprising:
    a processor;
    a memory for storing processor executable instructions;
    wherein the processor implements a method according to any of claims 8-10 by running the executable instructions.
  15. A computer readable storage medium having computer instructions stored thereon, wherein the instructions are executed by a processor to implement steps in a method according to any of claims 1-10.
EP21179695.8A 2020-07-08 2021-06-16 Trusted startup methods and apparatuses of dedicated blockchain node device Active EP3937041B1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010653803.2A CN111541553B (en) 2020-07-08 2020-07-08 Trusted starting method and device of block chain all-in-one machine

Publications (2)

Publication Number Publication Date
EP3937041A1 true EP3937041A1 (en) 2022-01-12
EP3937041B1 EP3937041B1 (en) 2023-08-23

Family

ID=71979748

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21179695.8A Active EP3937041B1 (en) 2020-07-08 2021-06-16 Trusted startup methods and apparatuses of dedicated blockchain node device

Country Status (3)

Country Link
US (1) US11604633B2 (en)
EP (1) EP3937041B1 (en)
CN (2) CN113971289A (en)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113971289A (en) * 2020-07-08 2022-01-25 支付宝(杭州)信息技术有限公司 Trusted starting method and device of block chain all-in-one machine
CN111538996B (en) * 2020-07-08 2021-06-29 支付宝(杭州)信息技术有限公司 Trusted starting method and device of block chain all-in-one machine
CN111539829B (en) 2020-07-08 2020-12-29 支付宝(杭州)信息技术有限公司 To-be-filtered transaction identification method and device based on block chain all-in-one machine
CN112491812B (en) 2020-07-08 2022-03-01 支付宝(杭州)信息技术有限公司 Hash updating method and device of block chain all-in-one machine
CN111541789A (en) * 2020-07-08 2020-08-14 支付宝(杭州)信息技术有限公司 Data synchronization method and device based on block chain all-in-one machine
CN111541784B (en) 2020-07-08 2021-07-20 支付宝(杭州)信息技术有限公司 Transaction processing method and device based on block chain all-in-one machine
CN111541726B (en) 2020-07-08 2021-05-18 支付宝(杭州)信息技术有限公司 Replay transaction identification method and device based on block chain all-in-one machine
CN111541783B (en) 2020-07-08 2020-10-20 支付宝(杭州)信息技术有限公司 Transaction forwarding method and device based on block chain all-in-one machine
CN112765586A (en) * 2021-01-12 2021-05-07 湖北宸威玺链信息技术有限公司 Block chain-based deployment file distribution method, equipment and storage medium
CN113032482B (en) * 2021-03-10 2022-05-13 杭州链网科技有限公司 Construction method and system of cross-chain transfer bridge
CN114584315B (en) * 2022-02-24 2024-04-02 武汉天喻信息产业股份有限公司 Block chain all-in-one machine, working method and construction method

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108229142A (en) * 2017-12-28 2018-06-29 中国人民银行数字货币研究所 A kind of method and apparatus upgraded based on digital cash wallet terminal-pair wallet
CN105320891B (en) * 2015-11-18 2018-10-09 北京微智全景信息技术有限公司 A kind of method and device of computer security loading system mirror image
CN110855791A (en) * 2019-11-18 2020-02-28 腾讯科技(深圳)有限公司 Block link point deployment method and related equipment

Family Cites Families (87)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7194092B1 (en) 1998-10-26 2007-03-20 Microsoft Corporation Key-based secure storage
US7409546B2 (en) 1999-10-20 2008-08-05 Tivo Inc. Cryptographically signed filesystem
US7526654B2 (en) * 2001-10-16 2009-04-28 Marc Charbonneau Method and system for detecting a secure state of a computer system
US7716494B2 (en) 2004-07-15 2010-05-11 Sony Corporation Establishing a trusted platform in a digital processing system
US7644287B2 (en) 2004-07-29 2010-01-05 Microsoft Corporation Portion-level in-memory module authentication
US7698744B2 (en) 2004-12-03 2010-04-13 Whitecell Software Inc. Secure system for allowing the execution of authorized computer program code
US8239686B1 (en) 2006-04-27 2012-08-07 Vudu, Inc. Method and system for protecting against the execution of unauthorized software
US8116455B1 (en) 2006-09-29 2012-02-14 Netapp, Inc. System and method for securely initializing and booting a security appliance
US9053323B2 (en) * 2007-04-13 2015-06-09 Hewlett-Packard Development Company, L.P. Trusted component update system and method
US8631397B2 (en) 2008-03-31 2014-01-14 Microsoft Corporation Virtualized application image patching
US9980146B2 (en) * 2009-01-28 2018-05-22 Headwater Research Llc Communications device with secure data path processing agents
US20120084445A1 (en) 2010-10-05 2012-04-05 Brock Scott L Automatic replication and migration of live virtual machines
US10496834B2 (en) * 2011-10-25 2019-12-03 Cupp Computing As Secure computing system
US9009840B1 (en) * 2012-01-23 2015-04-14 Amazon Technologies, Inc. Validating machine images
US9158913B2 (en) * 2012-07-09 2015-10-13 Ca, Inc. Managing virtual machines using owner digital signatures
US20140181975A1 (en) * 2012-11-06 2014-06-26 William Spernow Method to scan a forensic image of a computer system with multiple malicious code detection engines simultaneously from a master control point
US9104687B2 (en) 2012-12-20 2015-08-11 Dropbox, Inc. System and method for preventing duplicate uploads of modified photos in a synchronized content management system
US9336395B2 (en) 2013-01-25 2016-05-10 Hewlett-Packard Development Company, L.P. Boot driver verification
WO2014177904A1 (en) 2013-04-29 2014-11-06 Freescale Semiconductor, Inc. Memory controller
US9118670B2 (en) * 2013-08-30 2015-08-25 U-Me Holdings LLC Making a user's data, settings, and licensed content available in the cloud
CN105122738B (en) * 2014-03-26 2018-06-15 华为技术有限公司 Certificate configuration methods, devices and systems based on network function virtualization
KR101846427B1 (en) * 2014-04-28 2018-04-06 인텔 코포레이션 Securely booting a computing device
US10313257B1 (en) * 2014-06-12 2019-06-04 Tripwire, Inc. Agent message delivery fairness
US9634951B1 (en) * 2014-06-12 2017-04-25 Tripwire, Inc. Autonomous agent messaging
CN104200154A (en) * 2014-09-22 2014-12-10 上海众人科技有限公司 Identity based installation package signing method and identity based installation package signing device
US9971397B2 (en) * 2014-10-08 2018-05-15 Apple Inc. Methods and apparatus for managing power with an inter-processor communication link between independently operable processors
CN104539622B (en) * 2014-12-31 2018-01-23 华为技术有限公司 Depth method of proof, computing device and the computer system of virtual machine
CA3199536A1 (en) 2015-04-14 2016-10-20 Capital One Services, Llc Systems and methods for secure firmware validation
CN106295318A (en) 2015-06-05 2017-01-04 北京壹人壹本信息科技有限公司 A kind of system start-up bootstrap technique and device
JP2017004220A (en) * 2015-06-09 2017-01-05 株式会社東芝 Communication device, communication system, communication method, and program
US10075439B1 (en) * 2015-11-06 2018-09-11 Cisco Technology, Inc. Programmable format for securely configuring remote devices
US11669320B2 (en) * 2016-02-12 2023-06-06 Nutanix, Inc. Self-healing virtualized file server
US10404469B2 (en) 2016-04-08 2019-09-03 Chicago Mercantile Exchange Inc. Bilateral assertion model and ledger implementation thereof
CN106156635A (en) * 2016-07-29 2016-11-23 深圳兆日科技股份有限公司 Method for starting terminal and device
US11461485B2 (en) * 2016-08-12 2022-10-04 ALTR Solutions, Inc. Immutable bootloader and firmware validator
US10520110B2 (en) 2016-10-10 2019-12-31 Citrix Systems, Inc. Systems and methods for executing cryptographic operations across different types of processing hardware
CN106506163B (en) 2016-10-21 2019-11-15 北京小米移动软件有限公司 ROM packet processing method and device
JP6888673B2 (en) 2016-10-27 2021-06-16 株式会社デンソー Systems and methods for authenticating and authorizing devices
CN106599729A (en) * 2016-12-09 2017-04-26 郑州云海信息技术有限公司 Safety verification method and system for driving program
CN107077557B (en) * 2016-12-29 2020-07-31 深圳前海达闼云端智能科技有限公司 Method and device for releasing and verifying software application program
US20180198620A1 (en) * 2017-01-11 2018-07-12 Raptor Engineering, LLC Systems and methods for assuring data on leased computing resources
US10423791B2 (en) * 2017-04-27 2019-09-24 Microsoft Technology Licensing, Llc Enabling offline restart of shielded virtual machines using key caching
US20180367528A1 (en) * 2017-06-12 2018-12-20 Cyberark Software Ltd. Seamless Provision of Authentication Credential Data to Cloud-Based Assets on Demand
CN109309651B (en) 2017-07-28 2021-12-28 斑马智行网络(香港)有限公司 File transmission method, device, equipment and storage medium
US11061776B2 (en) * 2017-08-07 2021-07-13 Datto, Inc. Prioritization and source-nonspecific based virtual machine recovery apparatuses, methods and systems
US10795977B2 (en) * 2017-08-24 2020-10-06 Oracle International Corporation Digital asset traceability and assurance using a distributed ledger
CN108305072B (en) 2018-01-04 2021-02-26 上海点融信息科技有限责任公司 Method, apparatus, and computer storage medium for deploying a blockchain network
EP3746879B1 (en) 2018-01-29 2023-06-21 Shi, Alexander Secure blockchain integrated circuit
US20190306173A1 (en) 2018-04-02 2019-10-03 Ca, Inc. Alert smart contracts configured to manage and respond to alerts related to code
US20190305957A1 (en) 2018-04-02 2019-10-03 Ca, Inc. Execution smart contracts configured to establish trustworthiness of code before execution
CN108648079A (en) * 2018-05-02 2018-10-12 北京阿尔山金融科技有限公司 Block chain node monitoring method, apparatus and system
US10642984B2 (en) 2018-06-12 2020-05-05 The United States Of America As Represented By The Secretary Of The Navy Secure drive and method for booting to known good-state
US11082850B2 (en) * 2018-06-26 2021-08-03 At&T Intellectual Property I, L.P. Blockchain based wireless access point password management
US10754693B2 (en) 2018-07-05 2020-08-25 Vmware, Inc. Secure transfer of control over computational entities in a distributed computing environment
CN109375944B (en) 2018-08-28 2021-10-01 浪潮金融信息技术有限公司 Terminal software distribution verification method based on block chain data structure
US11133923B2 (en) 2018-10-24 2021-09-28 Landis+Gyr Innovations, Inc. Cryptographic operations using internet of things device pool
WO2020106498A1 (en) 2018-11-19 2020-05-28 Rare Bits, Inc. Lazy updating and state prediction for blockchain-based applications
CN109634619B (en) 2018-11-23 2022-05-10 试金石信用服务有限公司 Trusted execution environment implementation method and device, terminal device and readable storage medium
CN111277553B (en) * 2018-12-05 2022-05-24 阿里巴巴集团控股有限公司 Credible node determination method and device based on block chain network
CN109685502B (en) 2018-12-06 2021-04-30 成都佰纳瑞信息技术有限公司 Accelerated consensus method applicable to block chain network
CN109788032B (en) 2018-12-17 2021-12-14 深圳壹账通智能科技有限公司 Method and device for acquiring mirror image file, computer equipment and storage medium
US20200204510A1 (en) 2018-12-21 2020-06-25 Chicago Mercantile Exchange Inc. Multiple chain message data recordation with adjustable visibility permissioning
CN109491694A (en) 2019-01-04 2019-03-19 中国银行股份有限公司 Using update method and device, data push method and device
CN109784058A (en) 2019-01-07 2019-05-21 中国银行股份有限公司 Version strong consistency method of calibration, client, server and storage medium
CA3058239C (en) 2019-03-26 2021-01-05 Alibaba Group Holding Limited Field-programmable gate array based trusted execution environment for use in a blockchain network
CN110149316B (en) * 2019-04-22 2022-05-17 众安信息技术服务有限公司 Block chain publishing method and device
US10860265B2 (en) 2019-04-24 2020-12-08 Kyocera Document Solutions Inc. Image forming system, server, image forming apparatus, and image forming method that reduce server capacity and allows to pull print
US10999075B2 (en) * 2019-06-17 2021-05-04 Advanced New Technologies Co., Ltd. Blockchain-based patrol inspection proof storage method, apparatus, and electronic device
US10797887B2 (en) * 2019-06-26 2020-10-06 Alibaba Group Holding Limited Confidential blockchain transactions
CN110287170B (en) 2019-06-28 2021-05-11 杭州复杂美科技有限公司 Database upgrading method, state data calling method, device and storage medium
CN110535654B (en) 2019-07-23 2021-09-14 平安科技(深圳)有限公司 Block chain based parallel system deployment method and device and computer equipment
US11496518B2 (en) 2019-08-02 2022-11-08 Dell Products L.P. System and method for distributed network access control
CN110535938B (en) 2019-08-29 2021-07-27 腾讯科技(深圳)有限公司 Data processing method, equipment and storage medium based on intelligent contract
CN110502268A (en) 2019-08-29 2019-11-26 恩亿科(北京)数据科技有限公司 Application program update method, apparatus, server and storage medium
US11539530B2 (en) 2019-09-27 2022-12-27 Divi Labs And Technologies Sociedad Anonima Remote blockchain masternode deployment
CN110852734B (en) 2019-11-06 2021-07-02 上海景域文化传播股份有限公司 Scenic spot service settlement method and system based on block chain and electronic equipment
CN110989994B (en) 2019-11-18 2024-04-26 腾讯科技(深圳)有限公司 Code version management method, device, terminal and storage medium based on block chain
CN110995480B (en) 2019-11-25 2022-09-20 百度在线网络技术(北京)有限公司 Block chain network deployment method, device, electronic equipment and medium
US11144652B1 (en) 2019-12-19 2021-10-12 Xilinx, Inc. Secure update of programmable integrated circuits in data center computing environments
CN111143854B (en) 2019-12-25 2021-11-30 眸芯科技(上海)有限公司 Safe starting device, system and method of chip
CN111259348B (en) * 2020-02-20 2023-03-07 国网信息通信产业集团有限公司 Method and system for safely running executable file
US11243781B2 (en) * 2020-03-04 2022-02-08 Citrix Systems, Inc. Provisioning services (PVS) cloud streaming with read cache file storing preboot data including a network driver
CN111581277B (en) 2020-04-07 2021-09-17 浙商银行股份有限公司 Block chain management method based on container technology
CN111414612B (en) 2020-06-05 2020-10-16 腾讯科技(深圳)有限公司 Security protection method and device for operating system mirror image and electronic equipment
CN112491812B (en) 2020-07-08 2022-03-01 支付宝(杭州)信息技术有限公司 Hash updating method and device of block chain all-in-one machine
CN111538996B (en) * 2020-07-08 2021-06-29 支付宝(杭州)信息技术有限公司 Trusted starting method and device of block chain all-in-one machine
CN113971289A (en) * 2020-07-08 2022-01-25 支付宝(杭州)信息技术有限公司 Trusted starting method and device of block chain all-in-one machine

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105320891B (en) * 2015-11-18 2018-10-09 北京微智全景信息技术有限公司 A kind of method and device of computer security loading system mirror image
CN108229142A (en) * 2017-12-28 2018-06-29 中国人民银行数字货币研究所 A kind of method and apparatus upgraded based on digital cash wallet terminal-pair wallet
CN110855791A (en) * 2019-11-18 2020-02-28 腾讯科技(深圳)有限公司 Block link point deployment method and related equipment

Also Published As

Publication number Publication date
CN113971289A (en) 2022-01-25
US11604633B2 (en) 2023-03-14
US20210344506A1 (en) 2021-11-04
CN111541553A (en) 2020-08-14
CN111541553B (en) 2021-08-24
EP3937041B1 (en) 2023-08-23

Similar Documents

Publication Publication Date Title
EP3937041B1 (en) Trusted startup methods and apparatuses of dedicated blockchain node device
EP3937046B1 (en) Trusted startup methods and apparatuses of blockchain integrated station
US11516011B2 (en) Blockchain data processing methods and apparatuses based on cloud computing
EP3937422B1 (en) Dedicated blockchain node devices and automatic blockchain construction methods and apparatuses
US11616636B2 (en) Hash updating methods and apparatuses of blockchain integrated station
CN111541724B (en) Block chain all-in-one machine and automatic node adding method and device thereof
CN111541552B (en) Block chain all-in-one machine and automatic node adding method and device thereof
US20210328810A1 (en) Methods and apparatuses for processing transactions based on blockchain integrated station
US11626984B2 (en) Blockchain integrated station and cryptographic acceleration card, key management methods and apparatuses
EP3937053B1 (en) Methods and apparatuses for transferring transaction based on blockchain integrated station
EP3940575A1 (en) Methods and apparatuses for identifying to-be-filtered transaction based on dedicated blockchain node device

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20210616

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

B565 Issuance of search results under rule 164(2) epc

Effective date: 20211117

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20220826

RIC1 Information provided on ipc code assigned before grant

Ipc: H04L 9/32 20060101ALI20230203BHEP

Ipc: H04L 67/104 20220101ALI20230203BHEP

Ipc: H04L 9/40 20220101ALI20230203BHEP

Ipc: H04L 9/00 20060101ALI20230203BHEP

Ipc: G06F 8/61 20180101ALI20230203BHEP

Ipc: G06F 21/64 20130101ALI20230203BHEP

Ipc: G06F 21/60 20130101ALI20230203BHEP

Ipc: G06F 21/51 20130101AFI20230203BHEP

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20230320

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: CH

Ref legal event code: EP

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602021004451

Country of ref document: DE

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230922

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

REG Reference to a national code

Ref country code: NL

Ref legal event code: MP

Effective date: 20230823

REG Reference to a national code

Ref country code: AT

Ref legal event code: MK05

Ref document number: 1603440

Country of ref document: AT

Kind code of ref document: T

Effective date: 20230823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20231124

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20231223

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: PT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20231226

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20231123

Ref country code: NL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: LT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: IS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20231223

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: GR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20231124

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: AT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: PL

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: SM

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: RO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: ES

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: EE

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: DK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: CZ

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

Ref country code: SK

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20230823

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT