Microcontroller for intelligent cabin, vehicle and identity authentication method

Abstract

The invention discloses a microcontroller for an intelligent cabin, a vehicle and an identity authentication method, and belongs to the technical field of intelligent cabins. The microcontroller comprises an application core, middleware runs in the application core, and the middleware is used for receiving a first identity authentication request and converting the first identity authentication request into a second identity authentication request in a target protocol format; the target protocol format is a data protocol format which can be identified by an operating system; the hardware security module is in communication connection with the application core, an operating system is arranged in the hardware security module, and the operating system is used for receiving the second identity authentication request and performing identity authentication on the second identity authentication request to obtain an identity authentication result; sending an identity authentication result to the middleware; the middleware is also used for sending the identity authentication result to a requester corresponding to the first identity authentication request. According to the microcontroller, the hardware cost can be reduced, and meanwhile, the safety is improved.

Description

Technical Field

[0001] This application belongs to the field of intelligent cockpit technology, specifically relating to a microcontroller, vehicle, and identity authentication method for intelligent cockpits. Background Technology

[0002] In smart cockpits, to ensure information security, a dedicated controller is typically deployed inside the vehicle. This dedicated controller, as an independent functional unit, integrates a high-security Secure Element (SE).

[0003] As a standalone security chip, the SE (Secure Controller) is responsible for core security functions. Under this architecture, all security protocol processing and sensitive data are strictly confined to this independent SE hardware environment to achieve physical-level security isolation. However, the need to add a separate controller hardware and a matching SE security chip results in significant hardware costs.

[0004] Therefore, how to provide a solution that can effectively reduce hardware costs while ensuring security is an urgent problem to be solved. Summary of the Invention

[0005] The purpose of this application is to provide a microcontroller, vehicle, and identity authentication method for a smart cockpit, which can reduce hardware costs while improving security.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a microcontroller for a smart cockpit, comprising: The application core contains middleware that receives a first authentication request and converts it into a second authentication request in a target protocol format. The target protocol format is a data protocol format that the operating system can recognize. The hardware security module communicates with the application core. The hardware security module contains an operating system, which receives the second authentication request, performs authentication on the second authentication request, obtains the authentication result, and sends the authentication result to the middleware. The middleware is also used to send the authentication result to the requester corresponding to the first authentication request.

[0007] Secondly, embodiments of this application provide a vehicle including a microcontroller as described in the first aspect above.

[0008] Thirdly, embodiments of this application provide an authentication method applied to a microcontroller as described in the first aspect above, the method comprising: The middleware receives the first authentication request and converts it into a second authentication request in a target protocol format; the target protocol format is a data protocol format that the operating system can recognize. The operating system of the hardware security module receives the second authentication request, performs authentication on the second authentication request, obtains the authentication result, and sends the authentication result to the middleware. The authentication result is sent to the requester corresponding to the first authentication request via middleware.

[0009] In this embodiment, the microcontroller for the smart cockpit includes an application core and a hardware security module communicatively connected to the application core. The application core runs middleware, and the hardware security module contains an operating system. The middleware receives a first authentication request and converts it into a second authentication request in a data protocol format recognizable by the operating system. Then, the operating system of the hardware security module receives the second authentication request, performs authentication on it, obtains an authentication result, and sends the result to the middleware. Finally, the middleware sends the authentication result to the requester corresponding to the first authentication request. By introducing an application core (with middleware running within it) and a hardware security module into the microcontroller, and by implementing an operating system within the hardware security module for authentication, the system ensures that the authentication process is executed within a protected hardware environment. This effectively prevents the risks of key leakage and authentication logic tampering, fundamentally improving the system's security level. Integrating the hardware security module into the microcontroller replaces the traditional standalone security controller solution, significantly reducing the number of external components and the complexity of the circuit board, thus lowering the system's hardware cost and physical space footprint. Through middleware protocol conversion, the middleware acts as a security isolation layer, preventing the hardware security module from being directly exposed to complex external communication environments, reducing the risk of attack. Furthermore, the middleware's protocol conversion function enables the microcontroller to adapt to various requesters with different communication protocols (such as mobile phones and cloud services supporting different standards), greatly enhancing the system's compatibility and flexibility. Attached Figure Description

[0010] Figure 1 This is a first structural schematic diagram of the microcontroller provided in the embodiments of this application.

[0011] Figure 2 This is a schematic diagram of the second structure of the microcontroller provided in the embodiments of this application.

