Baseboard management controller, electronic device, and start-up method

Abstract

The application discloses a substrate management controller, an electronic device and a starting method, relates to the technical field of server firmware, and comprises a security hardware module embedded in the substrate management controller. The security hardware module is used to realize the security verification function of a security chip. The security hardware module is used as a trust anchor, and the firmware is sequentially subjected to security verification. The device firmware that passes the current verification is regarded as trusted firmware. The trusted firmware is used to perform security verification on the next device firmware. The firmware starting is realized through chain security verification. Therefore, the firmware security verification is realized through the security hardware module embedded in the substrate management controller. The substrate management controller provides a unified security interface, can effectively adapt to different firmware security verification requirements, does not increase additional hardware for the device, can realize full use of device resources, avoids idle resources, and solves the problems of additional security chips required for firmware security protection in the related art, increased hardware cost and design complexity and the like.

Description

Technical Field

[0001] This application relates to the field of server firmware technology, and in particular to baseboard management controllers, electronic devices, and boot methods. Background Technology

[0002] Firmware is the fundamental software of a hardware system, responsible for critical tasks such as initializing hardware devices and booting the operating system. With the rapid increase in the number of electronic devices and the changes in deployment methods, firmware security issues for electronic devices such as servers are becoming increasingly prominent. However, related technologies typically require the addition of an extra security chip for firmware security protection, increasing hardware costs and design complexity. Summary of the Invention

[0003] This application provides a baseboard management controller, electronic device, and boot method to at least solve the problems in related technologies that usually require additional security chips for firmware security protection, which increases hardware costs and design complexity.

[0004] This application provides a baseboard management controller connected to a first storage module. The first storage module stores a first image of the baseboard management controller. The baseboard management controller includes a second storage module, a security hardware module, a kernel module, a first control module, a second control module, and a third control module. After firmware security verification is passed, the security hardware module initiates firmware security verification for the third control module. After firmware security verification is passed, the third control module initiates firmware security verification for the kernel module. During the security verification process, the firmware communicates with at least one of the first and second control modules, sending at least one first load instruction and one second load instruction. The first control module responds to the first load instruction and loads first data into the first image. The second control module responds to the second load instruction and controls the second storage module to load second data. At least one of the first and second data is used for firmware security verification. After successful security verification, the firmware is loaded from the first image.

[0005] This application also provides an electronic device, including the aforementioned baseboard management controller.

[0006] This application also provides a boot method for an electronic device, applied to the aforementioned baseboard management controller. The method includes: after the baseboard management controller is powered on, performing firmware security verification on a security hardware module; after the security hardware module passes the firmware security verification, initiating firmware security verification on a third control module using the security hardware module; after the third control module passes the firmware security verification, initiating firmware security verification on a kernel module using the third control module; and completing the boot of the baseboard management controller after the firmware security verification of the kernel module; and using the baseboard management controller to perform firmware security verification on at least one of the boot system and other components of the electronic device, so as to complete the boot of the electronic device after firmware security verification, wherein the other components are components other than the baseboard management controller and the boot system.

[0007] This application embeds a security hardware module within the baseboard management controller. This module enables the security verification function of the security chip, serving as a trust anchor point to sequentially verify firmware. The currently verified firmware becomes the trusted firmware, which is then used to verify the next firmware, achieving chain-like security verification for firmware boot. This firmware security verification achieved through the embedded security hardware module in the base management controller effectively reduces hardware costs and design complexity. Furthermore, the baseboard management controller itself provides a unified security interface, effectively adapting to different firmware security verification requirements without adding extra hardware to the device, thus maximizing device resource utilization and avoiding idle resources. The multi-level trust chain construction for secure device boot significantly enhances boot security and reduces the risk of device attacks. Therefore, this application solves problems such as high firmware security verification adaptation requirements, high device hardware design complexity, and high hardware resource costs. Attached Figure Description

[0008] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a schematic diagram of a baseboard management controller structure provided in an embodiment of this application;

[0010] Figure 2 A schematic diagram of a server firmware security architecture provided in this application embodiment;

[0011] Figure 3 A schematic diagram of a first mirrored storage layout provided in an embodiment of this application;

[0012] Figure 4 A schematic diagram of a second mirrored storage layout provided in an embodiment of this application;

[0013] Figure 5 A schematic diagram of a third mirror storage layout provided in an embodiment of this application;

[0014] Figure 6 A flowchart illustrating a startup method for an electronic device provided in an embodiment of this application;

[0015] Figure 7 This is a flowchart illustrating a startup method for an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0017] It should be noted that, in the description of this application, 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. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0018] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] The specific application environment architecture or specific hardware architecture on which the baseboard management controller depends is described here.

[0020] Embodiments of this application provide a baseboard management controller, specifically, as follows: Figure 1 As shown, the baseboard management controller includes: a first read-only module 101, a second read-only module 102, a security hardware module 103, a kernel module 104, a second storage module 105, a first control module 106, a second control module 107, and a third control module 108.

[0021] like Figure 2As shown, the baseboard management controller is connected to the first storage module, which stores a first image of the baseboard management controller. After firmware security verification is passed, the security hardware module 103 initiates firmware security verification for the third control module 108. After firmware security verification is passed, the third control module 108 initiates firmware security verification for the kernel module 104. During the security verification process, the firmware communicates with at least one of the first control module 106 and the second control module 107, sending at least one of a first load instruction and a second load instruction. The first control module 106 responds to the first load instruction and loads first data into the first image. The second control module 107 responds to the second load instruction and controls the second storage module 105 to load second data. At least one of the first and second data is used for firmware security verification. After successful security verification, the firmware is loaded from the first image.

[0022] Among them, the baseboard management controller is a dedicated management chip that is independent of the main CPU (Central Processing Unit) and is responsible for out-of-band management of the server and supports the IPMI (Intelligent Platform Management Interface) protocol.

[0023] The first storage module stores the BMC (Baseboard Management Controller) firmware, sensor data, and FRU (Field Replaceable Unit) information, including the main image and backup image; the first image is the complete firmware program code and data set of the core functions of BMC startup, management, and monitoring included in the operation of the Baseboard Management Controller.

[0024] The second storage module 105 is a hardware that can only be written to once. This area stores the public key of the ROM (Read-Only Memory) of the hardware security module, the public key of the application of the hardware security module, the public key of the application of the third control module, and the public key of the U-Boot (Universal Boot Loader) of the BMC, which respectively verify the signature validity of the corresponding ROM or program.

[0025] Security hardware module 103 is an independent hardware root of trust module in the BMC chip. As a trust anchor point, it works with OTP (One-Time Programmable) to implement core functions such as firmware integrity verification, key storage, and identity authentication.

[0026] The first control module 106 supports full-duplex high-speed data transmission and enables SPI (Serial Peripheral Interface) protocol communication between the BMC and external storage devices; the second control module 107 manages write permissions for OTP memory, ensuring that data is programmed once and cannot be tampered with, and supports partition isolation and integrity verification modules; the third control module 108 is the core module responsible for selecting the boot path, triggering loading instructions, and managing error handling during the boot process to coordinate the BMC boot process; firmware security verification is a mechanism for verifying the integrity and legality of the firmware;

[0027] The first loading instruction is a loading instruction that the firmware communicates with the first control module 106 during the security verification process; the second loading instruction is a loading instruction that the firmware communicates with the second control module 107 during the security verification process.

[0028] The first data is the data loaded by the first control module 106 in response to the first loading command; the second data is the data loaded by the second control module 107 in response to the second loading command.

[0029] Understandably, this application embeds a security hardware module 103 within the baseboard management controller. The security hardware module 103 is used to implement the security verification function of the security chip. Using the security hardware module 103 as a trust anchor, the firmware is sequentially verified for security. The currently verified device firmware is designated as trusted firmware, and the trusted firmware is used to perform security verification on the next device firmware. This enables chain-like security verification for firmware booting. Therefore, by embedding the security hardware module 103 within the base management controller to achieve firmware security verification, hardware costs and design complexity can be effectively reduced. Furthermore, the baseboard management controller itself provides a unified security interface, effectively adapting to different firmware security verification requirements without adding extra hardware to the device. This allows for full utilization of device resources, avoiding resource idleness. Moreover, by constructing a multi-level trust chain to achieve secure device booting, boot security can be effectively improved, reducing the risk of device attacks.

