CN112162781B - Method and device for dual-core security initiation based on trusted root metric and related products - Google Patents

Method and device for dual-core security initiation based on trusted root metric and related products Download PDF

Info

Publication number
CN112162781B
CN112162781B CN202011017943.7A CN202011017943A CN112162781B CN 112162781 B CN112162781 B CN 112162781B CN 202011017943 A CN202011017943 A CN 202011017943A CN 112162781 B CN112162781 B CN 112162781B
Authority
CN
China
Prior art keywords
operating system
blockchain node
metric
root
core
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.)
Active
Application number
CN202011017943.7A
Other languages
Chinese (zh)
Other versions
CN112162781A (en
Inventor
阮安邦
王佳帅
魏明
陈旭明
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.)
Beijing Octa Innovations Information Technology Co Ltd
Original Assignee
Beijing Octa Innovations 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 Beijing Octa Innovations Information Technology Co Ltd filed Critical Beijing Octa Innovations Information Technology Co Ltd
Priority to CN202011017943.7A priority Critical patent/CN112162781B/en
Publication of CN112162781A publication Critical patent/CN112162781A/en
Application granted granted Critical
Publication of CN112162781B publication Critical patent/CN112162781B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4411—Configuring for operating with peripheral devices; Loading of device drivers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Storage Device Security (AREA)

Abstract

The embodiment of the application provides a method, a device and related products for dual-core security initiation based on trusted root metrics, wherein the method comprises the following steps: when the blockchain node is powered on, starting by loading an operating system of the blockchain node into a first core of the blockchain node to determine a trusted root metric of the operating system; loading the application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program; and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program. The embodiment of the application can realize the comprehensive evaluation of the trusted state of the blockchain node, reduce the overall time consumption for performing the trusted evaluation, and improve the timeliness of the trusted evaluation.

Description