[0012] Figure 3 This is a schematic diagram of the third structure of the microcontroller provided in the embodiments of this application.

[0013] Figure 4 This is a schematic diagram of the microcontroller performing the identity authentication process provided in the embodiments of this application.

[0014] Figure 5 This is a flowchart illustrating the identity authentication method provided in the embodiments of this application. Detailed Implementation

[0015] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0016] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0017] In smart cockpits, to ensure information security, a separate security chip (SE) is usually set up for identity authentication, which results in higher hardware costs.

[0018] To address the technical problems in related technologies, this application provides a microcontroller, vehicle, and identity authentication method for a smart cockpit. In this embodiment, the microcontroller for the smart cockpit includes an application core and a hardware security module communicatively connected to the application core. Middleware runs in the application core, receiving a first identity authentication request and converting it into a second identity authentication request in a data protocol format recognizable by the operating system. Subsequently, the operating system of the hardware security module receives the second identity authentication request, performs identity authentication on it, obtains an authentication result, and sends the authentication result to the middleware. Finally, the middleware sends the authentication result to the requester corresponding to the first identity authentication request. By introducing an application core (with middleware running within it) and a hardware security module into the microcontroller, and by implementing an operating system within the hardware security module for authentication, the system ensures that the authentication process is executed within a protected hardware environment. This effectively prevents the risks of key leakage and authentication logic tampering, fundamentally improving the system's security level. Integrating the hardware security module into the microcontroller replaces the traditional standalone security controller solution, significantly reducing the number of external components and the complexity of the circuit board, thus lowering the system's hardware cost and physical space footprint. Through middleware protocol conversion, the middleware acts as a security isolation layer, preventing the hardware security module from being directly exposed to complex external communication environments, reducing the risk of attack. Furthermore, the middleware's protocol conversion function enables the microcontroller to adapt to various requesters with different communication protocols (such as mobile phones and cloud services supporting different standards), greatly enhancing the system's compatibility and flexibility.

[0019] This application provides a microcontroller for a smart cockpit, such as... Figure 1 As shown, Figure 1 The diagram shows the first structural schematic of the microcontroller 100, which includes an application core (CPU (Central Processing Unit) core) 110 and a hardware security module (HSM) 120. The application core 110 and the hardware security module 120 are connected in communication. The application core 110 runs middleware 1101, and the hardware security module is equipped with an operating system 1201.

[0020] As an example, the application core 110 may include at least one of the following interfaces: a communication interface for communicating with external devices and networks; a communication interface for communicating with the vehicle's electronic control unit; and a communication interface for communicating with other functional modules within the microcontroller 100.

[0021] In this embodiment, the hardware security module 120 and the application core 110 exchange data via an internal bus. The internal bus is a dedicated, high-speed, internal data channel connecting the application core and the hardware security module, serving as the physical basis for efficient and secure data exchange. The MCU application core handles external interactions. The application core has multiple interfaces, including SPI (Serial Peripheral Interface), CAN (Controller Area Network) / LIN (Local Interconnect Network) for vehicle interaction, and Bluetooth (BT) and UWB (Ultra-Wide Band) for external communication.

[0022] like Figure 2 As shown, Figure 2 The diagram shows a second structural schematic of the microcontroller. In this embodiment, the operating system 1201 has multiple independent security domains, which are used to run security applications; each security domain corresponds to a security application.

[0023] For example, the operating system 1201 may include security domains a1201-1, b1201-2, c1201-3, d1201-4, and e1201-5. These security domains are isolated from each other. Correspondingly, each security domain corresponds one-to-one with a security application. For instance, security domain a1201-1 corresponds to security application a1201-11, security domain b1201-2 to security application b1201-21, security domain c1201-3 to security application c1201-31, security domain d1201-4 to security application d1201-41, and security domain e1201-5 to security application e1201-51. Each security domain has an independent key space and permission set. Keys and data from different security domains cannot be accessed by each other. Each security application can only use keys and data objects authorized by its own security domain. This arrangement of multiple independent security domains ensures secure isolation between multiple applications.

[0024] For example, taking a digital car key as an example, the security application corresponding to the security domain can be DCK applet1, DCK applet2, DCK applet3, DCK applet4, etc. For in-vehicle communication, a security domain is established, and the corresponding security application can also be an application that ensures the security of in-vehicle network communication, such as the SGA applet. The SGA applet is used to implement communication security for the in-vehicle BCM (Body Control Module) and IVI (In-Vehicle Infotainment System), verifying the message source through CMAC and preventing replay attacks through Freashvaue.