[0030] Specifically, in the baseboard management controller, the first storage module is BMC Flash (Baseboard Management Controller Flash), the second storage module 105 is the OTP public key area, the third storage module is BIOS (Basic Input / Output System) Flash (BIOS refers to the boot system in this embodiment), the fourth storage module is other Flash, the first image uses the BMC image, the second image is the BIOS image, the security hardware module 103 replaces the function of the security chip and is used to implement functions such as integrity verification, key storage, and identity authentication, the kernel module 104 uses the BMC main core, the first control module 106 uses the SPI controller, the second control module 107 uses the OTP controller, the third control module 108 uses the third control module, the first read-only module 101 is the third control module ROM, and the second read-only module 102 is the hardware security module ROM.

[0031] like Figure 1 As shown, the baseboard management controller includes a security hardware module 103, a second read-only module 102, a third control module 108, a first read-only module 101, a kernel module 104, a second control module 107, a second storage module 105, an SPI controller, and an I2C (Inter-Integrated Circuit, I²C bus) / I3C (Improved Inter-Integrated Circuit Bus) controller. In the baseboard management controller, the baseboard management controller is connected to the first storage module and the fourth storage module via the SPI bus. The baseboard management controller is connected to the third storage module via a multiplexer. The central processing unit is connected to the third storage module via the SPI bus via a multiplexer. Other components are connected to the third storage module via the SPI bus via a multiplexer. The complex programmable logic device controls two multiplexers via the Mux sel (Multiplexer Select) signal. The central processing unit, the complex programmable logic device, and other components are connected to the baseboard management controller via I2C or I3C.

[0032] Furthermore, in the embodiments of this application, the first data includes at least one of a first public key data, a first image data, and a first signature data. The first public key data is used for verifying the signature of the first signature data, and the image data is used for loading the firmware after the signature of the first signature data has been verified. The second data includes a second public key data, which is used for verifying the signature of the first signature data.

[0033] The first public key data is stored at the SPI interface connection and is paired with the private key of the first signature data; the first image data is the complete code and data set of the BMC's operating system, management program, drivers, etc. required for BMC operation; the first signature data is the digital signature of the first image data, which is generated by the firmware publisher using the private key to encrypt the first image data, and is usually stored in the BMC Flash along with the first image data; the second public key data is stored in the OTP and is used to verify the legitimacy of the first public key data.

[0034] It is understood that the first data includes at least one of the first public key data, the first image data, and the first signature data, and the second data includes the second public key data. The signature data is verified by the public key data. After the verification is successful, the image data is used for loading the firmware after the verification of the first signature data is successful. The signature data is verified by the public key data to confirm the legitimacy of the firmware source. The strong binding between the signature data and the image data ensures that the firmware has not been tampered with and guarantees the security and trustworthiness of the firmware loading process.

[0035] Specifically, the first image is a BMC image, such as... Figure 3 As shown, the distribution of the first mirror storage layout presents a hierarchical storage and functional clustering logic. Its bottom layer is based on hardware security root of trust content, forming the security foundation of the storage layout. U-Boot related storage units are distributed in parallel on top, forming independent boot program storage blocks. The core area is the storage cluster of the BMC kernel and applications, which is the main part of the mirror storage. The periphery is extended by supplementary public key storage units such as other components and BIOS-related components, forming a connection with the core area. Within each block, the program image, signature, and public key verification chain are stored in an orderly manner, and the blocks form a progressive or complementary storage architecture through functional dependencies.

[0036] Furthermore, in the embodiments of this application, the baseboard management controller further includes: a first read-only module 101 and a second read-only module 102, the first read-only module 101 stores a first boot program, the second read-only module 102 stores a second boot program, the first boot program is used to start the second read-only module 102, and the second boot program is used to load the firmware of the security hardware module 103.

[0037] The first read-only module 101 is a read-only memory built into the third control module responsible for coordinating the system startup process; the second read-only module 102 is a read-only memory built into the security hardware module 103; the first boot program is a security program embedded in the first read-only module 101 used to start the second read-only module 102; the second boot program is a firmware program embedded in the second read-only module 102 used to load the security hardware module 103.

[0038] Understandably, before loading the security hardware module 103, a root trust anchor and a trusted execution chain are constructed based on the first read-only module 101 and the second read-only module 102 due to their physical immutability. The first read-only module 101 provides an immutable root verification benchmark, and the second read-only module 102 becomes a trusted executor after being verified by the first read-only module 101. The two work together to verify the executor and then verify the firmware, anchoring the root trust layer by layer, thereby realizing the secure authentication loading of the security hardware module 103.

[0039] Specifically, the first read-only module 101 is the ROM of the third control module, and the second read-only module 102 is the ROM of the security hardware module 103. The first read-only module 101 and the second read-only module 102 are two independent hardware storage units, which are physically connected to the BMC main control chip through a dedicated bus, and both have hardware-level locked write functions.

[0040] The first boot program is a boot program stored in the ROM of the security hardware module, and the second boot program is a boot program stored in the ROM of the third control module. The first boot program contains jump and verification logic. First, it performs a hardware-level self-test, and then verifies its legality through hardware signature verification. After the verification is passed, it triggers the startup logic of the second read-only module 102 through bus instructions and transfers the execution right to the second read-only module 102. The second boot program is used for loading the security hardware firmware. After receiving the startup signal from the first boot program, it initializes the hardware interfaces of the security hardware module 103, such as the encryption chip and TPM (Trusted Platform Module), reads the firmware image of the security hardware module 103, verifies the firmware signature to confirm that the firmware has not been tampered with, and after the verification is passed, loads the firmware into the running memory of the security hardware module 103 to complete its initialization.

[0041] Furthermore, in the embodiments of this application, the first read-only module 101 starts the first boot program after the baseboard management controller is powered on. The first boot program communicates with the second control module 107, loads the public key of the second read-only module 102 in the second storage module 105, verifies the signature of the second read-only module 102 using the public key of the second read-only module 102, and loads the second read-only module 102 after the signature verification is successful.

[0042] Among them, power-on refers to the operation of turning on the power supply of the baseboard management controller, triggering the hardware circuit to start, and enabling the first read-only module 101 to enter the working state from the power-off sleep state; signature verification is the process of verifying the legitimacy of the second read-only module 102 through cryptographic means.

[0043] Understandably, after the baseboard management controller is powered on, the first read-only module 101 starts the first boot program to start the second read-only module 102. The first boot program is a pure hardware implementation that cannot be tampered with. The security hardware module 103 needs to be verified by the ROM public key before it can run. After power-on, the verification of the second read-only module 102 is achieved through the first boot program, thereby improving the security of the startup of the security hardware module 103.

[0044] Specifically, after the BMC is powered on, it loads the first read-only module 101 to boot, and loads the public key and encryption algorithm of the second read-only module 102 of the security hardware module 103 in the second control module 107. It then verifies the second read-only module 102 using the specified encryption algorithm. If the verification is successful, the second read-only module 102 of the hardware security module is loaded; otherwise, it fails to start.

[0045] After the BMC is powered on, the hardware circuit defaults to using the first read-only module 101 as the initial execution unit, automatically loading and running its internal first boot program. At this time, the system is in the lowest level startup stage, executing only the core logic related to hardware security verification.

[0046] After the first bootloader starts, it first accesses the second control module 107 to load two key resources: the public key of the second read-only module 102 and the specified encryption algorithm. The first bootloader uses these two key resources to perform a legality check on the second read-only module 102. If the check matches, it means that the second read-only module 102 has not been replaced or tampered with, and the verification is successful. The first bootloader sends a start signal to the second read-only module 102 to load the internal second bootloader, and then initializes the security hardware module 103 to complete the next step of building the trusted chain. If the check does not match, it is determined to be abnormal. The BMC immediately triggers abnormal handling mechanisms such as terminating the boot process, lighting up the hardware fault light, and sending an error log through the internal bus, refusing to start subsequent components and blocking untrusted hardware from accessing the system at the source.

[0047] The private and public key types, functions, and storage locations in the key pair of the second read-only module 102 are shown in Table 1.

[0048] Table 1

[0049]

[0050] Furthermore, in the embodiments of this application, the firmware of the security hardware module 103 includes a first application, and the second read-only module 102 starts a second boot program after loading. The second boot program communicates with the first control module 106 and the second control module 107, loads the public key of the first application in the second storage module 105, loads the image and signature of the first application in the first image, verifies the signature of the first application using the public key of the first application, and loads the first application according to the image of the first application after the signature verification is successful.