Method and device for dual-core security initiation based on trusted root metric and related products
Technical Field
The present disclosure relates to the field of blockchain technologies, and in particular, to a method, an apparatus, and a related product for dual-core secure boot based on a trusted root metric.
Background
In the prior art, when the credible judgment is carried out on the block chain link points, whether the operating system installed on the block chain nodes is credible is mainly judged, and the specific process is as follows: and in the process of powering on the block chain node but before the operating system is started, successively performing trusted judgment and transfer of trusted judgment control rights on the BIOS, the OS loader and the OS according to the sequence, and starting the operating system if the OS is finally judged to be trusted.
However, from the perspective of security, for the blockchain node, the operating system is only one factor affecting the security of the blockchain node, and after the operating system starts to run, a large number of applications are still running on the blockchain node, and whether these applications are trusted or not often affects the security of the blockchain node, especially in the internet era, and whether the blockchain node is in the whole internet environment or not actually the applications are trusted or not can meet a great challenge.
For this reason, it is desirable to provide a solution that comprehensively evaluates the trusted status of the blockchain nodes.
Disclosure of Invention
Based on the above problems, the embodiments of the present application provide a method, an apparatus, and a related product for dual-core secure boot based on a trusted root metric.
The embodiment of the application discloses the following technical scheme:
1. a method for dual-core secure boot based on a trusted root metric, comprising:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
Optionally, in an embodiment of the present application, at power-up of a blockchain node, the booting by loading an operating system of the blockchain node into a first core of the blockchain node to determine a root of trust metric of the operating system includes:
extracting executable files and/or library files of the operating system;
loading an executable file and/or a library file to a first core run of the blockchain node;
calculating the credible root metric in the running process of the executable file and/or the library file;
And determining the credible root metric of the operating system according to the credible root metrics of the executable file and/or the library file.
Optionally, in an embodiment of the present application, the loading the application of the blockchain node into the second core of the blockchain node is started to determine a root-of-trust metric of the application, including:
extracting executable files and/or library files of the application program;
loading the executable file and/or library file to a second core run;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the application program according to the credible root metrics of the executable file and/or the library file.
Optionally, in an embodiment of the present application, the loading the application of the blockchain node into the second core of the blockchain node is started to determine a root-trusted measure of the application, which includes: creating a first virtual operating system and a second virtual operating system in the second core;
the loading of the executable file and/or the library file into the second core operation comprises the following steps: and loading the executable file and/or the library file into the first virtual operating system and/or the second virtual operating system to run.
Optionally, in an embodiment of the present application, the loading the application of the blockchain node to the second core of the blockchain node is started to determine a root-trusted measure of the application, further includes: extracting a configuration file of the application program; and creating a third virtual operating system in the second core;
further comprises: and loading the configuration file to the third virtual operating system for operation.
Optionally, in an embodiment of the present application, extracting the executable file and/or the library file of the application includes: starting a virtual machine monitor, extracting executable files and/or library files of the application program through the started virtual machine monitor, and extracting configuration files of the application program.
Optionally, in an embodiment of the present application, the step of determining the root measure of trust of the operating system of the blockchain node by loading the operating system of the blockchain node into the first core of the blockchain node at the time of powering up the blockchain node includes: when a blockchain node is electrified, loading an operating system of the blockchain node to a first core of the blockchain node for starting, determining whether a key process called by the operating system in the starting process is registered in a key process list, and if so, calculating the credible root metric of the key process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
Optionally, in an embodiment of the present application, the loading the application of the blockchain node into the second core of the blockchain node is started to determine a root-of-trust metric of the application, including: and loading the application program of the blockchain node to a second core of the blockchain node for starting, determining whether the started application program is registered in a key application program list, and if so, calculating the credible root metric of the application program.
An apparatus for dual-core secure boot based on a trusted root metric, comprising:
the first measurement module is used for starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node when the blockchain node is powered on so as to determine a credible root measurement of the operating system;
a second metric module for loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root-of-trust metric of the application;
and the credibility evaluation module is used for evaluating the safety starting degree of the operating system and the safety starting degree of the application program according to the credibility root metric of the operating system and the credibility root metric of the application program.
Optionally, in an embodiment of the present application, the first measurement module includes:
the first extraction unit is used for extracting executable files and/or library files of the operating system;
a first loading unit for loading an executable file and/or a library file to a first core run of the blockchain node;
the first computing unit is used for computing the credible root metric in the running process of the executable file and/or the library file;
and the first measurement unit is used for determining the credible root measurement of the operating system according to the credible root measurement of the executable file and/or the library file.
Optionally, in an embodiment of the present application, the second measurement module includes:
a second extracting unit, configured to extract an executable file and/or a library file of the application program;
the second loading unit is used for loading the executable file and/or the library file to a second core operation;
the second calculation unit is used for calculating the credible root metric in the running process of the executable file and/or the library file;
and the second measurement unit is used for determining the credible root measurement of the application program according to the credible root measurement of the executable file and/or the library file.
Optionally, in an embodiment of the present application, the method further includes: a first creating module, configured to create a first virtual operating system and a second virtual operating system in the second core;
The second loading unit is further used for loading executable files and/or library files to the first virtual operating system and/or the second virtual operating system to run respectively.
Optionally, in an embodiment of the present application, the second measurement module further includes: a third extracting unit, configured to extract a configuration file of the application program;
the apparatus further comprises:
a second creation module for creating a first virtual operating system and a second virtual operating system in the second core;
and the third loading module loads the configuration file to the third virtual operating system for operation.
Optionally, in an embodiment of the present application, the second extracting unit is further configured to start a virtual machine monitor, extract, by the started virtual machine monitor, an executable file and/or a library file of the application program, and extract a configuration file of the application program.
Optionally, in an embodiment of the present application, the first metric module is further configured to load an operating system of a blockchain node to a first core of the blockchain node for starting when the blockchain node is powered on, determine whether a critical process called by the operating system in a starting process is registered in a critical process list, and if so, calculate a trusted root metric of the critical process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
Optionally, in an embodiment of the present application, the second metric module is further configured to load an application of the blockchain node to a second core of the blockchain node for starting, determine whether the started application is registered in a key application list, and if so, calculate a root-of-trust metric of the application.
A computer storage medium having stored thereon an executable program which when executed performs the method of any of the claims.
An electronic device comprising a trusted computing module comprising a memory and a processor, the memory having stored thereon an executable program, the processor executing the executable program to perform the steps of:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
Optionally, in an embodiment of the present application, the step of the processor executing, at power-up of a blockchain node, a startup by loading an operating system of the blockchain node to a first core of the blockchain node to determine a root-of-trust metric of the operating system includes:
extracting executable files and/or library files of the operating system;
loading an executable file and/or a library file to a first core run of the blockchain node;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the operating system according to the credible root metrics of the executable file and/or the library file.
Optionally, in an embodiment of the present application, the step of loading the application of the blockchain node to the second core of the blockchain node for startup to determine the root-of-trust metric of the application includes:
extracting executable files and/or library files of the application program;
loading the executable file and/or library file to a second core run;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the application program according to the credible root metrics of the executable file and/or the library file.
Optionally, in an embodiment of the present application, the step of loading the application of the blockchain node into the second core of the blockchain node for starting to determine the root-of-trust metric of the application is performed by the processor, including before: creating a first virtual operating system and a second virtual operating system in the second core;
the loading of the executable file and/or the library file into the second core operation comprises the following steps: and loading the executable file and/or the library file into the first virtual operating system and/or the second virtual operating system to run.
Optionally, in an embodiment of the present application, the processor starts when executing the step of loading the application of the blockchain node to the second core of the blockchain node to determine the root-of-trust metric of the application, further includes: extracting a configuration file of the application program; and creating a third virtual operating system in the second core; and loading the configuration file to the third virtual operating system for operation.
Optionally, in an embodiment of the present application, the step of the processor executing the extracting executable files and/or library files of the application program includes: starting a virtual machine monitor, extracting executable files and/or library files of the application program through the started virtual machine monitor, and extracting configuration files of the application program.
Optionally, in an embodiment of the present application, the step of the processor executing, at power-up of a blockchain node, a startup by loading an operating system of the blockchain node to a first core of the blockchain node to determine a root-of-trust metric of the operating system includes: when a blockchain node is electrified, loading an operating system of the blockchain node to a first core of the blockchain node for starting, determining whether a key process called by the operating system in the starting process is registered in a key process list, and if so, calculating the credible root metric of the key process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
Optionally, in an embodiment of the present application, the step of loading the application of the blockchain node to the second core of the blockchain node for startup to determine the root-of-trust metric of the application includes: and loading the application program of the blockchain node to a second core of the blockchain node for starting, determining whether the started application program is registered in a key application program list, and if so, calculating the credible root metric of the application program.
The big data trust system comprises a plurality of blockchain nodes, wherein each blockchain node is provided with a trusted computing module, and the trusted computing module is used for implementing the following steps:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
In the technical scheme of the embodiment of the application, when the blockchain node is powered on, an operating system of the blockchain node is loaded to a first core of the blockchain node to be started so as to determine the credible root metric of the operating system; loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program; according to the credible root measurement of the operating system and the credible root measurement of the application program, the safe starting degree of the operating system and the safe starting degree of the application program are respectively evaluated, so that the credible evaluation of the operating system and the evaluation of the application program can be realized, and the overall evaluation of the credible state of the blockchain node can be realized; in addition, no coupling relation exists between the credibility evaluation of the operating system and the evaluation of the application program, so that the overall time consumption for carrying out the credibility evaluation is reduced, and the timeliness of the credibility evaluation is improved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive faculty for a person skilled in the art.
FIG. 1 is a schematic diagram of a big data trust system in an embodiment of the present application;
FIG. 2 is a flowchart of a method for dual-core secure boot based on trusted root metrics in an embodiment of the present application;
fig. 3 is a schematic diagram of a preferred flow of S201 in the embodiment of the present application:
fig. 4 is a schematic flow chart of S202 in the embodiment of the present application:
FIG. 5 is a schematic diagram of another preferred flow of step S201 in the embodiment of the present application;
fig. 6 is another preferred flow chart of S202 in the embodiment of the present application:
FIG. 7 is a schematic diagram of a device for dual-core secure boot based on a trusted root metric in an embodiment of the present application;
FIG. 8 is a schematic structural diagram of a first metrology module according to an embodiment of the present disclosure;
FIG. 9 is a schematic structural diagram of a second metrology module according to an embodiment of the present disclosure;
FIG. 10 is another schematic structural view of the first metrology module according to an embodiment of the present disclosure;
FIG. 11 is a schematic diagram of another structure of a second metrology module according to an embodiment of the present disclosure;
fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application;
fig. 13 is a schematic diagram of a hardware structure of an electronic device in an embodiment of the application.
Detailed Description
It is not necessary for any of the embodiments of the present application to be practiced with all of the advantages described above.
In order to make the present invention better understood by those skilled in the art, the following description will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings, and it is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
FIG. 1 is a schematic diagram of a big data trust system in an embodiment of the present application; as shown in fig. 1, the big data trust system includes a plurality of blockchain nodes, and each blockchain node is provided with a trusted computing module, where the trusted computing module is configured to implement: when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system; loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program; and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
In this embodiment, the block link point types in the big data trust system may be the same or different.
In this embodiment, the first core and the second core may be cores of the same type or the same model, or cores of different types or different models.
In FIG. 1 described above, interactions between blockchain nodes are merely examples.
FIG. 2 is a flowchart of a method for dual-core secure boot based on trusted root metrics in an embodiment of the present application; as shown in fig. 2, the method for dual-core security initiation based on the trusted root metric includes:
s201, when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a credible root metric of the operating system;
in this embodiment, the blockchain node may belong to a private computer, an Ethernet (Ethernet) switch, an access point (access point), or a network access server.
In the present embodiment, the operating system is not particularly limited, and may be a windows system, a linux system, or the like.
In this embodiment, the root of trust metric for the operating system of the blockchain node may be calculated based on the static trust metric. Specifically, a trusted measurement module is configured on a blockchain node to serve as a trusted root, the trusted measurement is firstly performed to obtain a trusted root measurement, if the trusted root measurement is trusted, the trusted measurement is performed to the BIOS to obtain a trusted root measurement, if the trusted root measurement is trusted, the trusted root measurement is performed to obtain a trusted root measurement, if the trusted root measurement is trusted to the BIOS, the trusted root measurement is performed to the OS loader to obtain a trusted root measurement, if the trusted root measurement is trusted to the BIOS, the trusted root measurement is performed to the OS to obtain a trusted root measurement, if the trusted root measurement is trusted to the OS, the trusted root measurement is used to determine the trusted operating system, and the operating system is started, so that the trusted state of the operating system is accurately evaluated.
Specifically, in the process of obtaining the trusted root metric by performing the trusted metric, the running process of the used code is monitored to determine whether the jump relationship of the function is executed according to a predetermined jump relationship.
Further, hash operation can be performed on the used codes to obtain hash values, and then the hash values obtained by hash operation when the codes are executed according to a preset jump relationship are compared with the hash values obtained by hash operation, and if the hash values are identical or different in an acceptable range, a trusted conclusion is generated, so that the trusted state of the operating system is accurately estimated.
In this embodiment, the step S201 is executed in the kernel mode of the operating system to execute the step S201 in the kernel, thereby ensuring the security of the processing procedure of the step S201.
Alternatively, in other embodiments, a trusted information collecting proxy service module, such as a virtual machine monitor, may be configured to collect running information of the BIOS, the OS Loader, and the OS, and calculate the trusted heel amounts of the BIOS, the OS Loader, and the OS, and if the trusted heel amounts indicate that the BIOS, the OS Loader, and the OS are all trusted, start the operating system, otherwise, not start the operating system. By adopting the non-chained mode, dependence on a trust chain is avoided, and the transmission of a trust relationship is not needed, so that whether the operating system is trusted or not is rapidly determined.
S202, loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
specifically, in this embodiment, when the application program is loaded onto the second core of the blockchain node and started, the core file of the application program and the standard integrity data of the core file are extracted, and the standard trusted metric digest value corresponding to the integrity data is calculated.
To this end, determining the root-of-trust metric for the application may include the steps of: determining a start execution event of the application program through the constructed trusted execution environment; under the triggering of the starting execution event, extracting real-time integrity data of the application program, and calculating a real-time credible measurement abstract value of the real-time integrity data; and determining the trusted state of the application program according to the real-time trusted metric digest value and the standard trusted metric digest value so as to determine whether the application program is tampered.
Specifically, the process creation event in the operating system can be monitored through the constructed trusted execution environment, and the starting execution event of the application program is determined according to the monitored process creation event.
In this embodiment, hash operation is performed on the integrity data to obtain a real-time trusted metric digest value.
In this embodiment, the core files include executable files and dynamic library files. In the embodiment, firstly, hash operation is performed on the integrity data of an executable file to obtain a real-time trusted measurement abstract value, and the real-time trusted measurement abstract value is compared with a standard trusted measurement abstract value corresponding to the complete data when the executable file normally operates, and if the integrity data of the executable file is consistent with the standard trusted measurement abstract value, the executable file is trusted; and transmitting the control right of the trusted judgment to the dynamic library file, carrying out hash operation on the integrity data of the dynamic library file to obtain a real-time trusted measurement abstract value, comparing the real-time trusted measurement abstract value with a standard trusted measurement abstract value corresponding to the complete data of the dynamic library file in normal operation, and if the real-time trusted measurement abstract value is consistent with the standard trusted measurement abstract value, carrying out trusted operation on the dynamic library. If one of the executable file and the dynamic library file is not trusted, the application program can be determined to be not trusted, and if the one of the executable file and the dynamic library file is only trusted, the application program can be determined to be trusted, namely not tampered, otherwise, the application program can be determined to be not trusted, namely tampered.
In this embodiment, if the real-time trusted metric digest value is consistent with the standard trusted metric digest value, it indicates that the application is completely trusted, and the further the real-time trusted metric digest value is from the standard trusted metric digest value, the greater the degree of unreliability of the application is, the lesser the degree of trustiness is.
To this end, a trust threshold may be set, which indicates that the application is not trusted if the real-time trusted metric digest value is distant from the standard trusted metric digest value by more than the trust threshold. For the case that the distance between the real-time trusted metric digest value and the standard trusted metric digest value does not exceed the trusted threshold, the trusted level may be set according to the distance (such as euclidean distance), for example: fully trusted, essentially trusted, etc.
S203, according to the credible root metric of the operating system and the credible root metric of the application program, the safe starting degree of the operating system and the safe starting degree of the application program are respectively evaluated.
In this embodiment, if it can be determined by the root metric of the operating system and the root metric of the application program that the operating system and the application program can be started safely, such as completely trusted or basically trusted, the corresponding blockchain node can be considered to be driven safely if the safe start is verified and voted for by a certain proportion of blockchain nodes in the big data trust system, and further it can be determined that the blockchain node is safe.
Fig. 3 is a schematic diagram of a preferred flow of S201 in the embodiment of the present application: as shown in fig. 3, in step S201, at power-up of a blockchain node, the step of booting by loading an operating system of the blockchain node into a first core of the blockchain node to determine a root of trust metric of the operating system may include the steps of:
S211A, extracting executable files and/or library files of the operating system;
specifically, the executable files and/or library files of the operating system can be extracted according to the execution paths of the executable files and/or library files, so that the executable files and/or library files of the operating system can be quickly extracted.
S221A, loading an executable file and/or a library file to a first core operation of the blockchain node;
in this embodiment, a boot loader function in the operating system may be specifically invoked, so as to accurately load an executable file and/or a library file into the first core of the blockchain node. For windows, the boot loader function is, for example, bootloader.
S231A, calculating the credible root measurement in the running process of the executable file and/or the library file;
S241A, determining the credible root metric of the operating system according to the credible root metrics of the executable file and/or the library file.
In this embodiment, specifically, hash operation is performed on integrity data of an executable file to obtain a real-time trusted measurement abstract value, and the real-time trusted measurement abstract value is compared with a standard trusted measurement abstract value corresponding to the complete data when the executable file operates normally, a trusted root measurement is generated according to the consistency degree, and if the executable file is judged to be trusted according to the trusted root measurement, the executable file is considered to be in a safe starting state; and carrying out hash operation on the integrity data of the dynamic library file to obtain a real-time trusted measurement abstract value, comparing the real-time trusted measurement abstract value with a standard trusted measurement abstract value corresponding to the complete data of the dynamic library file in normal operation, generating a trusted root measurement according to the consistency degree, and if the trusted root measurement judges that the dynamic library is trusted, putting the dynamic library into a safe starting state. If one of the executable file and the dynamic library file is not trusted, the operating system can be determined to be not started safely, and if the executable file and the dynamic library file are both trusted, the operating system can be determined to be started safely, namely not tampered, and the operating system can be allowed to run. Otherwise, determining that the operating system is not trusted, i.e. not safely started, and prohibiting the operation of the operating system.
Specifically, after the root-trusted metrics of the executable files and/or library files, statistical analysis may be performed on the root-trusted metrics to generate a final root-trusted metric, which is used to represent the trust level of the operating system as a whole, and if the operating system is determined to be completely trusted or basically trusted through the final root-trusted metric, it is indicated that the executable files and/or library files in the operating system are in a state of being safely bootable as a whole, so that booting of the operating system is allowed, for example, for windows systems, a boot screen is realized to be visible to a user, and the operating system is allowed to be booted and is booted.
Further, in another embodiment, loading the application of the blockchain node into the second core of the blockchain node is initiated to determine a root of trust metric for the application, previously comprising: creating a first virtual operating system and a second virtual operating system in the second core;
the loading of the executable file and/or library file into the second core operation may further comprise: and loading the executable file and/or the library file into the first virtual operating system and/or the second virtual operating system to run.
In this embodiment, because the executable file may be loaded to the first virtual operating system and/or the library file may be loaded to the second virtual operating system for running, the root metrics of the executable file and the library file may be isolated from each other, so that crosstalk between each other is avoided; in addition, the time consumption of the trusted root metric calculation can be reduced, and the calculation efficiency is improved.
Further, the loading the application of the blockchain node into the second core of the blockchain node is started to determine a root-of-trust metric of the application, and may further include: extracting a configuration file of the application program; and creating a third virtual operating system in the second core; and loading the configuration file to the third virtual operating system for operation.
The creation of the first-third virtual operating systems described above may be implemented in particular by virtual machine tools.
Fig. 4 is a schematic flow chart of S202 in the embodiment of the present application: as shown in fig. 4, in step S202, loading an application of the blockchain node into a second core of the blockchain node for initiation to determine a root of trust metric of the application may include the steps of:
S212A, extracting executable files and/or library files of the application program;
in this embodiment, an interception request may be generated according to monitoring of a process creation event; and intercepting the start execution event of the application program under the triggering of the interception request.
In this embodiment, the path information of the application program is first determined under the triggering of the interception request, and the start execution event of the application program is intercepted according to the path information, so that accurate and rapid interception is realized. In this embodiment, a zwcreateprocess function in an operating system may be specifically called to intercept a startup execution event of the application program, and according to the intercepted startup execution event, an executable file and/or a library file of the application program may be extracted.
Alternatively, in other embodiments, the created trusted execution environment is hooked to a process creation function in the virtual operating system; and the method comprises the steps of determining a start execution event of the application program through a trusted execution environment of a process creation function hooked into an operating system, intercepting the start execution event of the application program, and extracting an executable file and/or a library file of the application program according to the intercepted start execution event.
In particular, the process creation function such as the zwCreateprocesssEX function may be specifically created by modifying the kernel of the system so that a HOOK of the kernel that relies on HOOK HOOKs the trusted execution environment into the operating system.
S222A, loading the executable file and/or the library file into a second core for operation;
S232A, calculating the credible root measurement in the running process of the executable file and/or the library file;
S242A, determining the credible root metric of the application program according to the credible root metrics of the executable file and/or the library file.
Specifically, in this embodiment, in step S212, the step of extracting the executable file and/or library file of the application program may include: starting a virtual machine monitor, extracting executable files and/or library files of the application program through the started virtual machine monitor, and extracting configuration files of the application program.
In the above embodiments, the operating system is also regarded as a special application program or a system-level application program, and the application programs that run on the operating system after the operating system is started are also called user-level application programs. However, from the trusted perspective, the trusted computing is performed on the executable file and the library file to obtain the trusted heel measure, so that the consistence is realized in the architecture of the trusted algorithm implementation, the implementation difficulty of the trusted algorithm is reduced, and meanwhile, the trusted computing efficiency can be improved.
FIG. 5 is a schematic diagram of another preferred flow of step S201 in the embodiment of the present application; as shown in fig. 5, in step S201, when the operating system of the blockchain node is loaded to the first core of the blockchain node to perform booting to determine the root trusted measure of the operating system at the time of powering up the blockchain node, the method may include:
S211B, loading an operating system of a blockchain node to a first core of the blockchain node for starting when the blockchain node is powered on;
S221B, determining whether a key process called by the operating system in the starting process is registered in a key process list;
S231B, the key process called by the operating system in the starting process is registered in a key process list, and the credible root metric of the key process is calculated;
S241B, determining the credible root metric of the operating system according to the feasible root metric of the key process.
In this embodiment, the importance analysis may be performed on the key processes possibly invoked according to the operating system startup process, and only those key processes that have a greater influence on the operating system startup, such as a Session Manager Session management process, a subsystem server process, a management user login process, a Session key generation process, and a ticket (ticket) process for interactive client/server authentication are concerned. When the trusted computing is carried out, only aiming at the key processes, but not aiming at all executable files and library files associated with the operating system from the integrity point of view, the trusted computing is more focused, so that the efficiency of the trusted computing can be improved, and whether the operating system is safely started or not can be rapidly judged.
Fig. 6 is another preferred flow chart of S202 in the embodiment of the present application: as shown in fig. 6, in step S202, loading an application of the blockchain node into a second core of the blockchain node for initiation to determine a root of trust metric of the application may include the steps of:
S212B, loading an application program of the blockchain node to a second core of the blockchain node for starting;
S222B, determining whether the started application program is registered in a key application program list;
and S232B, if yes, calculating the credible root metric of the application program.
Similarly, for the above operating system, based on the key process list, only the key processes registered in the key process list are subjected to the root of trust measurement. And aiming at the application programs, taking the key application program list as a basis, and performing trusted root measurement on only the application programs registered in the key application program list.
It should be noted that, the above-mentioned critical process list and critical application program list are not fixed, they can be updated continuously according to the operating system, the update can be based on big data analysis, for example, after the process or abnormality of virus high-frequency damage, the operation of the operating system is seriously affected, and it can be added into the critical process list in real time; similarly, the list of critical applications may also be updated in real time.
FIG. 7 is a schematic diagram of a device for dual-core secure boot based on a trusted root metric in an embodiment of the present application; as shown in fig. 7, it includes:
a first metric module 701, configured to determine a root-of-trust metric of an operating system of a blockchain node by loading the operating system into a first core of the blockchain node when the blockchain node is powered on;
a second metric module 702 for loading an application of the blockchain node into a second core of the blockchain node for startup to determine a root-of-trust metric of the application;
the trusted evaluation module 703 is configured to evaluate a secure launch degree of the operating system and a secure launch degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program, respectively.
For an exemplary description of the technology related to this embodiment, reference may be made to the embodiment shown in fig. 2 described above.
FIG. 8 is a schematic structural diagram of a first metrology module according to an embodiment of the present disclosure; as shown in fig. 8, the first metrology module includes:
a first extraction unit 711A for extracting executable files and/or library files of the operating system;
A first loading unit 721A for loading executable files and/or library files into a first core run of the blockchain node;
a first calculating unit 731A, configured to calculate a root measure of trust in the running process of the executable file and/or the library file;
a first metric unit 741A, configured to determine a root metric of trust of the operating system according to the root metrics of the executable file and/or the library file.
For an exemplary description of the technology related to this embodiment, reference may be made to the embodiment shown in fig. 3 described above.
FIG. 9 is a schematic structural diagram of a second metrology module according to an embodiment of the present disclosure; as shown in fig. 9, the second metrology module includes:
a second extracting unit 712A for extracting executable files and/or library files of the application program;
a second loading unit 722A, configured to load an executable file and/or a library file into a second core operation;
a second calculating unit 732A, configured to calculate a root-of-trust metric during the running process of the executable file and/or the library file;
a second metric unit 742A is configured to determine a root metric of trust of the application according to the root metrics of the executable file and/or the library file.
Optionally, in an embodiment, the method further includes: a first creating module, configured to create a first virtual operating system and a second virtual operating system in the second core;
The second loading unit is further used for loading executable files and/or library files to the first virtual operating system and/or the second virtual operating system to run respectively.
Optionally, in an embodiment, the second metrology module further comprises: a third extracting unit, configured to extract a configuration file of the application program; to this end, the device further comprises:
a second creation module for creating a first virtual operating system and a second virtual operating system in the second core;
and the third loading module loads the configuration file to the third virtual operating system for operation.
Further, in an embodiment, the second extracting unit is further configured to start a virtual machine monitor, extract an executable file and/or a library file of the application program through the started virtual machine monitor, and extract a configuration file of the application program.
For a detailed exemplary description of the present embodiment, reference may be made to the embodiment of fig. 4, which is not described herein.
FIG. 10 is another schematic structural view of the first metrology module according to an embodiment of the present disclosure; as shown in fig. 10, the first metrology module includes:
a third loading unit 711B, configured to load, when the blockchain node is powered on, an operating system of the blockchain node to a first core of the blockchain node for starting;
A key process determining unit 721B that determines whether a key process called by the operating system in a startup process is registered in a key process list;
a third calculating unit 731B, configured to calculate a root-trusted measure of a critical process called by the operating system in a startup process when the critical process is registered in a critical process list;
a third metric unit 741B, configured to determine a root-of-trust metric of the operating system according to the feasible root metrics of the critical process.
An exemplary description of the technology related to this embodiment can be found in the embodiment shown in fig. 5 described above.
FIG. 11 is a schematic diagram of another structure of a second metrology module according to an embodiment of the present disclosure; as shown in fig. 11, the second metrology module includes:
a fourth loading unit 712B for loading the application of the blockchain node to the second core of the blockchain node for booting;
a critical application determining unit 722B for determining whether the started application is registered in a critical application list;
a fourth calculating unit 732B calculates a root of trust metric of the application when the started application is registered in the list of critical applications.
Embodiments of the present application also provide a computer storage medium having stored thereon an executable program that when executed performs the method of any of the claims.
An exemplary description of the technology related to this embodiment can be found in the embodiment shown in fig. 6 described above.
Fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application; as shown in fig. 12, the electronic device includes a trusted computing module, where the trusted computing module includes a memory 1201 and a processor 1202, where the memory stores an executable program, and when the processor runs the executable program, the processor performs the following steps:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
Optionally, in an embodiment, the step of the processor executing, at power-up of a blockchain node, a boot up by loading an operating system of the blockchain node into a first core of the blockchain node to determine a root of trust metric of the operating system includes:
extracting executable files and/or library files of the operating system;
loading an executable file and/or a library file to a first core run of the blockchain node;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the operating system according to the credible root metrics of the executable file and/or the library file.
Optionally, in an embodiment, the processor performs the step of loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root of trust metric for the application, comprising:
extracting executable files and/or library files of the application program;
loading the executable file and/or library file to a second core run;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the application program according to the credible root metrics of the executable file and/or the library file.
Optionally, in an embodiment, the step of loading the application of the blockchain node to the second core of the blockchain node for startup to determine the root-of-trust metric of the application is performed by the processor, previously comprising: creating a first virtual operating system and a second virtual operating system in the second core;
the loading of the executable file and/or the library file into the second core operation comprises the following steps: and loading the executable file and/or the library file into the first virtual operating system and/or the second virtual operating system to run.
Optionally, in an embodiment, the processor initiates the step of executing the loading of the application of the blockchain node to the second core of the blockchain node to determine the root-of-trust metric of the application further comprises: extracting a configuration file of the application program; and creating a third virtual operating system in the second core; and loading the configuration file to the third virtual operating system for operation.
Optionally, in an embodiment, the step of the processor executing the extracting the executable file and/or library file of the application comprises: starting a virtual machine monitor, extracting executable files and/or library files of the application program through the started virtual machine monitor, and extracting configuration files of the application program.
Optionally, in an embodiment, the step of the processor executing, at power-up of a blockchain node, a boot up by loading an operating system of the blockchain node into a first core of the blockchain node to determine a root of trust metric of the operating system includes: when a blockchain node is electrified, loading an operating system of the blockchain node to a first core of the blockchain node for starting, determining whether a key process called by the operating system in the starting process is registered in a key process list, and if so, calculating the credible root metric of the key process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
Optionally, in an embodiment, the processor performs the step of loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root of trust metric for the application, comprising: and loading the application program of the blockchain node to a second core of the blockchain node for starting, determining whether the started application program is registered in a key application program list, and if so, calculating the credible root metric of the application program.
Fig. 13 is a schematic diagram of a hardware structure of an electronic device in an embodiment of the present application; as shown in fig. 13, it includes: a processor 1301, a communication interface 1302, a computer-readable medium 1303, and a communication bus 1304;
wherein the processor 1301, the communication interface 1302, and the computer readable medium 1303 perform communication with each other through the communication bus 1304;
alternatively, the communication interface 1302 may be an interface of a communication module, such as an interface of a GSM module;
wherein the processor 1301 may in particular be configured to run an executable program stored on a memory, thereby performing all or part of the processing steps of any of the method embodiments described above.
Processor 1301 may be a general purpose processor including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; but may also be a Digital Signal Processor (DSP), application Specific Integrated Circuit (ASIC), an off-the-shelf programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The electronic device of the embodiments of the present application exist in a variety of forms including, but not limited to:
(1) Mobile communication devices, which are characterized by mobile communication functionality and are aimed at providing voice, data communication. Such terminals include smart phones (e.g., iPhone), multimedia phones, functional phones, and low-end phones, among others.
(2) Ultra mobile personal computer equipment, which belongs to the category of personal computers, has the functions of calculation and processing and generally has the characteristic of mobile internet surfing. Such terminals include PDA, MID and UMPC devices, etc., such as iPad.
(3) Portable entertainment devices such devices can display and play multimedia content. Such devices include audio, video players (e.g., iPod), palm game consoles, electronic books, and smart toys and portable car navigation devices.
(4) The server, which is a device for providing computing services, is composed of a processor 710, a hard disk, a memory, a system bus, etc., and is similar to a general computer architecture, but is required to provide highly reliable services, and thus has high requirements in terms of processing power, stability, reliability, security, scalability, manageability, etc.
(5) Other electronic devices with data interaction function.
In the present embodiments, the processor may take the form of, for example, a microprocessor or a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), a programmable logic processor, and an embedded microprocessor, examples of the processor including, but not limited to, the following microprocessors: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory processor may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to a processor implemented as pure computer readable program code, the same functions may be implemented entirely by logic programming method steps such that the processor is in the form of logic gates, switches, application specific integrated circuits, programmable logic processors, embedded microprocessors, etc. Such a processor may thus be considered as a hardware component, and means for performing the various functions included therein may also be considered as structure within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
Embodiments of the present application also provide a computer storage medium having stored thereon an executable program that when executed performs the method of any of the claims.
Computer storage media, including both non-transitory and non-transitory, removable and non-removable media, may be implemented in any method or technology for storage of information. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of storage media for a computer include, but are not limited to, phase change memory (PRAM), static Random Access Memory (SRAM), dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), read Only Memory (ROM), electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. Computer storage media, as defined herein, does not include transitory computer readable media (transmission media), such as modulated data signals and carrier waves.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.
The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular transactions or implement particular abstract data types. The application may also be practiced in distributed computing environments where transactions are performed by remote processing devices that are connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
It should be noted that, in the present specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are all referred to each other, and each embodiment is mainly described in a different point from other embodiments. In particular, for the apparatus and system embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, with reference to the description of the method embodiments in part. The above-described embodiments of the apparatus and system are merely illustrative, in which the modules illustrated as separate components may or may not be physically separate, and the components illustrated as modules may or may not be physical, i.e., may be located in one place, or may be distributed over multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The foregoing is merely one specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope of the present application should be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (26)

