Security authentication method and device of vehicle-mounted equipment, electronic equipment and storage medium

Abstract

The invention relates to a safety certification method and device of vehicle-mounted equipment, electronic equipment and a storage medium, and the safety certification method of the vehicle-mounted equipment is applied to a vehicle-mounted domain controller integrated with an HSM. The SOC generates a security service request containing to-be-processed data and an operation instruction according to the digital certificate and the identity authentication operation, and sends the security service request to the MCU; and the MCU receives and analyzes the security service request to obtain to-be-processed data and an operation instruction, and calls the HSM, and the HSM executes identity authentication type cryptographic operation on the to-be-processed data according to the private key and the operation instruction, and returns an operation result to the SOC. The HSM integrated in the vehicle-mounted domain controller realizes a security authentication function without externally hanging a special security chip, and the private key is always stored in the HSM and is not exported, so that the security of the vehicle identity key is ensured.

Description

Technical Field

[0001] This invention relates to the field of electronic equipment technology, and more specifically to a security authentication method, apparatus, electronic device, and storage medium for vehicle-mounted equipment. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, intelligent connected vehicles, while bringing convenience, also face increasingly severe information security challenges. The openness of the internet allows traditional internet security threats to extend into the automotive field, with frequent hacking and attacks targeting in-vehicle infotainment systems, seriously threatening driving safety and user privacy. As a key hub in the V2X network, in-vehicle infotainment systems urgently need to possess high-level security protection capabilities.

[0003] Currently, mainstream solutions rely on external dedicated secure element (SE) chips to implement encryption and security authentication functions. However, this type of solution suffers from high hardware costs, large PCB space requirements, and high risk of exposing critical chip pins, which is detrimental to system integration and security improvement. Summary of the Invention

[0004] This invention provides a security authentication method, device, electronic device, and storage medium for vehicle-mounted equipment, in order to solve the problems of high cost, low integration, and high hardware security risks caused by the reliance on external security chips in existing technologies.

[0005] In a first aspect, the present invention provides a secure authentication method for an in-vehicle device, applied to an in-vehicle domain controller, wherein the in-vehicle domain controller includes a main control chip (SOC) and a microcontroller unit (MCU) integrating a hardware security module (HSM), and the private key used for vehicle identification is stored in the HSM; the secure authentication method for the in-vehicle device includes: when the in-vehicle domain controller needs to perform a vehicle identification operation, the SOC generates a security service request containing data to be processed and operation instructions based on a digital certificate and the identification operation, and sends the security service request to the MCU; the MCU receives and parses the security service request, obtains the data to be processed and operation instructions, calls the HSM, the HSM performs an identification-type cryptographic operation on the data to be processed based on the private key and operation instructions, and returns the operation result to the SOC; wherein the identification-type cryptographic operation includes at least one of: digital signature, signature verification, message authentication code generation, message authentication code verification, and challenge-response calculation.

[0006] This invention reuses the HSM already integrated in the vehicle domain controller to implement the security authentication function, eliminating the need for an external dedicated security chip. This effectively reduces hardware costs and PCB space usage, avoids the risk of exposing critical pins, and improves system integration and hardware security. At the same time, the private key is always stored inside the HSM and is not exported, ensuring the security of the vehicle identity key. Combined with the collaborative mechanism of SOC and MCU, it achieves efficient and reliable identity authentication, enhancing the ability of vehicle devices to resist network attacks and unauthorized access.

[0007] In an optional implementation, when the authentication operation is HTTPS two-way authentication between the vehicle domain controller and the vehicle network backend, before the SOC generates a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation, the method further includes: a first cryptographic middleware running in the SOC software environment intercepting the first protocol digest negotiated and generated by the vehicle domain controller and the vehicle network backend during the TLS handshake phase of HTTPS two-way authentication, and encapsulating the first protocol digest as the data to be processed into a first signature request; wherein, the first cryptographic middleware is configured not to perform cryptographic operations involving private keys during HTTPS two-way authentication; the first signature request is sent to a first security proxy service running in the SOC; the first security proxy service extracts the data to be processed from the first signature request, so that the SOC can generate a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation; after the HSM performs digital signature on the data to be processed and returns the operation result to the SOC, the first security proxy service receives the operation result and returns the operation result to the first cryptographic middleware, so that the first cryptographic middleware submits the operation result as the client authentication credential to the TLS protocol stack to complete HTTPS two-way authentication.

[0008] This implementation achieves secure isolation and transparent proxying of signature operations during HTTPS two-way authentication by deploying a first cryptographic middleware and a first security proxy service in the SOC. This ensures that sensitive private key calculations are completed entirely within the HSM, avoiding the risk of the private key being exposed on the SOC side. Simultaneously, the middleware is only responsible for intercepting protocol data and sending back results, without participating in actual cryptographic calculations, reducing the security requirements of the SOC software environment and improving system maintainability and compatibility. The entire process is seamlessly integrated into the standard TLS handshake process, achieving high-security vehicle communication identity authentication without modifying upper-layer application logic. This effectively prevents man-in-the-middle attacks and identity impersonation, ensuring the confidentiality and integrity of vehicle network communication.

[0009] In one optional implementation, when the authentication operation is HTTPS two-way authentication between the wireless communication module and the vehicle network backend, before the SOC generates a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation, the method further includes: a second cryptographic library running in the wireless communication module intercepting the second protocol digest negotiated between the wireless communication module and the vehicle network backend during the TLS handshake phase of HTTPS two-way authentication, and encapsulating the second protocol digest as the data to be processed into a second signature request; wherein, the second cryptographic library is configured not to perform cryptographic operations involving private keys in HTTPS two-way authentication; the second signature request is sent to a second security proxy service running in the wireless communication module; the second security proxy service extracts the data to be processed from the second signature request, so that the SOC can generate a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation; after the HSM performs digital signature on the data to be processed and returns the operation result to the SOC, the SOC forwards the operation result to the second security proxy service, which then passes it to the second cryptographic library; the second cryptographic library receives the operation result and submits it as the client authentication credential to the TLS protocol stack to complete HTTPS two-way authentication.