[0025] It should be noted that the lifecycle and permission management of multiple security applications follow a standardized lifecycle of "loading → installing → selecting / enabling → updating → deleting". Installation / updates must be performed through a secure channel and signed / authenticated by a security domain to prevent unauthorized tampering. Communication between multiple security domains and multiple security applications and external devices or the cloud is based on a secure channel protocol. Commands and data are transmitted encrypted / authenticated to prevent eavesdropping and replay attacks.

[0026] By creating multiple independent security domains within the operating system of the hardware security module HSM, each security domain can run different security applications (supporting different protocols) and the secure communication application SGA Applet, thus solving the problem that the hardware security module HSM cannot implement multiple applications.

[0027] To further enhance the security of data access, as an example, such as Figure 3 As shown, Figure 3 A third structural diagram of a microcontroller is shown. The microcontroller 100 includes a memory storage 130 and a control unit 140. The application core 110 and the hardware security module 120 share the memory storage 130. The memory storage 130 includes a secure storage area 1301 dedicated to the hardware security module.

[0028] It should be noted that both the application core 110 and the hardware security module 120 can access the memory storage 130 (Flash). To ensure access security, only one of the application core 110 and the hardware security module 120 is allowed to access the memory at any given time. Taking the hardware security module 120 as an example, the control unit 140 is used to control the hardware security module 120 to start first, and then control the application core 110 to start, when the microcontroller 100 starts. At the same time, a secure boot mechanism is used to ensure that if the hardware security module is tampered with during boot, it can be detected. The hardware security module 120 is also used to configure the access permissions of the secure storage area 1301, which is assigned to the secure storage area 1301 of the hardware security module 120. Before the application core 110 starts, the access permission configuration for the secure storage area 1301 is locked; after the application core 110 starts, access to the secure storage area 1301 by the application core 110 is prevented, thereby preventing the application core 110 from accessing the secure storage area 1301 of the hardware security module 120 after booting.

[0029] By enabling the hardware security module to start first and lock the secure storage area permissions, the sharing of the secure storage area between the hardware security module and the application is realized, further enhancing the system's security.

[0030] In this embodiment, the microcontroller 100 can further divide the security domain into different roles, with different permission sets for each role. Through clear permission division, the confidentiality, integrity, and availability of applications, data, and resources within the security chip are ensured. For example, multiple independent security domains may include: a developer security domain and at least one function provider security domain.

[0031] The developer security domain is configured to have the highest privileges among multiple independent security domains. The developer security domain's privileges include at least one of the following: creating or deleting other security domains, loading or deleting any security applications within the security chip, generating or distributing global keys, and allocating global storage resources. At least one feature provider security domain, created by the developer security domain and with privileges restricted by the developer security domain, is used to manage at least one of its own security applications.

[0032] The developer's security domain is the "root security domain" of the chip, possessing the highest privileges and responsible for creating other security domains and allocating global resources. For example, the developer's security domain can allocate storage space and keys to various digital key issuers, including the following permissions: 1) Security domain lifecycle management: Create security domain (Create SD), Delete security domain (Delete SD), Disable / Enable security domain (Disable / Enable SD), Update security domain key.

[0033] 2) All application lifecycle management: Load Applet, Install Applet, Register Applet, Delete Applet, Pause / Resume Applet.

[0034] 3) Key and Security Management: Generate / Import / Export Keys, Distribute Keys (e.g., distributing session keys to applications), Update / Destroy Keys, Establish Secure Channel (e.g., encrypted communication with external terminals), and Authenticate Privileges (e.g., verifying whether a terminal has the right to operate).

[0035] 4) Global resource allocation and management: Allocate memory (e.g., allocate data area for applications), allocate logical channels (e.g., for communication between applications and terminals), and monitor resource usage (e.g., to prevent memory overflow).

[0036] As an example, the feature provider security domain is the digital key issuer security domain, configured to run at least one digital car key application; the feature provider security domain's permissions include managing its own security applications, keys, and allocated resources.

