Quick start and safety verification method and equipment for embedded device, medium and program product

Abstract

The invention provides a quick start and security verification method and equipment for an embedded device, a medium and a program product, in the method, firmware is divided into a core start module and a non-core function module in advance, and the core start module and the non-core function module are respectively stored in a high-speed access area and a common storage area of a nonvolatile memory; after the embedded device is powered on, initialization of the key peripheral is completed; when firmware is started or updated for the first time, security verification based on a digital signature is executed on the core starting module, if verification is passed, a mirror image of the core starting module is written into a running cache partition of the nonvolatile memory, and an integrity label is generated; in the subsequent starting process, the mirror image is loaded from the running cache partition, and the integrity label is used for executing rapid verification; after loading of the core starting module is completed, the non-core function module is loaded, and lightweight check is executed. According to the method, the security of the core module is ensured, the performance and security requirements of the non-core module are considered, and the calculation and storage overhead is reduced.

Description

Technical Field

[0001] This application relates to the field of embedded systems technology, and in particular to a method, device, medium, and program product for fast startup and security verification of an embedded device. Background Technology

[0002] With the rapid development of the Internet of Things, smart homes, and industrial control, embedded devices are increasingly widely used in various terminal products. Existing embedded devices typically complete the boot process according to a fixed linear flow, which includes stages such as system power-on, hardware initialization, bootloader loading, operating system startup, and application layer startup.

[0003] Because embedded devices generally have limited storage space and computing power, their boot process and security verification mechanisms often need to balance performance and security. Common boot methods in existing technologies have the following shortcomings:

[0004] The startup time is relatively long. Traditional solutions often use a serial approach to complete hardware initialization and software loading sequentially, which takes a long time overall and is difficult to meet the requirements of rapid response in some scenarios.

[0005] Security and efficiency are difficult to balance. Existing security verification methods typically rely on hash verification or digital signature verification of the complete firmware image. While this method can guarantee system integrity to a certain extent, it incurs significant computational overhead, further extending startup time, and is difficult to implement effectively in resource-constrained environments.

[0006] Therefore, there is a trade-off between fast startup and security verification in existing embedded devices, and there is an urgent need for an improved method that can both shorten startup time and ensure security. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this application provides a fast startup and security verification method, device, medium, and program product for embedded devices, which at least solves the problems in existing technologies where the startup process relies on serial execution, resulting in excessively long startup times and large overall firmware verification computation overhead, making it difficult to balance performance and security.

[0008] To achieve the above objectives and other advantages, some embodiments of this application provide the following aspects:

[0009] In a first aspect, some embodiments of this application provide a fast boot and security verification method for an embedded device, wherein the firmware of the embedded device is pre-divided into a core boot module and a non-core functional module, the core boot module and the non-core functional module being stored in a high-speed access area of ​​a non-volatile memory and a normal storage area, respectively; the method includes:

[0010] After the embedded device is powered on, the initialization of key peripherals is completed;

[0011] When the firmware is first started or updated, a security verification based on digital signature is performed on the core startup module. If the security verification passes, the image of the core startup module is written into the runtime cache partition of the non-volatile memory, and an integrity tag corresponding to the image is generated.

[0012] During subsequent startup, the image is loaded from the runtime cache partition, and the integrity label is used to perform a quick verification on the image to confirm that the image has not been tampered with. If the quick verification fails, the security verification is re-executed.

[0013] After the core startup module is loaded, the non-core functional modules are loaded, and lightweight verification is performed on the non-core functional modules.

[0014] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising:

[0015] One or more processors; and a memory storing computer program instructions that, when executed, cause the processors to perform a fast startup and security verification method for an embedded device as described in any of the preceding descriptions.

[0016] Thirdly, some embodiments of this application also provide a computer-readable storage medium having a computer program and / or instructions stored thereon, which, when executed by a processor, implement the fast startup and security verification method for an embedded device as described above.

[0017] Fourthly, some embodiments of this application also provide a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the fast startup and security verification method for an embedded device as described above.