[0010] This implementation deploys a second cryptographic library and a second security proxy service within the wireless communication module, achieving localization and security decoupling of wireless communication link authentication. This ensures that the signature operation in HTTPS two-way authentication is still securely executed by the HSM, and the private key does not need to leave the security boundary, effectively preventing the risk of key leakage. Simultaneously, the wireless communication module is only responsible for intercepting the protocol digest and submitting the authentication credentials, without participating in private key calculations, reducing the security requirements for the communication module and improving the overall deployability and compatibility of the system. This solution fully utilizes the security capabilities of the vehicle domain controller to achieve cross-chip secure authentication collaboration, ensuring both the confidentiality and trustworthiness of vehicle network communication, while avoiding the complex architecture of external security chips, thus enhancing system integration and anti-attack capabilities.

[0011] In one optional implementation, a digital certificate containing the public key is stored in the main control chip. The security authentication method for the vehicle-mounted device further includes the following steps: after the MCU is powered on, the HSM loads the first-level boot code and uses the verification public key pre-embedded in the HSM to digitally sign and verify the first-level boot code to confirm its integrity and authenticity; after successful verification, the first-level boot code is executed, wherein the first-level boot code acts as a bootloader; during the execution of the bootloader, the bootloader performs digital signature verification on the second-level boot code to confirm its integrity and authenticity, and after successful verification, loads and executes the second-level boot code, wherein the second-level boot code acts as the MCU system program or its loader; after the second-level boot code is loaded, the second-level boot code initializes the MCU operating environment and starts system services to enter a normal working state; wherein the verification public key and private key belong to the same asymmetric key pair, or are independently pre-set trusted root public keys.

[0012] This implementation method constructs a trusted boot chain based on HSM, achieving step-by-step security verification from the first-level boot code to the MCU system program. This ensures that the firmware at each stage comes from a trusted source and has not been tampered with, effectively preventing malicious code injection and firmware flashing attacks. The verification public key is embedded in the HSM, providing hardware-level protection and enhancing the security strength of the root trust. The entire boot process forms a complete trust transfer mechanism, laying a trusted foundation for subsequent security authentication and system operation, and significantly enhancing the overall security and anti-attack capabilities of the vehicle equipment.

[0013] In one optional implementation, the security authentication method for the vehicle-mounted device further includes the following steps: after the vehicle domain controller is powered on and the MCU enters normal operating mode, the HSM generates a temporary key pair that is only valid for this startup, including a virtual private key and a virtual public key, wherein the virtual private key is securely stored inside the HSM and is not allowed to be exported; the HSM sends the virtual public key to the SOC; the SOC receives and stores the virtual public key; in subsequent communications, when the SOC needs to respond to an external authentication challenge, it constructs an identity statement based on the virtual public key, encapsulates the data to be signed into a signature request, and sends it to the MCU to initiate the signature process completed by the HSM.

[0014] This implementation achieves session-level isolation and forward security for vehicle identity authentication by dynamically generating a temporary key pair valid only for that specific session during each startup and strictly restricting the use of the virtual private key within the HSM, never exporting it. The SOC only receives and stores the virtual public key for constructing identity claims and initiates a security request when a signature is required. The HSM performs the private key calculation, effectively avoiding the direct exposure and frequent use of long-term identity private keys in communication. Even if the temporary key of a certain session is cracked in the future, it is impossible to deduce other sessions or long-term keys, significantly improving the system's ability to resist key leakage risks and enhancing the security protection level of in-vehicle equipment against long-term eavesdropping and replay attacks in open network environments.

[0015] In one optional implementation, the security authentication method for the vehicle-mounted device further includes the following steps: during the startup process of the vehicle domain controller, the MCU verifies the legitimacy of the device identity certificate stored in the SOC and verifies whether the HSM holds a private key that matches the public key contained in the device identity certificate through a challenge response mechanism; if the verification result is successful, the SOC configures the network communication module to enable simultaneous access to the first type of access point network and the second type of access point network; if the verification result is unsuccessful, the SOC configures the network communication module to only access the first type of access point network and prohibits access to the second type of access point network; wherein, the first type of access point network is used to connect to the controlled intranet service endpoint, and the second type of access point network is used to connect to the public network service endpoint.

[0016] This implementation achieves trusted confirmation and hardware-level binding of device identity by having the MCU verify the legitimacy of the device identity certificate in the SOC during the startup phase, and by combining a challenge response mechanism to verify the authenticity of the private key in the HSM. This effectively prevents unauthorized access caused by forged certificates or missing keys. Based on the verification results, network access policies are dynamically configured to ensure that access to the public network is only allowed when identity authentication is successful (second type of access point). Otherwise, access is restricted to the controlled internal network only (first type of access point). This constructs a defense-in-depth mechanism of "opening the network only after security and trust," which significantly reduces the security risk of vehicles being exposed to the public network when their identity is abnormal or tampered with, and improves the overall security and controllability of vehicle-to-everything (V2X) communication.

