Equipment starting method and device based on security trusted module encryption authentication

By encrypting and authenticating the device startup process through a secure and trusted module, the problem of malware bypassing traditional security detection is solved, trusted verification of driver firmware and startup code is achieved, and the security of device startup is improved.

CN120744931APending Publication Date: 2025-10-03ELECTRIC POWER RES INST CHINA SOUTHERN POWER GRID CO LTD +1
View PDF 0 Cites 1 Cited by

Patent Information

Application Number
CN202510875369.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-06-27
Publication Date
2025-10-03

AI Technical Summary

Technical Problem

During the device startup process, malware can bypass or tamper with traditional security detection procedures, leading to data security threats. How can we improve the security of the device startup process?

Method used

A method based on secure and trusted module encryption authentication is adopted to ensure the security of the boot process by performing trusted verification of the target device's driver firmware feature information, hardware availability detection, and integrity and trusted verification of the boot code.

Benefits of technology

It achieves comprehensive verification of the device startup process from both software and hardware aspects, ensuring the authenticity and integrity of the driver firmware and startup code, and improving the security of the device startup process.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120744931A_ABST
    Figure CN120744931A_ABST
Patent Text Reader

Abstract

The invention relates to an equipment starting method and device based on security trusted module encryption authentication, and relates to the technical field of information security. The method comprises the steps that after target equipment is powered on, first credible verification is conducted on feature information according to a stored first digital signature, and a first verification result is obtained; carrying out availability detection on target hardware of the safe and credible module to obtain a first detection result; under the condition that the first verification result indicates that the drive firmware is credible and the first detection result indicates that the secure credible module is available, according to the first summary information, performing integrity verification on a startup code of the target equipment to obtain a second verification result; according to the second digital signature, performing second credible verification on the starting code to obtain a third verification result; and under the condition that the second verification result indicates that the starting code is complete and the third verification result indicates that the starting code is credible, sending starting authorization information to the target equipment. By adopting the method, the safety of the equipment starting process can be improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a device startup method and apparatus based on secure and trusted module encryption authentication. Background Art

[0002] As digitalization accelerates, device security challenges are becoming increasingly severe. During device startup, attackers can exploit various methods to gain control of devices and steal sensitive information, posing a serious threat to data security. For example, hackers can use network attacks to inject malicious code into a device's startup program, causing it to automatically run upon startup, potentially collecting critical information or launching large-scale cyberattacks.

[0003] Traditional device startup mechanisms rely primarily on the system's own security protections, such as the operating system's built-in security checkers. However, malware can bypass or tamper with these checkers, posing a threat to the device startup process. Therefore, improving the security of the device startup process is an urgent issue. Summary of the Invention

[0004] Based on this, it is necessary to provide a device startup method and apparatus based on secure and trusted module encryption authentication that can improve the security of the device startup process in order to address the above technical problems.

[0005] In a first aspect, the present application provides a device startup method based on secure and trusted module encryption authentication, which is applied to a secure and trusted module corresponding to a target device. The secure and trusted module carries characteristic information of the driver firmware in the target device, including:

[0006] After the target device is powered on, performing a first trustworthy verification on the feature information according to the pre-stored first digital signature to obtain a first verification result; and performing an availability test on the target hardware of the security and trustworthy module to obtain a first test result;

[0007] If the first verification result indicates that the driver firmware is credible and the first detection result indicates that the security and trusted module is available, performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second credibility verification on the boot code according to the second digital signature to obtain a third verification result;

[0008] When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, boot authorization information is sent to the target device, so that the target device boots the target device by loading and executing the boot code.

[0009] In one embodiment, a first trusted verification is performed on the characteristic information based on a pre-stored first digital signature to obtain a first verification result, including: performing a first hash process on the characteristic information to obtain second summary information corresponding to the characteristic information; decrypting the first digital signature using a pre-stored trusted root key to obtain third summary information; and comparing the second summary information with the third summary information to obtain the first verification result.

[0010] In one embodiment, the integrity of the boot code of the target device is verified based on the first summary information to obtain a second verification result, including: performing a second hash process on the boot code to obtain fourth summary information corresponding to the boot code; and comparing the first summary information of the boot code with the fourth summary information to obtain the second verification result.

[0011] In one embodiment, a second trusted verification is performed on the boot code based on the second digital signature to obtain a third verification result, including: performing a third hash process on the boot code to obtain fifth summary information corresponding to the boot code; using the stored trusted root key to decrypt the second digital signature to obtain sixth summary information; and comparing the fifth summary information with the sixth summary information to obtain the third verification result.

[0012] In one embodiment, before performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second trusted verification on the boot code according to the second digital signature to obtain a third verification result, it also includes: sending a key acquisition request to the key management module corresponding to the target device; receiving an encrypted target key returned by the key management module in response to the key acquisition request; the encrypted target key is obtained by encrypting the public key sent by the security and trusted module; decrypting the encrypted target key using the private key corresponding to the public key to obtain the target key; obtaining the boot code ciphertext; decrypting the boot code ciphertext using the target key to obtain the boot code plaintext; accordingly, performing integrity verification on the boot code of the target device according to the first summary information to obtain the second verification result; and performing a second trusted verification on the boot code according to the second digital signature to obtain the third verification result, including: performing integrity verification on the boot code plaintext of the target device according to the first summary information to obtain the second verification result; and performing a second trusted verification on the boot code plaintext according to the second digital signature to obtain the third verification result.

