A processing method and apparatus

Abstract

The present application discloses a processing method, comprising: obtaining firmware status information of a first component of an electronic device after the boot system of the electronic device completes boot system firmware verification, the first component including at least one component different from the boot system; performing management processing on the firmware status information, and causing the electronic device to respond to the corresponding management processing result.

Description

Technical Field

[0001] This application relates to the field of computer technology, and to, but is not limited to, a processing method and apparatus. Background Technology

[0002] In related technologies, many electronic devices have firmware on their components. However, the boot system or operating system of the electronic device cannot know the firmware status information of other components, such as whether the firmware of other components has been attacked, or whether the firmware has automatically recovered after being attacked. Summary of the Invention

[0003] In view of this, embodiments of this application provide a processing method, apparatus, device, and storage medium.

[0004] In a first aspect, embodiments of this application provide a processing method, comprising: after the boot system of an electronic device completes boot system firmware verification, obtaining firmware status information of a first component of the electronic device, wherein the first component includes at least one component different from the boot system; performing management processing on the firmware status information, and causing the electronic device to respond to the corresponding management processing result.

[0005] Secondly, embodiments of this application provide a processing apparatus, comprising: an acquisition module, configured to acquire firmware status information of a first component of the electronic device after the boot system of the electronic device has completed boot system firmware verification, wherein the first component includes at least one component different from the boot system; and a processing module, configured to manage and process the firmware status information, and cause the electronic device to respond to the corresponding management and processing result.

[0006] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the steps in the processing method described in embodiments of this application.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the processing method described in embodiments of this application.

[0008] In this embodiment, the boot system obtains the firmware status information of the first component and manages and processes the firmware status information, so that the electronic device responds to the corresponding management and processing results. Thus, without increasing additional costs, the boot system or the operating system of the electronic device can know the firmware status information of other components to determine whether the firmware has been attacked, thereby improving the efficiency and convenience of firmware status management of components. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating a processing method according to an embodiment of this application;

[0010] Figure 2 This is a flowchart illustrating another processing method according to an embodiment of this application;

[0011] Figure 3 This is a flowchart illustrating another processing method according to an embodiment of this application;

[0012] Figure 4 This is a flowchart illustrating another processing method according to an embodiment of this application;

[0013] Figure 5 A flowchart illustrating a processing method is also provided as an embodiment of this application.

[0014] Figure 6 A flowchart illustrating a processing method is also provided as an embodiment of this application.

[0015] Figure 7 A flowchart illustrating a processing method is also provided as an embodiment of this application.

[0016] Figure 8 This is a schematic diagram of a trust chain of a component according to an embodiment of this application;

[0017] Figure 9 This is a flowchart illustrating a method for mutual verification between BIOS and driver according to an embodiment of this application;

[0018] Figure 10 This is a schematic diagram of the composition structure of a processing device according to an embodiment of this application;

[0019] Figure 11 This is a schematic diagram of a hardware entity of an electronic device according to an embodiment of this application. Detailed Implementation

[0020] The technical solution of this application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0021] Figure 1 This is a flowchart illustrating a processing method according to an embodiment of this application, as shown below. Figure 1 As shown, the method includes:

[0022] Step 102: After the boot system firmware verification is completed in the boot system of the electronic device, the firmware status information of the first component of the electronic device is obtained. The first component includes at least one component that is different from the boot system.

[0023] The boot system can include the Basic Input Output System (BIOS), the Unified Extensible Firmware Interface (UEFI), and the Extensible Firmware Interface (EFI). The BIOS is a set of programs embedded in a read-only memory (ROM) chip on the motherboard of an electronic device. It stores the most important basic input / output programs, the power-on self-test (POST) program, and the system boot program. The main function of the BIOS is to provide the lowest-level and most direct hardware settings and control for electronic devices. UEFI is a personal computer system specification that defines the software interface between the operating system and the system firmware, and can serve as an alternative to the BIOS. The Extensible Firmware Interface (EFI) is responsible for power-on self-test, communication with the operating system, and providing an interface between the operating system and the hardware.

[0024] The first component can be a component of an electronic device, such as an external graphics card, network card, storage device, Trusted Platform Module (TPM), fingerprint reader, camera, instruction register, keyboard, management engine (ME), embedded controller (EC), etc. The firmware can be code program embedded in the first component, and the firmware status information can characterize whether the firmware has been attacked and whether recovery has been completed after an attack.

[0025] The boot system firmware verification may include verifying the legitimacy of its own boot system firmware, verifying the legitimacy of the first component, and verifying the legitimacy of the second component; the second component includes at least one component that is different from the boot system and the first component; it should be noted that the first component or the second component may also verify the legitimacy of the boot system firmware.