[0037] In this embodiment, the digital key issuer's security domain is created by the developer's security domain and only manages its own applications and data. Its permissions are restricted by the developer's security domain. For example, each digital key issuer loads a digital key application (e.g., DCK APPLET1) to distribute and manage its digital keys, establishing a secure channel for communication with terminals or in-vehicle systems. It can only access and manage its own application data, including the following permissions: 1) Self-created application lifecycle management (controlling the entire process of an application within the chip "from loading to deletion" to prevent unauthorized applications from running): Load Applet, Install Applet, Register Applet, Delete Applet, Pause / Resume Applet.

[0038] 2) Self-key and security management (ensuring data transmission and storage security; keys are the "core credentials" for security domain access control): Generate / Import / Export Keys, Distribute Keys (e.g., distributing session keys to applications), Update / Destroy Keys, Establish Secure Channel (e.g., encrypted communication with external terminals), Authenticate Privileges (e.g., verifying whether a terminal has the right to operate).

[0039] 3) Resource allocation and management (avoiding resource abuse and ensuring orderly allocation of resources such as chip storage and communication channels): Allocate memory (e.g., allocate data area for applications), allocate logical channels (e.g., for communication between applications and terminals), and monitor resource usage (e.g., to prevent memory overflow).

[0040] 4) Data access and control (preventing sensitive data (such as user identity and transaction information) from being read or tampered with without authorization): Read / Write SD Data, Read / Write AppData (allowing only authorized applications to access), Encrypt / Decrypt Data (protecting sensitive data).

[0041] By physically isolating the highest-privilege developer security domain from the security domains of specific business function providers, the system's "root" security is ensured to be unaffected by security risks inherent in specific applications. Even if a function provider's security domain is compromised, attackers cannot steal keys from other security domains or tamper with their applications, nor can they gain root privileges such as creating or deleting security domains. Furthermore, the permissions of the function provider's security domain are strictly limited to its own business scope, adhering to the principle of "minimum privileges," effectively curbing the lateral spread of potential security incidents, achieving deep security isolation and minimization of privileges, and greatly enhancing the overall security of the system. Simultaneously, this architecture clearly defines the management boundaries of each party: the developer security domain is responsible for the management of the underlying platform and global resources; the function provider security domain is independently responsible for its own applications and keys. This constructs a clear and efficient collaborative management architecture, greatly improving the system's maintainability, flexibility, and management efficiency.

[0042] The above is an overall description of the microcontroller structure. Based on the microcontroller described above, this application embodiment also provides an identity authentication method.

[0043] Figure 4 The diagram illustrates the authentication process performed by the microcontroller. First, in step S210, the requester 200 sends a first authentication request to the middleware 1101. For example, the requester can be an external device, such as a mobile phone, or the cloud. Then, in step S220, the middleware 1101 receives the first authentication request and converts it into a second authentication request in a target protocol format; the target protocol format is a data protocol format that the operating system can recognize.

[0044] In this embodiment, the middleware 1101 receives a first authentication request sent by the requester (e.g., the cloud). The data protocol format of the first authentication request is usually JSON (JavaScript Object Notation) or other existing formats. However, the operating system 1201 cannot recognize the above-mentioned JSON format. The format that the operating system 1201 can recognize is APDU (Application Protocol Data Unit) instruction format. Therefore, after receiving the first authentication request, the middleware 1101 needs to convert the first authentication request into a second authentication request in the target protocol format, which is the APDU format.

[0045] It should be noted that when the requester is the cloud, the cloud first sends the first authentication request to the T-Box (Telematics Box). After receiving the first authentication request, the T-Box then sends it to the middleware 1101. When the requester is an external device, such as a mobile phone, the mobile phone can directly send the first authentication request to the middleware 1101. After the middleware 1101 converts the first authentication request into a second authentication request in the target protocol format, it executes S230 and sends the second authentication request to the operating system 1201.

[0046] It should be noted that when the operating system 1201 interacts with the cloud, the middleware 1101 needs to perform APDU format conversion. When the operating system 1201 interacts with external devices, such as mobile devices, the middleware 1101 also needs to perform APDU format conversion. That is, the middleware 1101 needs to convert other formats of instructions sent by external devices into APDU format, and then send the converted instructions to the operating system 1201.

[0047] Then, S240 and operating system 1201 are executed to receive the second identity authentication request, and the second identity authentication request is authenticated to obtain the identity authentication result.

[0048] Then, S250 and operating system 1201 are executed to send the authentication result to middleware 1101.

[0049] Then, S260 is executed and middleware 1101 sends the authentication result to the requester 200.

[0050] Then, in step S270, if the authentication result is successful, the requester 200 sends a vehicle control command to the middleware 1101. For example, the vehicle control command could be unlocking the vehicle or starting the vehicle engine, etc.

[0051] Then, S280 is executed and the middleware 1101 sends the vehicle control command to the vehicle actuator controller 300.

[0052] Then, S290 is executed and the vehicle actuator controller 300 executes the vehicle control command.

[0053] It should be noted that the requester 200 can recognize JSON or other formats. When the middleware 1101 sends the authentication result to the requester 200, it also needs to convert the data protocol format of the authentication result APDU into a format that the requester can recognize.

[0054] For example, if the authentication result is successful, the requester 200 sends a vehicle control command to the middleware 1101. Upon receiving the vehicle control command, the middleware 1101 transmits it to the vehicle actuator controller via the CAN bus, according to the command content. For instance, if the control command is "unlock the door," the middleware 1101 sends the command to the body control module (BCM). If the control command is "start the engine," the middleware 1101 sends the command to the engine control unit (ECU) or the relevant domain controller. If the control command is "turn on the air conditioning," the middleware 1101 sends the command to the HVAC (air conditioning) controller. If the authentication result indicates authentication failure, the authentication request can be terminated and an error message returned.

[0055] In this embodiment of the application, the middleware 1101 is further configured to parse the first identity authentication request to obtain the request source of the first identity authentication request; based on the request source, determine the target security application corresponding to the request source; and send the second identity authentication request with the target protocol format corresponding to the first identity authentication request to the target security application.

[0056] As an example, when middleware 1101 determines the target security application corresponding to the request source based on the request source, it can obtain a mapping table between the request source, protocol type, and security application, and determine the target security application corresponding to the request source based on the mapping table and the request source.

[0057] It should be noted that different request sources correspond to different protocol types, and different protocol types correspond to different security applications. Taking digital car key authentication as an example, the protocol types corresponding to different request sources can be CCC protocol (CarConnectivity Consortium (CCC) Digital Key), ICCE protocol (Intelligent Car-Connectivity Ecosystem (Alliance), ICCOA protocol (Intelligent Connected Car Open Alliance), or N / A (OEM-Proprietary Protocol). Based on the request source, the target security application corresponding to the request source is determined. Specifically, it can be based on the protocol type corresponding to the request source, such as the CCC protocol, to determine the corresponding target security application. For example, after middleware 1101 parses the first identity authentication request, the protocol corresponding to the request source is the CCC protocol, and the target security application corresponding to the CCC protocol is security application 1. Then, middleware 1101 will send the second identity authentication request with the target protocol format corresponding to the first identity authentication request to the target security application, i.e., security application 1.

[0058] In this embodiment, to further improve the performance of the hardware security module, a security strategy is provided by embedding an operating system (COS software), mainly involving the following aspects: software security policy settings, encrypted storage of sensitive data, authentication during external communication, data encryption, operation log auditing, abnormal behavior detection, and secure OTA, etc. For example, resistance to side-channel attacks and fault injection is addressed using algorithms to improve the overall security level. I. Software Improvements for Side-Channel Attacks (SCA) The essence of side-channel attacks is to infer sensitive data (such as encryption keys) by using physical information (such as power consumption, timing, electromagnetic radiation, cache hits / misses) leaked during hardware execution. The core of software improvement is to "eliminate the correlation between sensitive operations and physical information".

[0059] 1. Resistance to power analysis attacks (such as DPA and CPA) Power consumption analysis is the most common side-channel attack. Software weakens the attack conditions by "balancing power consumption characteristics" or "hiding sensitive operations." 1) Algorithm-level optimization: Masking technique By performing an XOR / arithmetic operation on sensitive data (such as AES keys) and a randomly generated "mask value," the intermediate results of each execution are randomized—even if an attacker collects the power consumption curve, they cannot deduce the data from the pattern of "the same input corresponds to the same power consumption."

[0060] For example, in AES encryption, a "first-order mask" (basic) or a "higher-order mask" (more secure, but with higher performance overhead) is applied to the plaintext, key, and intermediate values ​​of the round function to ensure that power consumption changes are only related to the random mask and not to the real sensitive data.

[0061] 2) Code-level optimization: Power Balancing The instruction sequence for sensitive operations is "symmetrically modified" to ensure that the number and type of instructions executed (such as arithmetic operations and memory accesses) are completely consistent regardless of whether the input data is 0 or 1, thereby avoiding the correlation between "data differences and power consumption differences" from the root.

[0062] For example, in a traditional conditional branch (if (x==0) {A} else {B}), the different instructions for A and B can lead to power consumption differences. This can be changed to "branchless execution" (e.g., tmp = (x==0); res = tmp*A + (1-tmp)*B), which forces both instructions for A and B to be executed, hiding the differences only through the result selection.

[0063] 3) Dynamic power consumption suppression During sensitive operations (such as encryption and key verification), the voltage / frequency can be dynamically adjusted by calling the hardware interface (such as the CPU's power management module) through software, or random "no-ops (NOPs)" can be inserted to make the power consumption curve "smooth" and mask the power consumption characteristics of the sensitive operation.

[0064] 2. Resistance to Timing Attacks Timing attacks exploit the differences in code execution time corresponding to different inputs to infer data (such as Flush+Reload and Prime+Probe in caching attacks). The core of software defense is to "eliminate the correlation between execution time and sensitive data." 1) Cache attack defense: Cache Coloring By statically allocating memory / code to the CPU cache using fixed "color groups" (based on cache line address mapping rules), it ensures that sensitive operations (such as encryption algorithms) are always mapped to independent cache lines, avoiding sharing cache resources with other applications, thereby blocking the leakage path of "cache hit / miss → timing difference".

[0065] 2) Constant-Time Execution (CTE) Refactor sensitive code logic to ensure that the number of instructions executed and the number of memory accesses remain exactly the same regardless of how the input data changes, thus keeping the execution time constant.

[0066] For example, the traditional "bitwise key comparison" (for (i=0; i<16; i++) if (key[i] != input[i]) return 0;) will return prematurely when the first mismatched bit occurs, causing execution time differences. Instead, it is changed to "full bit comparison and result judgment" (int diff=0; for (i=0; i<16; i++) diff |= (key[i]^input[i]); return(diff==0);), which ensures that all loops are executed regardless of which bit is mismatched, eliminating timing differences.

[0067] 3) Temporal randomization Inserting "controllable random delays" (such as NOP sequences based on hardware random number generators) into sensitive operations adds random noise to the execution time, making it impossible for attackers to extract the temporal patterns related to sensitive data through multiple samplings.

[0068] 3. Electromagnetic Analysis (EMA) Protection Electromagnetic radiation is directly related to power consumption (changes in current generate electromagnetic fields). Software defense strategies are similar to those against power consumption attacks: by using masking techniques, execution logic balancing, random delays, etc., the intensity and frequency changes of electromagnetic radiation are decoupled from sensitive data, reducing the possibility of attackers inferring data through electromagnetic signals.

[0069] II. Software Improvements to Counter Fault Injection Attacks (FIA) The essence of fault injection attacks is to force hardware to produce errors (such as register value flips or instruction jumps) through physical means (such as voltage glitches, clock disturbances, and laser irradiation), thereby bypassing security checks (such as signature verification and permission checks) or stealing sensitive data. The core of software improvement is "detecting faults, blocking fault exploitation, and restoring correct execution".

[0070] 1. Fault Detection: Abnormal execution status detected. By employing software redundancy or verification mechanisms, the execution process can be monitored in real time to detect any deviations from expectations and promptly identify potential fault injections. 1) Data redundancy check Calculate "redundant check codes" (such as CRC, hash value, parity check) for sensitive data (such as keys, encryption results, status register values) and re-verify them at critical nodes (such as after encryption and before signature verification). If a fault causes data tampering and the check codes do not match, an exception is triggered (such as terminating the program or clearing sensitive data).

[0071] For example, in the secure boot process, the software calculates the SHA-256 hash of the loaded firmware and compares it with a pre-stored "trusted hash value". If a fault causes the firmware to be tampered with, the hash verification fails and boot is refused.

[0072] 2) Command Flow Monitoring Insert an "execution path checkpoint" to ensure the program runs according to the preset logic: For example, insert an assertion (assert(current_mode == secure_mode)) after a conditional branch (such as if (auth_ok) {enter_secure_mode;}). If a failure causes "entering secure mode without authentication", the assertion will trigger an exception. A more complex implementation is "Control-Flow Integrity (CFI)": The software statically generates a "legitimate control flow graph" (such as function call relationships and jump targets), and verifies at runtime whether each function call / jump is within the legitimate range through instrumentation code. If a fault causes a jump to an illegal address (such as malicious code injected by an attack), execution is terminated immediately.

[0073] 3) Time threshold detection Set a "maximum execution time threshold" for sensitive operations (such as key decryption and signature verification). If a fault causes the execution to get stuck in an infinite loop or abnormally delayed (such as clock disturbances slowing down instruction execution), the software timer will trigger a timeout interrupt, forcibly terminating the operation and clearing sensitive data.

[0074] 2. Fault Recovery: Minimizing the Impact of Faults Even if a fault is detected, the software must use "state recovery" to prevent the system from falling into an unsafe state: 1) Snapshots and Rollbacks Before sensitive operations (such as the start of a secure transaction), the software creates a "snapshot" of critical registers and memory areas (such as transaction amount and user permissions); if a fault is detected, the system state is immediately restored from the snapshot to ensure that the fault does not spread to subsequent processes.

[0075] 2) Multiple copies of execution and voting The core security logic (such as key verification) is implemented in software as "multi-copy parallel execution" (such as executing the same logic 3 times in different threads or different time slices), and finally the results of the 3 executions are "majority vote" - if a single copy produces an error due to a fault, the majority of correct results can cover up the error and ensure that the output is correct.

[0076] 3. Fault Exploitation Blocking: Eliminate logical vulnerabilities that could be exploited by faults. Through software design, even if fault injection is successful, the attack target cannot be achieved: 1) Sensitive operations are "atomicized". Design security-critical operations (such as "verify signature → grant permissions") as "atomic steps," meaning they must either be fully executed or not executed at all, to prevent faults from causing "partial execution" (such as granting permissions without verifying the signature). For example, use software locks or status flags to ensure that the "permission flag" is only modified after signature verification, and that the modification operation is a single instruction (such as the CPU's atomic operation instruction cmpxchg), reducing opportunities for fault injection.

[0077] 2) Redundant permission check Instead of checking only at the entry point, permission checks are performed repeatedly at multiple code nodes. For example, even if a failure causes "entry point permission checks to be skipped," subsequent access to sensitive resources (such as reading keys) will still be subject to permission checks again, thus blocking attack paths.

[0078] In this embodiment, the microcontroller for the smart cockpit includes an application core and a hardware security module communicatively connected to the application core. The application core runs middleware, and the hardware security module contains an operating system. The middleware receives a first authentication request and converts it into a second authentication request in a data protocol format recognizable by the operating system. Then, the operating system of the hardware security module receives the second authentication request, performs authentication on it, obtains an authentication result, and sends the result to the middleware. Finally, the middleware sends the authentication result to the requester corresponding to the first authentication request. By introducing an application core (with middleware running within it) and a hardware security module into the microcontroller, and with the operating system integrated into the hardware security module for authentication, the system ensures that the authentication process is executed within a protected hardware environment. This effectively prevents the risks of key leakage and authentication logic tampering, fundamentally improving the system's security level. Integrating the hardware security module into the microcontroller replaces the traditional standalone security controller solution, significantly reducing the number of external components and the complexity of the circuit board, thus lowering the system's hardware cost and physical space footprint. Through middleware protocol conversion, the middleware acts as a security isolation layer, preventing the hardware security module from being directly exposed to complex external communication environments, reducing the risk of attack. Furthermore, the middleware's protocol conversion function enables the microcontroller to adapt to various requesters with different communication protocols (such as mobile phones and cloud services supporting different standards), greatly enhancing the system's compatibility and flexibility.

[0079] Based on the microcontroller described above, this application also provides an authentication method. Figure 5 A flowchart of the identity authentication method provided in an embodiment of this application is shown.

[0080] S510: Receive the first authentication request through middleware and convert the first authentication request into a second authentication request in a target protocol format; the target protocol format is a data protocol format that the operating system can recognize. S520: Receives the second authentication request through the operating system of the hardware security module, performs authentication on the second authentication request, obtains the authentication result, and sends the authentication result to the middleware. S530: Send the authentication result to the requester corresponding to the first authentication request through the middleware.

[0081] As one embodiment, the operating system has multiple independent security domains, each used to run secure applications; each security domain corresponds one-to-one with a secure application; the method further includes: The middleware parses the first authentication request to obtain the request source; based on the request source, it determines the target security application corresponding to the request source; and sends the second authentication request with the target protocol format corresponding to the first authentication request to the target security application. The target security application performs identity authentication based on a second identity authentication request, and obtains the authentication result.