[0013] In one embodiment, the target hardware includes at least one of a chip and a circuit; accordingly, an availability test is performed on the target hardware of the security and trusted module to obtain a first test result, including: performing an integrity test on the characteristic data carried in the chip according to the seventh summary information, and / or performing a functional test on the chip according to a preset test instruction to obtain a first sub-test result; obtaining a second sub-test result based on the electrical parameter data in the circuit and a preset data range; and obtaining a first test result based on the first sub-test result and / or the second sub-test result.

[0014] In a second aspect, the present application further provides a device startup device based on secure and trusted module encryption authentication, which is configured in a secure and trusted module corresponding to a target device, wherein the secure and trusted module carries characteristic information of the driver firmware in the target device, and the device comprises:

[0015] A first verification module is configured to, after the target device is powered on, perform a first trustworthy verification on the feature information based on a pre-stored first digital signature to obtain a first verification result; and perform an availability test on the target hardware of the security and trustworthy module to obtain a first test result;

[0016] a second verification module configured to, if the first verification result indicates that the driver firmware is credible and the first detection result indicates that the security and trusted module is available, perform integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and perform a second trustworthy verification on the boot code according to the second digital signature to obtain a third verification result;

[0017] The first sending module is configured to send startup authorization information to the target device if the second verification result indicates that the startup code is complete and the third verification result indicates that the startup code is credible, so that the target device starts the target device by loading and executing the startup code.

[0018] In a third aspect, the present application further provides a computer device configured with a secure and trusted module corresponding to a target device, wherein the secure and trusted module carries characteristic information of a driver firmware in the target device, the computer device including a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the following steps are implemented:

[0019] After the target device is powered on, performing a first trustworthy verification on the feature information according to the pre-stored first digital signature to obtain a first verification result; and performing an availability test on the target hardware of the security and trustworthy module to obtain a first test result;

[0020] If the first verification result indicates that the driver firmware is credible and the first detection result indicates that the security and trusted module is available, performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second credibility verification on the boot code according to the second digital signature to obtain a third verification result;

[0021] When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, boot authorization information is sent to the target device, so that the target device boots the target device by loading and executing the boot code.

[0022] In a fourth aspect, the present application further provides a computer-readable storage medium configured in a security and trusted module corresponding to a target device, wherein the security and trusted module carries characteristic information of a driver firmware in the target device, and a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, the following steps are implemented:

[0023] After the target device is powered on, performing a first trustworthy verification on the feature information according to the pre-stored first digital signature to obtain a first verification result; and performing an availability test on the target hardware of the security and trustworthy module to obtain a first test result;

[0024] If the first verification result indicates that the driver firmware is credible and the first detection result indicates that the security and trusted module is available, performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second credibility verification on the boot code according to the second digital signature to obtain a third verification result;

[0025] When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, boot authorization information is sent to the target device, so that the target device boots the target device by loading and executing the boot code.

[0026] In a fifth aspect, the present application further provides a computer program product configured in a security and trusted module corresponding to a target device, wherein the security and trusted module carries characteristic information of a driver firmware in the target device, and the computer program product includes a computer program that, when executed by a processor, implements the following steps:

[0027] After the target device is powered on, performing a first trustworthy verification on the feature information according to the pre-stored first digital signature to obtain a first verification result; and performing an availability test on the target hardware of the security and trustworthy module to obtain a first test result;

[0028] If the first verification result indicates that the driver firmware is credible and the first detection result indicates that the security and trusted module is available, performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second credibility verification on the boot code according to the second digital signature to obtain a third verification result;

[0029] When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, boot authorization information is sent to the target device, so that the target device boots the target device by loading and executing the boot code.

[0030] The above-mentioned device startup method and apparatus based on encryption authentication of a secure and trusted module, after the target device is powered on, can perform a first trustworthy verification on the characteristic information of the driver firmware in the target device carried in the secure and trusted module according to a pre-stored first digital signature to obtain a first verification result, and perform an availability test on the target hardware of the secure and trusted module to obtain a first test result. If the first verification result indicates that the driver firmware is trustworthy and the first test result indicates that the secure and trusted module is available, the integrity of the startup code of the target device is verified according to the first summary information to obtain a second verification result, and the second trustworthy verification is performed on the startup code according to the second digital signature to obtain a third verification result. The above-mentioned process can realize verification of the startup process of the target device from both software and hardware aspects, which can more comprehensively resist security attacks. Moreover, in the process of verifying the startup process of the target device, the characteristic information of the driver firmware is trusted through the digital signature verification technology, which can ensure the authenticity of the driver firmware to a certain extent. The trustworthy verification of the startup code through the digital signature verification technology and the integrity verification of the startup code through the summary information verification technology can ensure the authenticity and integrity of the startup code to a certain extent, thereby improving the security of the device startup process. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments of the present application or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying any creative work.

[0032] Figure 1 A schematic diagram of a process for starting a device based on secure and trusted module encryption authentication in one embodiment;

[0033] Figure 2 A schematic flow chart of steps for obtaining a first verification result in one embodiment;

[0034] Figure 3 A schematic flow chart of the steps for obtaining a second verification result in one embodiment;

[0035] Figure 4 A schematic flow chart of steps for obtaining a third verification result in one embodiment;

[0036] Figure 5 A flowchart of a device startup method based on secure and trusted module encryption authentication in another embodiment;

[0037] Figure 6 A schematic diagram of the connection pins in a key management module in one embodiment;

[0038] Figure 7 A schematic diagram of the states of the host input and the slave output MOSI pins when the target device sends first service data in one embodiment;