[0026] Step 104: Manage the firmware status information and make the electronic device respond with the corresponding management processing result.

[0027] The management process may include storing firmware status information, processing firmware status information data, updating and maintaining firmware based on firmware status information, etc.

[0028] Correspondingly, when the management process involves storing firmware status information, the management process result can be based on the firmware status represented by the firmware status information, storing the firmware status information to the corresponding storage location, and then normally booting into the operating system state or component information display state; when the management process involves data processing of firmware status information, the management process result can be based on the firmware status represented by the firmware status information, performing data processing on the firmware status information, for example, updating the storage location of the firmware status information, and then normally booting into the operating system (OS); when the management process involves updating and maintaining the firmware based on the firmware status information, the management process result can be based on the firmware status information to update or maintain the firmware, and the firmware is in an update or maintenance state.

[0029] In some embodiments, after the electronic device is powered on, the BIOS performs legality verification on the BIOS firmware and on the first components such as the external graphics card, network card, storage device, trusted platform module, fingerprint recognition component, camera, instruction register, keyboard, management engine, and embedded controller, as well as the second components such as the external hard drive of the electronic device. Then, the BIOS can initialize the first and second components. During the initialization process, the BIOS queries the firmware status information of the components. The components can report the firmware status information through the protocol specified by the BIOS, so that the BIOS can obtain the firmware status information of the first components.

[0030] The BIOS can store the firmware status information of the first and / or second components. The BIOS can also update the storage location of the firmware status information of the first and / or second components. When booting into the operating system, the operating system can access the storage location of the firmware status information of the components to obtain the firmware status information of the corresponding components, and then determine whether the BIOS firmware, the firmware of the first component, and the firmware of the second component are secure based on the firmware status information. The BIOS can also update and maintain the firmware status information of other components besides the BIOS. The BIOS or the operating system can obtain the firmware status information of other components in a timely manner to determine whether the firmware has been attacked or whether it has been recovered after being attacked, which improves the efficiency of firmware status management of components without increasing the cost.

[0031] In this embodiment, the boot system obtains the firmware status information of the first component and manages and processes the firmware status information, so that the electronic device responds to the corresponding management and processing results. Thus, without increasing additional costs, the boot system or the operating system of the electronic device can know the firmware status information of other components to determine whether the firmware has been attacked, thereby improving the efficiency and convenience of firmware status management of components.

[0032] In some embodiments, such as Figure 2 As shown, step 104, "managing the firmware status information and causing the electronic device to respond with the corresponding management processing result," can be achieved through step 141 or step 142:

[0033] Step 141: If the firmware status information indicates that the firmware of the first component is in a secure state, store the firmware status information in the Trusted Platform Module (TPM) chip of the electronic device.

[0034] The firmware status information can be represented as Detect, Protect, and Recover; Protect and Recover can both indicate that the firmware is in a safe state; Detect can indicate that the firmware is in a risky state.

[0035] The TPM chip is a secure cryptographic processor designed specifically for cryptographic operations. It is tamper-proof and contains a unique key that can be used for platform device authentication. The TPM can check the system's integrity during the boot process to ensure the system has not been tampered with.

[0036] Step 142: If the firmware status information indicates that the firmware of the first component is in a risky state, restore or upgrade the firmware of the first component.

[0037] In some embodiments, when the firmware status information is Protect or Recover, it indicates that the firmware is in a secure state. The BIOS can store the firmware status information in the Trusted Platform Module (TPM) chip of the electronic device so that the operating system can read the firmware status information of the BIOS or other components. When the firmware status information is Detect, it indicates that the firmware is in a risky state. The BIOS can allow the firmware of the first component to recover automatically by unplugging the network cable. If the firmware cannot recover automatically, a new version of the firmware can be downloaded to restore or upgrade the firmware. After the firmware is restored or upgraded, the BIOS can store the firmware status information of the firmware in the TPM chip.

[0038] In this embodiment of the application, by saving the firmware status information to the TPM when the firmware is in a secure state, the risk of the firmware status information being tampered with can be reduced and the reliability of the firmware status information can be improved; by restoring and upgrading the firmware when the firmware is in a risky state, the firmware can be maintained in a timely and efficient manner, thereby reducing the probability of firmware risk.

[0039] In some embodiments, such as Figure 3As shown, the step 141 of "storing the firmware status information to the Trusted Platform Module (TPM) chip of the electronic device" can be achieved through the following steps 1411 or 1412:

[0040] Step 1411: If the firmware status information indicates that the firmware of the first component has not been modified, the firmware status information is directly mapped to the target storage bit in the Trusted Platform Module (TPM) chip of the electronic device.