[0051] The first application is an application in the firmware of the security hardware module 103 that needs to be signed and verified using its own public key before it can be loaded and run.

[0052] Understandably, after being loaded, the second read-only module 102 starts the second boot program. The second boot program communicates with the first control module 106 and the second control module 107, loads the public key of the first application in the second storage module 105, and loads the first application in the security hardware module 103 after successful verification. Thus, the security hardware module 103 is verified during the startup process of the first boot program, thereby improving the security of the startup of the security hardware module 103.

[0053] Specifically, the security hardware module 103 loads two core data types from the second storage module 105: the first application public key and the first image of the security hardware module 103. It then verifies that the first read-only module 101 uses a specified encryption algorithm, combined with the loaded first application public key and the first image, to verify that the first read-only module 101 has not been tampered with and has a legitimate source. If the verification passes, it indicates that the first read-only module 101 is secure and reliable, and then the second read-only module 102 is loaded. If the verification fails, it is determined that there is a security risk in the basic environment, triggering an abnormal termination mechanism, and the security hardware module 103 stops starting.

[0054] After the second read-only module 102 boots up, it first loads the image and signature of the first application from the security hardware module 103. The second read-only module 102 verifies the signature of the first application using the public key of the second read-only module 102 according to the specified encryption algorithm. It verifies whether the signature is generated by the private key paired with the public key to confirm that the application comes from the authorized party and to exclude forgery. It also verifies whether the signature matches the image of the first application to confirm that the image has not been tampered with and to ensure integrity. If the signature verification is successful, the first application is determined to be legitimate and complete, and the image is loaded.

[0055] If the signature verification fails, the core application is deemed to have a risk, triggering the abnormal termination mechanism and stopping the startup process.

[0056] The private and public key types, functions, and storage locations in the key pair of the first application are shown in Table 2.

[0057] Table 2

[0058]

[0059] Furthermore, in the embodiments of this application, the firmware of the third control module 108 includes a second application. After the first application of the security hardware module 103 is loaded, it communicates with the first control module 106 and the second control module 107. The public key of the second application is loaded in the second storage module 105. The image and signature of the second application are loaded in the first image. The signature of the second application is verified using the public key of the second application. After the signature is verified, the second application is loaded according to the image of the second application.

[0060] The second application is an application that needs to be loaded and run in the firmware of the third control module 108 after the signature is verified using its own public key.

[0061] Understandably, after the first application of the security hardware module 103 is loaded, it communicates with the first control module 106 and the second control module 107, loads the public key of the second application in the second storage module 105, loads the image and signature of the second application in the first image, and verifies the second application through the public key and signature. Since the public key, signature and image can only be loaded after the security verification of the previous firmware has passed, the security of loading the second application can be improved.

[0062] Specifically, after the first application starts, it first loads two key data components from the third control module 108: the image of the second application and the signature of the second application. The first application verifies the signature of the second application using the public key of the second application according to a preset encryption algorithm. This verifies whether the signature was generated by the private key paired with the public key, confirming that the source of the second application is official or authorized, and excluding counterfeit illegal programs. It also verifies whether the signature matches the image of the second application, confirming that the image has not been maliciously tampered with during storage and transmission, and ensuring the integrity of the program logic. If the signature verification passes, the system determines that the image of the second application is legitimate and complete, and therefore loads the image. If the signature verification fails, the system determines that the core application of the third control module has a security risk and will immediately trigger an abnormal termination mechanism to stop the entire startup process.

[0063] Furthermore, in embodiments of this application, kernel module 104 includes at least one of a third bootloader, a fourth application, a kernel component, and a fifth application, wherein the third bootloader is used to load the fourth application.

[0064] Among them, the third bootloader is a bootloader in kernel module 104 that needs to verify the signature using its own public key, and the verification process is coordinated by the second application in the third control module 108; the fourth application is a functional component in kernel module 104 that needs to be loaded and run after the second application loads its public key and the third bootloader participates in the signature verification for multi-layer security verification; the kernel component is a component in kernel module 104 that undertakes supporting functions, providing the underlying operating environment and capability support for the bootloader, application, etc. in kernel module 104; the fifth application is a functional component in kernel module 104 that needs to be loaded and run after the fourth application loads its public key and the kernel component participates in the signature verification for multi-layer security verification.

[0065] It is understandable that kernel module 104 includes a third bootloader, a fourth application, a kernel component, and a fifth application. The third bootloader ensures the orderly startup process, the kernel component provides underlying support capabilities, and the fourth and fifth applications implement specific functions. This enables kernel module 104 to reliably execute specific business logic when managing resources and coordinating interactions between upper and lower layers, ultimately supporting the stable operation of the entire system.

[0066] Furthermore, in the embodiments of this application, after the second application of the third control module 108 is loaded, it communicates with the first control module 106 and the second control module 107, loads the public key of the third boot program in the second storage module 105, loads the image and signature of the third boot program in the first image, verifies the signature of the third boot program using the public key of the third boot program, and loads the third boot program according to the image of the third boot program after the verification is successful.

[0067] Understandably, once the security verification of the second application in the third control module 108 is passed, it is already in a trusted state and can communicate with the first control module 106 and the second control module 107 to build a trusted interactive environment. It loads the public key of the third bootloader from the second storage module 105, loads the image and signature of the third bootloader from the first image, and verifies the signature using the public key of the third bootloader. After the signature verification is successful, the loading is completed based on the image of the third bootloader. This ensures that the public key, image, and signature used to verify the third bootloader are legitimate, greatly reducing the risk of the third bootloader being illegally loaded and improving the security of loading the third bootloader.

[0068] Specifically, after the second application starts, it first loads two key pieces of data: the image of the third bootloader and the signature of the third bootloader. The second application uses the public key of the third bootloader image to verify the signature of the third bootloader according to a preset encryption algorithm. It verifies whether the signature is generated by the private key paired with the public key, confirms that the source of the third bootloader image is official or authorized, and excludes counterfeit and illegal bootloaders. It also verifies whether the signature matches the image of the third bootloader, confirming that the image has not been maliciously tampered with during storage and transmission, and ensuring the integrity of the program logic. If the signature verification passes, the system determines that the image of the third bootloader is legitimate and complete, and therefore loads the image. If the signature verification fails, the system determines that the third bootloader has a security risk, immediately triggers the abnormal termination mechanism, stops the entire startup process, and prevents illegal bootloaders from causing system startup failure or security vulnerabilities.

[0069] The private and public key types, functions, and storage locations in the third bootstrap key pair are shown in Table 3.

[0070] Table 3

[0071]

[0072] Furthermore, in the embodiments of this application, the second application is also used to load the public key of the fourth application in the first image. After loading, the third bootstrap communicates with the first control module 106, loads the image and signature of the fourth application in the first image, verifies the signature of the fourth application using the public key of the fourth application, and loads the fourth application according to the image of the fourth application after the verification is successful.

[0073] Understandably, the second application, having passed security verification, is in a trusted state. It loads the public key of the fourth application from the first image. After the third bootstrap completes the loading and passes security verification, it communicates with the first control module 106 to load the image and signature of the fourth application from the first image. Using the loaded public key of the fourth application, it verifies the signature. After successful verification, it completes the loading based on the image of the fourth application. Both the second application and the third bootstrap are trusted entities that have undergone prior security verification, ensuring that the source of the loaded public key, image, and signature is traceable and legitimate. By verifying the signature with a legitimate public key, it ensures that the fourth application has not been tampered with and that its source is compliant, guaranteeing that the fourth application runs in a trusted environment and improving the security of loading the fourth application.

[0074] Specifically, once the third bootloader is started, it means that it has passed the verification of the third control module and become a trusted subject for the next stage of verification. At this point, it will be responsible for verifying the legitimacy of the fourth application.