[0039] Figure 8 This is a schematic diagram of the state of the MOSI pin when the target device receives second service data in one embodiment;

[0040] Figure 9 A structural block diagram of a device startup apparatus based on secure and trusted module encryption authentication in one embodiment;

[0041] Figure 10 FIG. 1 is a diagram showing the internal structure of a computer device in one embodiment. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0043] In an exemplary embodiment, Figure 1 As shown, a device startup method based on secure and trusted module encryption authentication is provided, which is applied to the secure and trusted module corresponding to the target device. The secure and trusted module carries feature information of the driver firmware in the target device.

[0044] The secure and trusted module can be understood as a module that performs security verification on the boot process of the target device. Optionally, the secure and trusted module can include a chip. Alternatively, the secure and trusted module can include a chip module.

[0045] What needs to be understood here is that the security and trusted module can correspond to the target device. Optionally, the security and trusted module can be integrated into the target device. For example, the security and trusted module can be integrated into the motherboard or main control chip of the target device. Or optionally, the security and trusted module can be deployed in other devices. For example, the security and trusted module can be deployed on a device management system server used to centrally manage multiple target devices. The security and trusted module can be connected to the corresponding target device. For example, the security and trusted module can be connected to the corresponding target device via the Peripheral Component Interconnect Express (PCI-Express). In short, the security and trusted module can be used to perform security verification on the startup process of the corresponding target device.

[0046] Target devices can include physical devices or terminals connected via the internet or a communications network and capable of sensing, data transmission, and intelligent processing, such as IoT devices. For example, in the field of power distribution networks, target devices can include metering terminals, power distribution terminals, or charging stations.

[0047] The driver firmware may be understood as a boot loader carried in the operating system of the target device, which is used to initialize the hardware of the target device and guide the operating system of the target device to run.

[0048] The characteristic information of the driver firmware can be understood as information used to characterize the target characteristics of the driver firmware. The target characteristics of the driver firmware may include at least one of the identity characteristics and functional characteristics of the driver firmware. Exemplarily, the characteristic information of the driver firmware may include at least one of the version information and function code of the driver firmware. The version information can be used to indicate the version of the driver firmware. The function code can be understood as a code used to implement a certain function. Optionally, different function codes may implement different functions. Different driver firmware may contain different function codes.

[0049] The characteristic information of the driver firmware can be set on the secure and trusted module by burning and customizing it.

[0050] The device startup method based on secure and trusted module encryption authentication includes S110 to S130.

[0051] S110: After the target device is powered on, a first trustworthy verification is performed on the feature information according to a pre-stored first digital signature to obtain a first verification result; and an availability test is performed on the target hardware of the security and trustworthy module to obtain a first test result.

[0052] The first digital signature can be understood as being obtained by encrypting the summary information corresponding to the characteristic information.

[0053] In an optional embodiment, the first digital signature may be stored within the secure and trusted module. During the process of integrating the operating system into the target device and detecting the target device, the secure and trusted module may encrypt the summary information corresponding to the characteristic information to obtain the first digital signature, and store the first digital signature within the secure and trusted module.

[0054] The first trustworthy verification can be understood as verifying the credibility of the feature information to ensure that its source is trustworthy.

[0055] The target hardware of the security and trusted module may include chips and / or circuits in the security and trusted module.

[0056] Among them, the availability detection of the chip can be understood as the verification of the integrity of the chip.

[0057] The circuit availability test can be understood as the verification of the stability of the circuit connection.

[0058] After verifying the integrity of the chip and / or the stability of the circuit connection, it can be determined that the security and trustworthy module is available. The available security and trustworthy module can be used to verify the boot code of the target device.

[0059] In an optional embodiment, after the target device is powered on, the security and trusted module may be first started. The started security and trusted module may perform a first trustworthy verification on the feature information based on a pre-stored first digital signature to obtain a first verification result; and may also perform an availability test on the target hardware of the security and trusted module to obtain a first test result.

[0060] In an optional embodiment, when the first verification result indicates that the driver firmware is untrustworthy, the security and trustworthy module may send an alarm message to the target device to prevent the target device from starting.

[0061] In an optional embodiment, if the first verification result indicates that the driver firmware is trustworthy, the security and trust module can monitor the target device's startup status and record and process security events related to the target device. Security events can be understood as information indicating the success or failure of verification of the target device, including the reason for the failure. If verification fails, the security and trust module can check whether backup information corresponding to the startup process is stored and use it to boot the target device. If booting using the backup information fails, the target device is prohibited from booting.

[0062] S120: When the first verification result indicates that the driver firmware is trustworthy and the first detection result indicates that the security and trusted module is available, perform integrity verification on the startup code of the target device according to the first summary information to obtain a second verification result; and perform a second trustworthy verification on the startup code according to the second digital signature to obtain a third verification result.

[0063] The first summary information can be understood as being obtained by performing hash processing on the startup code.

[0064] Among them, integrity verification can be understood as verifying the legitimacy of the startup code.

[0065] The second digital signature can be understood as being obtained by encrypting the summary information of the boot code plain text. Alternatively, the second digital signature can be obtained by encrypting the first summary information.

[0066] The second trusted verification can be understood as verifying the credibility of the boot code to ensure that its source is credible.

[0067] In an optional embodiment, the first digest information and the second digital signature may be stored within the secure and trusted module. During the process of integrating the operating system into the target device and testing the target device, the secure and trusted module may hash the plaintext boot code to obtain the first digest information, store the first digest information within the secure and trusted module, and encrypt the first digest information to obtain the second digital signature, and store the second digital signature within the secure and trusted module.