[0041] Step 1412: If the firmware status information indicates that the firmware of the first component has been modified, update the mapping relationship between the firmware status information and the target memory bit in the TPM chip of the electronic device based on the update information.

[0042] Among them, the firmware status information Protect indicates that the firmware is in a safe state and has not been modified, that is, the firmware has not been attacked. The firmware status information Recover indicates that the firmware is in a safe state and has been modified, that is, although the firmware has been tampered with, it has been restored to a trustworthy firmware.

[0043] In some embodiments, when the firmware status information is Protect, it indicates that the firmware is in a secure state and has not been modified. The firmware status information of the firmware can be directly mapped to the target storage bit in the Trusted Platform Module (TPM) chip of the electronic device. When the firmware status information is Recover, it indicates that the firmware is in a secure state and has been modified. The mapping relationship between the firmware status information and the target storage bit in the TPM chip of the electronic device can be updated based on the update information. The target storage bit can be the physical address where the firmware status information is stored, determined according to the mapping relationship (or address translation function) defined in each firmware. The address translation function is used to convert between the virtual address space and the physical address of the firmware status information.

[0044] It should be noted that if the firmware of the first component is changed, the virtual address information of the firmware will change accordingly, and the mapping relationship between the firmware status information and the target storage bit needs to be updated accordingly.

[0045] In this embodiment, when the firmware has not been modified, the firmware status information is stored in the target storage location of the TPM; when the firmware is modified, the storage location of the firmware status information is updated, thereby enabling timely and accurate determination of the physical storage location of the firmware status information.

[0046] In some embodiments, such as Figure 4 As shown, the "response to the corresponding management processing result" in step 104 can be achieved through the following steps 143, 144, or 145:

[0047] Step 143: In response to the boot system completing the legality verification of the system boot program, enter the operating system or target application running state;

[0048] In some embodiments, after the boot system completes the legality verification of the system boot program, the system boot program guides the electronic device into the operating system or target application running state, and the operating system or target application can obtain the firmware status information of the boot system firmware or the first component.

[0049] Step 144: Output the management processing result of the firmware status information;

[0050] In some embodiments, the target storage bit of firmware status information, the mapping relationship between the updated firmware status information and the target storage bit, or the firmware status information after firmware updates and maintenance can be output.

[0051] Step 145: Read the firmware status information of the target component from the TPM chip of the electronic device, so as to execute the function carried by the target component after verification.

[0052] In this process, after the operating system or application verifies the firmware status information and obtains the first verification result, it can compare it with the second verification result of the boot system on the firmware status information. If the comparison result shows that the first verification result and the second verification result are consistent, the verification is considered to be successful and the function carried by the target component can be executed.

[0053] In some embodiments, when the target component is a fingerprint recognition component, the operating system or application of the electronic device can read the firmware status information of the fingerprint recognition component and perform fingerprint recognition through the fingerprint recognition component after successful verification.

[0054] In this embodiment of the application, different management and processing results are obtained by managing and processing firmware status information, thereby improving the diversity of firmware status information management and processing.

[0055] In some embodiments, such as Figure 5 As shown, after step 141, the method further includes steps 151 and 152:

[0056] Step 151: Use the configuration register of the TPM as the root of trust, where the configuration register stores the firmware status information of the first component obtained by the boot system;

[0057] In some embodiments, the trusted measurement root can be the base point for trusted platform to perform trusted measurement. The trusted measurement root can be a piece of software that is executed first when the central processing unit (CPU) starts up. It is the first code in the BIOS, that is, the first few lines of BIOS instructions. The first few lines of BIOS instructions are hard-coded in the BIOS Serial Peripheral Interface (SPI) and cannot be modified. The trusted measurement root can also be the configuration register of TPM.

[0058] Step 152: Based on the trusted measurement root, perform a trusted measurement on the system bootloader, operating system, or target application, and grant access permissions or output warning information to the system bootloader, operating system, or target application based on the measurement result.

[0059] The access permissions can be TPM access permissions, and the warning information can be used to indicate that the system bootloader, operating system, or target application has low credibility (i.e., is untrustworthy) and TPM access permissions cannot be granted to the system bootloader, operating system, or target application.

[0060] If the measurement results indicate that the system bootloader, operating system, or target application is trustworthy, access to the TPM can be granted to the system bootloader, operating system, or target application; if the measurement results indicate that the system bootloader, operating system, or target application is untrustworthy, a warning message can be output.

[0061] In some embodiments, when access to the TPM is enabled, the operating system of the electronic device or the target application can read the firmware status information of the target component from the TPM chip to execute the function carried by the target component after verification.