[0075] After the third bootloader starts, it first loads two key pieces of data: the image of the fourth application and the signature of the fourth application. Using a preset encryption algorithm, the third bootloader verifies the signature of the fourth application using its public key. It checks whether the signature was generated by the private key paired with the public key, confirming the origin of the fourth application as official or authorized, thus excluding counterfeit or illegal programs. It also verifies whether the signature matches the image of the fourth application, confirming that the image has not been maliciously tampered with during storage and transmission, ensuring the integrity of the program's functionality. If the signature verification passes, the system determines that the image of the fourth application is legitimate and complete, and therefore loads the image, along with the kernel module's 104 public key, ensuring that the security verification during the BMC kernel loading process can proceed normally. If the signature verification fails, the system determines that the fourth application poses a security risk and immediately triggers an abnormal termination mechanism, stopping the entire boot process to prevent illegal programs from causing U-Boot malfunctions or system security vulnerabilities.

[0076] The private and public key types, functions, and storage locations in the key pair of the fourth application are shown in Table 4.

[0077] Table 4

[0078]

[0079] Furthermore, in the embodiments of this application, the third bootstrap program is also used to load the public key of the kernel component in the first image, and the fourth application communicates with the first control module 106 after loading, loads the image and signature of the kernel component in the first image, verifies the signature of the kernel component using the public key of the kernel component, and loads the kernel component according to the image of the kernel component after the verification is successful.

[0080] Understandably, the third bootloader, having passed the prior security verification, is in a trusted state. It loads the public key of the kernel component from the first image. After the fourth application, which has undergone security verification, completes the loading, it communicates with the first control module 106 to load the image and signature of the kernel component from the first image. Using the public key of the loaded kernel component, it verifies the signature. Once the signature verification is successful, the loading of the kernel component is complete. Since both the third bootloader and the fourth application are trusted entities that have undergone prior verification, the source of their loaded public key, image, and signature is traceable and legitimate. This ensures that the core data used to verify the kernel component has not been forged or tampered with. Furthermore, relying on the security foundation of the prior firmware, it ensures that the loading and verification process is within a trusted framework, thereby ensuring the effectiveness of the verification and guaranteeing the stability and security of the kernel module 104.

[0081] Specifically, after the fourth application starts, it first loads two key pieces of data: the image of the first bootloader and the signature of the first bootloader. The kernel module 104 verifies the signature of the first bootloader using the public key of the second application according to a preset encryption algorithm. It verifies whether the signature is generated by the private key paired with the public key, confirming that the source of the first bootloader is official or authorized, and excluding counterfeit illegal programs. It also verifies whether the signature matches the image of the first bootloader, confirming that the image has not been maliciously tampered with during storage and transmission, and ensuring the integrity of the program logic. If the signature verification passes, the system determines that the image of the first bootloader is legal and complete, and therefore loads the image. At the same time, it loads the boot public keys of other components, reserving key verification tools for subsequent verification of the boot bootloaders of other components, ensuring that the security verification of the boot process of other components can be carried out normally. If the signature verification fails, the system determines that the first bootloader has a security risk and immediately triggers the abnormal termination mechanism to stop the boot process of the BMC.

[0082] The types, functions, and storage locations of the private and public keys in the key pairs of the kernel components are shown in Table 5.

[0083] Table 5

[0084]

[0085] Furthermore, in the embodiments of this application, the fourth application is also used to load the public key of the fifth application in the first image. After loading, the kernel component communicates with the first control module 106 to load the image and signature of the fifth application in the first image, verify the signature of the fifth application using the public key of the fifth application, and load the fifth application according to the image of the fifth application after the verification is successful.

[0086] Understandably, the fourth application, which has passed the prior security verification, is in a trusted state. The fourth application loads the public key of the fifth application from the first image. After the kernel component completes the loading through security verification, it communicates with the first control module 106 to load the image and signature of the fifth application from the first image. Using the loaded public key of the fifth application, it verifies the signature. After the signature verification is successful, the loading of the fifth application is completed. Relying on the security foundation of the prior firmware, it can be ensured that the loading and verification process is within a trusted framework. Both the fourth application and the kernel component are trusted entities that have been verified in the prior process. The public key, image, and signature they load are legitimate and traceable, ensuring that the core data used to verify the fifth application has not been forged or tampered with, thus guaranteeing the effectiveness of the signature verification process and improving the security of loading the fifth application.

[0087] Specifically, the fourth application extracts and loads the public key of the fifth application from the first image. After the kernel component completes its own loading, it loads two key pieces of data from the first image: the image of the fifth application and the signature of the fifth application. The signature of the fifth application is verified using the public key of the fifth application. The verification is performed according to a preset encryption algorithm to verify whether the signature is generated by the private key paired with the public key, thus confirming that the source of the fifth application is authorized and eliminating forgery. The signature is also verified to match the image of the fifth application, thus confirming that the image has not been tampered with and ensuring integrity. If the verification passes, the system determines that the fifth application is legitimate and complete, and loads the program into the runtime environment based on its image, enabling it to start and execute preset functions. If the verification fails, the system determines that the program has security risks, terminates the loading process, and prevents unauthorized programs from running.

[0088] Table 6 shows the type, function, and storage location of the private and public keys in the key pair of the fifth application.

[0089] Table 6

[0090]

[0091] Furthermore, in the embodiments of this application, the baseboard management controller is also connected to a third storage module, which is used to store the second image of the boot system. The fourth application is also used to load the public key of the boot system in the first image. The kernel component communicates with the first control module 106 and sends a third loading instruction to the first control module 106. The first control module 106 responds to the third loading instruction and loads third data in the second image. The kernel component uses the public key of the boot system and the third data to verify the firmware of the boot system. After the verification is successful, the firmware of the boot system is loaded.

[0092] The third storage module is a physical storage medium that persistently stores the BIOS code and data, ensuring that the BIOS program is not lost. The boot system is the core program that runs first when a computer or electronic device starts, initializes hardware devices, performs power-on self-test, establishes basic hardware and software interaction interfaces, and guides the operating system to load from the storage device into memory for startup. The second image is a data carrier of the boot system program image file, which is stored in the third storage module and contains the data and code required for BIOS operation. The third load instruction is a control signal sent by the kernel component to the first control module 106 to trigger the first control module 106 to perform operations. The third data is a set of data that supports firmware verification and loading of the boot system.

[0093] Understandably, the fourth application, having passed the prior security verification, is in a trusted state. The fourth application loads the public key of the boot system from the first image. The kernel component communicates with the first control module 106 and sends a third loading command. The first control module 106 responds to the command and controls the second image stored in the third storage module to load the third data. The kernel component uses the loaded boot system public key and the third data to verify the firmware of the boot system. After the verification is successful, the loading of the boot system firmware is completed. The boot system public key and the third data are both loaded based on the previously verified fourth application and kernel component, which can ensure the legitimacy of the core verification data source. Through the verification mechanism of public key and signature, the legitimacy and integrity of the boot system can be ensured, providing security support for the entire boot process and reducing the risk of malicious boot programs being implanted into the device.

[0094] Specifically, the second image refers to the BIOS image, such as... Figure 4 As shown, the second image storage layout is structurally divided from functional and security perspectives. The left-hand module revolves around the boot process of the startup system, including the image of the bootloader, its signature, and the public key used for application verification, responsible for the initialization and security verification of the system startup process. The right-hand module revolves around the application execution process of the startup system, including the image of the application, its signature, and other CPU-related public keys, supporting the operation of the startup system application functions and the secure adaptation to the corresponding hardware environment. The overall distribution reflects that in the functional chain of startup booting and application execution, the startup system uses the structure of image, signature, and public key to achieve integrity and legality verification of each module, ensuring the security and reliability of the startup system and its applications.

[0095] Furthermore, in the embodiments of this application, the third data includes at least one of the third public key data, the second image data, and the second signature data. The public key of the system is used for the verification of the second signature data, the third public key data is used for the verification of the second signature data, and the second image data is used for the loading of the firmware after the verification of the second signature data is successful.

[0096] The third public key data is the public key information used to verify the legitimacy of the second signature data; the second image data is the data contained in the second image stored in the third storage module, including the code, configuration information, etc. required to start the system firmware; the second signature data is a digital signature generated based on the second image data and used to verify the integrity and source legitimacy of the second image data.

[0097] It is understandable that the third data includes at least one of the following: third public key data, second image data, and second signature data. By using the public key and / or third public key data of the boot system to verify the signature of the second signature data, the authenticity and legality of the second signature data can be verified, ensuring the security of the image data and the security of the boot system firmware loading, and improving the credibility of the boot process.

[0098] Specifically, the third data includes a set of verification information for one of the following: third public key data, second image data, and second signature data. The third public key data is used to verify the legitimacy of the second signature data, and the second signature data is used to prove that the second image data has not been tampered with or replaced. Only when the third public key data passes the verification of the second signature data will the system allow the loading of the firmware corresponding to the second image data.

[0099] Furthermore, in the embodiments of this application, the firmware of the boot system includes a fourth boot program. The kernel component communicates with the first control module 106, loads the image and signature of the fourth boot program in the second image, and the kernel component verifies the signature of the fourth boot program using the public key of the boot system. After the signature verification is successful, the fourth boot program is loaded according to the image of the fourth boot program.

[0100] The fourth bootloader is a boot component in the boot system firmware that needs to be signed and verified by the kernel component using the boot system's public key before it can be loaded and run to ensure the security of BIOS boot.

[0101] Understandably, the kernel component, which has passed the pre-security verification, communicates with the first control module 106 to load the image and signature of the fourth boot program from the second image. The kernel component uses the public key of the loaded boot system to verify the signature of the fourth boot program. After the verification is successful, the fourth boot program is loaded based on its image. The loaded fourth boot program image, signature, and verification process are all within a trusted framework, which can ensure that the core data is not forged or tampered with, thus guaranteeing the legitimacy of the boot program and the operational security of the entire boot system.

[0102] Specifically, the fourth bootloader included in the system firmware provides a legitimacy tool for subsequent signature verification of the public key. In the process of obtaining the image and signature of the fourth bootloader, the second image is responsible for loading the image and signature of the fourth bootloader. The signature verification kernel component based on the public key uses the public key that boots the system to verify the signature of the fourth bootloader according to a preset encryption algorithm: verifying whether the signature is generated by the corresponding private key paired with the public key to confirm the legitimacy of the source, verifying whether the signature matches the image of the fourth bootloader to confirm that the image has not been tampered with. After the signature verification is passed, the system actually loads the program according to the image of the fourth bootloader, puts it into running state, and promotes the boot process to continue.

[0103] The private and public key types, functions, and storage locations in the key pair of the fourth bootstrap procedure are shown in Table 7.

[0104] Table 7

[0105]

[0106] Furthermore, in the embodiments of this application, the firmware of the boot system also includes a sixth application, and the kernel component is also used to load the public key of the sixth application in the second image. The fourth boot program communicates with the first control module 106 to load the image and signature of the sixth application in the second image. The fourth boot program uses the public key of the sixth application to verify the signature of the sixth application. After the signature verification is successful, the sixth application is loaded according to the image of the sixth application.

[0107] The sixth application is a functional component that needs to be loaded into the system firmware by the kernel component to load its public key, and then loaded and run by the fourth bootloader after a security verification of its signature using the public key.

[0108] Understandably, the kernel component, which has passed the pre-process security verification, loads the public key of the sixth application from the second image. The fourth bootloader, which has passed the signature verification, is in a trusted state. The fourth bootloader communicates with the first control module 106 to load the image and signature of the sixth application from the second image. The fourth bootloader uses the public key of the loaded sixth application to verify its signature. After the signature verification is successful, the loading of the sixth application is completed based on its image. Both the kernel component and the fourth bootloader are trusted entities that have passed the pre-process verification. The public key, image, and signature they load are legitimate and traceable, which can ensure that the core data used to verify the sixth application has not been forged or tampered with. By verifying the signature with the public key, the source compliance and integrity of the sixth application are directly verified, ensuring that all BIOS functions are executed in a trusted environment, and strengthening the overall security and stability of the boot system.

[0109] Specifically, when the process starts, it first loads two key pieces of information: the image of the fourth bootloader and its signature. The system uses a preset encryption algorithm and the public key of the fourth bootloader to verify the signature. This verifies whether the signature was generated by the private key paired with the public key, confirming its legitimacy and preventing forgery. It also verifies whether the signature matches the image of the fourth bootloader, confirming that the image has not been tampered with and ensuring its integrity. If the signature verification passes, the fourth bootloader is proven to be legitimate and complete. At this point, the motherboard CPLD releases the CPU_RST# signal, the BIOS loads the image of the fourth bootloader and the public key of the sixth application program, ensuring that the next stage of security verification can proceed normally. If the signature verification fails, the system immediately determines that there is a security risk in the boot environment and directly stops the entire boot process to prevent unauthorized programs from entering the system.

[0110] Table 8 shows the type, function, and storage location of the private and public keys in the key pair of the sixth application.

[0111] Table 8

[0112]

[0113] Furthermore, in the embodiments of this application, the baseboard management controller is also connected to a fourth storage module. The fourth storage module is used to store a third image of other components, which are components other than the baseboard management controller and the boot system. The fifth application is also used to load the public keys of other components into the third image. The fifth application communicates with the first control module 106 and sends a fourth loading command to the first control module 106. The first control module 106 responds to the fourth loading command and loads fourth data into the third image. The fifth application uses the public key of the boot system and the fourth data to verify the firmware of other components. After the verification is successful, the firmware of other components is loaded.

[0114] The fourth storage module is a flash memory device connected to the baseboard management controller, specifically for storing the third image of other components. The third image is a firmware image file stored in the fourth storage module, containing the core code, configuration information, and other data required for the operation of the component. The fourth load instruction is a control signal instruction sent by the fifth application to the first control module 106 to trigger the first control module 106 to perform the operation of loading the fourth data on the third image. The fourth data is a core data set that includes public key data, image data, and signature data related to the component, and supports firmware verification and loading of other components.

[0115] Understandably, the fifth application, having passed the pre-security verification, is in a trusted state. The fifth application loads the public keys of other components from the third image. It communicates with the first control module 106, sending a fourth loading command. The first control module 106 responds to the command, loading fourth data from the third image. The fifth application uses the public key of the boot system and the fourth data to verify the firmware of other components. Once the verification is successful, the loading of the firmware for other components is complete. The fifth application is the trusted subject of the pre-security verification, the public key of the boot system is legitimate, and its loaded public key, fourth data, and verification process are all within a trusted framework. This ensures that the core verification data of the firmware for other components has not been forged or tampered with, achieving trust transfer from core components to peripheral components, verifying the source compliance and integrity of the firmware for other components, and improving the overall security and reliability of the system.

[0116] Specifically, the fourth storage module uses a different FLASH, which is a flash memory device directly connected to the baseboard management controller. It is dedicated to storing a third image of other components, and its connection with the BMC ensures the BMC's access to and control over the storage module.

[0117] like Figure 5 As shown, the third image refers to the images of other components, and the firmware image file stored in the fourth storage module contains the core code and core data required for operation.

[0118] Furthermore, in the embodiments of this application, the firmware of other components includes a fifth bootloader, a fifth application communicates with the first control module 106, loads the image and signature of the fifth bootloader in the third image, the fifth application verifies the signature of the fifth bootloader using the public key of the fifth bootloader, and loads the fifth bootloader according to the image of the fifth bootloader after the verification is successful.

[0119] The fifth bootloader is a boot component other than the baseboard management controller and boot system that needs to be loaded and run after the fifth application uses its public key to perform signature security verification.

[0120] Understandably, the fifth application, having passed the pre-security verification, is in a trusted state. The fifth application communicates with the first control module 106, loading the image and signature of the fifth bootloader from the third image. The fifth application uses the public key of the fifth bootloader to verify its signature. After successful verification, it completes the loading of the fifth bootloader image. The fifth application is the trusted subject of the pre-security verification, and its loading image, signature, and verification process all rely on a trusted framework. This ensures that the core verification data of the fifth bootloader has not been forged or tampered with, realizing the trust transfer from other component firmware to its boot component. By verifying the signature with the public key, the source compliance and data integrity of the fifth bootloader are directly verified, improving the overall security loop of the system.

[0121] Specifically, the startup of the BMC first and second applications is the trigger condition for the entire process. These two applications are the core programs in the BMC system responsible for managing the startup logic of other components.

[0122] BMC's first and second applications first load two key pieces of data: the image of the fifth bootloader and the signature of the fifth bootloader.

[0123] The BMC application verifies the signature of the fifth bootstrap program using the loaded fifth bootstrap public key according to a preset encryption algorithm. It checks whether the signature was generated by the private key paired with the public key, confirms the image's origin as official or authorized, excludes forgery, and verifies whether the signature matches the fifth bootstrap image to confirm that the image has not been maliciously tampered with during storage or transmission, ensuring its integrity.

[0124] If the signature verification passes, the system determines that the fifth bootloader image is legitimate and complete, and therefore loads the image, along with the public keys of other component applications, to provide verification tools for subsequent verification of other component applications, ensuring that the next stage of secure loading can proceed normally. If the signature verification fails, the system determines that the fifth bootloader has a security risk and will immediately trigger an abnormal termination mechanism to stop the entire startup process of other components, preventing unauthorized programs from entering the system and affecting security.

[0125] The types, functions, and storage locations of the private and public keys in the fifth bootstrap program's key pair are shown in Table 9.

[0126] Table 9

[0127]

[0128] Furthermore, in the embodiments of this application, the firmware of other components also includes a seventh application. The fifth application is also used to load the public key of the seventh application in the third image. The fifth bootloader communicates with the first control module 106, loads the image and signature of the seventh application in the third image, and uses the public key of the seventh application to verify the signature of the seventh application. After the signature verification is successful, the seventh application is loaded according to the image of the seventh application.

[0129] Among them, the seventh application is a functional component in the firmware of other components that requires the fifth application to load its public key, the fifth bootloader to use the public key to sign and verify it, and then load and run it after security verification.

[0130] Understandably, the fifth application, having passed the prior security verification, is in a trusted state. The fifth application loads the public key of the seventh application from the third image. The fifth bootstrap program, having passed signature verification, communicates with the first control module 106 to load the image and signature of the seventh application from the third image. The fifth bootstrap program uses the loaded public key of the seventh application to verify its signature. After successful verification, it completes the loading of the seventh application based on its image.

[0131] Both the fifth application and the fifth bootloader are trusted entities that have been verified in the previous steps. The public keys, images, and signatures they load are legitimate and traceable, which can ensure that the core data used to verify the seventh application has not been forged or tampered with, thus realizing the transfer of trust from other component firmware to specific functional components.

[0132] Specifically, the fifth bootloader serves as the core for booting other components. After starting, it first loads the image and signature of the seventh application. The fifth bootloader then verifies the signature of the seventh application using a preset encryption algorithm. It checks whether the signature was generated by the private key paired with the public key, confirming that the source of the seventh application is official or authorized, thus excluding counterfeit and illegal programs. It also verifies whether the signature matches the image of the seventh application, confirming that the image has not been maliciously tampered with during storage and transmission, ensuring the integrity of the program. If the signature verification passes, the system determines that the image of the seventh application is legitimate and complete, and therefore loads the image. If the signature verification fails, the system determines that the seventh application poses a security risk and immediately triggers an abnormal termination mechanism, stopping the boot process of all other components to prevent the operation of illegal programs from causing component failures or system security issues.

[0133] Table 10 shows the private and public key types, functions, and storage locations in the key pair of the seventh application.

[0134] Table 10

[0135]

[0136] Furthermore, in the embodiments of this application, a security interface abstraction layer is set in the BMC, and the differences between different trusted root protocols are shielded through the software adaptation layer.

[0137] Among them, the security interface abstraction layer is an intermediate layer designed to shield the implementation differences of the underlying security components in the system; the software adaptation layer is an intermediate layer located between the upper-layer application software and the underlying hardware / operating system, responsible for coordinating the differences between different modules and software and hardware; the root of trust protocol is a specification protocol for the rules of establishing, verifying, using and passing on the trust chain of trust.

[0138] Understandably, by shielding the differences between different root of trust protocols through the software adaptation layer, BMC can avoid custom development for specific protocols, be compatible with multiple root of trust components, and the security interface abstraction layer provides a unified interface, which can reduce code complexity and maintenance costs, ensure the consistency of security functions, and improve the reliability of the overall security mechanism of BMC.

[0139] Specifically, a security interface abstraction layer is deployed in the baseboard management controller. This layer provides a unified security operation interface for upper-layer security function modules such as signature verification, key management, and trust chain verification. Below the security interface abstraction layer, a software adaptation layer is deployed. This layer is responsible for interfacing with different trusted root protocols to handle differences in rules such as authentication, key derivation, and trust transfer. When an upper-layer module needs to call a trusted root-related security function, it initiates a request through the unified interface of the security interface abstraction layer. After receiving the request, the software adaptation layer converts the requirements of the unified interface into the operation logic of the specific adaptation protocol differences of the corresponding trusted root protocol, interacts with different trusted root components at the bottom layer, completes the security operation, and returns the result.

[0140] In summary, this application embeds a security hardware module 103 within the baseboard management controller. This module enables the security verification function of the security chip. Using the security hardware module 103 as a trust anchor, firmware is sequentially verified. The currently verified device firmware is designated as trusted firmware, and the trusted firmware is used to perform security verification on the next device firmware. This achieves chain-like security verification for firmware booting. By embedding the security hardware module 103 within the base management controller, firmware security verification is achieved, effectively reducing hardware costs and design complexity. Furthermore, the baseboard management controller itself provides a unified security interface, effectively adapting to different firmware security verification requirements without adding extra hardware to the device. This ensures full utilization of device resources, avoiding resource idleness. Moreover, by constructing a multi-level trust chain to achieve secure device booting, boot security is effectively improved, reducing the risk of device attacks.

[0141] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0142] Embodiments of this application also provide an electronic device including a baseboard management controller of any of the above.

[0143] Embodiments of this application also provide a method for starting an electronic device, the method being applied to the baseboard management controller of any of the above.

[0144] like Figure 6 As shown, the startup method flowchart for this electronic device includes the following steps:

[0145] In step S601, after the baseboard management controller is powered on, firmware security verification is performed on the security hardware module.

[0146] Understandably, after the baseboard management controller is powered on, firmware security verification, such as confirming firmware integrity and verifying firmware legality, is performed on the security hardware module. This can prevent the module from being implanted with malicious code, backdoors, or having its critical logic tampered with, ensuring that a compliant version without vulnerabilities is running and supporting trusted system startup.

[0147] Specifically, such as Figure 7 As shown, after power-on, the BMC_SRST# (board management controller system reset) signal is triggered, and the third control module ROM boot program is executed first to load the hardware security module ROM boot, followed by the loading of the hardware security module application. The hardware security module application image and its signature are verified using the public key of the hardware security module ROM pre-burned in OTP and the public key of the hardware security module application to ensure that the firmware of the hardware security module has not been tampered with. The third control module application and the BMC U-Boot boot program are loaded. The third control module application image and the BMC U-Boot boot program image and their signatures are verified using the public key of the third control module application and the public key of the BMC U-Boot boot program, respectively, to ensure the integrity and legality of this layer of firmware.

[0148] This application embodiment performs firmware security verification on the security hardware module after the baseboard management controller is powered on, such as confirming firmware integrity and verifying firmware legality. This can prevent the module from being implanted with malicious code, backdoors, or having its critical logic tampered with, ensuring that a compliant version without vulnerabilities is running and achieving trusted system startup.

[0149] In step S602, after the security hardware module passes the firmware security verification, the security hardware module initiates the firmware security verification of the third control module.

[0150] Understandably, after the security hardware module 103 passes the firmware security verification, it can initiate the firmware security verification of the third control module 108. This can build a complete security chain from root trust to system-wide trust, ensuring that the trustworthiness of each component of the system can be traced back to the hardware foundation, ensuring that the core control logic has not been tampered with, and improving the overall resilience against attacks.

[0151] Specifically, such as Figure 7 As shown, during its power-on phase, the security hardware module 103 has confirmed that its firmware has not been tampered with through a chain verification from the public key of the hardware trusted root ROM to the public key of the hardware security module application, becoming the root trust source of the entire process. The verification of the third control module 108 depends on the trustworthiness of the security hardware module 103, which is achieved through three steps: image loading, signature verification, and public key binding. The third control module 108 firmware image loading security hardware module 103 reads the firmware image of the third control module 108 through the bus or BMC relay and loads it into the verification environment. The digital signature verification security hardware module 103 calls the built-in cryptographic engine to extract the digital signature corresponding to the firmware image and performs signature verification in combination with the pre-stored public key. If it is a BIOS-type third module, the BIOS boot program signature is verified through the BIOS application public key to ensure that the BIOS firmware comes from a legitimate manufacturer and has not been tampered with. If it is another hardware component, the signature of the other component application is verified through the public key of the other component application to block malicious firmware implanted in the supply chain.

[0152] This application embodiment, by using the security hardware module 103 to initiate firmware security verification of the third control module 108 after the firmware security verification is passed, can build a complete security chain from root trust to system-wide trust, ensuring that the trustworthiness of each component of the system can be traced back to the hardware foundation, ensuring that the core control logic has not been tampered with, and improving the overall resilience against attacks.

[0153] In step S603, after the third control module 108 passes the firmware security verification, the third control module 108 initiates the firmware security verification of the kernel module 104, and the baseboard management controller is started after the firmware security verification of the kernel module 104 is completed.

[0154] Understandably, using the third control module 108 to initiate firmware security verification of the kernel module 104, and completing the firmware security verification of the kernel module 104 to start the baseboard management controller, extends the trusted chain to the kernel layer, builds an end-to-end trusted boot chain, realizes trusted boot of the baseboard management controller throughout the entire process, can verify that its firmware can prevent malicious code injection and logic tampering, ensure the trustworthiness of the kernel module 104, ensure that each boot component has not been tampered with, and block security risks throughout the entire process from the root.

[0155] Specifically, such as Figure 7 As shown, the third control module 108, under the verification of the security hardware module 103, has confirmed that its own firmware is trustworthy and has not been tampered with, and becomes the trust source for the next level of verification. The kernel module 104 is the core control layer of BMC, and its verification depends on the trustworthiness of the third control module 108. This is achieved by loading the image to the signature verification to the trust chain extension. The third control module 108 reads the firmware image of the BMC kernel module 104 through the bus and loads it into the verification environment.

[0156] The third control module 108 for digital signature verification calls the built-in cryptographic capabilities to extract the digital signature corresponding to the kernel firmware and performs signature verification in conjunction with the pre-stored public key. If it is the BMC kernel layer, the BMC kernel signature is verified through the BMC application public key to ensure the integrity and legitimacy of the kernel firmware. If it is the BMC application layer, the BMC application signature is verified through the boot public key of other components to block malicious tampering of the application layer.

[0157] This application embodiment utilizes the third control module 108 to initiate firmware security verification of the kernel module 104. After the firmware security verification of the kernel module 104 is completed, the baseboard management controller is started. This extends the trusted chain to the kernel layer, constructs an end-to-end trusted startup chain, and realizes trusted startup of the baseboard management controller throughout the entire process. It can verify that its firmware can prevent malicious code injection and logic tampering, ensure the trustworthiness of the kernel module 104, and ensure that each startup component has not been tampered with, thus blocking security risks throughout the entire process from the root.

[0158] In step S604, the baseboard management controller is used to perform firmware security verification on at least one of the boot system and other components of the electronic device, so as to complete the boot of the electronic device after firmware security verification. The other components are components other than the baseboard management controller and the boot system.

[0159] Understandably, using a baseboard management controller (BMC) to perform firmware security verification on the boot system and other components of electronic devices, and then completing the boot process after firmware security verification, constructs a trusted boot system for the entire hardware-to-software chain of electronic devices. By verifying the firmware of the boot system and other peripheral components through the BMC, risks such as malicious firmware injection and supply chain tampering are blocked at the source, ensuring that the firmware of each component has not been tampered with.

[0160] Specifically, such as Figure 7 As shown, in the hardware trusted root secure boot phase and the BMC kernel secure boot phase, the BMC first needs to complete its own firmware security verification, verifying the firmware of its own hardware security modules, kernel, and applications to ensure that the BMC itself is trusted, laying the foundation for subsequent verification and booting of the system and other components.

[0161] The system boots up according to the BIOS-like components shown in the diagram. The BMC reads the BIOS bootloader image, extracts the BIOS bootloader signature, and verifies the signature using the pre-stored BIOS application public key to ensure that the BIOS firmware has not been tampered with. After the signature verification is successful, the BIOS bootloader is allowed to load, thereby starting the BIOS application.

[0162] For verification of other components, BMC needs to read the application images of other components, extract the signatures of other component applications, and verify the signatures using the pre-stored public keys of other component applications to ensure the integrity and legitimacy of these peripheral firmware. Once the signature verification is successful, the applications of other components are allowed to load and run.

[0163] Once the firmware security verification of the boot system and all other components has passed, each component starts up sequentially according to the trusted chain. After the BIOS boots up, it guides the CPU to initialize, and other components start up synchronously, finally completing the power-on boot process of the entire electronic device.

[0164] To better understand the solution of this application, the substrate management controller of this application is described below through a specific embodiment, as follows:

[0165] After the server power is turned on, the BMC SRNT# signal is released to power on the BMC. At this time, the CPU and other components cannot start.

[0166] After the BMC powers on, the ROM loads the third control module ROM for booting. The OTP loads the hardware security module's ROM public key and encryption algorithm, and verifies the ROM using the specified encryption algorithm. If successful, the hardware security module ROM is loaded; otherwise, the system fails to boot.

[0167] The hardware security module loads the application public key of the hardware security module in the OTP and the BMC image, and verifies the ROM using a specified encryption algorithm. If successful, the hardware security module's ROM is loaded; otherwise, it fails to boot.

[0168] The hardware security module ROM boots and loads the hardware security module application image and its signature. It then uses the loaded hardware security module ROM public key to verify the signature using a specified encryption algorithm. If successful, the hardware security module application image is loaded; otherwise, the boot process fails.

[0169] The hardware security module application mirror starts, loads the third control module application image and its signature, and performs signature verification using the loaded hardware security module's application public key according to the specified encryption algorithm. If successful, the third control module application image is loaded; otherwise, an error occurs and the application does not start.

[0170] The third control module application starts, loads the U-Boot bootloader image and its signature, and performs signature verification using the loaded U-Boot bootloader image public key according to the specified encryption algorithm. If successful, it loads the U-Boot bootloader image and the U-Boot application public key; otherwise, it fails to start due to an error.

[0171] The U-Boot bootloader starts, loads the U-Boot application image and its signature, and performs signature verification using the loaded U-Boot application public key and a specified encryption algorithm. If successful, it loads the U-Boot application image and the BMC kernel public key; otherwise, it fails to boot due to an error.

[0172] The U-Boot application starts, loads the BMC kernel image and its signature, and performs signature verification using the loaded BMC kernel public key and a specified encryption algorithm. If successful, it loads the BMC kernel image, along with the BMC kernel public key and the BIOS bootloader public key; otherwise, it fails to boot due to an error.

[0173] The BMC kernel boots, loading the BMC bootloader image and its signature. It then verifies the signature using the loaded BMC application public key and a specified encryption algorithm. If successful, it loads the BMC bootloader image and the boot public keys for other components; otherwise, it fails to boot. Next, it loads the BIOS bootloader image and its signature, verifying the signature using the loaded BIOS bootloader public key and a specified encryption algorithm. If successful, the motherboard CPLD releases the CPU_RST# signal, and the BIOS loads the BIOS bootloader image and the BIOS application public key; otherwise, it fails to boot.

[0174] The BIOS bootloader starts, loads the BIOS application image and its signature, and verifies the signature using the loaded BIOS application public key and a specified encryption algorithm. If successful, it loads the BIOS application image and other CPU-related public keys; otherwise, it fails to boot due to an error.

[0175] The BMC application starts, loads the bootloader images of other components and their signatures, and verifies the signature using the public key of the loaded bootloader of other components according to the specified encryption algorithm. If successful, it loads the bootloader images of other components and the public keys of other component applications; otherwise, it fails to start due to an error.

[0176] The bootloader for other components starts, loads the application images and their signatures for those components, and verifies the signature using the public key of the loaded application components and a specified encryption algorithm. If successful, the application image for the component is loaded; otherwise, it fails to start.

[0177] Other component applications start, and from this point on, the BMC, BIOS, and other component applications have all completed the chained secure boot process.

[0178] In summary, the boot method for electronic devices proposed in this application embeds a security hardware module within the baseboard management controller. This security hardware module enables the security verification function of the security chip. Using the security hardware module as a trust anchor, the firmware is sequentially verified for security. The currently verified device firmware is designated as trusted firmware, and the trusted firmware is used to perform security verification on the next device firmware. This achieves chain-like security verification for firmware booting. Therefore, by embedding a security hardware module within the base management controller to achieve firmware security verification, hardware costs and design complexity can be effectively reduced. Furthermore, the baseboard management controller itself provides a unified security interface, effectively adapting to different firmware security verification requirements without adding extra hardware to the device. This ensures full utilization of device resources, avoids resource idleness, and by constructing a multi-level trust chain to achieve secure device booting, boot security can be effectively improved, reducing the risk of device attacks.