[0068] When the first verification result indicates that the driver firmware is trustworthy and the first detection result indicates that the security and trusted module is available, the boot code of the target device can be integrity verified based on the stored first summary information to obtain a second verification result, and the boot code can be second trusted verification based on the stored second digital signature to obtain a third verification result.

[0069] In another optional embodiment, during the process of integrating the operating system into the target device and detecting the target device, the security and trusted module can hash the plaintext of the boot code to obtain first summary information, and then encrypt the first summary information to obtain a second digital signature, and store the second digital signature in the security and trusted module.

[0070] When the first verification result indicates that the driver firmware is trustworthy and the first detection result indicates that the security and trusted module is available, the stored second digital signature can be decrypted to obtain the first summary information, and then the obtained first summary information is used to perform integrity verification on the startup code of the target device to obtain a second verification result, and based on the stored second digital signature, a second trustworthy verification is performed on the startup code to obtain a third verification result.

[0071] S130: When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, sending boot authorization information to the target device, so that the target device boots the target device by loading and executing the boot code.

[0072] The startup authorization information may be understood as information used to instruct the processor of the target device to load and execute the startup code to start the operating system of the target device.

[0073] In the above-mentioned device startup method based on encryption authentication of a secure and trusted module, after the target device is powered on, a first trustworthy verification can be performed on the characteristic information of the driver firmware in the target device carried in the secure and trusted module according to a pre-stored first digital signature to obtain a first verification result, and an availability test can be performed on the target hardware of the secure and trusted module to obtain a first test result. If the first verification result indicates that the driver firmware is trustworthy and the first test result indicates that the secure and trusted module is available, the integrity of the startup code of the target device is verified according to the first summary information to obtain a second verification result, and the second trustworthy verification is performed on the startup code according to the second digital signature to obtain a third verification result. The above-mentioned process can realize verification of the startup process of the target device from both software and hardware aspects, which can more comprehensively resist security attacks. Moreover, in the process of verifying the startup process of the target device, the trustworthy verification of the characteristic information of the driver firmware through the digital signature verification technology can ensure the authenticity of the driver firmware to a certain extent. The trustworthy verification of the startup code through the digital signature verification technology and the integrity verification of the startup code through the summary information verification technology can ensure the authenticity and integrity of the startup code to a certain extent, thereby improving the security of the device startup process.

[0074] In an exemplary embodiment, Figure 2 As shown, the step of obtaining the first verification result includes S210 to S230.

[0075] S210: Perform a first hash process on the characteristic information to obtain second summary information corresponding to the characteristic information.

[0076] The second summary information can be understood as a hash value corresponding to the feature information.

[0077] S220: Decrypt the first digital signature using the pre-stored trusted root key to obtain third summary information.

[0078] Among them, the trusted root key can be generated by the key management module corresponding to the target device.

[0079] Optionally, the key management module can be integrated into the target device. For example, the key management module can be integrated into the mainboard or main control chip of the target device. Alternatively, the key management module can be deployed in other devices. For example, the key management module can be deployed on a device management system server for centralized management of multiple target devices. The key management module can be connected to the security and trusted module, for example, the key management module can be connected to the security and trusted module via a dedicated secure bus.

[0080] The key management module can send the generated trusted root key to the security trusted module.

[0081] The first digital signature may be obtained by encrypting the third summary information using an encryption key corresponding to the trusted root key.

[0082] The third summary information may be a hash value obtained by performing the first hash process on the feature information.

[0083] S230: Compare the second summary information with the third summary information to obtain a first verification result.

[0084] When the second digest information is consistent with the third digest information, it indicates that the characteristic information of the driver firmware has not been tampered with. In this case, the first verification result obtained can be that the driver firmware is credible.

[0085] When the second digest information is inconsistent with the third digest information, it indicates that the characteristic information of the driver firmware has been tampered with. In this case, the first verification result obtained may be that the driver firmware is untrustworthy.

[0086] In this embodiment, by performing the first trustworthy verification on the characteristic information of the driver firmware in a digital signature verification manner, the trustworthiness of the driver firmware can be ensured to a certain extent, thereby improving the security of the target device startup process.

[0087] In an exemplary embodiment, Figure 3 As shown, the steps of obtaining the second verification result include S310 to S320.

[0088] S310: Perform a second hash process on the boot code to obtain fourth digest information corresponding to the boot code.

[0089] The fourth summary information may be understood as a hash value corresponding to the startup code.

[0090] S320: Compare the first digest information of the boot code with the fourth digest information to obtain a second verification result.

[0091] The first summary information of the startup code may be obtained by performing a second hash process on the startup code.

[0092] When the fourth digest information is consistent with the first digest information, it indicates that the boot code has not been tampered with. In this case, the second verification result obtained may be that the boot code is complete.

[0093] When the fourth digest information is inconsistent with the first digest information, it indicates that the startup code has been tampered with. In this case, the second verification result obtained may be that the startup code is incomplete.

[0094] In this embodiment, by performing integrity verification on the boot code in a manner of digest information verification, the integrity of the boot code can be ensured to a certain extent, thereby improving the security of the target device boot process.

[0095] In an exemplary embodiment, Figure 4 As shown, the steps of obtaining the third verification result include S410 to S430.

[0096] S410: Perform a third hash process on the boot code to obtain fifth digest information corresponding to the boot code.

[0097] The fifth summary information may be understood as a hash value corresponding to the startup code.

[0098] S420: Decrypt the second digital signature using the stored trusted root key to obtain sixth summary information.