1. The block chain node trust evaluation method for dual-core security initiation based on the trust root metric is characterized by comprising the following steps:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
2. The method of claim 1, wherein at power-up of a blockchain node, booting by loading an operating system of the blockchain node into a first core of the blockchain node to determine a root of trust metric of the operating system comprises:
extracting executable files and/or library files of the operating system;
loading an executable file and/or a library file to a first core run of the blockchain node;
calculating the credible root metric in the running process of the executable file and/or the library file;
And determining the credible root metric of the operating system according to the credible root metrics of the executable file and/or the library file.
3. The method of claim 1, wherein the loading the application of the blockchain node into the second core of the blockchain node is initiated to determine the root-of-trust metric of the application, comprising:
extracting executable files and/or library files of the application program;
loading the executable file and/or library file to a second core run;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the application program according to the credible root metrics of the executable file and/or the library file.
4. The method of claim 3, wherein the loading the application of the blockchain node into the second core of the blockchain node is initiated to determine the root-of-trust metric of the application, previously comprising: creating a first virtual operating system and a second virtual operating system in the second core;
the loading of the executable file and/or the library file into the second core operation comprises the following steps: loading the executable file into the first virtual operating system and/or loading the library file into a second virtual operating system for operation.
5. The method of claim 4, wherein loading the application of the blockchain node to the second core of the blockchain node is initiated to determine a root-of-trust metric for the application, further comprising: extracting a configuration file of the application program; and creating a third virtual operating system in the second core; and loading the configuration file to the third virtual operating system for operation.
6. The method of claim 5, wherein the extracting executable files and/or library files of the application program comprises: starting a virtual machine monitor, extracting executable files and/or library files of the application program through the started virtual machine monitor, and extracting configuration files of the application program.
7. The method of claim 1, wherein the booting by loading an operating system of a blockchain node into a first core of the blockchain node to determine a root of trust metric of the operating system at power-up of the blockchain node comprises: when a blockchain node is electrified, loading an operating system of the blockchain node to a first core of the blockchain node for starting, determining whether a key process called by the operating system in the starting process is registered in a key process list, and if so, calculating the credible root metric of the key process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
8. The method of claim 1, wherein the loading the application of the blockchain node into the second core of the blockchain node is initiated to determine the root-of-trust metric of the application, comprising: and loading the application program of the blockchain node to a second core of the blockchain node for starting, determining whether the started application program is registered in a key application program list, and if so, calculating the credible root metric of the application program.
9. A blockchain node trust evaluation device for dual-core security initiation based on a trust root metric, comprising:
the first measurement module is used for starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node when the blockchain node is powered on so as to determine a credible root measurement of the operating system;
a second metric module for loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root-of-trust metric of the application;
and the credibility evaluation module is used for evaluating the safety starting degree of the operating system and the safety starting degree of the application program according to the credibility root metric of the operating system and the credibility root metric of the application program.
10. The apparatus of claim 9, wherein the first metrology module comprises:
the first extraction unit is used for extracting executable files and/or library files of the operating system;
a first loading unit for loading an executable file and/or a library file to a first core run of the blockchain node;
the first computing unit is used for computing the credible root metric in the running process of the executable file and/or the library file;
and the first measurement unit is used for determining the credible root measurement of the operating system according to the credible root measurement of the executable file and/or the library file.
11. The apparatus of claim 9, wherein the second metrology module comprises:
a second extracting unit, configured to extract an executable file and/or a library file of the application program;
the second loading unit is used for loading the executable file and/or the library file to a second core operation;
the second calculation unit is used for calculating the credible root metric in the running process of the executable file and/or the library file;
and the second measurement unit is used for determining the credible root measurement of the application program according to the credible root measurement of the executable file and/or the library file.
12. The apparatus as recited in claim 11, further comprising: a first creating module, configured to create a first virtual operating system and a second virtual operating system in the second core;
the second loading unit is further configured to load the executable file to the first virtual operating system and/or load the library file to a second virtual operating system for running.
13. The apparatus of claim 12, wherein the second metrology module further comprises: a third extracting unit, configured to extract a configuration file of the application program;
the apparatus further comprises:
a second creation module for creating a third virtual operating system in the second core;
and the third loading module loads the configuration file to the third virtual operating system for operation.
14. The apparatus according to claim 13, wherein the second extraction unit is further configured to start a virtual machine monitor, extract executable files and/or library files of the application program through the started virtual machine monitor, and extract configuration files of the application program.
15. The apparatus of claim 9, wherein the first metric module is further configured to, upon power-up of a blockchain node, load an operating system of the blockchain node to a first core of the blockchain node for startup, and determine whether a critical process invoked by the operating system during startup is registered in a critical process list, and if so, calculate a root of trust metric for the critical process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
16. The apparatus of claim 9, wherein the second metric module is further configured to load an application of the blockchain node to a second core of the blockchain node for launching and determine whether the launched application is registered in a critical application list, and if so, calculate a root of trust metric for the application.
17. A computer storage medium having stored thereon an executable program which when executed performs the method of any of claims 1-8.
18. An electronic device comprising a trusted computing module, the trusted computing module comprising a memory and a processor, the memory having stored thereon an executable program, the processor executing the steps of:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
And respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
19. The electronic device of claim 18, wherein the processor performs the step of booting by loading an operating system of a blockchain node to a first core of the blockchain node at power-up of the blockchain node to determine a trustlet metric of the operating system, comprising:
extracting executable files and/or library files of the operating system;
loading an executable file and/or a library file to a first core run of the blockchain node;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the operating system according to the credible root metrics of the executable file and/or the library file.
20. The electronic device of claim 18, wherein the processor performs the step of loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root of trust metric for the application, comprising:
Extracting executable files and/or library files of the application program;
loading the executable file and/or library file to a second core run;
calculating the credible root metric in the running process of the executable file and/or the library file;
and determining the credible root metric of the application program according to the credible root metrics of the executable file and/or the library file.
21. The electronic device of claim 20, wherein the processor performs the step of loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root of trust metric for the application, previously comprising: creating a first virtual operating system and a second virtual operating system in the second core;
the loading of the executable file and/or the library file into the second core operation comprises the following steps: loading the executable file into the first virtual operating system and/or loading the library file into a second virtual operating system for operation.
22. The electronic device of claim 21, wherein the processor initiates upon executing the loading of the application of the blockchain node to the second core of the blockchain node to determine the root-of-trust metric for the application, further comprising: extracting a configuration file of the application program; and creating a third virtual operating system in the second core; and loading the configuration file to the third virtual operating system for operation.
23. The electronic device of claim 22, wherein the processor performing the step of extracting executable files and/or library files of the application program comprises: starting a virtual machine monitor, extracting executable files and/or library files of the application program through the started virtual machine monitor, and extracting configuration files of the application program.
24. The electronic device of claim 18, wherein the processor performs the step of booting by loading an operating system of a blockchain node to a first core of the blockchain node at power-up of the blockchain node to determine a trustlet metric of the operating system, comprising: when a blockchain node is electrified, loading an operating system of the blockchain node to a first core of the blockchain node for starting, determining whether a key process called by the operating system in the starting process is registered in a key process list, and if so, calculating the credible root metric of the key process; and determining the credible root metric of the operating system according to the feasible root metric of the key process.
25. The electronic device of claim 18, wherein the processor performs the step of loading an application of the blockchain node to a second core of the blockchain node for startup to determine a root of trust metric for the application, comprising: and loading the application program of the blockchain node to a second core of the blockchain node for starting, determining whether the started application program is registered in a key application program list, and if so, calculating the credible root metric of the application program.
26. The big data trust system is characterized by comprising a plurality of blockchain nodes, wherein each blockchain node is provided with a trusted computing module, and the trusted computing module is used for implementing the following steps:
when a blockchain node is powered on, starting an operating system of the blockchain node by loading the operating system into a first core of the blockchain node to determine a trusted root metric of the operating system;
loading an application program of the blockchain node to a second core of the blockchain node for starting to determine a credible root metric of the application program;
and respectively evaluating the safe starting degree of the operating system and the safe starting degree of the application program according to the trusted root metric of the operating system and the trusted root metric of the application program.
CN202011017943.7A 2020-09-24 2020-09-24 Method and device for dual-core security initiation based on trusted root metric and related products Active CN112162781B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202011017943.7A CN112162781B (en) 2020-09-24 2020-09-24 Method and device for dual-core security initiation based on trusted root metric and related products

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202011017943.7A CN112162781B (en) 2020-09-24 2020-09-24 Method and device for dual-core security initiation based on trusted root metric and related products