[0018] Compared with existing technologies, the solution provided in this application divides the firmware into a core boot module and non-core functional modules, storing them respectively in a high-speed access area of ​​non-volatile memory and a normal storage area. Combined with the setting of a runtime cache partition, the core boot module image can be directly loaded and fast verification performed during subsequent boot processes, avoiding repeated high-strength digital signature verification. This significantly shortens boot time, enabling embedded devices to meet the needs of real-time applications. The use of digital signature-based security verification for the core boot module and lightweight verification during the loading process of non-core functional modules effectively ensures the security of the core module while balancing the performance and security requirements of non-core modules, thereby improving the overall reliability of the system. Therefore, through hierarchical verification and runtime cache partitioning mechanisms, the overhead of repeated calculations during each boot process is reduced, lowering the consumption of computing and storage resources and enhancing the applicability of the method in resource-constrained embedded devices. Attached Figure Description

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

[0020] Figure 1 This is a schematic diagram of a layered firmware structure for an embedded device provided in an embodiment of this application;

[0021] Figure 2 This is one of the flowcharts illustrating a fast startup and security verification method for an embedded device provided in this application embodiment;

[0022] Figure 3 This is a second schematic flowchart of a fast startup and security verification method for an embedded device provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] First Embodiment

[0026] The first embodiment of this application relates to a fast boot and security verification method for an embedded device. The firmware of the embedded device is pre-divided into a core boot module and a non-core functional module. The core boot module and the non-core functional module are stored in the high-speed access area and the ordinary storage area of ​​a non-volatile memory, respectively. The firmware of the embedded device refers to the program code and related data stored in the non-volatile memory of the embedded device. Non-volatile memory refers to a storage medium that can retain data after power loss, and may include, but is not limited to, Flash memory (such as NAND Flash, NOR Flash), EEPROM, or novel non-volatile memory.

[0027] Firmware is loaded and executed when the device is powered on or reset, and is used to complete operations such as system startup, peripheral initialization, security verification, and function expansion. For example... Figure 1 As shown, the firmware is pre-divided into a core boot module and non-core functional modules. The core boot module provides the basic functions required for system booting, including system initialization logic, basic hardware drivers, and security verification mechanisms. The non-core functional modules provide application layer functions, data processing modules, and communication services.

[0028] To improve access efficiency, the core boot module is stored in the high-speed access area of ​​the non-volatile memory, while non-core functional modules are stored in the ordinary storage area of ​​the same non-volatile memory. The high-speed access area refers to a partition in the memory with fast access speed, supporting direct processor access or possessing higher bandwidth, such as the high-speed execution area of ​​Flash memory or the reserved boot partition in eMMC or UFS memory. The ordinary storage area refers to a regular partition in the memory with relatively low access speed, primarily used to store non-critical data or application programs, such as the ordinary data area of ​​Flash memory or the user partition of eMMC or UFS memory.

[0029] Reference Figure 2 , Figure 3 As shown, the method may include the following steps:

[0030] Step S1: After the embedded device is powered on, complete the initialization of key peripherals.