[0062] In this embodiment, a trust measurement can be performed on the system bootloader, operating system, or target application based on the trust measurement root. Based on the measurement result, it can be determined whether to grant TPM access permissions to the system bootloader, operating system, or target application or to output a warning message. This allows for more accurate trust measurement and improves data security by determining whether to grant TPM access permissions based on the measurement result.

[0063] In some embodiments, after step 151, the method may further include steps 153 to 156:

[0064] Step 153: Based on the aforementioned trust metric root, perform a trust metric on the system bootloader;

[0065] The system bootloader can be represented as a system boot program. It can be verified once by the public key stored in the boot system (such as BIOS). If the system boot program is signed by the private key corresponding to the public key, then the system boot program is trustworthy and can be invoked.

[0066] Step 154: If the measurement result of the system bootloader indicates that the system bootloader is trustworthy, perform a trustworthiness measurement on the operating system based on the verification mechanism of the system bootloader;

[0067] Step 155: If the measurement results of the operating system indicate that the operating system is trustworthy, perform a trustworthiness measurement on the target application based on the verification mechanism of the operating system;

[0068] In some embodiments, a trusted chain can be formed by starting with a trusted metric root and gradually expanding to include a trusted metric root, a system bootloader, an operating system, and a target application. In the trusted chain, the trusted metric root can be used to verify the trustworthiness of the system bootloader, the system bootloader can be used to verify the trustworthiness of the operating system, and the operating system's own verification mechanism can be used to verify the trustworthiness of the target application (i.e., the target application), ultimately achieving security and trustworthiness from the underlying hardware to the mid-level operating system and then to the upper-level application.

[0069] In some embodiments, where the trusted measurement root is the first few lines of BIOS instructions, the trusted chain can also be "trusted measurement root - boot system firmware - system bootloader - operating system - target application". In the trusted chain, the trusted measurement root is used to verify the trustworthiness of the hardware and boot system firmware, the boot system firmware's verification mechanism is used to verify the trustworthiness of the system bootloader, the system bootloader is used to verify the trustworthiness of the operating system, and the operating system's own verification mechanism is used to verify the trustworthiness of the target application, ultimately achieving security and trustworthiness from the underlying hardware to the mid-level operating system and then to the upper-level application.

[0070] Step 156: If the measurement results of the target application indicate that the target application is trustworthy, start the target application or invoke the target components required by the target application.

[0071] In this embodiment, the target application is only started or its required components are invoked when the target application has a high degree of trustworthiness, thereby improving data security and reducing the risk of data tampering.

[0072] In some embodiments, such as Figure 6 As shown, the step 102 of "obtaining the firmware status information of the first component of the electronic device" can be achieved through the following step 121:

[0073] Step 121: During the process of initializing the first component in the boot system, read the firmware status information of each of the first components through the target protocol; or, receive the firmware status information of each of the first components reported by their respective firmware in accordance with the target protocol.

[0074] In some embodiments, the boot system (such as BIOS) can query the firmware status information of the first component according to the target protocol specified by the BIOS. The boot system can also receive the firmware status information actively reported by the first component according to the target protocol specified by the BIOS. After obtaining the firmware status information of the first component, the firmware status information can be reported to the operating system (OS) or upper-layer software through standard interfaces such as System Management BIOS (SMBIOS) or Advanced Configuration and Power Management Interface (ACPI).

[0075] In this embodiment, firmware status information can be reported by the respective firmware according to the target protocol, or the boot system can obtain firmware status information through the target protocol, which improves the standardization and diversity of forms of the boot system in obtaining firmware status information.

[0076] In some embodiments, such as Figure 6 As shown, the method further includes:

[0077] Step 101: After the second component of the electronic device completes its own legitimacy verification, it uses a preset algorithm and a preset public key to verify the legitimacy of the boot system firmware in order to complete the verification of the boot system firmware. The second component is a driver program different from the first component. The first component includes at least one component different from the boot system or the second component.

[0078] The second component can be a driver for a portable hard drive; the boot system can verify the legitimacy of the driver through the driver's identification information, and the driver can also verify the legitimacy of the boot system firmware through the boot system's identification information.

[0079] In some embodiments, after the driver of the portable hard drive of the electronic device completes its own legitimacy verification, it can also use a preset algorithm and a preset public key to verify the legitimacy of the boot system firmware (such as BIOS firmware) to complete the verification of the boot system firmware. That is, the driver of the portable hard drive can verify its own legitimacy and also verify the legitimacy of the boot system firmware; while the boot system can verify its own boot system firmware and also verify the firmware of the second component. Therefore, the boot system can verify the legitimacy of the portable hard drive driver, and the portable hard drive driver can verify the legitimacy of the boot system. That is, the boot system and the portable hard drive driver can verify each other's legitimacy.