Publications (2)

Publication Number Publication Date
CN112162781A CN112162781A (en) 2021-01-01
CN112162781B true CN112162781B (en) 2023-07-18

Family

ID=73863724

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202011017943.7A Active CN112162781B (en) 2020-09-24 2020-09-24 Method and device for dual-core security initiation based on trusted root metric and related products

Country Status (1)

Country Link
CN (1) CN112162781B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113536317A (en) * 2021-06-17 2021-10-22 杭州加速科技有限公司 Method and system for enhancing safety of ATE (automatic test equipment) testing machine
CN113642006A (en) * 2021-08-30 2021-11-12 南方电网数字电网研究院有限公司 Safe starting method of dual-core relay protection system
CN114327791B (en) * 2022-03-03 2022-06-10 阿里云计算有限公司 Virtualization-based trusted computing measurement method, device, equipment and storage medium

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101504704A (en) * 2009-03-17 2009-08-12 武汉大学 Star trust chain supporting embedded platform application program integrality verification method
CN101515316A (en) * 2008-02-19 2009-08-26 北京工业大学 Trusted computing terminal and trusted computing method
CN102332070A (en) * 2011-09-30 2012-01-25 中国人民解放军海军计算技术研究所 Trust chain transfer method for trusted computing platform
CN106548063A (en) * 2016-11-01 2017-03-29 广东浪潮大数据研究有限公司 A kind of credible tolerance methods, devices and systems
CN109241745A (en) * 2018-08-28 2019-01-18 全球能源互联网研究院有限公司 A kind of credible starting method and device of computing platform
CN110147674A (en) * 2019-04-08 2019-08-20 全球能源互联网研究院有限公司 A kind of trusted system environment construction method and device of charging control unit

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101515316A (en) * 2008-02-19 2009-08-26 北京工业大学 Trusted computing terminal and trusted computing method
CN101504704A (en) * 2009-03-17 2009-08-12 武汉大学 Star trust chain supporting embedded platform application program integrality verification method
CN102332070A (en) * 2011-09-30 2012-01-25 中国人民解放军海军计算技术研究所 Trust chain transfer method for trusted computing platform
CN106548063A (en) * 2016-11-01 2017-03-29 广东浪潮大数据研究有限公司 A kind of credible tolerance methods, devices and systems
CN109241745A (en) * 2018-08-28 2019-01-18 全球能源互联网研究院有限公司 A kind of credible starting method and device of computing platform
CN110147674A (en) * 2019-04-08 2019-08-20 全球能源互联网研究院有限公司 A kind of trusted system environment construction method and device of charging control unit