[0031] In this step, key peripherals may include, but are not limited to, non-volatile memory interfaces, memory controllers, clock modules, communication interface modules, and network physical layer interfaces. The non-volatile memory interface is used to establish an access channel with the storage medium after the system (i.e., the embedded device's operating environment, the hardware and software framework supporting firmware loading and subsequent application execution) is powered on, ensuring the firmware image can be read correctly. The memory controller is used to initialize and map on-chip storage resources to ensure the system can execute programs in the correct address space. The clock module provides the clock signal required for system operation; its stability directly affects the reliability of subsequent firmware loading and instruction execution. The communication interface module initializes serial ports or bus interfaces to enable data interaction with external devices. The network physical layer interface establishes basic link connections, supporting the device's networking capabilities.

[0032] Step S2: When the firmware is first started or updated, perform a security verification based on digital signature on the core boot module. If the security verification passes, proceed to step S3.

[0033] In this step, security verification can be achieved through digital signature verification mechanisms, such as RSA or ECC-based digital signature verification. When the embedded device boots for the first time or performs an update, it pre-reads the signature data of the core boot module from the storage area and calls the built-in public key verification logic to verify the digital signature of the core boot module using the public key pre-stored in the read-only storage area. This verification ensures that the integrity of the core boot module has not been tampered with and confirms its trustworthy origin, thereby preventing unauthorized firmware execution.

[0034] During the verification process, if the digital signature verification passes, the core boot module is deemed to meet the trusted execution conditions, and the process proceeds to step S3. If the digital signature verification fails, it indicates that the core boot module may be at risk of tampering or loading errors. In this case, the embedded device refuses to load the module and triggers a preset security policy. This security policy may include: putting the embedded device into a secure mode, providing only limited diagnostic functions; or loading a backup security image from a preset protected security area to ensure minimum available functionality and remote recovery capabilities of the device.

[0035] In this embodiment, when the core startup module fails the security check, the method further includes:

[0036] A backup security image is loaded from the protected security area of ​​the embedded device. The security image carries a version number, a unique device identifier, and a digital signature to ensure that the source is trustworthy and has not been tampered with.

[0037] After loading the security image, the embedded device is put into a restricted security operating mode where the firmware is unavailable;

[0038] Record anomaly logs, which should include at least the type of verification failure, the time of occurrence, the device's unique identifier, and the operating environment parameters, for subsequent analysis and tracing.

[0039] Specifically, the protected secure area of ​​an embedded device refers to a dedicated storage partition within the system reserved for storing security-critical data or backup firmware images. This area is equipped with stricter access control mechanisms, such as write protection, read-only locking, or permission configuration based on memory protection units or memory management units, and requires authorization through secure boot logic or hardware security modules to access or update, thereby establishing security isolation at the hardware level.

[0040] If the core boot module fails verification during the security check process, the system will execute an emergency handling procedure. A backup security image is loaded from the protected security area of ​​the embedded device. This security image is pre-configured with a version number, a unique device identifier, and a digital signature, and undergoes digital signature verification before loading to ensure the image's origin is trustworthy and its content has not been tampered with. This backup security image typically contains only the minimum functional modules required to maintain basic secure operation of the device, such as health monitoring, logging, and secure communication interfaces, to ensure controlled operation even in abnormal conditions.

[0041] After the backup security image is loaded, the system switches the device to a restricted security operating mode. Restricted security operating mode means that when the core boot module or critical firmware fails verification, the system abandons loading the abnormal firmware and enters a controlled operating environment. In this mode, the system prohibits the execution of unverified firmware, retaining only minimal security and monitoring functions such as logging, alarm reporting, and remote upgrades. By disabling or restricting the execution of non-core functional modules, potential attack entry points are effectively reduced, lowering the risk of the device being exposed to external attacks. Simultaneously, it prevents abnormal or untrusted modules from interfering with system resources during operation, ensuring the stable operation of core functions and allowing the device to maintain a basic security posture and controllability even in abnormal states.

[0042] Simultaneously, the system generates an exception log to record key information about the verification failure. The exception log includes at least the type of verification failure, the time of occurrence, the device's unique identifier, and operating environment parameters. It can be stored in a secure storage area to prevent loss, or reported to a remote management platform via a secure communication link for centralized security monitoring and subsequent traceability analysis. This ensures that even if the core boot module fails the security verification, the embedded device can still operate under a controlled and secure state, guaranteeing the system has minimal security protection capabilities and providing data support for subsequent fault analysis and system hardening.

[0043] Step S3: Write the image of the core boot module to the runtime cache partition of the non-volatile memory and generate an integrity tag corresponding to the image.

[0044] In this step, the runtime cache partition is a protected area reserved in the non-volatile memory of the embedded device. It is used to store the core boot module image that has passed digital signature verification during the first firmware boot or update. This partition is different from ordinary storage areas; its write and access are subject to access control. The core boot module image can only be written after successful security verification, and it will be loaded directly from this area during subsequent boot processes.

[0045] By storing a verified core boot module image in the runtime cache partition, the device can quickly verify the image's integrity by relying on integrity tags instead of performing strong digital signature verification again during subsequent boots, eliminating the need for such verification. This mechanism significantly reduces the overhead of redundant calculations while ensuring security, thereby shortening boot time and improving the system's real-time responsiveness.

[0046] Step S4: During the subsequent startup process, the image is loaded from the runtime cache partition, and a quick verification is performed on the image using the integrity label to confirm that the image has not been tampered with. If the quick verification fails, the security verification is re-executed.

[0047] In this step, the fast verification relies on the integrity tag generated in step S3 to confirm whether the core boot module image loaded from the runtime cache partition is consistent with the one used in the initial verification. This fast verification can be achieved by comparing the image's hash value, version information, and runtime environment parameters, thereby avoiding repeated high-strength digital signature verification and shortening startup time. If the fast verification fails, the system will fall back to a secure verification based on digital signatures to ensure the integrity and trustworthiness of the core boot module.

[0048] Step S5: After the core startup module is loaded, load the non-core functional modules and perform lightweight verification on the non-core functional modules.

[0049] In this step, after the core startup module is loaded, the system begins loading non-core functional modules. To ensure both security and startup efficiency, lightweight verification is performed on non-core functional modules, such as using Cyclic Redundancy Check (CRC) or MD5 hash verification, to detect whether module data has been tampered with with low computational overhead. Compared to the high-strength digital signature verification of the core startup module, this lightweight verification can be completed quickly under resource-constrained conditions, avoiding prolonging the overall startup time. The loading of non-core functional modules can be completed gradually through background threads or low-priority tasks, allowing the system to enter a usable state immediately after the core functions are ready, without delays caused by large-scale module loading. If an anomaly is detected in a non-core functional module during the lightweight verification process, the system can pause the loading of that module and report the anomaly information to the upper-level system through logging or remote communication mechanisms, thereby preventing the abnormal module from affecting the operation of the device's core functions.

[0050] Compared with existing technologies, the solution provided in this application divides the firmware into a core boot module and non-core functional modules, storing them respectively in a high-speed access area of ​​non-volatile memory and a normal storage area. Combined with the setting of a runtime cache partition, the core boot module image can be directly loaded and fast verification performed during subsequent boot processes, avoiding repeated high-strength digital signature verification. This significantly shortens boot time, enabling embedded devices to meet the needs of real-time applications. The use of digital signature-based security verification for the core boot module and lightweight verification during the loading process of non-core functional modules effectively ensures the security of the core module while balancing the performance and security requirements of non-core modules, thereby improving the overall reliability of the system. Therefore, through hierarchical verification and runtime cache partitioning mechanisms, the overhead of repeated calculations during each boot process is reduced, lowering the consumption of computing and storage resources and enhancing the applicability of the method in resource-constrained embedded devices.

[0051] Second Embodiment

[0052] The second embodiment of this application relates to a fast startup and security verification method for an embedded device. The second embodiment is an improvement upon the first embodiment, specifically in that: in the second embodiment, the integrity tag includes a hash value, a unique device identifier, a monotonically increasing version count, and environmental parameter information; step S4 may further include the following steps:

[0053] Step S401: Confirm that the core startup module has not rolled back based on the version count;

[0054] Step S402: Determine the reliability of the embedded device's operating environment based on environmental parameter information;

[0055] Step S403: When the version count confirms that there has been no rollback and the operating environment of the embedded device is trustworthy, perform a fast verification on the image using the hash value of the integrity tag and the unique identifier of the device to confirm that the image has not been tampered with.

[0056] Step S404: If the quick verification fails, the security verification is re-executed.

[0057] Specifically, the integrity tag records a monotonically increasing version count, which automatically increments with each firmware update. During subsequent boot processes, the system reads the version count from the current integrity tag and compares it with the latest version information stored on the device. If the version count is detected to be lower than the recorded value, it is determined that a rollback attack has occurred, and the core boot module is refused to be loaded.

[0058] During the initial firmware boot or update, the integrity tag records key environmental parameters such as clock frequency, peripheral initialization status, and security mode flag. On subsequent boots, the system collects relevant parameters of the current operating environment and compares them with the environmental parameters recorded in the integrity tag to confirm whether the current operating conditions are consistent with the trusted environment during the initial firmware verification. This method allows for the timely detection of environmental discrepancies caused by abnormal clock configuration, peripheral initialization errors, or unauthorized activation of security mode, thus preventing embedded devices from operating in untrusted environments during the rapid verification phase and further enhancing system security and reliability.

[0059] Once the version count confirms no rollback and the embedded device's runtime environment is trustworthy, the hash value of the image loaded from the runtime cache partition is recalculated. The calculated result is compared with the hash value recorded in the integrity tag to confirm that the image has not been tampered with during storage and loading. Simultaneously, the device's unique identifier is read and compared with the device identifier bound to the integrity tag to ensure that the image can only run on the embedded device it is bound to. If all the above comparisons match, the image is determined to be complete and trustworthy, and the system can directly proceed to the loading process.

[0060] When hash value comparison fails, device unique identifier is inconsistent, version is rolled back, or the operating environment is untrusted, the fast verification is deemed a failure. In this case, it will fall back to a high-strength security verification process based on digital signatures to ensure the integrity and trustworthiness of the core boot module image.

[0061] This fast verification mechanism can significantly reduce computational overhead while ensuring that the loaded core boot module image has not been tampered with and is running on a legitimate device, thereby improving boot efficiency and ensuring security.

[0062] Third Embodiment

[0063] The third embodiment of this application relates to a fast startup and security verification method for an embedded device. The third embodiment is an improvement on the first embodiment, specifically in that step S1 may further include the following steps:

[0064] Step S101: Obtain the task descriptor stored in the on-chip memory for initializing peripherals. The task descriptor includes at least register operations, timeout thresholds, and dependencies for indicating critical peripherals.

[0065] Step S102: Based on the dependency relationship, perform clock enable, reset release and register configuration on the key peripherals indicated by the task descriptor to complete the initialization operation in parallel.

[0066] Step S103: Perform status polling on critical peripherals, and enter firmware startup recording when all critical peripherals are in an available state.

[0067] Specifically, in this embodiment, on-chip memory refers to a small-capacity, high-speed storage unit integrated within the embedded processor. It is used to store critical control information, such as task descriptors required for peripheral initialization, during the initial power-up of the device. This differs from the non-volatile memory of the embedded device, which stores large amounts of firmware images and application data. By storing task descriptors in on-chip memory, the scheduling and driving of critical peripherals can be completed before the external non-volatile memory has finished initializing, thereby shortening startup time and improving system reliability.

[0068] The task descriptor describes the configuration information of critical peripherals during the initialization process, including at least register operations, timeout thresholds, and dependencies. Register operations indicate the required control register configurations for the peripherals; timeout thresholds limit the maximum time a peripheral can complete its response during initialization to trigger error handling in abnormal situations; and dependencies describe the preconditions between different peripherals, such as the memory controller depending on the clock module being properly powered on.

[0069] By setting task descriptors, the initialization process of critical peripherals can be abstracted into schedulable task units. During scheduling, the system determines the startup conditions of each peripheral based on the dependencies in the task descriptors, and triggers the initialization operations of multiple peripherals simultaneously when the conditions are met, achieving parallel control. Compared with the traditional serial initialization method, this method can significantly reduce the initialization time after power-on, enabling embedded devices to enter the firmware loading stage more quickly.

[0070] Further, in this embodiment, step S102 specifically includes:

[0071] After resetting critical peripherals, perform the following steps:

[0072] Driver Step 1: Drive the non-volatile memory interface to establish a firmware access channel and set bus timing parameters;

[0073] Step 2: Drive the memory controller to perform storage space initialization and trigger the calibration process of the storage cells;

[0074] Step 3: Drive the clock module to enable the system running clock and configure the clock frequency and stabilization mechanism;

[0075] Each driving step is executed in parallel provided that the dependencies indicated by the task descriptor are satisfied.

[0076] Specifically, releasing the reset of critical peripherals refers to the process where, after the embedded device is powered on, the system's reset control module releases the peripheral's reset signal, allowing the peripheral to move from its initial locked state to a configurable state. Specifically, the processor can write a control instruction to the on-chip memory's reset control register to clear the reset hold on the target peripheral; alternatively, it can release the peripheral's reset by pulling a separate reset pin high or using a gating signal. These methods ensure that critical peripherals such as the non-volatile memory interface, memory controller, and clock module sequentially enter a usable state when the dependent conditions are met and the system clock is stable, thus providing the prerequisites for subsequent register configuration and initialization operations.

[0077] After resetting the critical peripherals, the system performs driver operations on each critical peripheral according to the task descriptor, specifically including:

[0078] The non-volatile memory interface driver. Under the instruction of the task descriptor, the processor writes initialization parameters to the control register of the non-volatile memory interface, including the data bus width, timing control register value, and read / write wait cycle count, to establish an access channel with the non-volatile memory. Simultaneously, appropriate verification mechanisms, such as Cyclic Redundancy Check (CRC) or the memory's built-in error correction code (ECC), are configured to detect and correct errors during data transmission, ensuring the integrity of firmware image reads and writes.

[0079] The memory controller driver. The task descriptor further instructs the system to initiate the memory controller initialization process, including performing address mapping configuration, refresh cycle setting, and access priority management. Simultaneously, the system triggers memory cell calibration processes, such as write level calibration and read latency calibration, to ensure the timing accuracy and data stability of memory accesses.

[0080] Clock module driver. After the clock module is released from reset, the system configures the clock source selection register, divider register, and phase-locked loop (PLL) multiplication factor according to the task descriptor, and starts the master clock required for system operation. Subsequently, the system performs clock stability checks, such as checking the PLL lock status and jitter indicators, to ensure that the clock signal reaches the target frequency and remains stable, providing a reliable timing reference for other peripherals and the processor core.

[0081] The aforementioned driving steps are not executed sequentially, but rather scheduled by the scheduler based on the dependencies defined in the task descriptor. For modules that do not depend on other peripherals, such as clock modules and some non-volatile memory interfaces, initialization can begin immediately after the reset is lifted; while for memory controllers that depend on clock signals, initialization is automatically triggered after the clock module enters a stable state. In this way, the driving processes of multiple peripherals can be performed in parallel as long as the dependency conditions are met, significantly reducing the initialization time.

[0082] Fourth embodiment

[0083] The fourth embodiment of this application relates to a fast startup and security verification method for an embedded device. The fourth embodiment is an improvement upon the first embodiment, specifically in that the method further includes:

[0084] The trust status of the system is dynamically evaluated during the operation of the embedded device. The dynamic evaluation is based on the integrity verification results of at least the core boot module and the lightweight verification results of non-core functional modules.

[0085] When the dynamic evaluation results determine that the integrity verification of the core boot module fails or the lightweight verification of the non-core functional module fails, a security policy is triggered. The security policy includes: putting the embedded device into a function degradation mode available in the firmware or loading a backup security image.

[0086] It should be noted that while the core boot module undergoes rigorous digital signature verification during power-on and startup, it can still be vulnerable to malicious attacks, memory tampering, and firmware hot update anomalies as the system continues to run. Verification during startup alone is insufficient to guarantee security throughout the entire operating cycle. Non-core functional modules are loaded after startup using lightweight verification, and their security level is lower than that of the core boot module. If download module anomalies, external attack injections, or data corruption occur during operation, security vulnerabilities may arise; therefore, continuous monitoring during operation is essential.

[0087] In this embodiment, dynamic trust status assessment can be performed periodically via a background thread or a low-priority task. The assessment includes at least: recalculating the hash value of the core startup module and comparing it with the integrity label to confirm that it has not been tampered with during operation; performing lightweight verification on non-core functional modules, such as fast verification based on CRC or MD5, to detect any anomalies during loading or operation. When the dynamic assessment detects an anomaly, the system immediately triggers a security policy. For example, if the core startup module verification fails, it can directly switch to a pre-set security image in the protected security area of ​​the embedded device to ensure the device continues to operate in a trusted environment; if a non-core functional module verification fails, the operation of that module can be paused or uninstalled, and the device can be switched to a functional degradation mode, retaining only the core functions to ensure system stability. Simultaneously, the system can also record anomaly logs or report status information to the management server via remote communication for subsequent analysis and tracking. Through this dynamic assessment mechanism, the device can maintain dynamic trust status assessment and a rapid response mechanism even after entering normal operation, thereby effectively reducing security risks.

[0088] Fifth Embodiment

[0089] The fifth embodiment of this application relates to a fast startup and security verification method for an embedded device. The fifth embodiment is an improvement on the first embodiment, specifically in that step S5 may further include the following steps:

[0090] Step S501: Divide the non-core functional modules into several data segments with segment indexes and verification information;

[0091] Step S502: After the core startup module enters the running state, non-core functional modules are loaded in a segmented manner through background threads or low-priority tasks, and the target data segments are read into the buffer sequentially in the system's idle window according to the preset scheduling strategy.

[0092] Step S503: Perform a lightweight check on each data segment before writing. If the check fails, pause the loading of non-core functional modules, record the exception log, and send an alarm to the upper-layer system via the communication interface.

[0093] Specifically, non-core functional modules are divided into several data segments with segment indexes and verification information. Each data segment contains a segment header, which records the logical order of the data segment within the entire module, the target storage address range, and the corresponding verification value. This segmentation design allows for independent processing of segments during loading, avoiding bus congestion or excessive processor usage caused by loading excessively large modules at once. It also enables the system to quickly locate abnormal segments when verification fails, reducing the overhead of troubleshooting and recovery.

[0094] After the core startup module enters the running state, the system loads non-core functional modules in a segmented, gradual manner through background threads or low-priority tasks. The loading thread follows a preset scheduling strategy, such as time-slice polling or idle detection, and only reads the target data segment from non-volatile memory into the buffer when it detects processor load or that the memory bus is in an idle window. This ensures that the device's core functions and foreground tasks can operate normally even before non-core functional modules are fully loaded.

[0095] Before each data segment is written to the target area, the system performs a lightweight check on the segment, such as cyclic redundancy check (CRC32) or MD5 hash check. If the check result matches the check information recorded in the segment header, the data segment is confirmed to be untampered and can be safely written to the target address, completing the segment loading. If the check fails, the loading of subsequent segments is immediately aborted, and an exception log is generated. This exception log includes at least the index of the exception segment, the type of failed check, the timestamp of the occurrence, and the unique identifier of the current device. Furthermore, runtime environment parameters (such as clock status and bus load) can be appended to the log to distinguish whether the exception occurred due to storage media damage, external attack injection, or an anomaly during the loading process in subsequent tracing.

[0096] When verification fails, in addition to logging the error locally, the device can also send alarm information to the upper-level system or remote management platform in real time via a communication interface (such as UART, Ethernet interface, or wireless module). This allows administrators to obtain the device status immediately and take measures, such as remotely disabling the faulty module, triggering security policies, or issuing patch updates.

[0097] It is not difficult to see that the solution provided in this application, by dividing non-core functional modules into several data segments with segment indexes and verification information, and then gradually loading non-core functional modules in the system's idle window using background threads or low-priority tasks after the core startup module enters the running state, minimizes interference with the system's core functions and user response. Therefore, this embodiment effectively improves the security and controllability of the non-core functional module loading process, while maintaining the system's real-time responsiveness and resource utilization efficiency. This allows embedded devices to balance performance and security even in resource-constrained environments, enhancing the overall stability and reliability of operation.

[0098] Taking an IoT communication device as an example, the specific implementation method of this invention is as follows:

[0099] The device's firmware has a total size of 2MB, with the core startup module occupying approximately 200KB. This module mainly contains basic communication protocols and sensor drivers, ensuring that the device can quickly establish a minimum working environment after power-on. The non-core functional modules occupy approximately 1.8MB, mainly containing data analysis and cloud synchronization functions, which are used to provide extended services after the core modules are running.

[0100] After the device is powered on, the core boot module completes loading within approximately 50ms and verifies its integrity and provenance through a digital signature based on the ECC algorithm. Once this process is complete, the device enters its basic operational state, possessing the necessary communication and sensing capabilities.

[0101] Furthermore, non-core functional modules are loaded incrementally over the next 500ms via a background thread, with a CRC32 check performed before writing to detect whether the module data has been tampered with. This segmented loading and lightweight verification mechanism avoids delaying the response time of the device's core functions.

[0102] Furthermore, the image of the core boot module is stored in a specific secure cache area of ​​the Flash memory. During subsequent device boot processes, rapid verification and loading based on integrity tags can be completed in approximately 10ms, significantly reducing the overhead of repeatedly performing digital signature verification and improving boot efficiency.

[0103] Finally, if a non-core functional module fails to verify during device operation, the system will automatically restrict the activation of cloud synchronization functions, but will still maintain the normal operation of basic data collection and local storage functions, thereby ensuring that core tasks are not affected and achieving a balance between security and availability.

[0104] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0105] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices.

[0106] The electronic device includes: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform a fast startup and security verification method for an embedded device as provided in any one or more of the above embodiments. Figure 4 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0107] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103, and output device 1104 may be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0108] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0109] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0110] In this embodiment, a computer-readable medium stores a computer program / instruction, which, when executed by a processor, implements a fast startup and security verification method for an embedded device provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more computer-readable instructions.

[0111] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0112] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0113] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0114] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0115] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0116] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0117] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0118] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0119] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0120] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A method for rapid startup and security verification of an embedded device, characterized in that, The firmware of the embedded device is pre-divided into a core boot module and a non-core functional module, wherein the core boot module and the non-core functional module are stored in a high-speed access area of ​​non-volatile memory and a normal storage area, respectively; the method includes: After the embedded device is powered on, the initialization of key peripherals is completed; When the firmware is first started or updated, a security verification based on digital signature is performed on the core startup module. If the security verification passes, the image of the core startup module is written into the runtime cache partition of the non-volatile memory, and an integrity tag corresponding to the image is generated. During subsequent startup, the image is loaded from the runtime cache partition, and the integrity label is used to perform a quick verification on the image to confirm that the image has not been tampered with. If the quick verification fails, the security verification is re-executed. After the core startup module is loaded, the non-core functional modules are loaded, and lightweight verification is performed on the non-core functional modules.

2. The fast startup and security verification method for an embedded device according to claim 1, characterized in that, The integrity tag includes a hash value, a unique device identifier, a monotonically increasing version count, and environmental parameter information; During subsequent startup, the image is loaded from the runtime cache partition, and a quick verification is performed on the image using the integrity label to confirm that the image has not been tampered with. If the quick verification fails, the security verification is re-executed, including: Based on the version count, it was confirmed that the core startup module did not undergo a rollback; The reliability of the operating environment of the embedded device is determined based on the environmental parameter information. When the version count confirms that there has been no rollback and the operating environment of the embedded device is trustworthy, the image is quickly verified using the hash value of the integrity tag and the device's unique identifier to confirm that the image has not been tampered with. If the quick verification fails, the security verification is re-executed.

3. The fast startup and security verification method for an embedded device according to claim 1, characterized in that, The step of initializing key peripherals after the embedded device is powered on includes: Obtain a task descriptor stored in on-chip memory for initializing peripherals, the task descriptor including at least register operations, timeout thresholds and dependencies for indicating critical peripherals; Based on the aforementioned dependencies, the key peripherals indicated by the task descriptor are clocked, reset, and configured, and the initialization operations are completed in parallel. The status of the critical peripherals is polled, and firmware startup loading begins when all critical peripherals are in an available state.

4. The fast startup and security verification method for an embedded device according to claim 3, characterized in that, The key peripherals include a non-volatile memory interface, a memory controller, and a clock module; The steps of performing clock enable, reset release, and register configuration on the critical peripherals indicated by the task descriptor based on the aforementioned dependency relationship, and completing the initialization operation in parallel, include: After resetting the critical peripheral device, perform the following steps: Driver Step 1: Drive the non-volatile memory interface to establish a firmware access channel and set bus timing parameters; Step 2: Drive the memory controller to perform storage space initialization and trigger the calibration process of the storage cells; Step 3: Drive the clock module to enable the system operating clock and configure the clock frequency and stabilization mechanism; Each driving step is executed in parallel provided that the dependencies indicated by the task descriptor are satisfied.

5. The fast startup and security verification method for an embedded device according to claim 1, characterized in that, The method further includes: The trust status of the system is dynamically evaluated during the operation of the embedded device. The dynamic evaluation is based on the integrity verification results of at least the core boot module and the lightweight verification results of non-core functional modules. When the dynamic evaluation results determine that the integrity verification of the core boot module fails or the lightweight verification of the non-core functional module fails, a security policy is triggered. The security policy includes: putting the embedded device into a firmware-available function degradation mode or loading a backup security image.

6. The fast startup and security verification method for an embedded device according to claim 1, characterized in that, The step of loading the non-core functional modules after the core startup module has been loaded, and performing lightweight verification on the non-core functional modules, includes: The non-core functional modules are divided into several data segments with segment indexes and verification information; After the core startup module enters the running state, the non-core functional modules are loaded in a segmented manner through background threads or low-priority tasks, and the target data segments are read into the buffer sequentially in the system's idle window according to a preset scheduling strategy. Lightweight verification is performed on each data segment before writing. If the verification fails, the loading of the non-core functional modules is paused, an exception log is recorded, and an alarm is sent to the upper-layer system via the communication interface.

7. The fast startup and security verification method for an embedded device according to claim 1, characterized in that, If the core startup module fails the security check, the method further includes: A backup security image is loaded from the protected security area of ​​the embedded device. The security image carries a version number, a unique device identifier, and a digital signature to ensure that the source is trustworthy and has not been tampered with. After loading the security image, the embedded device is put into a restricted security operating mode where the firmware is unavailable; Record anomaly logs, which include at least the type of verification failure, the time of occurrence, the device's unique identifier, and operating environment parameters, for subsequent analysis and tracing.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the fast startup and security verification method for an embedded device as described in any one of claims 1-7.

9. A computer-readable storage medium having a computer program and / or instructions stored thereon, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the fast startup and security verification method for the embedded device as described in any one of claims 1-7.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the fast startup and security verification method for the embedded device as described in any one of claims 1-7.

Images