[0179] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0180] The foregoing has provided a detailed description of a baseboard management controller, electronic device, and startup method provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the methods and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A baseboard management controller, characterized in that, The baseboard management controller is connected to a first storage module, which stores a first image of the baseboard management controller. The baseboard management controller includes: a second storage module, a security hardware module, a kernel module, a first control module, a second control module, and a third control module. After its own firmware security verification is passed, the security hardware module initiates the firmware security verification of the third control module. After its own firmware security verification is passed, the third control module initiates the firmware security verification of the kernel module. The security hardware module implements the security verification function of the security chip. As a trust anchor, the security hardware module performs security verification on the firmware inside the baseboard management controller in sequence. The currently verified firmware is regarded as trusted firmware. The trusted firmware performs security verification on the next firmware to realize the firmware startup of chain-style security verification. During the security verification process, the firmware communicates with at least one of the first control module and the second control module and sends at least one of the first loading instruction and the second loading instruction. The first control module responds to the first load instruction and loads first data into the first image. The second control module responds to the second load instruction and controls the second storage module to load second data. At least one of the first data and the second data is used for firmware security verification. The firmware is loaded from the first image after the security verification is passed.

2. The baseboard management controller according to claim 1, characterized in that, The first data includes at least one of a first public key data, a first image data, and a first signature data. The first public key data is used for verifying the signature of the first signature data, and the image data is used for loading the firmware after the signature of the first signature data has been verified. The second data includes a second public key data, which is used for verifying the signature of the first signature data.

3. The baseboard management controller according to claim 1, characterized in that, The baseboard management controller further includes: a first read-only module and a second read-only module, wherein the first read-only module stores a first boot program and the second read-only module stores a second boot program, the first boot program is used to load the second read-only module, and the second boot program is used to load the firmware of the security hardware module.

4. The baseboard management controller according to claim 3, characterized in that, After the first read-only module is powered on by the baseboard management controller, it starts the first boot program. The first boot program communicates with the second control module, loads the public key of the second read-only module into the second storage module, verifies the signature of the second read-only module using the public key of the second read-only module, and loads the second read-only module after the signature verification is successful.

5. The baseboard management controller according to claim 3, characterized in that, The firmware of the security hardware module includes a first application. After being loaded, the second read-only module starts the second boot program. The second boot program communicates with the first control module and the second control module. The public key of the first application is loaded in the second storage module. The image and signature of the first application are loaded in the first image. The signature of the first application is verified using the public key of the first application. After the signature is verified, the first application is loaded according to the image of the first application.

6. The baseboard management controller according to claim 1, characterized in that, The firmware of the third control module includes a second application. After the first application of the security hardware module is loaded, it communicates with the first control module and the second control module, loads the public key of the second application in the second storage module, loads the image and signature of the second application in the first image, verifies the signature of the second application using the public key of the second application, and loads the second application according to the image of the second application after the verification is successful.

7. The baseboard management controller according to claim 1, characterized in that, The kernel module includes at least one third bootloader, a fourth application, a kernel component, and a fifth application, wherein the third bootloader is used to load the fourth application.

8. The baseboard management controller according to claim 7, characterized in that, After being loaded, the second application of the third control module communicates with the first control module and the second control module, loads the public key of the third bootstrap program in the second storage module, loads the image and signature of the third bootstrap program in the first image, verifies the signature of the third bootstrap program using the public key of the third bootstrap program, and loads the third bootstrap program according to the image of the third bootstrap program after the verification is successful.

9. The baseboard management controller according to claim 8, characterized in that, The second application is also used to load the public key of the fourth application into the first image. After loading, the third bootstrap communicates with the first control module, loads the image and signature of the fourth application into the first image, verifies the signature of the fourth application using the public key of the fourth application, and loads the fourth application according to the image of the fourth application after the verification is successful.

10. The baseboard management controller according to claim 9, characterized in that, The third bootloader is also used to load the public key of the kernel component in the first image. After loading, the fourth application communicates with the first control module, loads the image and signature of the kernel component in the first image, verifies the signature of the kernel component using the public key of the kernel component, and loads the kernel component according to the image of the kernel component after the verification is successful.

11. The baseboard management controller according to claim 10, characterized in that, The fourth application is also used to load the public key of the fifth application into the first image. After loading, the kernel component communicates with the first control module to load the image and signature of the fifth application into the first image, and uses the public key of the fifth application to verify the signature of the fifth application. After the signature verification is successful, the fifth application is loaded according to the image of the fifth application.

12. The baseboard management controller according to claim 10, characterized in that, The baseboard management controller is also connected to a third storage module, which is used to store a second image of the boot system. The fourth application is also used to load the public key of the boot system into the first image. The kernel component communicates with the first control module and sends a third loading instruction to the first control module. The first control module responds to the third loading instruction and loads third data into the second image. The kernel component uses the public key of the boot system and the third data to verify the firmware of the boot system. After the verification is successful, the firmware of the boot system is loaded.

13. The baseboard management controller according to claim 12, characterized in that, The third data includes at least one of a third public key data, a second image data, and a second signature data. The public key used to start the system is used to verify the second signature data. The third public key data is used for verifying the second signature data. The second image data is used for loading the firmware after the verification of the second signature data is successful.

14. The baseboard management controller according to claim 13, characterized in that, The firmware of the boot system includes a fourth bootloader. The kernel component communicates with the first control module, loads the image and signature of the fourth bootloader in the second image, and the kernel component verifies the signature of the fourth bootloader using the public key of the boot system. After the signature verification is successful, the fourth bootloader is loaded according to the image of the fourth bootloader.

15. The baseboard management controller according to claim 14, characterized in that, The firmware of the boot system also includes a sixth application. The kernel component is also used to load the public key of the sixth application in the second image. The fourth bootloader communicates with the first control module and loads the image and signature of the sixth application in the second image. The fourth bootloader uses the public key of the sixth application to verify the signature of the sixth application. After the signature verification is successful, the sixth application is loaded according to the image of the sixth application.

16. The baseboard management controller according to claim 12, characterized in that, The baseboard management controller is also connected to a fourth storage module, which stores a third image of other components, which are components other than the baseboard management controller and the boot system. The fifth application is also used to load the public keys of the other components into the third image. The fifth application communicates with the first control module and sends a fourth loading command to the first control module. The first control module responds to the fourth loading command and loads fourth data into the third image. The fifth application uses the public key of the boot system and the fourth data to verify the firmware of the other components. After the verification is successful, the firmware of the other components is loaded.

17. The baseboard management controller according to claim 16, characterized in that, The firmware of the other components includes a fifth bootloader. The fifth application communicates with the first control module, loads the image and signature of the fifth bootloader in the third image, and verifies the signature of the fifth bootloader using the public key of the fifth bootloader. After the signature verification is successful, the fifth bootloader is loaded according to the image of the fifth bootloader.

18. The baseboard management controller according to claim 17, characterized in that, The firmware of the other components also includes a seventh application. The fifth application is also used to load the public key of the seventh application in the third image. The fifth bootloader communicates with the first control module, loads the image and signature of the seventh application in the third image, and verifies the signature of the seventh application using the public key of the seventh application. After the signature verification is successful, the seventh application is loaded according to the image of the seventh application.

19. An electronic device, characterized in that, Includes the baseboard management controller as described in any one of claims 1-18.

20. A method for starting an electronic device, characterized in that, The method is applied to the baseboard management controller according to any one of claims 1-18, and the method includes: After the baseboard management controller is powered on, firmware security verification is performed on the security hardware module; After the security hardware module passes its own firmware security verification, the security hardware module initiates firmware security verification of the third control module. After the firmware security verification of the third control module is passed, the firmware security verification of the kernel module is initiated by the third control module, and the baseboard management controller is started after the firmware security verification of the kernel module is completed. The baseboard management controller is used to perform firmware security verification on at least one of the boot system and other components of the electronic device, so as to complete the boot of the electronic device after firmware security verification. The other components are components other than the baseboard management controller and the boot system.

Images