[0017] Secondly, the present invention provides a security authentication device for an in-vehicle device, applied to an in-vehicle domain controller, wherein the in-vehicle domain controller includes a main control chip (SOC) and a microcontroller unit (MCU) integrating a hardware security module (HSM), and the private key used for vehicle identification is stored in the HSM, and a digital certificate containing the public key is stored in the SOC; the security authentication device for the in-vehicle device includes a first processing module and a second processing module; the first processing module is used to generate a security service request containing data to be processed and operation instructions based on the digital certificate and the identity authentication operation when the in-vehicle domain controller needs to perform vehicle identity authentication operation, and send the security service request to the MCU; the second processing module is used to receive and parse the security service request, obtain the data to be processed and operation instructions, call the HSM, the HSM performs identity authentication cryptographic operations on the data to be processed based on the private key and operation instructions, and returns the operation result to the SOC; wherein the identity authentication cryptographic operations include at least one of: digital signature, signature verification, message authentication code generation, message authentication code verification, and challenge response calculation.

[0018] Thirdly, the present invention provides an electronic device, comprising: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the security authentication method of the vehicle-mounted device described in the first aspect or any corresponding embodiment thereof.

[0019] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to execute the security authentication method for an in-vehicle device according to the first aspect or any corresponding embodiment thereof.

[0020] Fifthly, the present invention provides a computer program product, including computer instructions, which are used to cause a computer to execute the security authentication method for an in-vehicle device according to the first aspect or any corresponding embodiment described above. Attached Figure Description

[0021] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific 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 from these drawings without creative effort.

[0022] Figure 1 This is a block diagram of an external SE chip system in related technologies; Figure 2 This is a system block diagram of the built-in HSM solution in an embodiment of the present invention; Figure 3 This is a software system architecture diagram of the built-in HSM solution in an embodiment of the present invention; Figure 4 This is a first flowchart of a vehicle-mounted device security authentication method according to an embodiment of the present invention; Figure 5 This is a second flowchart of the vehicle-mounted device security authentication method according to an embodiment of the present invention; Figure 6 This is a secure boot process based on MCU-HSM according to an embodiment of the present invention; Figure 7 This is a third flowchart of the vehicle-mounted device security authentication method according to an embodiment of the present invention; Figure 8 This is a communication security scheme based on MCU-HSM according to an embodiment of the present invention; Figure 9 This is a structural block diagram of an in-vehicle equipment safety authentication device according to an embodiment of the present invention; Figure 10 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0023] 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.

[0024] It is understood that before using the technical solutions disclosed in the various embodiments of the present invention, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in the present invention and their authorization should be obtained in accordance with relevant laws and regulations through appropriate means.

[0025] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0026] like Figure 1As shown, current mainstream vehicle information security solutions mainly consist of chips such as the CYT2B97 MCU (with a built-in HSM security module), SE encryption chips (such as NXP / NCJ38E, used to store and execute secure communication algorithms), and SOC chips using MTK8666 or MTK8675. The secure communication algorithm is typically stored in a separate SE encryption chip, which implements key security functions such as authentication, key generation, and storage. While this architecture provides a certain level of communication security, its core relies on an external dedicated security element (SE) chip for encryption and authentication. However, this type of solution suffers from high hardware costs, additional PCB board space requirements, and increased system complexity. Furthermore, the exposed communication pins between the SE chip and the MCU or SOC introduce security risks of key information theft or tampering, hindering the highly integrated development of vehicle systems and further improvements in overall security.

[0027] Based on this, such as Figure 2 As shown, this embodiment eliminates the external SE chip and utilizes the hardware security module (HSM) built into the MCU chip as the root of trust and security core to achieve a complete set of information security encryption functions. Figure 3 As shown, the built-in HSM software system architecture provided in this embodiment of the invention constructs a comprehensive security protection system covering system, application, data, network, communication, and access point aspects: at the system level, it provides protection mechanisms such as root detection, security upgrade, and secure startup; at the application level, it implements anti-tampering and uninstallation protection for authorized apps and interception of unauthorized app installations; at the data level, it ensures the confidentiality, integrity, and ownership of sensitive data; at the network level, it integrates security functions such as firewalls, intrusion detection, and security logs; at the communication level, it ensures the authenticity and confidentiality of communication data sources; and at the access point level, it implements security control over interfaces such as Bluetooth and Wi-Fi. This architecture, based on the HSM hardware security module built into the MCU chip, achieves a high-security solution: the HSM communicates with the MCU via an internal SPI bus, avoiding the pin exposure risks associated with traditional external SE chips using I2C and other external interfaces, thus improving system security and integration. Simultaneously, the MCU's built-in HSM module provides reliable cryptographic services for upper-layer applications, supporting key generation, import, and secure storage, and is capable of using mainstream international cryptographic algorithms (such as RSA, ECC, and AES), while also providing certificate import and storage management functions. Furthermore, the system uses the MCU-HSM as a root of trust to achieve secure boot, ensuring firmware integrity and trustworthiness. In the communication scenario between the vehicle-mounted APP and the vehicle network backend, the HTTPS / TLS secure communication protocol is adopted to ensure data confidentiality and identity authentication security in the communication link, fully meeting the information security requirements of the in-vehicle environment.

[0028] Furthermore, this embodiment provides a security authentication method embodiment for in-vehicle devices. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Also, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0029] This embodiment provides a secure authentication method for in-vehicle devices, which can be used in an in-vehicle domain controller. The in-vehicle domain controller includes a main control chip (SOC) and a microcontroller unit (MCU) with an integrated hardware security module (HSM). The private key used for vehicle identification is stored in the HSM, and the digital certificate containing the public key is stored in the SOC. Figure 4 This is a flowchart of the first type of vehicle-mounted device security authentication method according to an embodiment of the present invention, such as... Figure 4 As shown, the process includes the following steps: Step S401: When the vehicle domain controller needs to perform vehicle authentication, the SOC generates a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation, and sends the security service request to the MCU.

[0030] Digital certificates contain critical data such as public keys, holder information, validity periods, and the issuing authority's digital signature. They use asymmetric encryption technology to ensure the authenticity of identity and the security of communication. In automotive environments, digital certificates are used to verify the legitimate identity of vehicles or controllers, prevent forgery and man-in-the-middle attacks, and serve as the fundamental trust anchor for achieving secure authentication and data encryption.

[0031] Step S402: The MCU receives and parses the security service request, obtains the data to be processed and the operation instructions, calls the HSM, and the HSM performs identity authentication cryptographic operations on the data to be processed according to the private key and the operation instructions, and returns the operation results to the SOC.

[0032] Specifically, the HSM decrypts the plaintext of the communication key and operation instructions based on the private key, performs authentication-type cryptographic operations on the data to be processed, and returns the operation results to the SOC.

[0033] Among them, cryptographic operations for identity authentication include at least one of the following: digital signature, signature verification, message authentication code generation, message authentication code verification, and challenge-response calculation.

[0034] Therefore, the built-in HSM software system architecture provided in this embodiment has the following beneficial effects: 1) Save on software maintenance costs. Multiple projects can achieve the same software version for overseas and domestic projects, including software development costs, testing manpower costs, after-sales market maintenance costs, supplier production costs, etc. 2) Saves PCB routing space – reducing the number of chips and their surrounding circuitry, making circuit and structural design simpler and more efficient; 3) The hardware structure reduces the exposure of key chip pins, achieving a higher level of chip security protection.

[0035] 4) Compared to external interface communication methods such as SPI / I2C, this method only needs to communicate through an internal bus (such as SPI), which is faster.

[0036] 5) Store the key independently in the HSM, eliminating the need for obfuscated storage and reducing software development workload.

[0037] This embodiment reuses the HSM already integrated in the vehicle domain controller to implement the security authentication function, eliminating the need for an external dedicated security chip. This effectively reduces hardware costs and PCB space usage, avoids the risk of exposing critical pins, and improves system integration and hardware security. At the same time, the private key is always stored inside the HSM and is not exported, ensuring the security of the vehicle identity key. Combined with the collaborative mechanism of SOC and MCU, it achieves efficient and reliable identity authentication, enhancing the vehicle equipment's ability to resist network attacks and unauthorized access.

[0038] This embodiment provides a secure authentication method for in-vehicle devices, which can be used in an in-vehicle domain controller. The in-vehicle domain controller includes a main control chip (SOC) and a microcontroller unit (MCU) with an integrated hardware security module (HSM). The private key used for vehicle identification is stored in the HSM, and the digital certificate containing the public key is stored in the SOC. Figure 5 This is a second flowchart of the vehicle-mounted device security authentication method according to an embodiment of the present invention, such as... Figure 5 As shown, the process includes the following steps: Step S501: After the MCU is powered on, the first-level boot code is loaded by the HSM, and the first-level boot code is digitally signed and verified using the verification public key pre-embedded in the HSM to confirm its integrity and authenticity; after the verification is successful, the first-level boot code is executed, where the first-level boot code serves as the Bootloader.

[0039] To ensure the trustworthiness of the verification public key itself, the verification public key embedded within the HSM pre-calculates its hash value and compares it with the corresponding hash value burned into the efuse chip. Only when the hash values ​​match is the public key considered tamper-proof and can it be used for subsequent digital signature verification of the first-level boot code. This mechanism constitutes the root of trust for secure boot, preventing attackers from compromising system security by replacing the public key or boot code.

[0040] In this process, the public key and private key are verified to belong to the same asymmetric key pair, or to be an independently pre-set trusted root public key.

[0041] Step S502: During the execution of the Bootloader, the Bootloader performs digital signature verification on the second-level startup code to confirm its integrity and authenticity. After the verification is successful, the second-level startup code is loaded and executed, whereby the second-level startup code serves as the MCU system program or its loader.

[0042] Specifically, the bootloader calculates the SHA256 hash value of the IIB (Initial Image Block) area storing the Level 2 boot code and verifies the accompanying digital signature using a pre-set verification public key (e.g., RSA or ECDSA signature verification) to recover the original hash value; then, it compares the two. Only when the hash values ​​match is the Level 2 boot code deemed tamper-proof and of a trustworthy origin, allowing loading and execution to continue.

[0043] Step S503: After the second-level startup code is loaded, the second-level startup code initializes the MCU operating environment and starts system services to enter normal working state.

[0044] like Figure 6 As shown, the trustworthiness of the MCU system depends on the Root of Trust, which is stored in the MCU's built-in HSM. This ensures that the Root of Trust is not tampered with or erased, and performs integrity checks on the next-level boot code. After the MCU powers on, the Root of Trust first verifies the integrity and authenticity of the bootloader; then the bootloader verifies the integrity and authenticity of the MCU system program. For example, MCU boot firmware verification can be implemented based on the RSA2048 algorithm. The HSM is loaded first, and then a secure boot verification is performed on the bootloader and application. Only after successful verification is the loading of the bootloader and application allowed. Furthermore, the MCU platform provider provides an image signing tool to sign the image file. The public key used for signing needs to be provided to the MCU platform provider before being loaded into the MCU, greatly increasing system security.

[0045] Step S504: The first cryptographic middleware running in the SOC software environment intercepts the first protocol digest generated by the vehicle domain controller and the vehicle network backend during the TLS handshake phase of HTTPS two-way authentication, and encapsulates the first protocol digest as data to be processed into a first signature request.

[0046] The first cryptographic middleware is configured not to perform cryptographic operations involving the private key during HTTPS mutual authentication. For example, the first cryptographic middleware could be a custom BoringSSL library.

[0047] Step S505: Send the first signature request to the first security agent service running on the SOC.

[0048] For example, the first security proxy service can be the vecentekseservice service.

[0049] Step S506: The first security agent service extracts the data to be processed from the first signature request.

[0050] Step S507: The SOC generates a security service request containing the data to be processed and operation instructions based on the digital certificate and identity authentication operation, and sends the security service request to the MCU.

[0051] Step S508: The MCU receives and parses the security service request, obtains the data to be processed and the operation instructions, calls the HSM, and the HSM performs identity authentication cryptographic operations on the data to be processed according to the private key and the operation instructions, and returns the operation results to the SOC.

[0052] Step S509: The first security proxy service receives the operation result and returns the operation result to the first cryptographic middleware, so that the first cryptographic middleware submits the operation result as the client authentication credential to the TLS protocol stack to complete HTTPS two-way authentication.

[0053] In other words, the terminal's RSA private key and certificate required for two-way authentication between the vehicle-mounted system and the backend are securely written using a dedicated production filling tool. The RSA private key is always stored in the vehicle-mounted system's HSM (Hardware Storage System), ensuring it never leaves the chip; the certificate is encrypted using a white-box encryption algorithm and stored in the vehicle-mounted system's regular storage area. Each terminal uses a unique self-signed certificate issued by the vehicle manufacturer's PKI system—one certificate per device—ensuring the uniqueness and trustworthiness of the device's identity. The two-way authentication process is implemented using the RSA-2048 algorithm.

[0054] When performing HTTPS two-way authentication with the backend on the Android side, a customized BoringSSL library and the `vecentekseservice` service need to be integrated, and the `vecentekseservice` service must be ensured to start automatically at boot. The `vecentekseservice` service needs to establish a communication channel (such as SPI, UART, or IPC mechanism) between the Android system and the MCU to send the signature data required for two-way authentication to the MCU, which then performs the signature calculation using the HSM. After the MCU completes the HSM signature, it returns the result to the `vecentekseservice` service in the Android system, and finally sends it back to the TLS protocol stack to complete client authentication.

[0055] Throughout the entire HTTPS two-way authentication process, the link layer supports the TLS 1.2 protocol and employs a high-security encryption suite, specifically including: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_DHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 The aforementioned encryption suites all employ a forward secure key exchange algorithm (DHE or ECDHE), a strong encryption algorithm (AES-GCM), and a secure hash function (SHA256 / SHA384), combined with an HSM-based private key protection mechanism, to achieve confidentiality, integrity, and resistance to replay attacks in the communication link.

[0056] The secure authentication method for in-vehicle devices provided in this embodiment achieves secure isolation and transparent proxying of signature operations during HTTPS two-way authentication by deploying a first cryptographic middleware and a first secure proxy service in the SOC. This ensures that sensitive private key calculations are completed entirely within the HSM, avoiding the risk of the private key being exposed on the SOC side. Simultaneously, the middleware is only responsible for intercepting protocol data and sending back results, without participating in actual cryptographic calculations, reducing the security requirements of the SOC software environment and improving the system's maintainability and compatibility. The entire process is seamlessly integrated into the standard TLS handshake process, achieving high-security in-vehicle communication identity authentication without modifying upper-layer application logic. This effectively prevents man-in-the-middle attacks and identity impersonation, ensuring the confidentiality and integrity of vehicle network communication.

[0057] This embodiment provides a secure authentication method for in-vehicle devices, which can be used in an in-vehicle domain controller. The in-vehicle domain controller includes a main control chip (SOC) and a microcontroller unit (MCU) with an integrated hardware security module (HSM). The private key used for vehicle identification is stored in the HSM, and the digital certificate containing the public key is stored in the SOC. Figure 7 This is a third flowchart of the vehicle-mounted device security authentication method according to an embodiment of the present invention, such as... Figure 7 and Figure 8 As shown, the process includes the following steps: Step S701: After the MCU is powered on, the first-level boot code is loaded by the HSM, and the first-level boot code is digitally signed and verified using the verification public key pre-embedded in the HSM to confirm its integrity and authenticity; after the verification is successful, the first-level boot code is executed, where the first-level boot code serves as the Bootloader.

[0058] In this process, the public key and private key are verified to belong to the same asymmetric key pair, or to be an independently pre-set trusted root public key.

[0059] Step S702: During the execution of the Bootloader, the Bootloader performs digital signature verification on the second-level startup code to confirm its integrity and authenticity. After the verification is successful, the second-level startup code is loaded and executed, whereby the second-level startup code serves as the MCU system program or its loader.

[0060] Step S703: After the second-level startup code is loaded, the second-level startup code initializes the MCU operating environment and starts system services to enter normal working state.

[0061] Step S704: After the vehicle domain controller is powered on and the MCU enters normal working state, the HSM generates a temporary key pair that is only valid for this startup, including a virtual private key and a virtual public key. The virtual private key is securely stored inside the HSM and cannot be exported.

[0062] Step S705: The HSM sends the virtual public key to the SOC; the SOC receives and stores the virtual public key.

[0063] Step S706: The SOC generates a temporary identity based on the virtual public key and provides it to the wireless communication module for constructing a client identity statement in HTTPS two-way authentication.

[0064] Thus, at each startup, the HSM dynamically generates a temporary key pair valid only for that specific session, and strictly restricts the virtual private key to use within the HSM and never exports it, achieving session-level isolation and forward security for vehicle identity authentication; the SOC only receives and stores the virtual public key, which is used to construct identity claims and initiates a security request when a signature is required, with the HSM performing the private key calculation, effectively avoiding the direct exposure and frequent use of long-term identity private keys in communication; even if the temporary key of a certain session is cracked in the future, it is impossible to deduce other sessions or long-term keys, significantly improving the system's ability to resist key leakage risks and enhancing the security protection level of in-vehicle equipment against long-term eavesdropping and replay attacks in open network environments.

[0065] Step S707: The second cryptographic library running in the wireless communication module intercepts the second protocol digest generated by the wireless communication module and the vehicle network backend during the TLS handshake phase of HTTPS two-way authentication, and encapsulates the second protocol digest as data to be processed into a second signature request.