Also Published As

Publication number Publication date
CN112162781A (en) 2021-01-01

Similar Documents

Publication Publication Date Title
CN112162781B (en) Method and device for dual-core security initiation based on trusted root metric and related products
KR101894926B1 (en) Trusted kernel starting method and apparatus
US9686281B2 (en) Trusted application migration across computer nodes
CN103299311B (en) Methods and apparatus for trusted boot optimization
EP3761198B1 (en) Container escape detection method, apparatus and system, and storage medium
KR101931007B1 (en) Initialization trace of a computing device
CN111523112B (en) Method, device, equipment and medium for safely starting server
CN105308612A (en) Dynamically loaded measured environment for secure code launch
CN108111464B (en) Data verification method and device
CN106203092B (en) Method and device for intercepting shutdown of malicious program and electronic equipment
CN110083433B (en) Embedded software running method and device, terminal and computer readable storage medium
CN113065140A (en) Embedded safety protection system and method for chip control protection device
CN112162782B (en) Method, device and related product for determining application program trusted state based on trusted root dynamic measurement
WO2018136087A1 (en) Multiple remote attestation service for cloud-based systems
WO2014204470A1 (en) Generating a fingerprint representing a response of an application to a simulation of a fault of an external service
CN114371859A (en) Application software RASP program updating method, server, electronic device and storage medium
CN109766702A (en) The credible starting method of inspection of overall process based on virtual machine state data
CN111651769A (en) Method and device for obtaining measurement of secure boot
CN111353150B (en) Trusted boot method, trusted boot device, electronic equipment and readable storage medium
CN111400771A (en) Target partition checking method and device, storage medium and computer equipment
CN115964721A (en) Program verification method and electronic equipment
CN113569232A (en) Credibility measuring method and device for container and data system
US10776490B1 (en) Verifying an operating system during a boot process using a loader
CN114282205A (en) Firmware starting method and device and computer readable storage medium
CN113157543A (en) Credibility measuring method and device, server and computer readable storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant