Security authentication method and system based on software firmware on heterogeneous system

Abstract

The invention provides a security authentication method and system based on software firmware on a heterogeneous system, electronic equipment and a storage medium, and aims at a heterogeneous vehicle-mounted SOC system formed by a Cortex-A core (running a rich operating system) and a Cortex-R core (running a real-time system), ROM partition information is used as a system-level security map, and a chain type + parallel full firmware verification process is constructed; the method comprises the following steps of: firstly, starting a BootLoader of an R core by a BootRom of which the chip is solidified; the BootLoader preferentially verifies ROM partition information (including storage positions of all firmware) of the ROM fixed address, if verification fails, the SOC is controlled to be powered off, and if verification passes, the ROM partition information is loaded to a memory; then, the BootLoader checks a Linux system bootstrap program (the bootstrap program further checks U-boot, a Linux kernel and a root file system after being started to start an A-kernel Linux system) and R-kernel firmware (the R kernel is started after the R-kernel firmware passes) respectively; and after the Linux system evokes the application program, the middleware verifies the storage partition of the application program after the system load is stable, and full-link security authentication is realized.

Description

Technical Field

[0001] This invention relates to the field of security authentication technology for heterogeneous embedded systems in vehicles and vehicles, and particularly to a security authentication method, system, electronic device, and storage medium based on software firmware on a heterogeneous system. Background Technology

[0002] As automotive electronic and electrical architecture rapidly evolves from traditional distributed ECUs (Electronic Control Units) to "domain-centralized / centralized computing" architectures, the computing power and functional integration of automotive SoCs (System-on-Chips) continue to improve. The heterogeneous multi-core architecture of "high-performance Cortex-A core (hereinafter referred to as A core) + real-time Cortex-R core (hereinafter referred to as R core)" has become the mainstream design solution. The A core typically runs rich operating systems such as Linux or Android, handling complex non-real-time tasks such as in-vehicle infotainment, human-machine interaction, and environmental perception data processing. The R core runs an RTOS (Real-Time Operating System) or has no operating system, responsible for high real-time safety-related tasks such as power control, chassis steering, and braking execution. While this heterogeneous architecture can balance "complex task processing capabilities" and "real-time control safety," it also requires the coordinated scheduling of multiple levels of BootLoaders, RTOS firmware, Linux kernels, and applications during the system startup phase, posing complex challenges to system security authentication across multiple nodes and kernels.

[0003] The boot process of a heterogeneous A+RSoC system exhibits a "chain dependency" characteristic: from chip power-on to full system operation, the BootROM (Boot Read-Only Memory), R-core BootLoader, Linux bootloader, Linux kernel, R-core firmware, and applications must be activated sequentially. Any modification or replacement of any level of software firmware can lead to malicious code injection, failure of critical control logic, and ultimately threaten vehicle safety. Existing security authentication schemes for such systems often employ a "firmware-by-firmware independent verification" strategy, meaning that the A-core Linux image and R-core real-time firmware are verified separately, but a comprehensive partition topology description of all firmware in the ROM (Read-Only Memory) is not established. This scheme has significant security vulnerabilities: attackers can bypass verification through "address redirection" or "partition spoofing," for example, by tampering with the storage address identifier of a firmware in the ROM, causing the verification program to mistakenly verify an unmodified "shadow partition," while actually loading and running the tampered malicious firmware, rendering the security authentication mechanism ineffective.

[0004] To compensate for the security deficiencies of "firmware-by-firmware verification," some solutions adopt a "microcontroller unit (MCU) + hardware security module (HSM) dual-chip architecture," using an independent HSM chip to centrally authenticate all firmware. However, this solution has significant drawbacks: firstly, the additional HSM chip increases BOM (Bill of Materials) costs, and the communication between the two chips prolongs system startup time, making it difficult to meet the startup speed requirements of automotive systems; secondly, the dual-chip layout requires complex PCB (Printed Circuit Board) routing design, increasing the difficulty of mass production processes and the failure rate. Furthermore, existing solutions also face pain points in OTA (Over-The-Air) upgrades and mass production deployment: because the verification information of each firmware is stored separately, OTA upgrades require separate signing and version management for the A-core image and R-core firmware, resulting in increased upgrade package size and complex key lifecycle maintenance; in the mass production stage, verification parameters need to be configured separately for different firmware, reducing production efficiency and making it difficult to meet the needs of large-scale mass production by car manufacturers. Summary of the Invention

[0005] This invention provides a security authentication method, system, electronic device, and storage medium based on software firmware on a heterogeneous system, to solve the technical problems in the prior art, such as the lack of cloud collaboration mechanisms and network adaptability design leading to the easy retention and loss of critical data, the waste of resources due to the lack of integration with vehicle operation plans, and the single dimension of video value judgment easily causing important data to be covered.

[0006] In a first aspect, embodiments of the present invention provide a security authentication method based on software firmware on a heterogeneous system, wherein the heterogeneous system includes a Cortex-A core running a rich operating system and a Cortex-R core running a real-time system, and the method includes the following steps: S1. After the SOC chip is powered on, the BootRom embedded in the SOC chip starts the BootLoader program corresponding to the Cortex-R core. S2. The BootLoader program verifies the ROM partition information stored at a fixed address in the ROM. The ROM partition information contains the storage location information of all software firmware in the heterogeneous system. If the verification fails, the SOC chip is powered off. If the verification passes, step S3 is executed. S3. The BootLoader program loads the ROM partition information into memory; S4. The BootLoader program obtains the storage location of the Linux system boot program based on the ROM partition information and verifies the Linux system boot program; if the verification passes, the Linux system boot program is started. S5. The Linux system bootloader verifies the U-boot kernel, Linux kernel, and root file system; if the verification passes, the Linux system is booted. S6. After the Linux system starts up, the application is invoked; after the Linux system load stabilizes, the middleware of the Linux system verifies the application storage partition in the ROM. S7. The BootLoader program obtains the storage location of the Cortex-R core firmware according to the ROM partition information and verifies the Cortex-R core firmware; if the verification passes, the program boots the Cortex-R core firmware.

[0007] Preferably, in step S2, the BootLoader program verifies the ROM partition information by calculating the hash value of the ROM partition information to be verified and comparing it with a preset baseline hash value.

[0008] Preferably, the BootROM is written by the SOC chip during the chip manufacturing stage, and the code of the BootROM cannot be modified by subsequent software, and is automatically triggered and executed only when the SOC chip is powered on.

[0009] Preferably, in step S2, if the ROM partition information verification fails, the BootLoader program will also record the fault type and verification time to a preset non-volatile fault log storage area, and then control the SOC chip to power off.

[0010] Preferably, in step S4, the Linux system bootloader is an ATF bootloader or an UBoot bootloader.

[0011] As a preferred option, OTA upgrade steps are also included: Obtain an OTA update package, which contains new ROM partition information and a corresponding software firmware image; perform signature verification on the new ROM partition information; if the verification passes, update the original partition information and software firmware image in the ROM based on the new ROM partition information; after the update is completed, execute S1.

[0012] Preferably, in step S6, the middleware of the Linux system verifies the application storage partition in the ROM, including: The middleware reads the firmware data from the application storage partition in the ROM, calculates the hash value of the firmware data, and compares it with the hash value of the currently running application; if they do not match, a security alarm is triggered.

[0013] Secondly, an embodiment of the present invention provides a security authentication system based on software firmware on a heterogeneous system, wherein the heterogeneous system includes a Cortex-A core running a rich operating system and a Cortex-R core running a real-time system, and the system includes: The solidified storage module is used to start the BootLoader program corresponding to the Cortex-R core by the BootRom solidified in the SOC chip after the SOC chip is powered on; The ROM partition security module verifies the ROM partition information stored at a fixed address in the ROM. The ROM partition information contains the storage location information of all software firmware in the heterogeneous system. If the verification fails, the SOC chip is powered down. If the verification passes, step S3 is executed. The BootLoader program loads the ROM partition information into memory; The Linux bootloader security module uses the BootLoader program to obtain the storage location of the Linux system bootloader based on the ROM partition information and verifies the Linux system bootloader; if the verification passes, the Linux system bootloader is started. The A-core system secure boot module is used to verify the U-boot kernel, Linux kernel, and root file system through the Linux system boot program; if the verification passes, the Linux system is booted. The A-core software secure boot module is used to launch applications after the Linux system starts up; after the Linux system load stabilizes, the middleware of the Linux system verifies the application storage partition in ROM. The R-core system secure boot module is used to obtain the storage location of the Cortex-R core firmware according to the ROM partition information through the BootLoader program, and to verify the Cortex-R core firmware; if the verification is successful, the Cortex-R core firmware is booted.

[0014] Thirdly, embodiments of the present invention provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the security authentication method based on software firmware on a heterogeneous system as described in the first aspect of the present invention.

[0015] Fourthly, embodiments of the present invention provide a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the security authentication method based on software firmware on a heterogeneous system as described in the first aspect of the present invention.

[0016] This invention provides a security authentication method, system, electronic device, and storage medium based on software firmware in a heterogeneous system. Specifically, it addresses a heterogeneous automotive SOC system composed of a Cortex-A core (running a rich operating system) and a Cortex-R core (running a real-time system). Using ROM partition information as a "system-level security map," a chain-like and parallel full firmware verification process is constructed: After the SOC powers on, the chip-embedded BootROM first starts the R core's BootLoader; the BootLoader prioritizes verifying the ROM partition information at a fixed ROM address (including all firmware storage locations). If verification fails, the SOC is powered down; if successful, the firmware is loaded into memory. Subsequently, the BootLoader verifies the Linux system bootloader (which, after startup, further verifies U-boot, the Linux kernel, and the root file system to start the A core Linux system) and the R core firmware (if successful, the R core is started); after the Linux system wakes up the application, the middleware waits for the system load to stabilize before verifying the application storage partition, thus achieving end-to-end security authentication. In terms of technical benefits, firstly, by using a single-point verification and global failure mechanism for ROM partition information, the system avoids the problems of traditional firmware-by-firmware verification, susceptibility to address redirection, and partition spoofing, thus improving system security. Secondly, it does not rely on the MCU+HSM dual-chip architecture; it only needs to use BootRom+BootLoader+Linux middleware three-level verification to meet ISO 26262 ASIL-B and above requirements, reducing BOM costs, shortening boot timing, and simplifying PCB design. Thirdly, the ROM partition information centrally manages firmware addresses and verification benchmarks; OTA upgrades only require updating partition information and the corresponding image, and mass production does not require separate configuration of firmware verification parameters, simplifying version management and key maintenance and improving deployment efficiency. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart of a security authentication method based on software firmware on a heterogeneous system according to an embodiment of the present invention; Figure 2This is a detailed flowchart of a security authentication method based on software firmware on a heterogeneous system according to an embodiment of the present invention; Figure 3 This is a block diagram of a security authentication system based on software firmware on a heterogeneous system according to an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] In the embodiments of this application, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0021] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a system, product, or device that includes a series of components or units is not limited to the listed components or units, but may optionally include unlisted components or units, or may optionally include other components or units inherent to such products or devices. In the description of this application, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] This invention provides a security authentication method based on software firmware on a heterogeneous system, such as... Figure 1 As shown, the heterogeneous system includes a Cortex-A core running a rich operating system and a Cortex-R core running a real-time system. The method includes the following steps: S1. After the SOC chip is powered on, the BootRom embedded in the SOC chip starts the BootLoader program corresponding to the Cortex-R core. S2. The BootLoader program verifies the ROM partition information stored at a fixed address in the ROM. The ROM partition information contains the storage location information of all software firmware in the heterogeneous system. If the verification fails, the SOC chip is powered off. If the verification passes, step S3 is executed. S3. The BootLoader program loads the ROM partition information into memory; S4. The BootLoader program obtains the storage location of the Linux system boot program based on the ROM partition information and verifies the Linux system boot program; if the verification passes, the Linux system boot program is started. S5. The Linux system bootloader verifies the U-boot kernel, Linux kernel, and root file system; if the verification passes, the Linux system is booted. S6. After the Linux system starts up, the application is invoked; after the Linux system load stabilizes, the middleware of the Linux system verifies the application storage partition in the ROM. S7. The BootLoader program obtains the storage location of the Cortex-R core firmware according to the ROM partition information and verifies the Cortex-R core firmware; if the verification passes, the program boots the Cortex-R core firmware.

[0024] Specifically, in S1, the SOC chip, or System on Chip, is the hardware core of the heterogeneous automotive system. It integrates all key hardware modules, including the Cortex-A core (A core), Cortex-R core (R core), memory controller, and peripheral interfaces, essentially acting as the brain of the vehicle's electronics. The BootRom, or Boot Read-Only Memory, is a read-only memory area directly written by the SOC chip manufacturer during the chip manufacturing stage and cannot be modified subsequently. It stores the initial boot program after the system is powered on and is the source of the entire system's startup. The Cortex-R core (R core) is a kernel under the ARM architecture specifically designed for real-time control, emphasizing high real-time performance and reliability. It typically runs an RTOS (Real-Time Operating System) or has no operating system, and is responsible for safety-critical tasks such as vehicle power control, braking execution, and chassis steering. The BootLoader program is the bridge connecting the BootRom and subsequent firmware (such as the Linux bootloader and R core firmware), responsible for initializing the SOC hardware and loading and verifying subsequent firmware.

[0025] After the vehicle system is powered on (e.g., when the user inserts the key or presses the start button), the most reliable program must be launched first to prevent tampering with the initial setup. Since the BootROM is unmodifiable, its R-core BootLoader program possesses trusted root attributes. Heterogeneous systems need to collaboratively launch multiple firmware types, including the A-core and R-core. The R-core BootLoader is launched first because it undertakes security-critical tasks; a trusted foundation for the real-time core must be established before extending to the rich operating system of the A-core. The technical effect of this step is to establish a trusted starting point for system startup, blocking the possibility of malicious code being implanted through the initial boot process, and laying the foundation for subsequent end-to-end security authentication.

[0026] Furthermore, in S2, read-only memory is used in automotive scenarios to store critical firmware that cannot be arbitrarily modified (such as Linux bootloaders and R kernel firmware). Physically, it is not easily tampered with, but logically, data integrity needs to be verified.

[0027] ROM partition information is a system-level map stored at a fixed address in the ROM. As described in the attachment, it records the specific storage address and verification benchmark (such as hash value) of all software firmware (Linux bootloader, kernel, and application programs of A core, real-time firmware of R core, etc.) in the ROM in the heterogeneous system. It is the core basis for subsequent location and verification of all firmware.

[0028] In automotive heterogeneous systems, there are numerous firmware files (3-4 types for A-cores and 1-2 types for R-cores). Traditional solutions require firmware-by-firm verification, which is easily bypassed by address redirection (e.g., tampering with a firmware address causes the verification program to mistakenly verify a shadow partition). In this step, the BootLoader first verifies the overall map of ROM partition information. If the map is tampered with (e.g., firmware address is changed), the SOC is directly powered down, essentially preventing the system from continuing if the map is incorrect. Combining the design concept of single-point verification and global failure, this step achieves global security blocking at minimal cost: no firmware-by-firm verification is required; a single verification covers the positioning basis of all firmware, avoiding the vulnerability of traditional solutions where partial operation is still possible even after step-by-step error reporting, significantly improving security authentication efficiency.

[0029] In S3, memory refers to the running memory of the SOC (such as DDR), which has the characteristics of fast read and write speed and data loss when power is off. It is different from ROM, which is read-only and slow. It is mainly used to store data that needs to be accessed frequently during system operation.

[0030] This step prepares for subsequent system startup steps. Both S4 (finding the Linux bootloader) and S7 (finding the R-core firmware) require frequent queries to the firmware storage address. Reading partition information from the slow ROM each time would prolong system startup time (in automotive scenarios, basic function initialization must be completed within 3-5 seconds of power-on to avoid excessive user waiting). Loading the partition information into high-speed memory allows subsequent steps to quickly obtain the firmware address, reducing the number of ROM accesses. This improves the efficiency of subsequent verification and startup, shortens the overall system startup time, and meets the automotive system's requirement for "fast power-on response" (e.g., the ability to quickly operate navigation, air conditioning, and other functions after power-on).

[0031] In S4, the Linux system bootloader, such as ATF (Arm Trusted Firmware) or UBoot, is a key program that connects the BootLoader and the Linux kernel. It is responsible for initializing the A-core hardware (such as memory controllers and peripheral interfaces), establishing a secure execution environment, and loading the Linux kernel. It is a crucial stepping stone for A-core booting.

[0032] The A-core runs rich operating systems such as Linux, undertaking complex non-real-time tasks such as in-vehicle infotainment (e.g., music, navigation) and environmental perception data processing (e.g., camera, radar data). Its startup depends on the Linux system bootloader. If the bootloader is tampered with, it may cause the Linux kernel to fail to load (e.g., a black screen on the in-vehicle infotainment system) or inject malicious code (e.g., stealing user navigation data, interfering with perception signals). The BootLoader locates and verifies the bootloader based on a "trusted map" (verified ROM partition information), ensuring the security of the A-core's boot "stepping stone." The technical effect is to block the risk of tampering at the source of the A-core boot process, establishing a "secondary trusted link" for the secure operation of the subsequent Linux system and applications, and preventing A-core functional failure due to bootloader anomalies.

[0033] In S5, U-boot, in some scenarios, works with ATF as a bootloader, focusing on hardware initialization and kernel loading, and can be understood as an enhanced springboard; the Linux kernel is the core of the Linux system, responsible for the hardware resource management of the A kernel (such as CPU scheduling and memory allocation) and task scheduling (such as handling navigation and music playback simultaneously), and is the "core engine" for the operation of the A kernel. The root file system stores all the basic files of the Linux system (such as hardware drivers, system services, and configuration files), which is equivalent to the "system folder" of the A kernel. Driver abnormalities can cause peripherals (such as cameras and touch screens) to malfunction.

[0034] Modifications to the U-boot, kernel, and root file system can lead to system malfunctions. In automotive scenarios, if the kernel is tampered with, it may cause A-core task scheduling chaos (such as navigation lag or music interruptions). If the camera driver in the root file system is modified, it will affect the perception functions of ADAS (Advanced Driver Assistance Systems) (such as the inability to recognize obstacles ahead). The Linux bootloader verifies these three core components to ensure the integrity of the A-core engine and system folders. The technical effect is to guarantee the core integrity of the A-core Linux system, avoid vehicle system malfunctions due to kernel or file system tampering (such as black screens or peripheral device failures), and especially provide system-level security for safety-related perception tasks such as ADAS.

[0035] In S6, Linux middleware is a software component running on the Linux system, independent of applications and the kernel. It is responsible for implementing specific general functions, equivalent to a security check assistant for the A-core. The application storage partition is an independent area in the ROM specifically for storing in-vehicle applications (such as navigation apps, tire pressure monitoring apps, and music apps). These applications are directly user-facing and may also involve security functions (such as tire pressure monitoring). Stable system load refers to waiting 10-15 seconds after the initial Linux startup (when multiple programs start simultaneously, CPU usage may reach over 70%) until it drops below 30%, to avoid system lag caused by verification consuming resources.

[0036] In-vehicle applications are the direct entry point for user interaction. If they are tampered with (e.g., a tire pressure monitoring app displaying false data or a navigation app redirecting to an incorrect route), it will affect user experience and even driving safety. However, Linux experiences high load during the initial boot process, and verifying applications at this time can cause the in-vehicle system to lag (e.g., touch screen unresponsiveness). This step first activates the application to meet basic user needs, and then middleware verifies the application after the load stabilizes. This avoids impacting the user experience while ensuring that the application has not been tampered with. The technical effect is a balance between security and user experience: it blocks the risk of application tampering (e.g., preventing false tire pressure data from misleading users) while avoiding system lag caused by the verification process, meeting the requirement of "balancing security and user experience" in the in-vehicle scenario.

[0037] In S7, the Cortex-R core firmware is the core program running on the R core. It is usually an RTOS firmware or a bare-metal program. It contains safety-critical code such as power control (e.g., engine fuel injection control), braking execution (e.g., ABS anti-lock braking logic), and power steering control. It is the lifeline of vehicle safety.

[0038] The tasks performed by the R core have extremely high requirements for real-time performance and safety (e.g., braking commands must respond within 10ms). If its firmware is tampered with (e.g., extending the braking response time or altering steering assist parameters), it will directly threaten driving safety (e.g., brake failure, loss of steering control). The BootLoader locates and verifies the R core firmware based on a trusted map, ensuring that the R core boots compliant firmware. Simultaneously, this step can be executed in parallel with S4-S5 (A core bootloader verification) (after the BootLoader loads partition information, it can simultaneously process the location verification of both the A and R core firmware), avoiding the time extension caused by serial booting. The technical effect is to ensure the source security of critical driving safety functions, directly blocking the risk of power and braking failure caused by R core firmware tampering, while shortening the overall system boot time through parallel execution, meeting the real-time requirements of in-vehicle systems.

[0039] Based on the above embodiments, as a preferred implementation, in step S2, the BootLoader program verifies the ROM partition information by calculating the hash value of the ROM partition information to be verified and comparing it with a preset benchmark hash value.

[0040] Specifically, the core security challenge of heterogeneous in-vehicle systems (A core running Linux / Android, R core running RTOS) lies in the chain-like risk of multiple firmware co-booting. If the storage address of a firmware is tampered with (e.g., an attacker redirects the address of the R core braking firmware to a malicious code partition), the traditional firmware-by-firmware independent verification scheme will misverify the untampered shadow partition, leading to the loading of malicious firmware.

[0041] After the SOC chip is powered on (such as when the user presses the vehicle start button), BootRom first starts the BootLoader program of the R core. At this time, the system has not yet loaded any other firmware, and the BootLoader is in a clean and trusted state, which is ready to perform the initial verification. Verification execution process: The BootLoader first reads the ROM partition information to be verified at a fixed address in the ROM, and calculates its real-time hash value using a built-in hash algorithm (such as SHA256); then it reads the preset base hash value stored in the ROM and compares the real-time hash value with the base hash value at the byte level. Risk blocking logic: If the comparison results are inconsistent (indicating that the ROM partition information has been tampered with, such as the firmware address being modified or the number of partitions being increased or decreased), the BootLoader immediately triggers a global failure mechanism, controlling the SOC chip to power down directly, preventing the system from loading any firmware (including the security-critical firmware of the R core and the user interaction firmware of the A core) under the guidance of the error map; if the comparison is consistent, the subsequent steps of loading the ROM partition information into memory will be executed, providing a reliable basis for locating the A core Linux boot program and the R core firmware.

[0042] Based on the above embodiments, as a preferred implementation, the BootROM is written by the SOC chip during the chip manufacturing stage, and the code of the BootROM cannot be modified by subsequent software, and is automatically triggered and executed only when the SOC chip is powered on.

[0043] In traditional automotive systems, if the bootloader is stored in a rewritable ROM partition, attackers could potentially tamper with it using malicious code, causing it to launch malicious firmware. In this embodiment, the BootROM is designed to be written by the manufacturer during the production stage and cannot be modified subsequently, thus blocking tampering at the hardware source.

[0044] Timing of writing: Before the SOC chip leaves the factory, the manufacturer writes the boot code for starting the R core BootLoader into the BootROM according to the boot requirements of the heterogeneous system, ensuring that the code is strongly bound to the chip hardware.

[0045] Unmodifiable guarantee: The BootRom adopts a hardware-level read-only design. Even if a malicious attack occurs during vehicle use (such as injecting tampered code through the USB port), the boot logic within the BootRom cannot be modified, ensuring that the boot code used each time the vehicle is powered on is a trusted version preset by the manufacturer.

[0046] Based on the above embodiments, as a preferred implementation, in step S2, if the ROM partition information verification fails, the BootLoader program will also record the fault type and verification time to a preset non-volatile fault log storage area, and then control the SOC chip to power off.

[0047] Specifically, the core design of step S2 is that if the verification fails, the SOC will power down, blocking the loading of malicious firmware at minimal cost. However, in automotive scenarios, in addition to security blocking, it is also necessary to address the maintenance needs of how to troubleshoot the root cause after a fault. Traditional solutions only involve power loss without logging, making it impossible for maintenance personnel to determine whether the ROM partition information has been tampered with or whether the hardware storage is damaged, resulting in low troubleshooting efficiency and long repair cycles. Based on this, this embodiment adds a fault log recording step to the original logic. The overall logical flow is as follows, without affecting the timeliness of security blocking.

[0048] After ROM partition information verification fails, the BootLoader performs operations in the sequence of fast logging → safe power-off to avoid giving malicious firmware an opportunity to load due to log recording delays. Step 1: After determining that the verification has failed, the BootLoader immediately calls the built-in fault log writing interface without waking up other modules (such as A-core Linux system, R-core RTOS), and accesses the non-volatile fault log storage area only through the BootLoader's own permissions. The second step: The written content contains three core pieces of information: fault type (fixed to ROM partition information hash check mismatch), check time (real-time time read from the SOC built-in RTC module, accurate to the second, to meet the time accuracy requirements of vehicle diagnostics), and ROM partition information storage address (to help maintenance personnel locate whether the storage hardware is abnormal). Step 3: After the log writing is completed (in the vehicle scenario, this operation takes ≤10ms, which is much shorter than the time required to load malicious firmware), the BootLoader immediately executes the "control SOC chip power failure" logic originally designed in the attachment to ensure that the system has no chance to load any abnormal firmware.

[0049] Based on the above embodiments, as a preferred implementation, in step S4, the Linux system bootloader is an ATF bootloader or an UBoot bootloader.

[0050] Based on the above embodiments, as a preferred implementation, an OTA upgrade step is also included: Obtain an OTA update package, which contains new ROM partition information and a corresponding software firmware image; perform signature verification on the new ROM partition information; if the verification passes, update the original partition information and software firmware image in the ROM based on the new ROM partition information; after the update is completed, execute S1.

[0051] Specifically, an OTA update package refers to the firmware upgrade carrier pushed by the car manufacturer to a heterogeneous system through the vehicle network (such as 4G / 5G, vehicle networking). Based on the ROM partition information as the core design of the system-level map, it must contain two key contents: new ROM partition information (the storage location and verification benchmark information of all firmware after the update, replacing the original system map) and corresponding software firmware image (such as the new Linux kernel and new applications of the A core, and the new real-time firmware of the R core, which is the actual upgraded function code). The two must correspond one-to-one to ensure that the upgraded firmware can be accurately located.

[0052] Signature verification: A core technology in the field of automotive security used to confirm the trusted source and integrity of update packages. It refers to the process by which car manufacturers digitally sign the new ROM partition information using a dedicated private key (secretly held by the car manufacturer) when generating OTA update packages. The in-vehicle system has a built-in public key of the car manufacturer (written during mass production and cannot be tampered with). After receiving the update package, the public key is used to verify the signature. Only when the signature verification is successful is it confirmed that the update package comes from a trusted car manufacturer and has not been tampered with, thus preventing malicious upgrade package injection.

[0053] Software firmware image: The upgraded version of all software firmware in the heterogeneous system. It is the functional carrier of OTA upgrade, including the Linux bootloader (such as ATF / UBoot), Linux kernel, root file system, and applications on the A-core side, as well as the real-time firmware on the R-core side. Its storage location and verification information must completely match the new ROM partition information in the OTA update package to ensure that it can be located and verified by the BootLoader after the upgrade.

[0054] Update the original partition information and software firmware image in the ROM: After the signature verification is passed, the vehicle system overwrites the original data in the ROM in the order of updating the map first and then updating the firmware. First, the new ROM partition information is written to a fixed address in the ROM. Then, according to the location description of the new partition information, the corresponding software firmware image is written to the specified firmware partition in the ROM. This ensures that when the system starts up after the upgrade, the BootLoader can locate the new firmware based on the new map.

[0055] The end-to-end security verification is based on ROM partition information. OTA upgrades need to update firmware without breaking this verification logic. Traditional vehicle OTA solutions require signing the A-core Linux image and R-core firmware separately because the A-core and R-core firmware verification information are scattered, resulting in large upgrade package size and complex version management (this pain point is clearly mentioned in the appendix).

[0056] Based on the above embodiments, as a preferred implementation, in step S6, the middleware of the Linux system verifies the application storage partition in the ROM, including: The middleware reads the firmware data from the application storage partition in the ROM, calculates the hash value of the firmware data, and compares it with the hash value of the currently running application; if they do not match, a security alarm is triggered.

[0057] The core of step S6 is to avoid the verification defects caused by the high load and large application size in the early stage of Linux system startup. Its complete execution logic needs to be combined with the startup sequence and security requirements of the vehicle system and broken down into the following 5 key links, and the whole process echoes the overall framework of the full-link security authentication in the appendix.

[0058] Verify the trigger timing, and wait for the Linux system load to stabilize (wait 10-15 seconds). When a Linux system first boots up (during the S5 step when applications are invoked), it loads kernel services, drivers, and multiple applications simultaneously, potentially reaching CPU utilization of over 70% (in-vehicle SOCs typically have limited computing power). If large applications (such as navigation apps that may occupy hundreds of MB of storage) are immediately validated at this time, it can cause system lag (e.g., unresponsive touchscreens, music interruptions), impacting user experience. Therefore, the middleware automatically waits 10-15 seconds (specified in the appendix) after the application starts, reading metrics such as CPU and memory usage to confirm that the system load has dropped to a stable threshold (usually ≤30%) before initiating the validation process. This avoids impacting user experience while ensuring the middleware has sufficient computing power to complete the hash calculation.

[0059] Reading the verification object: Locating data based on trusted ROM partition information "ROM partition information is a system-level map for all firmware locations." Before the middleware reads the verification data, it needs to obtain the ROM partition information already loaded into memory through the Linux kernel (this information has been verified by the BootLoader in step S2 and has a reliable basis), and extract two key pieces of information from it: The physical address of the application storage partition in ROM: This ensures that the middleware can accurately read the original application firmware data in the ROM that has not been tampered with (avoiding reading the wrong partition and causing deviation in the verification object). Application baseline hash value: If the application baseline hash value is recorded in the ROM partition information, the middleware can directly use it as a substitute baseline for the ROM firmware data hash value, reducing one hash calculation, improving verification efficiency, and conforming to the concept of centralized management of all firmware verification baselines in ROM partition information.

[0060] Double-ended hash calculation: Ensures verification covers the entire storage and operational process. Traditional automotive solutions only verify applications stored in ROM, not applications running in memory. This presents a vulnerability where ROM data may be normal, but memory can be tampered with during loading (e.g., an attacker injects malicious code into memory to modify a running application). This vulnerability is mitigated through dual-end computation: One-end calculation: The middleware reads the complete firmware data of the application storage partition through the ROM controller and calculates the original hash value (representing the base state in the ROM that has not been tampered with) according to the SHA256 algorithm. On the other end, the middleware reads the application image currently running in memory through the Linux kernel's memory access interface (excluding temporary cached data and extracting only the core execution code), and also calculates the real-time hash value (representing the current actual running program state). The dual-end calculation ensures that the verification covers the entire process from ROM storage to memory loading to execution, with no security blind spots.

[0061] Consistency comparison and result judgment: The middleware compares the original hash value with the real-time hash value byte by byte, and the result is divided into two cases. The response logic fully conforms to the design principles of attachment security blocking and fault logging: If the comparison is consistent, it means that the application has not been tampered with during the process of loading from ROM to memory, the running logic is reliable, the middleware records the verification log and then terminates the verification process, the application runs normally, ensuring the reliability of subsequent ECU functions (such as tire pressure monitoring and navigation), which meets the core objective of ensuring driving safety in the appendix. Inconsistent comparison: Immediately trigger two key actions: ① Pause the currently running application (to prevent malicious logic from continuing to execute, such as preventing false tire pressure data from misleading users); ② Execute a security alarm (illuminate the fault light + report the DTC code), and at the same time write the fault type (application tampering), verification time, and hash value comparison results to the non-volatile fault log (in line with the fault log recording scheme, to prevent the tampered application from continuously affecting system security).

[0062] Secondly, an embodiment of the present invention provides a security authentication system based on software firmware on a heterogeneous system, based on the security authentication method based on software firmware on a heterogeneous system in the above-described format example, such as... Figure 2 As shown, the heterogeneous system includes a Cortex-A core running a rich operating system and a Cortex-R core running a real-time system. The system includes: The solidified storage module 210 is used to start the BootLoader program corresponding to the Cortex-R core by the BootRom solidified in the SOC chip after the SOC chip is powered on; ROM partition security is added to module 220. The BootLoader program verifies the ROM partition information stored at a fixed address in the ROM. The ROM partition information contains the storage location information of all software firmware in the heterogeneous system. If the verification fails, the SOC chip is powered down. If the verification passes, step S3 is executed. The BootLoader program loads the ROM partition information into memory; The Linux bootloader security module 230 uses the BootLoader program to obtain the storage location of the Linux system bootloader based on the ROM partition information and verifies the Linux system bootloader; if the verification passes, the Linux system bootloader is started. The A-core system secure boot module 240 is used to verify the U-boot kernel, Linux kernel, and root file system through the Linux system boot program; if the verification passes, the Linux system is booted. The A-core software secure boot module 250 is used to wake up the application after the Linux system starts up; after the Linux system load stabilizes, the middleware of the Linux system verifies the application storage partition in ROM. The R-core system secure boot module 20 is used to obtain the storage location of the Cortex-R core firmware according to the ROM partition information through the BootLoader program, and to verify the Cortex-R core firmware; if the verification is successful, the Cortex-R core firmware is booted.

[0063] Based on the same concept, this invention also provides a schematic diagram of a physical structure, such as... Figure 3 As shown, the server may include a processor 310, a communications interface 320, a memory 330, and a communication bus 340, wherein the processor 310, communications interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions in the memory 330 to execute the steps of the security authentication method based on software firmware on a heterogeneous system as described in the above embodiments.

[0064] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0065] Based on the same concept, embodiments of the present invention also provide a non-transitory computer-readable storage medium storing a computer program containing at least one piece of code that can be executed by a master control device to control the master control device to implement the steps of the security authentication method based on software firmware on a heterogeneous system as described in the above embodiments.

[0066] Based on the same technical concept, this application also provides a computer program, which, when executed by a main control device, is used to implement the above-described method embodiments.

[0067] The program may be stored, in whole or in part, on a storage medium packaged with the processor, or in part or in whole on a memory not packaged with the processor.

[0068] Based on the same technical concept, this application also provides a processor for implementing the above-described method embodiments. The processor can be a chip.

[0069] The various embodiments of the present invention can be combined arbitrarily to achieve different technical effects.

[0070] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can 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 can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can 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).

[0071] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0072] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A security authentication method based on software firmware on a heterogeneous system, wherein the heterogeneous system includes a Cortex-A core running a rich operating system and a Cortex-R core running a real-time system, characterized in that, The method includes the following steps: S1. After the SOC chip is powered on, the BootRom embedded in the SOC chip starts the BootLoader program corresponding to the Cortex-R core. S2. The BootLoader program verifies the ROM partition information stored at a fixed address in the ROM. The ROM partition information contains the storage location information of all software firmware in the heterogeneous system. If the verification fails, the SOC chip is powered off. If the verification passes, step S3 is executed. S3. The BootLoader program loads the ROM partition information into memory; S4. The BootLoader program obtains the storage location of the Linux system boot program based on the ROM partition information and verifies the Linux system boot program; if the verification passes, the Linux system boot program is started. S5. The Linux system bootloader verifies the U-boot kernel, Linux kernel, and root file system; if the verification passes, the Linux system is booted. S6. After the Linux system starts up, the application is invoked; after the Linux system load stabilizes, the middleware of the Linux system verifies the application storage partition in the ROM. S7. The BootLoader program obtains the storage location of the Cortex-R core firmware according to the ROM partition information and verifies the Cortex-R core firmware; if the verification passes, the program boots the Cortex-R core firmware.

2. The security authentication method based on software firmware on a heterogeneous system according to claim 1, characterized in that, In step S2, the BootLoader program verifies the ROM partition information by calculating the hash value of the ROM partition information to be verified and comparing it with a preset baseline hash value.

3. The security authentication method based on software firmware on a heterogeneous system according to claim 1, characterized in that, The BootROM is written to the SOC chip during the chip manufacturing stage, and the code of the BootROM cannot be modified by subsequent software. It is only automatically triggered and executed when the SOC chip is powered on.

4. The security authentication method based on software firmware on a heterogeneous system according to claim 1, characterized in that, In step S2, if the ROM partition information verification fails, the BootLoader program will also record the fault type and verification time to a preset non-volatile fault log storage area, and then control the SOC chip to power off.

5. The security authentication method based on software firmware on a heterogeneous system according to claim 4, characterized in that, In step S4, the Linux system bootloader is either an ATF bootloader or an UBoot bootloader.

6. The security authentication method based on software firmware on a heterogeneous system according to claim 1, characterized in that, It also includes OTA upgrade steps: Obtain an OTA update package, which contains new ROM partition information and a corresponding software firmware image; perform signature verification on the new ROM partition information; if the verification passes, update the original partition information and software firmware image in the ROM based on the new ROM partition information; after the update is completed, execute S1.

7. The security authentication method based on software firmware on a heterogeneous system according to claim 1, characterized in that, In step S6, the middleware of the Linux system verifies the application storage partition in the ROM, including: The middleware reads the firmware data from the application storage partition in the ROM, calculates the hash value of the firmware data, and compares it with the hash value of the currently running application; if they do not match, a security alarm is triggered.

8. A security authentication system based on software firmware on a heterogeneous system, wherein the heterogeneous system includes a Cortex-A core running a rich operating system and a Cortex-R core running a real-time system, characterized in that, The system includes: The solidified storage module is used to start the BootLoader program corresponding to the Cortex-R core by the BootRom solidified in the SOC chip after the SOC chip is powered on; The ROM partition security module verifies the ROM partition information stored at a fixed address in the ROM. The ROM partition information contains the storage location information of all software firmware in the heterogeneous system. If the verification fails, the SOC chip is powered down. If the verification passes, step S3 is executed. The BootLoader program loads the ROM partition information into memory; The Linux bootloader security module uses the BootLoader program to obtain the storage location of the Linux system bootloader based on the ROM partition information and verifies the Linux system bootloader; if the verification passes, the Linux system bootloader is started. The A-core system secure boot module is used to verify the U-boot kernel, Linux kernel, and root file system through the Linux system boot program; if the verification passes, the Linux system is booted. The A-core software secure boot module is used to launch applications after the Linux system starts up; after the Linux system load stabilizes, the middleware of the Linux system verifies the application storage partition in ROM. The R-core system secure boot module is used to obtain the storage location of the Cortex-R core firmware according to the ROM partition information through the BootLoader program, and to verify the Cortex-R core firmware; if the verification is successful, the Cortex-R core firmware is booted.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the security authentication method based on software firmware on a heterogeneous system as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the security authentication method based on software firmware on a heterogeneous system as described in any one of claims 1 to 7.

Images