[0066] The second cryptography library is configured not to perform cryptographic operations involving the private key in HTTPS mutual authentication. For example, the second cryptography library could be a custom OpenSSL library.

[0067] Step S708: Send the second signature request to the second security agent service running on the wireless communication module.

[0068] For example, the second security agent service can be a channel service provided in the 4G module for communication with the MCU.

[0069] Step S709: The second security agent service extracts the data to be processed from the second signature request and forwards the data to be processed to the SOC through a preset secure communication interface.

[0070] Step S710: The SOC receives the data to be processed from the wireless communication module, generates a security service request containing a key identifier, the data to be processed, and operation instructions based on the virtual public key and the preset authentication operation type, and sends it to the MCU.

[0071] Step S711: The MCU receives and parses the security service request, obtains the data to be processed and the operation instructions, calls the HSM, and the HSM performs a digital signature operation on the data to be processed according to the virtual private key specified by the key identifier and the operation instructions, and returns the signature result to the SOC.

[0072] Specifically, the HSM decrypts the plaintext of the communication key and operation instructions based on the private key, performs authentication-type cryptographic operations on the data to be processed, and returns the operation results to the SOC.

[0073] Step S712: The SOC forwards the operation result to the second security proxy service, which then passes it to the second cryptographic library; the second cryptographic library receives the operation result and submits it as the client authentication credential to the TLS protocol stack to complete HTTPS two-way authentication.

[0074] By deploying a second cryptographic library and a second security proxy service within the wireless communication module, localization and security decoupling of wireless communication link authentication are achieved. This ensures that the signature operation in HTTPS two-way authentication is still securely executed by the HSM, and the private key does not need to leave the security boundary, effectively preventing the risk of key leakage. Simultaneously, the wireless communication module is only responsible for intercepting the protocol digest and submitting the authentication credentials, without participating in private key calculations. This reduces the security requirements for the communication module and improves the overall deployability and compatibility of the system. This solution fully utilizes the security capabilities of the vehicle domain controller to achieve cross-chip secure authentication collaboration, ensuring both the confidentiality and trustworthiness of vehicle network communication, while avoiding the complex architecture of external security chips, thus enhancing system integration and anti-attack capabilities.

[0075] For example, during two-way authentication on the 4G side, a customized OpenSSL library is added. The customized OpenSSL library needs to call the communication channel between 4G and MCU to send the signature data required for two-way authentication to MCU. MCU uses the private key in HSM to sign it. After MCU completes the signing with the private key, it returns the data to the 4G OpenSSL library.

[0076] Furthermore, the security authentication method for in-vehicle devices provided in this embodiment also includes the following steps: During the startup process of the in-vehicle domain controller, the MCU verifies the legitimacy of the device identity certificate stored in the SOC, and verifies whether the HSM holds a private key that matches the public key contained in the device identity certificate through a challenge response mechanism; if the verification result is successful, the SOC configures the network communication module to enable simultaneous access to the first type of access point network and the second type of access point network; if the verification result is unsuccessful, the SOC configures the network communication module to only access the first type of access point network and prohibits access to the second type of access point network; wherein, the first type of access point network is used to connect to the controlled intranet service endpoint, and the second type of access point network is used to connect to the public network service endpoint.

[0077] In other words, based on private and public APNs, and by verifying the key certificate in the HSM module, data isolation transmission is achieved—if the verification fails, only private network transmission is supported.

[0078] In summary, the security authentication method for in-vehicle devices provided in this embodiment ensures a high level of security in the in-vehicle environment through a series of comprehensive security mechanisms. First, it achieves secure booting of the Android system and MCU, and provides security management functions such as authorization detection, integrity detection, and encryption protection for in-vehicle Android upgrade packages, MCU upgrade packages, and CDC upgrade packages, while preventing downgrade attacks. Second, it strictly limits system user account permissions, prohibits the allocation of ROOT permissions, and further enhances system account security through access control. Third, it uses IDS technology in IDPS for abnormal behavior monitoring, including CPU and memory resource usage, system permission changes, and brute-force attempts, and records relevant logs for subsequent analysis. Furthermore, this method also covers the field of communication security, including security protection for various communication methods such as CAN bus, Ethernet, message, and WIFI & BT. At the application level, it strengthens application security by protecting code, permissions, and authorization processes. Finally, in terms of data security, it ensures the confidentiality and integrity of data through data compliance measures and sensitive information encryption technology, thereby constructing a multi-dimensional and deep-layered security protection system, providing a solid and reliable security guarantee for in-vehicle devices.

[0079] This embodiment also provides a security authentication device for an in-vehicle device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0080] This embodiment provides a security authentication device for vehicle-mounted equipment, such as... Figure 9 As shown, it includes: The first processing module 901 is used to generate a security service request containing data to be processed and operation instructions based on the digital certificate and the identity authentication operation when the vehicle domain controller needs to perform vehicle identity authentication operation, and send the security service request to the MCU. The second processing module 902 is used to receive and parse security service requests, obtain the data to be processed and operation instructions, call HSM, HSM performs identity authentication cryptographic operations on the data to be processed according to the private key and operation instructions, and returns the operation results to SOC.

[0081] In some alternative implementations, the security authentication device for the vehicle-mounted equipment may also include a third processing module. The third processing module, when the authentication operation is HTTPS two-way authentication between the vehicle domain controller and the vehicle network backend, before the SOC generates a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation, has a first cryptographic middleware running in the SOC software environment intercept the first protocol digest generated by the negotiation between the vehicle domain controller and the vehicle network backend during the TLS handshake phase of HTTPS two-way authentication, and encapsulate the first protocol digest as the data to be processed into a first signature request; wherein, the first cryptographic middleware is configured not to perform cryptographic operations involving private keys in HTTPS two-way authentication; the first signature request is sent to the first security proxy service running in the SOC; the first security proxy service extracts the data to be processed from the first signature request, so that the SOC can generate a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation; after the HSM performs digital signature on the data to be processed and returns the operation result to the SOC, the first security proxy service receives the operation result and returns the operation result to the first cryptographic middleware, so that the first cryptographic middleware submits the operation result as the client authentication credential to the TLS protocol stack, completing HTTPS two-way authentication.