[0080] In this embodiment of the application, the objectivity and credibility of the verification between the boot system firmware and the second component can be improved by performing mutual legality verification between the boot system firmware and the second component.

[0081] In some embodiments, such as Figure 7 As shown, the step 102 of "obtaining the firmware status information of the first component of the electronic device" can be achieved through the following step 122:

[0082] Step 122: Obtain the first identification information of the first component obtained by the driver corresponding to the first component. If the first identification information matches the second identification information stored in the boot system, obtain the firmware status information of the first component of the electronic device.

[0083] In some embodiments, the boot system can determine whether the legitimacy authentication of the first component is successful by whether the first identification information of the first component obtained matches the second identification information stored in the boot system. If the first identification information matches the second identification information, the legitimacy authentication of the first component is successful, and the boot program obtains the firmware status information of the first component. If the first identification information does not match the second identification information, the legitimacy authentication of the first component fails, and the boot program cannot obtain the firmware status information of the first component.

[0084] In this embodiment of the application, the boot system can determine the legality authentication result of the first component by matching the identification information of the first component with the second identification information stored in the boot system, thereby improving the credibility of the firmware status information of the first component and improving data security and reliability.

[0085] In some embodiments, such as Figure 7 As shown, the method further includes:

[0086] Step 106: After receiving the instruction to run the first component of the electronic device, the identification information of the first component obtained by the driver corresponding to the first component is matched, so as to intercept the instruction or make the electronic device respond to the instruction based on the matching result.

[0087] In some embodiments, the first component can be a portable hard drive. Since the portable hard drive is detachable, it can be removed from one electronic device and installed on another, allowing access to encrypted file content. However, there is a risk of data leakage if the password is cracked. The boot system can verify the portable hard drive using its identification information. If the identification information matches the second identification information stored in the boot system, the boot system considers the verification of the portable hard drive's legitimacy to be successful. If the identification information does not match the second identification information stored in the boot system, the boot system considers the verification of the portable hard drive's legitimacy to be unsuccessful. When legitimacy verification fails, the command to run the portable hard drive can be intercepted; when legitimacy verification succeeds, the electronic device can respond to the command to run the portable hard drive.

[0088] In some embodiments, the portable hard drive can also verify the legitimacy of the boot system through the identification information of the boot system. If the identification information of the portable hard drive matches the third identification information stored in the boot system, the boot system can be considered to have passed the legitimacy verification of the portable hard drive. If the identification information of the portable hard drive does not match the third identification information stored in the boot system, the boot system can be considered to have failed the legitimacy verification of the portable hard drive.

[0089] In some embodiments, mutual verification can be performed between the portable hard drive's driver and the boot system. After both the portable hard drive's driver and the boot system pass mutual verification, the electronic device can respond to the instruction and run the portable hard drive. If either verification fails, the instruction is intercepted, thus avoiding the risk of data leakage caused by the portable hard drive being booted on other electronic devices.

[0090] In this embodiment of the application, the determination of whether to run the first component is based on the matching result of the identification information of the first component is made so that the running instructions of the first component can be intercepted when the legality authentication of the first component fails, thereby reducing the risk of data leakage of the first component.

[0091] In related technologies, many devices (i.e., electronic devices) on desktop computers have firmware (FW) on them. Firmware is hardware with software functions; it is a device that embeds software into hardware. In order to meet the requirements of the National Institute of Standards and Technology (NIST-800-193), all component FWs are required to have detect-protect-recovery functions. Related technologies can only tell users the status of the Basic Input Output System (BIOS), Management Engine (ME), and Embedded Controller (EC) devices. However, there is no mechanism to tell the BIOS or the system the firmware status of other components (such as external graphics cards, network cards, storage devices, etc.), such as whether the device firmware has been attacked or whether the device firmware has recovered itself.

[0092] To address the aforementioned problems and the shortcomings of solutions in related technologies, this application proposes the following embodiments:

[0093] The BIOS defines a unified architecture and protocol, requiring all component firmware to comply with this specification. This application proposes that when a detect-protect-recovery event occurs in the component's firmware, it should be reported to the BIOS. The BIOS will then report this to the operating system (OS) or upper-layer software via standard interfaces such as SMBIOS or the Advanced Configuration and Power Management Interface (ACPI).

[0094] The components in this application embodiment may include an external graphics card, a network card, a storage device, a trusted platform module, a fingerprint recognition component, a camera, an instruction register, a touchpad and keyboard, a management engine, an embedded controller, etc.

[0095] Using the embodiments of this application does not affect the current cost, and can support the system or upper-layer application software to obtain the firmware status of the component, giving users a better experience.

[0096] This application provides a processing method, which may include the following steps:

[0097] Step S202: When the electronic device is powered on, the BIOS of the electronic device initializes the various components of the electronic device;

[0098] Step S204: The BIOS queries the firmware status of each component;

[0099] Step S206: Each component reports its firmware status information according to the target protocol specified by the BIOS.

[0100] Step S208: The BIOS summarizes the firmware status information of each component and puts it into the TPM's Program Control Register (PCR), so that the system knows whether the BIOS and other components besides the BIOS are safe.

[0101] The BIOS can report specific firmware status information through SMBIOS, ACPI, or Windows Management Instrumentation (WMI) information, at which point the operating system or upper-level application software can obtain the corresponding firmware status information.

[0102] It should be noted that the trust chain in the BIOS can be:

[0103] First, the first few lines of BIOS instructions that the CPU runs when it boots up are hard-coded into the BIOS SPI and cannot be modified.

[0104] Next, all the code that the BIOS is about to run will be checked first to see if the data is intact and if the HASH value is consistent with the pre-stored value. If they are consistent, then it is considered safe and the code can be executed.

[0105] The system bootloader that the BIOS ultimately calls also needs to be verified using the public key stored in the BIOS. If it is signed with the corresponding private key, then it is trustworthy and the system bootloader will be called.

[0106] The trust chain for other components is similar to that of the BIOS.

[0107] like Figure 8 As shown, the components may include an embedded controller 81, a management engine 82, a basic input / output system 84, and other components 83; the trustworthiness of the firmware status information of each component can be verified based on the Root of Trust for Measurement (RTM).

[0108] For example, the reliability of the firmware status information of the embedded controller 81 firmware 801 is verified based on the Trusted Measure Root (RTM); the reliability of the firmware status information of the management engine 82 firmware 802 is verified based on the RTM; the reliability of the firmware status information of other components 83 firmware 803 is verified based on the RTM; the reliability of the firmware status information of the basic input / output system 84 firmware is verified based on the RTM; the basic input / output system 84 can collect the firmware status information of each component firmware (firmware 801, firmware 802, firmware 803 and BIOS firmware) through the Reporting Proxy in BIOS 85 within the basic input / output system 84 and put it into the program control register 86 (PCR) of the Trusted Platform Module (TPM).

[0109] It should be noted that the credibility of the system bootloader 87 can also be verified based on the firmware verification mechanism.

[0110] In related technologies, once a portable hard drive (also known as a disk) is removed, it can be installed on other machines (electronic devices) and start normally, which poses a risk of data leakage.

[0111] The related technologies employ transparent encryption and decryption, with the keys typically stored on the network or locally. This means that even after the external hard drive is removed and installed on another machine, it can still boot normally, and the user can view the encrypted file content. However, this poses a risk of data leakage should the encryption be compromised.

[0112] Figure 9 This is a flowchart illustrating a method for mutual verification between BIOS and driver according to an embodiment of this application. Figure 9 As shown, the method includes the following steps:

[0113] Step 901: Update BIOS;

[0114] Step 902: Determine if the BIOS verification function is enabled;

[0115] If yes, proceed to step 903; if no, proceed to step 907.

[0116] Step 903: Install the function module in the BIOS;

[0117] The aforementioned functional module, also known as the verification module, is used to perform mutual verification between the BIOS and the driver.

[0118] Step 904: Power on and start the electronic device;

[0119] Among them, the portable hard drive can be installed on an electronic device, and when the electronic device is turned on and starts up, the portable hard drive also starts up.

[0120] Step 905: Determine whether the mutual verification between the BIOS and the external hard drive driver is successful; if the verification is successful, proceed to step 907; if the verification fails, proceed to step 906.

[0121] The BIOS and external hard drive drivers can verify each other using their unique identifiers.

[0122] Step 906: Intercept the boot process of the external hard drive;

[0123] Step 907: Start the external hard drive normally.

[0124] In this embodiment, the BIOS and the external hard drive driver can be combined. Each time the system boots, the driver and BIOS verify each other using their unique identifiers. If verification fails, the normal boot process of the external hard drive is blocked; if verification succeeds, the external hard drive runs normally.

[0125] In this embodiment, the risk of data leakage from obsolete disks can be reduced, and it is a pure software solution that does not require additional hardware costs and has low modification costs.

[0126] It should be noted that, in the embodiments of this application, if the above-described processing method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause the washing equipment to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0127] Based on the foregoing embodiments, this application provides a processing device, which includes the modules included, and can be implemented by a processor in the device; of course, it can also be implemented by specific logic circuits; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor unit (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0128] Figure 10 This is a schematic diagram of the composition structure of a processing device according to an embodiment of this application, as shown below. Figure 10 As shown, the device 1000 includes an acquisition module 1001 and a processing module 1002, wherein:

[0129] The acquisition module 1001 is used to obtain the firmware status information of a first component of the electronic device after the boot system firmware verification is completed in the boot system of the electronic device. The first component includes at least one component that is different from the boot system.

[0130] The processing module 1002 is used to manage and process the firmware status information and make the electronic device respond with the corresponding management and processing result.

[0131] In some embodiments, the processing module 1002 includes: a first processing submodule, configured to store the firmware status information to the Trusted Platform Module (TPM) chip of the electronic device if the firmware status information indicates that the firmware of the first component is in a secure state; and a second processing submodule, configured to restore or upgrade the firmware of the first component if the firmware status information indicates that the firmware of the first component is in a risky state.

[0132] In some embodiments, the first processing submodule includes: a first processing unit, configured to directly map the firmware status information to a target storage bit in the Trusted Platform Module (TPM) chip of the electronic device if the firmware status information indicates that the firmware of the first component is in a secure state and the firmware status information indicates that the firmware of the first component has not been modified; and a second processing unit, configured to update the mapping relationship between the firmware status information and the target storage bit in the TPM chip of the electronic device based on update information if the firmware status information indicates that the firmware of the first component is in a secure state and the firmware status information indicates that the firmware of the first component has been modified.

[0133] In some embodiments, the processing module 1002 includes: a third processing module, configured to enter the operating system or target application running state in response to the boot system completing the legality verification of the system boot program; a fourth processing module, configured to output the management processing result of the firmware status information; and a fifth processing module, configured to read the firmware status information of the target component from the TPM chip of the electronic device, so as to execute the function carried by the target component after the verification is passed.

[0134] In some embodiments, the apparatus further includes: a determination module, configured to use the configuration register of the TPM as a trust metric root, the configuration register storing firmware status information of the first component obtained by the boot system; and a first verification module, configured to perform a trust metric on the system bootloader, operating system, or target application based on the trust metric root, so as to grant access permissions to the system bootloader, operating system, or target application or output warning information based on the metric result.

[0135] In some embodiments, the apparatus further includes: a second verification module, configured to perform a trust measurement on the system bootloader based on the trust measurement root; a third verification module, configured to perform a trust measurement on the operating system based on the verification mechanism of the system bootloader if the measurement result of the system bootloader indicates that the system bootloader is trustworthy; a fourth verification module, configured to perform a trust measurement on the target application based on the verification mechanism of the operating system if the measurement result of the operating system indicates that the operating system is trustworthy; and a startup module, configured to start the target application or invoke target components required by the target application if the measurement result of the target application indicates that the target application is trustworthy.

[0136] In some embodiments, the acquisition module includes: a first acquisition submodule, configured to read firmware status information of each of the first components through a target protocol during the process of initializing the first components in the boot system; and a second acquisition submodule, configured to receive firmware status information of each of the first components reported by their respective firmware in accordance with the target protocol.

[0137] In some embodiments, the acquisition module further includes: a third acquisition submodule, configured to perform legality verification on the boot system firmware using a preset algorithm and a preset public key after the second component of the electronic device has completed its own legality verification, so as to complete the verification of the boot system firmware, wherein the second component is a driver different from the first component, and the first component includes at least one component different from the boot system or the second component.

[0138] In some embodiments, the acquisition module includes: a fourth acquisition submodule, configured to obtain first identification information of the first component obtained by the driver corresponding to the first component, and if the first identification information matches the second identification information stored in the boot system, obtain firmware status information of the first component of the electronic device.

[0139] In some embodiments, the apparatus includes a matching module, configured to, after receiving an instruction to run a first component of the electronic device, match the identification information of the first component obtained by the driver corresponding to the first component, so as to intercept the instruction or cause the electronic device to respond to the instruction based on the matching result.

[0140] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0141] Correspondingly, embodiments of this application provide an electronic device, Figure 11 This is a schematic diagram of a hardware entity of an electronic device according to an embodiment of this application, such as... Figure 11 As shown, the hardware entity of the electronic device 1100 includes a memory 1101 and a processor 1102. The memory 1101 stores a computer program that can run on the processor 1102. When the processor 1102 executes the program, it implements the steps in the processing method in the above embodiments.

[0142] The memory 1101 is configured to store instructions and applications executable by the processor 1102, and can also cache data to be processed or already processed (e.g., image data, audio data, voice communication data and video communication data) in the processor 1102 and various modules in the electronic device 1100. It can be implemented by flash memory or random access memory (RAM).

[0143] Correspondingly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in the processing method provided in the above embodiments.