[0099] The second digital signature may be obtained by encrypting the sixth summary information using an encryption key corresponding to the trusted root key.

[0100] The sixth summary information may be a hash value obtained by performing a third hash process on the startup code.

[0101] S430: Compare the fifth summary information with the sixth summary information to obtain a third verification result.

[0102] When the fifth digest information and the sixth digest information are consistent, it indicates that the boot code has not been tampered with. In this case, the third verification result obtained can be that the boot code is credible.

[0103] When the fifth digest information and the sixth digest information are inconsistent, it indicates that the startup code has been tampered with. In this case, the third verification result obtained may be that the startup code is untrustworthy.

[0104] In this embodiment, by performing credibility verification on the boot code in a digital signature verification manner, the credibility of the boot code can be ensured to a certain extent, thereby improving the security of the target device boot process.

[0105] In an exemplary embodiment, before performing integrity verification on the startup code of the target device based on the first summary information to obtain a second verification result; and performing a second trust verification on the startup code based on the second digital signature to obtain a third verification result, the device startup method based on secure and trusted module encryption authentication also includes: sending a key acquisition request to the key management module corresponding to the target device; receiving the encrypted target key returned by the key management module in response to the key acquisition request; the encrypted target key is obtained by encrypting the public key sent by the secure and trusted module; decrypting the encrypted target key using the private key corresponding to the public key to obtain the target key; obtaining the startup code ciphertext; and decrypting the startup code ciphertext using the target key to obtain the startup code plaintext.

[0106] Accordingly, the integrity of the boot code plaintext of the target device is verified based on the first summary information to obtain a second verification result; and the second trustworthy verification is performed on the boot code plaintext based on the second digital signature to obtain a third verification result.

[0107] In an optional embodiment, the encrypted target key can be generated by encrypting a temporary encryption key generated by the key management module using a public key sent by the security and trusted module. In other words, the encrypted target key can be an encrypted temporary encryption key. The security and trusted module can decrypt the encrypted target key using its own private key to obtain the target key, i.e., the temporary encryption key.

[0108] In an optional embodiment, the security and trustworthy module can obtain the boot code ciphertext from the storage medium of the target device. During the acquisition process, the boot code ciphertext can be decrypted using the target key to obtain the boot code plaintext.

[0109] After obtaining the boot code plaintext, the target device's boot code plaintext can be subjected to integrity verification based on the first digest information to obtain a second verification result. The specific process can be found in the description of S310-S320 above and will not be repeated here. Furthermore, a second trusted verification can be performed on the boot code plaintext based on the second digital signature to obtain a third verification result. The specific process can be found in the description of S410-S430 above and will not be repeated here.

[0110] In this embodiment, by obtaining the target key and decrypting the boot code ciphertext, the security of the boot code can be ensured to a certain extent. After obtaining the boot code plaintext, the boot code plaintext is verified for integrity and a second trusted verification is performed, thereby improving the security of the target device boot process.

[0111] In an exemplary embodiment, the target hardware can be further refined into at least one of a chip and a circuit. Accordingly, performing an availability test on the target hardware of the security and trusted module to obtain a first test result may include: performing an integrity test on the characteristic data carried by the chip based on the seventh summary information, and / or performing a functional test on the chip based on a preset test instruction to obtain a first sub-test result; obtaining a second sub-test result based on the electrical parameter data in the circuit and a preset data range; and obtaining the first test result based on the first sub-test result and / or the second sub-test result.

[0112] The seventh summary information can be understood as a hash value generated by the manufacturer during the chip manufacturing phase based on the characteristic data carried in the chip of the security and trusted module. The seventh summary information can be stored in the target area of ​​the security and trusted module or in an external secure storage device.

[0113] For example, the characteristic data carried in the chip may include a function code and an identity identification number stored in the chip.

[0114] In an optional embodiment, during the integrity test, the security and trust module can again generate eighth summary information based on the characteristic data carried by the chip. The seventh summary information and the eighth summary information are then compared to obtain a first comparison result. If the first comparison result indicates a consistency, it indicates that the chip's characteristic data has not been tampered with and has good integrity. If the first comparison result indicates a disagreement, it indicates that the chip's characteristic data may have been tampered with, damaged, or faulty.

[0115] The preset test instructions can be understood as preset functional test instructions. For example, for a microprocessor chip, the preset test instructions may include arithmetic operation test instructions, logic operation test instructions, and test instructions for data storage and reading operations. For example, the preset test instructions may include logic circuit test instructions and storage unit test instructions.

[0116] In an optional embodiment, during the integrity test, the actual results of the chip executing the preset test instructions can be compared with the expected results to obtain a second comparison result. If the second comparison result indicates consistency, it indicates that the chip is functioning normally and has good integrity. If the second comparison result indicates inconsistency, it indicates that the chip may have a hardware fault or software error and has poor integrity.

[0117] In an optional embodiment, during the integrity test, a built-in self-test circuit can execute preset test instructions to test the chip's internal logic circuits, memory cells, and other components, and obtain test results. For example, according to preset read and write test instructions, the built-in self-test circuit can perform read and write tests on the chip's memory to verify whether data can be correctly stored and read. Another example is that the built-in self-test circuit can perform functional tests on logic gate circuits to verify the correctness of logical operations. The built-in self-test circuit can quickly detect internal chip hardware faults and determine chip integrity.

[0118] A first sub-detection result may be obtained according to at least one of the first comparison result, the second comparison result, and the test result.