[0082] In some alternative implementations, the security authentication device for the vehicle-mounted equipment may also include a fourth processing module. The fourth processing module is used to, when the authentication operation is HTTPS two-way authentication between the wireless communication module and the vehicle network backend, before the SOC generates a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation, have a second cryptographic library running in the wireless communication module intercept the second protocol digest negotiated between the wireless communication module and the vehicle network backend during the TLS handshake phase of HTTPS two-way authentication, and encapsulate the second protocol digest as the data to be processed into a second signature request; wherein, the second cryptographic library is configured not to perform cryptographic operations involving private keys in HTTPS two-way authentication; the second signature request is sent to the second security proxy service running in the wireless communication module; the second security proxy service extracts the data to be processed from the second signature request, so that the SOC can generate a security service request containing the data to be processed and operation instructions based on the digital certificate and the authentication operation; after the HSM performs digital signature on the data to be processed and returns the operation result to the SOC, the SOC forwards the operation result to the second security proxy service, which then passes it to the second cryptographic library; the second cryptographic library receives the operation result and submits it as the client authentication credential to the TLS protocol stack to complete HTTPS two-way authentication.

[0083] In some optional implementations, the security authentication device for the vehicle-mounted equipment further includes a fifth processing module. The fifth processing module is used for: after the MCU is powered on, loading the first-level boot code by the HSM and performing digital signature verification on the first-level boot code using a verification public key pre-embedded in the HSM to confirm its integrity and authenticity; executing the first-level boot code after successful verification, where the first-level boot code acts as a bootloader; during the execution of the bootloader, performing digital signature verification on the second-level boot code to confirm its integrity and authenticity, loading and executing the second-level boot code after successful verification, where the second-level boot code acts as the MCU system program or its loader; after the second-level boot code is loaded, initializing the MCU operating environment and starting system services to enter normal operating status; wherein the verification public key and private key belong to the same asymmetric key pair, or are independently pre-set trusted root public keys.

[0084] In some optional implementations, the security authentication device for the in-vehicle equipment further includes a sixth processing module. The sixth processing module is used to: after the in-vehicle domain controller powers on and the MCU enters normal operating mode, generate a temporary key pair valid only for this startup, including a virtual private key and a virtual public key, wherein the virtual private key is securely stored internally within the HSM and cannot be exported; the HSM sends the virtual public key to the SOC; the SOC receives and stores the virtual public key; in subsequent communications, when the SOC needs to respond to an external authentication challenge, it constructs an identity statement based on the virtual public key, encapsulates the data to be signed into a signature request, and sends it to the MCU to initiate the signing process completed by the HSM.

[0085] In some optional implementations, the security authentication device for the vehicle-mounted equipment further includes a seventh processing module. The seventh processing module is used to: during the startup process of the vehicle domain controller, have the MCU verify the legitimacy of the device identity certificate stored in the SOC, and verify whether the HSM holds a private key paired with the public key contained in the device identity certificate through a challenge-response mechanism; if the verification result is successful, have the SOC configure the network communication module to enable simultaneous access to both the first type of access point network and the second type of access point network; if the verification result is unsuccessful, have the SOC configure the network communication module to only access the first type of access point network and prohibit access to the second type of access point network; wherein the first type of access point network is used to connect to the controlled intranet service endpoint, and the second type of access point network is used to connect to the public network service endpoint.

[0086] The vehicle-mounted device security authentication apparatus provided in this embodiment of the invention can execute the vehicle-mounted device security authentication method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0087] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0088] The following is a detailed reference. Figure 10 This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1001, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from memory 1008 into random access memory (RAM) 1003. The RAM 1003 also stores various programs and data required for the operation of the electronic device. The processor 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0089] Typically, the following devices can be connected to the I / O interface 1005: input devices 1006 including, for example, a touchscreen, touchpad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 1007 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; memory devices 1008 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows electronic devices to exchange data via wireless or wired communication with other devices. Although Figure 10 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0090] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 1009, or installed from a memory 1008, or installed from a ROM 1002. When the computer program is executed by the processor 1001, it performs the functions defined in the security authentication method for in-vehicle devices according to embodiments of the present invention.

[0091] Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0092] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the security authentication method for the vehicle-mounted device shown in the above embodiments is implemented.

[0093] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0094] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A security authentication method for a vehicle-mounted device, characterized by comprising: The application is applied to a vehicle-mounted domain controller, wherein the vehicle-mounted domain controller comprises a master control chip and a micro control unit integrated with a hardware security module, and a private key for vehicle identity identification is stored in the hardware security module; The security authentication method of the vehicle-mounted device comprises: When the vehicle-mounted domain controller needs to perform an identity authentication operation of the vehicle, the master control chip generates a security service request containing to-be-processed data and operation instructions according to the digital certificate and the identity authentication operation, and sends the security service request to the micro control unit; The micro control unit receives and analyzes the security service request to obtain the to-be-processed data and the operation instructions, calls the hardware security module, the hardware security module performs an identity authentication type cryptographic operation on the to-be-processed data according to the private key and the operation instructions, and returns the operation result to the master control chip; The identity authentication type cryptographic operation comprises at least one of digital signature, signature verification, message authentication code generation, message authentication code verification, challenge-response calculation.