[0144] It should be noted that the descriptions of the storage medium and device embodiments above are similar to those of the method embodiments above, and have similar beneficial effects as the device embodiments. For technical details not disclosed in the storage medium and method embodiments of this application, please refer to the descriptions of the device embodiments of this application for understanding.

[0145] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0146] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0147] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0148] The units described above as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units; some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the embodiments of this application may all be integrated into one processing unit, or each unit may be a separate unit, or two or more units may be integrated into one unit; the integrated unit may be implemented in hardware or in a combination of hardware and software functional units.

[0149] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks. Alternatively, if the integrated units of this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause the washing equipment to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0150] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict. The features disclosed in the several product embodiments provided in this application can be arbitrarily combined to obtain new product embodiments without conflict. The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined to obtain new method embodiments or device embodiments without conflict.

[0151] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A processing method, comprising: After the boot system of the electronic device completes the boot system firmware verification, it obtains the firmware status information of the first component of the electronic device, wherein the first component includes at least one component that is different from the boot system. The firmware status information is managed and processed, and the electronic device responds with the corresponding management and processing results; The management and processing of the firmware status information includes at least one of the following: If the firmware status information indicates that the firmware of the first component is in a secure state and has not been modified, the firmware status information is directly mapped to the target storage bit in the Trusted Platform Module (TPM) chip of the electronic device; or, If the firmware status information indicates that the firmware of the first component is in a secure state and has been modified, the mapping relationship between the firmware status information and the target storage bit in the TPM chip of the electronic device is updated based on the update information; the mapping relationship indicates the conversion between the virtual address space and the physical address of the firmware status information.

2. The method according to claim 1, wherein the step of managing the firmware status information and causing the electronic device to respond with the corresponding management processing result further includes: If the firmware status information indicates that the firmware of the first component is in a risky state, the firmware of the first component shall be restored or upgraded.

3. The method according to claim 1 or 2, wherein, The corresponding management processing results include: In response to the boot system completing the legality verification of the system boot program, the system enters the operating system or target application running state; or, Output the management processing result of the firmware status information; or, The firmware status information of the target component is read from the TPM chip of the electronic device to execute the function carried by the target component after verification.

4. The method according to claim 3, further comprising: The configuration register of the TPM is used as the root of trust, and the configuration register stores the firmware status information of the first component obtained by the boot system; Based on the trusted measurement root, a trusted measurement is performed on the system bootloader, operating system, or target application, so as to grant access permissions or output warning information to the system bootloader, operating system, or target application based on the measurement result; or, Based on the aforementioned trust metric root, the trust metric of the system bootloader is performed. If the measurement results of the system bootloader indicate that the system bootloader is trustworthy, the operating system is subjected to a trustworthiness measurement based on the verification mechanism of the system bootloader. If the measurement results of the operating system indicate that the operating system is trustworthy, the target application is subjected to a trustworthiness measurement based on the verification mechanism of the operating system. If the measurement results of the target application indicate that the target application is trustworthy, then the target application is launched or the target components required by the target application are invoked.

5. The method according to claim 1, wherein, Obtaining firmware status information of the first component of the electronic device includes: During the initialization of the first component in the boot system, the firmware status information of each of the first components is read through the target protocol, or the firmware status information of each of the first components reported by their respective firmware in accordance with the target protocol is received.

6. The method according to claim 1, wherein, The boot system of an electronic device completes boot system firmware verification, including: After the second component of the electronic device completes its own legitimacy verification, it uses a preset algorithm and a preset public key to verify the legitimacy of the boot system firmware in order to complete the verification of the boot system firmware. The second component is a driver program different from the first component, and the first component includes at least one component different from the boot system or the second component.

7. The method according to claim 1, further comprising: Obtain the first identification information of the first component obtained by the driver corresponding to the first component. If the first identification information matches the second identification information stored in the boot system, obtain the firmware status information of the first component of the electronic device.

8. The method according to claim 1 or 7, further comprising: After receiving an instruction to run the first component of the electronic device, the first identification information of the first component obtained by the driver corresponding to the first component is matched, so as to intercept the instruction or make the electronic device respond to the instruction based on the matching result.

9. A processing apparatus, comprising: The acquisition module is used to obtain firmware status information of a first component of the electronic device after the boot system firmware verification is completed. The first component includes at least one component that is different from the boot system. The first processing submodule is used to directly map the firmware status information to a target storage bit in the Trusted Platform Module (TPM) chip of the electronic device if the firmware status information indicates that the firmware of the first component is in a secure state and has not been modified. or, If the firmware status information indicates that the firmware of the first component is in a secure state and has been modified, the mapping relationship between the firmware status information and the target memory bit in the TPM chip of the electronic device is updated based on the update information. The mapping relationship represents the conversion between the virtual address space and the physical address of the firmware state information.

Images