[0119] The electrical parameter data in the circuit can be understood as at least one of the electrical impedance, voltage and current of the circuit.

[0120] In an optional embodiment, the secure and trusted module can inject an AC signal of a specific frequency and amplitude into the circuit to obtain the circuit's electrical impedance. Based on the obtained impedance and the corresponding preset data range, an impedance test result can be obtained. When the connection is normal and stable, the circuit's impedance is within the preset data range. If the circuit connection is loose, broken, or shorted, the impedance will exceed the preset data range.

[0121] In an optional embodiment, the secure and trusted module can detect the voltage and current values ​​of key nodes in the circuit. Based on the obtained voltage and the corresponding preset data range, a voltage detection result can be obtained. Based on the obtained current value and the corresponding preset data range, a current value detection result can be obtained.

[0122] When the circuit connection is stable, the voltage and current fluctuate within the preset data range. When the circuit connection is unstable, such as due to poor contact, the voltage drop and current value fluctuate greatly, exceeding the corresponding preset data range. Taking the lithium battery module connection circuit stability test as an example, the open circuit voltage, current and other parameters of the lithium battery can be used to determine whether the connection circuit is stable.

[0123] In an optional embodiment, the security and trust module can detect other parameters of the circuit transmission signal, such as amplitude, phase, rising and falling edge times, etc. An unstable connection can cause signal reflections, crosstalk, attenuation, and other issues, affecting signal integrity. By monitoring signal integrity indicators, the stability of the circuit connection can be determined. Based on these parameter data and the corresponding preset data ranges, corresponding other parameter data detection results can be obtained.

[0124] A second sub-detection result may be obtained based on the above-mentioned electrical impedance detection result, voltage detection result, current value detection result and other parameter data detection results.

[0125] A first detection result may be obtained according to the first sub-detection result and / or the second sub-detection result.

[0126] In this embodiment, by performing availability detection on the chip and circuit, and verifying the availability of the secure and trusted module, the startup process of the target device is verified, which can ensure the security and effectiveness of the verification process to a certain extent.

[0127] On the basis of the technical solutions of the above embodiments, the present application also provides an optional embodiment, in which a device startup method based on secure and trusted module encryption authentication is described in detail.

[0128] See also Figure 5 The flowchart of the device startup method based on secure and trusted module encryption authentication shown includes:

[0129] S501: The target device is powered on and the security and trustworthy module is started.

[0130] Among them, the target device's mainboard or main control chip integrates a security and trust module and a key management module.

[0131] The secure and trusted module is connected to the processor, hard disk and other components of the target device via the PCI-Express bus. The key management module is connected to the secure and trusted module via a dedicated secure bus.

[0132] The security and trustworthy module carries the characteristic information of the driver firmware in the target device.

[0133] S502: The security and trust module performs an availability test on the target hardware to obtain a first test result, and performs a first trust verification on feature information of the driver firmware based on a pre-stored first digital signature to obtain a first verification result.

[0134] S503: When the first detection result indicates that the security and trusted module is available and the first detection result indicates that the driver firmware is trustworthy, the security and trusted module sends a key acquisition request to a key management module corresponding to the target device.

[0135] S504: The key management module generates a set of temporary encryption keys, encrypts the temporary encryption keys using the public key of the security and trustworthy module, and then sends the encrypted temporary encryption keys to the security and trustworthy module.

[0136] S505: The security and trusted module decrypts the encrypted temporary encryption key using the private key to obtain the temporary encryption key.

[0137] S506: The security and trusted module obtains the boot code ciphertext from the storage medium of the target device, and decrypts the boot code ciphertext using the temporary encryption key to obtain the boot code plaintext.

[0138] S507: The security and trust module performs integrity verification on the boot code plaintext according to the first summary information to obtain a second verification result; and performs second trust verification on the boot code plaintext according to the second digital signature to obtain a third verification result.

[0139] S508: When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, the security and trusted module may send boot authorization information to the target device, so that the target device can boot the target device by loading and executing the boot code.

[0140] In one exemplary embodiment, the target device can be a computer. A secure and trusted module and a key management chip can be integrated on the computer's motherboard. The secure and trusted module connects to the computer's processor, hard drive, and other components via the PCI-Express bus, while the key management chip connects to the secure and trusted module via a dedicated secure bus. Customized firmware can be burned into the secure and trusted module to implement functions such as hardware self-test, key processing, and boot code verification. A device management system client can be installed in the computer's operating system to receive alert information sent by the secure and trusted module.

[0141] When the computer is powered on, the security and trust module first boots up, performing hardware availability checks and firmware trust verification. After these checks and verifications pass, the security and trust module exchanges keys with the key management chip to obtain a temporary encryption key. The security and trust module then reads the boot code from the hard drive and uses the temporary encryption key to decrypt and verify its authenticity. If verification succeeds, the security and trust module sends a boot authorization signal to the processor, booting the operating system. If verification fails, the device management system client displays an alert window, notifying the user of security risks during the boot process.

[0142] In an exemplary embodiment, the target device may be an IoT device. A secure and trusted module and a key management chip may be integrated into the IoT device's main control chip. The secure and trusted module connects to the IoT device's storage chip, sensors, and other components via a serial peripheral interface (SPI) bus, while the key management chip connects to the secure and trusted module via a two-wire serial bus. A streamlined firmware can be burned into the secure and trusted module. A device management system server is deployed on the IoT device management platform to enable centralized management of multiple IoT devices.