2. The method of claim 1, wherein, When the identity authentication operation is HTTPS two-way authentication between the vehicle-mounted domain controller and a vehicle networking background, before the master control chip generates a security service request containing to-be-processed data and operation instructions according to the digital certificate and the identity authentication operation, the method further comprises: A first cryptographic middleware running in a software environment of the master control chip intercepts a first protocol digest generated by negotiation between the vehicle-mounted domain controller and the vehicle networking background in a TLS handshake stage of the HTTPS two-way authentication, and encapsulates the first protocol digest as a first signature request as the to-be-processed data; wherein the first cryptographic middleware is configured not to perform cryptographic operations involving the private key in the HTTPS two-way authentication; The first signature request is sent to a first security agent service running in the master control chip; The first security agent service extracts the to-be-processed data from the first signature request, so that the master control chip generates a security service request containing to-be-processed data and operation instructions according to the digital certificate and the identity authentication operation; After the hardware security module performs digital signature on the to-be-processed data and returns the operation result to the master control chip, the first security agent service receives the operation result and returns the operation result to the first cryptographic middleware, so that the first cryptographic middleware submits the operation result as a client authentication credential to a TLS protocol stack, and completes the HTTPS two-way authentication.

3. The method of claim 1, wherein, When the identity authentication operation is HTTPS two-way authentication between a wireless communication module and a vehicle networking background, before the master control chip generates a security service request containing to-be-processed data and operation instructions according to the digital certificate and the identity authentication operation, the method further comprises: intercept, by a second cryptography library running in the wireless communication module, a second protocol digest generated by the wireless communication module and the Internet of Vehicles background in negotiation during a TLS handshake phase of the HTTPS two-way authentication, and encapsulate the second protocol digest as a second signature request for the to-be-processed data; wherein the second cryptography library is configured not to perform a cryptography operation involving the private key in the HTTPS two-way authentication; send the second signature request to a second security agent service running in the wireless communication module; extract, by the second security agent service, the to-be-processed data from the second signature request, so that the host chip generates a security service request containing to-be-processed data and operation instructions according to the digital certificate and the identity authentication operation; after the hardware security module performs digital signature on the to-be-processed data and returns the operation result to the host chip, the host chip forwards the operation result to the second security agent service, which then transmits the operation result to the second cryptography library; the second cryptography library receives the operation result and submits it as a client authentication credential to a TLS protocol stack, thereby completing the HTTPS two-way authentication.

4. The method of claim 1, wherein, The digital certificate containing the public key has been stored in the host chip, and the security authentication method of the vehicle-mounted device further comprises: after the micro control unit is powered on, load a first level startup code by the hardware security module, and perform digital signature verification on the first level startup code using a verification public key pre-solidified in the hardware security module to confirm the integrity and authenticity of the first level startup code; after the verification passes, execute the first level startup code, wherein the first level startup code serves as a Bootloader; during the execution of the Bootloader, perform digital signature verification on a second level startup code by the Bootloader to confirm the integrity and authenticity of the second level startup code; after the verification passes, load and execute the second level startup code, wherein the second level startup code serves as a system program of the micro control unit or a loader thereof; after the loading of the second level startup code is completed, initialize the micro control unit running environment and start system services by the second level startup code to enter a normal working state; wherein the verification public key and the private key belong to the same asymmetric key pair, or are an independently preset trusted root public key.

5. The method of claim 1, wherein, Further comprising: after the vehicle-mounted domain controller is powered on and the micro control unit enters a normal working state, generate a temporary key pair including a virtual private key and a virtual public key by the hardware security module, wherein the virtual private key is securely stored in the hardware security module and is not allowed to be exported; send the virtual public key to the host chip by the hardware security module; receive and store the virtual public key by the host chip; when responding to an external authentication challenge in subsequent communication, construct an identity statement based on the virtual public key and encapsulate to-be-signed data as a signature request by the host chip, and send the signature request to the micro control unit to start a signature process completed by the hardware security module.

6. The method of claim 1, wherein, Further comprising: In the vehicle-mounted domain controller startup process, the micro control unit performs legality verification on the device identity certificate stored in the master control chip, and verifies whether the private key paired with the public key contained in the device identity certificate is held in the hardware security module through a challenge-response mechanism; If the verification result is passed, the master control chip configures the network communication module to enable simultaneous access to the first type access point network and the second type access point network; If the verification result is not passed, the master control chip configures the network communication module to only access the first type access point network and prohibits access to the second type access point network; The first type access point network is used to connect a controlled internal network service endpoint, and the second type access point network is used to connect a public network service endpoint.

7. A security authentication apparatus for a car navigation device, characterized by comprising: The application is applied to a vehicle-mounted domain controller, wherein the vehicle-mounted domain controller includes a master control chip and a micro control unit integrated with a hardware security module, and a private key for vehicle identity identification is stored in the hardware security module, and a digital certificate containing a public key is stored in the master control chip. The security authentication device of the vehicle-mounted device includes: A first processing module is configured to generate a security service request containing to-be-processed data and operation instructions based on the digital certificate and the identity authentication operation when the vehicle-mounted domain controller needs to perform an identity authentication operation of the vehicle, and send the security service request to the micro control unit. A second processing module is configured to receive and parse the security service request to obtain the to-be-processed data and the operation instructions, call the hardware security module, and perform an identity authentication type cryptographic operation on the to-be-processed data based on the private key and the operation instructions, and return the operation result to the master control chip. The identity authentication type cryptographic operation includes at least one of digital signature, signature verification, message authentication code generation, message authentication code verification, and challenge-response calculation.

8. An electronic device, comprising: The application includes: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the security authentication method of the vehicle-mounted device according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer instructions for causing a computer to perform the security authentication method of the vehicle-mounted device according to any one of claims 1 to 6.

10. A computer program product, characterised in that, The computer instructions are used to cause a computer to perform the security authentication method of the vehicle-mounted device according to any one of claims 1 to 6.

Images