[0082] As one embodiment, if the identity authentication result is successful, the middleware receives the vehicle control command sent by the requester and sends the vehicle control command to the vehicle actuator controller so that the vehicle actuator controller executes the vehicle control command.

[0083] Based on the microcontroller described above, this application also provides a vehicle.

[0084] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0085] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0086] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0087] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0088] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A microcontroller for a smart cockpit, characterized in that, include: An application core, in which middleware runs, the middleware is used to receive a first identity authentication request and convert the first identity authentication request into a second identity authentication request in a target protocol format; The target protocol format is a data protocol format that the operating system can recognize; A hardware security module is communicatively connected to the application core. The hardware security module contains the operating system, which is used to receive the second identity authentication request, perform identity authentication on the second identity authentication request, and obtain the identity authentication result. And send the authentication result to the middleware; The middleware is also used to send the authentication result to the requester corresponding to the first authentication request.

2. The microcontroller according to claim 1, characterized in that, The operating system has multiple independent security domains, which are used to run security applications; each security domain corresponds to a security application. The middleware is also used to parse the first identity authentication request to obtain the request source of the first identity authentication request; Based on the source of the request, determine the target security application corresponding to the source of the request; Send the second authentication request, which has the target protocol format, corresponding to the first authentication request, to the target security application; The target security application is used to perform identity authentication based on the second identity authentication request and obtain the identity authentication result.

3. The microcontroller according to claim 2, characterized in that, The multiple independent security domains include: The developer security domain is configured to have the highest privileges among the plurality of independent security domains, and the privileges of the developer security domain include at least one of the following: creating or deleting other security domains, loading or deleting any security applications within the security chip, generating or distributing global keys, and allocating global storage resources; At least one feature provider security domain, created by the developer security domain and with permissions restricted by the developer security domain, is used to manage at least one security application dedicated to it.

4. The microcontroller according to claim 3, characterized in that, The security domain of the function provider is the security domain of the digital key issuer, and is configured to run at least one digital car key application; the permissions of the security domain of the function provider include managing its own security applications, keys and allocated resources.

5. The microcontroller according to claim 1, characterized in that, The middleware is also used for: If the identity authentication result is successful, the system receives the vehicle control command sent by the requester and sends the vehicle control command to the vehicle actuator controller so that the vehicle actuator controller executes the vehicle control command.

6. The microcontroller according to claim 1, characterized in that, The microcontroller includes a memory storage and a control unit, and the application core shares the memory storage with the hardware security module; the memory storage includes a secure storage area dedicated to the hardware security module. The control unit is used to control the hardware security module to start first, and then control the application core to start, when the microcontroller starts. The hardware security module is also used to configure access permissions for the secure storage area; lock the access permission configuration for the secure storage area before starting the application core; and prevent the application core from accessing the secure storage area after starting the application core.

7. The microcontroller according to any one of claims 1-6, characterized in that, The application core includes at least one of the following interfaces: Communication interface for communicating with external devices and networks; Communication interface for communicating with the vehicle's electronic control unit; The communication interface for communicating with other functional modules inside the microcontroller.

8. A vehicle, characterized in that, Including the microcontroller as described in any one of claims 1-7.

9. An identity authentication method, characterized in that, Applied to the microcontroller according to any one of claims 1-7, the method comprises: The middleware receives a first authentication request and converts it into a second authentication request in a target protocol format; the target protocol format is a data protocol format that the operating system can recognize. The operating system of the hardware security module receives the second identity authentication request, performs identity authentication on the second identity authentication request, obtains the identity authentication result, and sends the identity authentication result to the middleware. The middleware sends the authentication result to the requester corresponding to the first authentication request.

10. The method according to claim 9, characterized in that, The operating system has multiple independent security domains, which are used to run secure applications. The security domain corresponds one-to-one with the security application; the method further includes: The middleware parses the first authentication request to obtain the request source of the first authentication request; based on the request source, it determines the target security application corresponding to the request source; and sends the second authentication request with the target protocol format corresponding to the first authentication request to the target security application. The target security application performs identity authentication based on the second identity authentication request to obtain the identity authentication result.

11. The method according to claim 9, characterized in that, The method further includes: If the identity authentication result is successful, the middleware receives the vehicle control command sent by the requester and sends the vehicle control command to the vehicle actuator controller so that the vehicle actuator controller executes the vehicle control command.

Images