[0143] When the IoT device is powered on, the security and trust module starts up, performing hardware availability checks and firmware trust verification. The security and trust module then exchanges keys with the key management chip to obtain a temporary encryption key. The security and trust module reads the boot code from the device's flash memory and uses the temporary encryption key to decrypt and verify its trustworthiness. If verification succeeds, the device's application starts up. If verification fails, the device management system server sends an alert to the administrator, allowing them to take timely action to ensure the security of the IoT device.

[0144] After starting the target device, the target device can send the first service data to the service system. If the service system returns a target error code (e.g., 6A90), indicating that an error occurred during the transmission of the first service data, the target device can initiate a process of resending the first service data.

[0145] The business system can return second business data to the target device based on the first business data. After receiving the second business data, the target device can process the second business data according to preset data processing rules to obtain data in the first format. It can then compare the first format data with the second format data received from the key management module for consistency. If there is any inconsistency, it indicates that an error occurred during the transmission of the second business data. In this case, the target device can restart the receiving process.

[0146] Figure 6 The diagram of the connection of the wiring pins in the key management module is shown in Table 1. Table 1 describes the pin name, signal, pin number and pin description of each wiring pin in the key management module.

[0147] Table 1

[0148]

[0149] Figure 7 This diagram shows the state of the Master Input Slave Output (MISO) pin when the target device sends first service data. The MISO pin must remain in a receiving state. Data on the MISO pin is invalid data, so the target device does not need to process it and directly discards or does not receive it. Figure 8 The diagram shows the state of the MOSI pin of the target device when receiving the second service data. The MISO pin should always maintain a low level.

[0150] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0151] Based on the same inventive concept, embodiments of the present application also provide a device startup apparatus based on secure and trusted module encryption authentication for implementing the aforementioned device startup method based on secure and trusted module encryption authentication. The implementation solution provided by this apparatus is similar to the implementation solution described in the aforementioned method. Therefore, the specific limitations of one or more embodiments of the device startup apparatus based on secure and trusted module encryption authentication provided below can be found in the limitations of the device startup method based on secure and trusted module encryption authentication above, and will not be repeated here.

[0152] In an exemplary embodiment, Figure 9 As shown, a device startup device based on secure and trusted module encryption authentication is provided, which is configured in a secure and trusted module corresponding to a target device. The secure and trusted module carries characteristic information of the driver firmware in the target device, including: a first verification module 910, a second verification module 920 and a first sending module 930, wherein:

[0153] A first verification module 910 is configured to, after the target device is powered on, perform a first trustworthy verification on the feature information based on a pre-stored first digital signature to obtain a first verification result; and perform an availability test on the target hardware of the security and trustworthy module to obtain a first test result;

[0154] A second verification module 920 is configured to, if the first verification result indicates that the driver firmware is trustworthy and the first detection result indicates that the security and trustworthy module is available, perform integrity verification on the boot code of the target device based on the first summary information to obtain a second verification result; and perform a second trustworthiness verification on the boot code based on the second digital signature to obtain a third verification result;

[0155] The first sending module 930 is configured to send startup authorization information to the target device if the second verification result indicates that the startup code is complete and the third verification result indicates that the startup code is credible, so that the target device can start the target device by loading and executing the startup code.

[0156] In one embodiment, the first verification module 910 is specifically used to: perform a first hash process on the characteristic information to obtain second summary information corresponding to the characteristic information; use a pre-stored trusted root key to decrypt the first digital signature to obtain third summary information; compare the second summary information with the third summary information to obtain a first verification result.

[0157] In one embodiment, the second verification module 920 is specifically configured to: perform a second hash process on the boot code to obtain fourth digest information corresponding to the boot code; and compare the first digest information of the boot code with the fourth digest information to obtain a second verification result.

[0158] In one embodiment, the second verification module 920 is specifically used to: perform a third hash process on the boot code to obtain fifth summary information corresponding to the boot code; use the stored trusted root key to decrypt the second digital signature to obtain sixth summary information; and compare the fifth summary information with the sixth summary information to obtain a third verification result.

[0159] In one embodiment, before performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second trusted verification on the boot code according to the second digital signature to obtain a third verification result, the device also includes: a second sending module, used to: send a key acquisition request to the key management module corresponding to the target device; a receiving module, used to: receive the encrypted target key returned by the key management module in response to the key acquisition request; the encrypted target key is obtained by encrypting the public key sent by the security and trusted module; a first decryption module, used to: decrypt the encrypted target key using the private key corresponding to the public key to obtain the target key; an acquisition module, used to obtain the boot code ciphertext; a second decryption module, used to decrypt the boot code ciphertext using the target key to obtain the boot code plaintext; accordingly, the second verification module 920 is specifically used to: perform integrity verification on the boot code plaintext of the target device according to the first summary information to obtain a second verification result; and perform a second trusted verification on the boot code plaintext according to the second digital signature to obtain a third verification result.

[0160] In one embodiment, the target hardware includes at least one of a chip and a circuit; accordingly, the first verification module 910 is specifically used to: perform integrity detection on the characteristic data carried in the chip according to the seventh summary information, and / or perform functional detection on the chip according to a preset test instruction to obtain a first sub-detection result; obtain a second sub-detection result based on the electrical parameter data in the circuit and a preset data range; obtain a first detection result based on the first sub-detection result and / or the second sub-detection result.

[0161] Each module in the aforementioned device startup apparatus based on secure and trusted module encryption authentication can be implemented in whole or in part through software, hardware, or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in hardware form, or can be stored in a computer device memory in software form, so that the processor can call and execute the corresponding operations of each module.

[0162] In an exemplary embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as shown in FIG. Figure 10 As shown. The computer device includes a processor, a memory, an input / output interface (Input / Output, I / O) and a communication interface. The processor, memory and input / output interface are connected through a system bus, and the communication interface is connected to the system bus through the input / output interface. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The input / output interface of the computer device is used to exchange information between the processor and an external device. The communication interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a device startup method based on secure and trusted module encryption authentication is implemented.

[0163] Those skilled in the art will understand that Figure 10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0164] In an exemplary embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the steps of the device startup method based on secure and trusted module encryption authentication provided in any of the above embodiments are implemented.

[0165] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of the device startup method based on secure and trusted module encryption authentication provided in any of the above embodiments are implemented.

[0166] In one embodiment, a computer program product is provided, including a computer program, which, when executed by a processor, implements the steps of the device startup method based on secure and trusted module encryption authentication provided in any of the above embodiments.

[0167] Those skilled in the art will understand that all or part of the processes in the above-mentioned embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. In particular, any reference to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The databases involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the various embodiments provided herein may be, but are not limited to, general-purpose processors, central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), programmable logic devices (PLDs), quantum computing-based data processing logic devices, artificial intelligence (AI) processors, and the like.

[0168] The technical features of the above embodiments can be combined arbitrarily. In order to make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0169] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A device startup method based on secure and trusted module encryption authentication, characterized in that: A secure and trusted module corresponding to a target device is applied thereto, wherein the secure and trusted module carries characteristic information of a driver firmware in the target device. The method includes: After the target device is powered on, performing a first trustworthy verification on the feature information according to a pre-stored first digital signature to obtain a first verification result; and performing an availability test on the target hardware of the security and trustworthy module to obtain a first test result; If the first verification result indicates that the driver firmware is credible and the first detection result indicates that the security and trusted module is available, performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and performing a second credibility verification on the boot code according to the second digital signature to obtain a third verification result; When the second verification result indicates that the boot code is complete and the third verification result indicates that the boot code is credible, boot authorization information is sent to the target device, so that the target device boots the target device by loading and executing the boot code.

2. The method according to claim 1, characterized in that The step of performing a first trustworthy verification on the feature information according to the pre-stored first digital signature to obtain a first verification result includes: Performing a first hash process on the characteristic information to obtain second summary information corresponding to the characteristic information; Decrypting the first digital signature using a pre-stored trusted root key to obtain third summary information; The second summary information is compared with the third summary information to obtain a first verification result.

3. The method according to claim 1, characterized in that The performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result includes: performing a second hash process on the startup code to obtain fourth digest information corresponding to the startup code; The first digest information of the startup code is compared with the fourth digest information to obtain a second verification result.

4. The method according to claim 1, wherein The performing a second trusted verification on the startup code according to the second digital signature to obtain a third verification result includes: performing a third hash process on the startup code to obtain fifth digest information corresponding to the startup code; Decrypting the second digital signature using the stored trusted root key to obtain sixth summary information; The fifth summary information is compared with the sixth summary information to obtain a third verification result.

5. The method according to claim 1, wherein performing integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; Furthermore, before performing a second trusted verification on the boot code based on the second digital signature and obtaining a third verification result, the method further includes: Sending a key acquisition request to the key management module corresponding to the target device; receiving an encrypted target key returned by the key management module in response to the key acquisition request; the encrypted target key is obtained by encrypting the public key sent by the security and trusted module; Decrypting the encrypted target key using a private key corresponding to the public key to obtain the target key; Get the startup code ciphertext; Decrypting the startup code ciphertext using the target key to obtain the startup code plaintext; Accordingly, the integrity verification of the boot code of the target device is performed based on the first summary information to obtain a second verification result; and the second trustworthy verification is performed on the boot code based on the second digital signature to obtain a third verification result, including: Performing integrity verification on the boot code plaintext of the target device according to the first summary information to obtain a second verification result; and performing a second trusted verification on the boot code plaintext according to the second digital signature to obtain a third verification result.

6. The method according to any one of claims 1 to 5, characterized in that The target hardware includes at least one of a chip and a circuit; accordingly, performing availability detection on the target hardware of the secure and trusted module to obtain a first detection result includes: performing an integrity test on the characteristic data carried in the chip according to the seventh summary information, and / or performing a function test on the chip according to a preset test instruction to obtain a first sub-test result; Obtaining a second sub-detection result based on the electrical parameter data in the circuit and a preset data range; A first detection result is obtained according to the first sub-detection result and / or the second sub-detection result.

7. A device startup device based on secure and trusted module encryption authentication, characterized in that: A secure and trusted module configured to correspond to a target device, wherein the secure and trusted module carries characteristic information of a driver firmware in the target device, and the apparatus comprises: a first verification module configured to, after the target device is powered on, perform a first trustworthy verification on the feature information based on a pre-stored first digital signature to obtain a first verification result; and perform an availability test on the target hardware of the security and trustworthy module to obtain a first test result; a second verification module configured to, if the first verification result indicates that the driver firmware is trustworthy and the first detection result indicates that the security and trusted module is available, perform integrity verification on the boot code of the target device according to the first summary information to obtain a second verification result; and perform a second trustworthy verification on the boot code according to the second digital signature to obtain a third verification result; The first sending module is configured to send startup authorization information to the target device when the second verification result indicates that the startup code is complete and the third verification result indicates that the startup code is credible, so that the target device starts the target device by loading and executing the startup code.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Citation Information

Cited By

  • Safety starting hardware trust root module integrated on mainboard and verification method

    CN121659330A