Vehicle-mounted Ethernet gateway controller information security system and method based on HSM

Abstract

The invention discloses a vehicle-mounted Ethernet gateway information security system and method based on an HSM, belongs to the field of automobile electronic network security, and aims to solve the problems that an existing vehicle-mounted gateway is low in security mechanism performance, prone to secret key leakage and isolated in protection. The system has a security isolation environment, a hardware encryption engine and an irreversible fusing mechanism, and securely stores key, certificate and other core assets. The four functions of safe starting, SECOC real-time communication, TLS bidirectional authentication diagnosis and OTA safe refreshing are achieved through HSM, a deep defense system covering the whole life cycle of the gateway is formed, the safety and real-time performance of the vehicle-mounted gateway are improved, and illegal invasion and data tampering are eradicated.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of automobile electronic network security, and particularly relates to a vehicle-mounted Ethernet gateway controller information security system and method based on HSM. BACKGROUND

[0002] With the development of automobile intelligence, networking and electrification, the vehicle network architecture is evolving from the traditional distributed controller area network to the centralized domain controller architecture with vehicle-mounted Ethernet as the backbone. The vehicle-mounted Ethernet gateway, as the communication hub of the vehicle network, is responsible for connecting various functional domains in the vehicle with external networks, and its security is directly related to the functional safety and information security of the vehicle.

[0003] In the prior art, the security scheme of the vehicle-mounted network has the following defects: The software-implemented security mechanism has low performance and is vulnerable to attacks: traditional security algorithms (such as AES, SHA, RSA) are usually implemented in software on the general-purpose CPU of the gateway main controller, which consumes a large amount of CPU resources and causes significant impact in gateway controllers with high integration and multiple functions. It causes performance bottlenecks during high-bandwidth communication, and the software-implemented keys and algorithms are more likely to be stolen or tampered with by malicious software; The security mechanism is single and lacks a comprehensive protection mechanism: existing solutions are often designed for a single security threat, such as implementing only secure boot or using encryption on a certain communication link. These security measures are independent of each other and cannot form a collaborative defense system covering the entire life cycle of system startup, runtime communication, data storage, software updates, etc. Once an attacker successfully attacks a certain point, it can cause comprehensive damage; Weak key management: in pure software solutions, encryption keys are usually stored in non-volatile memory such as Flash, which lacks effective physical and logical protection and is easy to extract, rendering the entire security system useless; It is difficult to meet the high real-time requirements of vehicle-mounted systems: buses such as CAN, CANFD, and vehicle-mounted Ethernet have strict requirements for communication delay, and software implementation of complex cryptographic operations (such as SECOC MAC verification) will introduce unacceptable delays, affecting the normal control functions of the vehicle.

[0004] Therefore, there is an urgent need in the art for a vehicle-mounted Ethernet gateway security solution that can provide high performance, high security level, and multi-level in-depth defense. SUMMARY

[0005] In view of the deficiencies in the prior art, the purpose of the present application is to provide a vehicle-mounted Ethernet gateway controller information security system and method based on HSM.

[0006] To achieve the above object, the application provides the following technical scheme: a vehicle-mounted Ethernet gateway main controller, as a system main processor, runs OTA upgrade software and application software of an integrated information security software module; a hardware security core HSM is integrated in a CPU chip of the vehicle-mounted Ethernet gateway main controller, is a separate coprocessor core with a secure isolation environment, internally integrates a cryptography algorithm engine, a true random number generator and a protected nonvolatile memory, the protected nonvolatile memory is used for storing a root key, a certificate, a secure boot signature public key and a secure boot trust root (Boot Mac Key), and the HSM has a fuse mechanism that cannot be closed once it is turned on, only performs encryption and decryption operations through hardware acceleration, and the main core has no authority to tamper with the stored key; a diagnostic instrument device or a vehicle-mounted OTA Master node is connected with the vehicle-mounted Ethernet gateway main controller through an OBD interface, is preset with a trusted certificate and an ECDHE private key, and is used for initiating a TLS bidirectional security authentication process, a secure refresh process and a vehicle-mounted gateway diagnostic request, wherein the secure refresh process loads an upgrade package carrying a digital signature; and an internal vehicle network is used for connecting CAN, CANFD, LIN and Ethernet buses in the vehicle, and realizes signal interaction between the vehicle-mounted Ethernet gateway main controller and an Ethernet node in the vehicle.

[0007] The application further provides that: the Code Flash region of the HSM is divided into a special code running region and only stores HSM core firmware code; the Data Flash region is divided into a special data storage region and only stores a root key, a certificate, a secure boot trust root and a security log, and only the data of the Code Flash and Data Flash regions can be rewritten through the flash drive of the HSM core; after the fuse mechanism is enabled, a burning tool cannot rewrite the Code Flash region, the Data Flash region and security-related configuration words of the HSM, and the HSM core firmware has a self-update function to prevent hardware loss caused by incorrect firmware burning.

[0008] The application further provides that: the key stored by the HSM supports a "one piece one key" configuration, different root keys and secure boot signature public keys are respectively loaded for the HSM of each vehicle-mounted Ethernet gateway controller through a special burning tool in the production link, and a secret control process is performed in the key loading process to prohibit unauthorized access to key data.

[0009] The application is further provided with: S1: security start verification, when the system is powered on, the HSM calls the stored security start trust root (Boot Mac Key) to perform encryption verification operation on the software firmware data of the OTA boot program and App application to be started of the vehicle Ethernet gateway controller, and if the verification is passed, the main core is released and the software is allowed to start, and if the verification fails, the start is prohibited; S2: SECOC real-time security communication, when the vehicle Ethernet gateway controller interacts with the CAN bus signal, the API interface of the HSM is called to perform symmetric encryption operation on the original CAN message to generate an authentication code, and the original message and the authentication code are combined and transmitted; the receiver calls the HSM to verify the authentication code and the freshness value of the received message, and if the verification is passed, the message is received, otherwise it is discarded; S3: TLS transmission layer security authentication, the vehicle Ethernet gateway controller disables the 13400 port of the DOIP protocol and only opens the TCPIP port of the TLS protocol; the external diagnostic instrument transmits a trust certificate through the TLS port, the HSM participates in certificate chain verification, ECDHE temporary key generation and pre-master key, master key and session key negotiation, and after the authentication is passed, the 13400 port is opened to perform DOIP protocol interaction; S4: secure refresh verification, when OTA upgrading, the cloud OTA server or the diagnostic instrument uses the RSA private key to sign the upgraded firmware; after the vehicle Ethernet gateway controller receives the upgraded firmware, the HSM calculates the firmware hash value and decrypts the signature using the preset RSA public key, and if the hash values are consistent, the verification is passed, the new firmware is enabled and the security start trust root in the HSM is updated.

[0010] The application is further provided with: the encryption verification operation in step S1 is AES-128 CMAC operation or RSA signature operation; if it is RSA signature operation, the HSM obtains a first hash value by decrypting the signature of the security start trust root through the RSA public key, and reads the software firmware data to be started to calculate a second hash value, and if the first hash value and the second hash value are consistent, the verification is passed; if it is AES-128 CMAC operation, the HSM calculates the CMAC value of the software firmware data to be started, and if the CMAC value of the stored security start trust root is consistent, the verification is passed; and after the OTA upgrading is successful, the vehicle Ethernet gateway controller calls the API interface of the HSM to recalculate the security start trust root of the software firmware data, and updates it to the protected nonvolatile memory of the HSM.

[0011] The application is further provided with: S21: the sender application generates data to be transmitted, the SECOC module obtains the current freshness value (FV) from the freshness value manager, and the freshness value is automatically incremented in the counter mode; S22: the SECOC module splices the data to be transmitted and the complete freshness value, calls the HSM to perform the AES-CMAC operation using the pre-shared symmetric key to generate the complete CMAC; S23: the sender combines the original data, the truncated CMAC (Truncated MAC) and part of the freshness value and transmits them through the internal vehicle network (S103); S24: the receiver reconstructs the complete freshness value according to the received part of the freshness value, compares the reconstructed complete freshness value with the locally maintained FV state, and after the comparison is consistent, calls the HSM to calculate the local CMAC using the same pre-shared symmetric key, the received data and the reconstructed complete freshness value, and the comparison of the local CMAC and the received Truncated MAC is consistent, and the verification is passed.

[0012] The application is further provided with: S31: the diagnostic instrument sends the Client Hello message to the vehicle-mounted Ethernet gateway controller, including the supported TLS version, the client random number, the cipher suite list and the elliptic curve list; S32: the vehicle-mounted Ethernet gateway controller returns the Server Hello message, including the selected TLS version, the server random number generated by the HSM and the extension information; S33: the vehicle-mounted Ethernet gateway controller sends the X509 format EDDSA root certificate and the device certificate chain stored in the HSM, calls the HSM to generate the ECDH temporary key pair, sends the temporary elliptic curve public key parameter and the HSM signed random number and public key parameter; S34: the vehicle-mounted Ethernet gateway controller sends the certificate request and the Server Hello Done message, and the diagnostic instrument returns the certificate chain, the HSM uses the RSA algorithm to sign and verify the certificate validity; S35: the diagnostic instrument generates the ECDH temporary key pair and sends the public key parameter, the two parties calculate the pre-master key through the ECDH algorithm, and the HSM generates the master key and the session key in combination with the client random number and the server random number; the diagnostic instrument sends the Change Cipher Spec and the encrypted Client Finished message, the vehicle-mounted Ethernet gateway controller opens the 13400 port after the verification is passed, and periodically monitors the heartbeat signal, and if the heartbeat is lost or wrong, the port is closed.

[0013] The application is further configured that the specific flow of the security refresh verification in step S4 comprises: S41, the cloud OTA server or the diagnostic instrument upgrade system calculates the SHA-256 hash value of the upgrade firmware, signs the hash value using the RSA private key reserved by the automobile host factory, and generates an upgrade package containing the upgrade firmware and the digital signature; S42, after the vehicle-mounted Ethernet gateway controller receives the upgrade package, the old firmware in the FLASH is erased, the HSM is called to calculate the SHA-256 hash value of the upgrade firmware, and the original hash value is obtained by using the RSA public key preset in the HSM to resolve the digital signature; S43, the hash value calculated by the HSM is compared with the original hash value obtained by resolving the signature, and if they are consistent, the verification is passed, the old firmware of the vehicle-mounted Ethernet gateway controller is invalidated and the validity flag of the new firmware is set, and the HSM is called to update the security start trust root; if they are inconsistent, the upgrade is terminated and the old firmware is reserved.

[0014] The application is further configured that for the non-inductive OTA product, the OTA boot program and the App application are integrated in the same software firmware, and the security start verification in step S1 is performed only once; after the OTA upgrade is successful, the API interface of the HSM is directly called by the vehicle-mounted Ethernet gateway controller to calculate and update the security start trust root of the integrated software firmware, and it is not necessary to separately verify the OTA boot program and the App application.

[0015] The application is further configured that the security start verification in step S1 supports two modes of serial start and parallel start; when the serial start is used, the HSM first verifies the OTA boot program, releases the main core to run the OTA boot program after the verification is passed, and then the HSM is called by the OTA boot program to verify the App application; when the parallel start is used, the HSM synchronously verifies multiple software modules, and the main core is released after all the verification is passed, and if the verification of any module fails, the main core remains in the reset state. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 It is a schematic diagram of the architecture of the vehicle gateway information security system in which the HSM is involved. Figure 2 It is a schematic diagram of the security start flow in which the HSM is involved. Figure 3 It is a schematic diagram of the security communication flow in which the HSM is involved. Figure 4 It is a schematic diagram of the TLS bidirectional authentication in which the HSM is involved. Figure 5 It is a schematic diagram of the security refresh in which the HSM is involved.

[0017] In the figure: S100, vehicle-mounted Ethernet gateway main controller; 101, HSM; 102, OTA Master node; S103, internal vehicle network. DETAILED DESCRIPTION

[0018] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. The described embodiments are only some of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0019] In the following description, the specific embodiments of the present application are executed in the software and hardware system in Figure 1 , unless otherwise specified.

[0020] The term "module" or "component" used in the text can be regarded as a software object executed on the security system. Different components and modules in the text can be regarded as implementation objects on the operation system. The apparatus and method in the text are preferably executed in the software combined with the HSM (S101) hardware, and all fall within the protection scope of the present application.

[0021] The flow methods and the participation of the HSM (S101) will be introduced in the order of secure boot, secure communication, secure authentication and secure refresh.

[0022] The secure boot flow in which the HSM (S101) participates can refer to Figure 2 , and the steps are described as follows: The secure boot can be set according to the software components to be verified, and divided into serial boot and parallel boot. According to the actual chip characteristics, the HSM (S101) security core must be started first, and the Host main core is released after the secure boot verification performed by the HSM (S101) security core is completed or the main core is not subjected to the secure verification and directly released to run the main core code to call the API function interface of the HSM (S101) to check the secure boot verification result. If the secure boot verification results are inconsistent, the system can be in a reset state.

[0023] The specific implementation process of the serial boot mode of the plurality of software modules will be described by taking the Boot or OTA code and the application product code to be verified as examples. First, the HSM (S101) core needs to be enabled on the circuit board of the vehicle Ethernet controller. The HSM (S101) core can be enabled by writing a configuration word through a burning tool, and the Code flash code running address range, the Data Flash address range, the first address of the interrupt vector table of the HSM (S101) core start, and the firmware object file compiled from the source code of the HSM (S101) core running are also specified.

[0024] After the setting is successful, power off and power on are needed to take effect. After the effect, the main core will no longer be able to erase and write the Code Flash area and the Data Flash area used by the HSM (S101). Only the HSM (S101) core has control right. The second erasing and writing of the HSM (S101) by the burning tool software or the rewriting of the security-related configuration word will fail. This process is irreversible. In order to prevent hardware loss caused by incorrect firmware burning, the software upgrade scheme of the HSM (S101) firmware needs to be considered in advance. The HSM (S101) firmware self-updating is realized. The running code of the HSM (S101) is executed in the designated Code Flash area. The security-related keys, logs, certificates and the like are stored in the designated Data Flash area. They can only be rewritten through the flash drive of the HSM (S101). Therefore, in addition to the security algorithms required for the development of the main core security function, the self-updating function and the storage function also need to be developed in the firmware development stage of the HSM (S101). The inter-core communication between the main core and the security core, how to pass variables to ensure that the variable values cannot be tampered with, is also an important factor to be considered in the development stage.

[0025] Next, the code security area to be verified needs to be set in the HSM (S101) to inform the HSM (S101) to perform the security start key calculation. The security start can be enabled in the HSM (S101) core source code and this area is set. The security start verification of the OTA / Boot software is performed in the HSM (S101) core. The start address of the OTA code and the length to be verified are set. The HSM (S101) reads the data in the OTA code area according to these information and uses the Boot Key to participate in the operation to obtain the operation result. The operation result is written into the Key slot of the Boot MacKey as the security start trust root. In the subsequent each start of the HSM (S101), the current OTA code area data is read and used to participate in the operation. The operation result is compared with the trust root stored in the Boot MacKey slot. If they are consistent, the main core is allowed to jump to the OTA code and run. Otherwise, the start is not allowed and stops in the HSM (S101) security core.

[0026] Here, the algorithm for calculating the secure boot trust root can be the RSA signature algorithm or the AES-128(CMAC), and the algorithm description is roughly as follows: if the RSA algorithm is used, the HASH value is compared each time, and the public key of the RSA is used to obtain a set of hashes by resolving the stored trust root signature; a set of hashes is obtained by reading the current OTA code data through the HSM (S101) and performing hash operation, and the two sets of values are compared, if the AES algorithm is used, AES-128(CMAC) operation is performed each time, and the previously stored trust root CMAC value is compared, it should be noted that: the key Key participating in the RSA signature and signature or participating in the AES-128(CMAC) operation does not require one key for one product, and the same value can be specified, and one key for one product needs to load different keys for each product in the production link, and the implementation needs to be performed according to the requirements of each host manufacturer, and the key needs to be specially processed to control its secrecy.

[0027] After the Boot code is securely started, the HSM (S101) is called in the Boot code area to execute the security algorithm to check the security trust root of the App, and the method is similar to the above, and the security start algorithms of Boot and App can be selected respectively.

[0028] For non-sensing refresh products, the Boot code means that it cannot be updated after leaving the factory, and for sensing OTA products, the OTA function and application software function are integrated in one code, and only one security start needs to be performed, and the security trust root is updated in the HSM (S101) in time after the subsequent software is updated through the security OTA process, so as to facilitate the smooth start next time, this step is realized in the OTA upgrade code, and after successful upgrade, the API interface of the HSM (S101) is added to execute the security start key calculation and key update action, and the software maliciously tampered with through the security refresh process will not update the trust root key, and even if the tampering takes effect, the next power-on start will still be intercepted by the security start mechanism to avoid malicious damage.

[0029] The key elements used for security start verification are stored in the secure HSM (S101), and the security algorithm is accelerated by the HSM (S101), thereby improving the security performance, The SECOC security communication establishment process in which the HSM (S101) participates is as follows: The specific execution process of the SECOC security communication conforms to the requirements in the Autosar specification, the HSM (S101) is mainly used to call the CMAC calculation of the main core, and the key used for CMAC calculation can also be stored in the HSM (S101) module to improve the security, and the specific reference can be made to Figure 3 , and the step description is as follows: 1. Sender data preparation: Application of the Ethernet gateway controller generates data to be sent; 2. Freshness value acquisition: SECOC module requests a current FV from the freshness value manager, assuming a counter mode, the counter is incremented; 3. CMAC calculation: SECOC module uses a pre-shared symmetric key, takes data and full FV as input, calls HSM (S101) to perform AES-CMAC calculation to obtain a complete CMAC; Formulaic expression: CMAC = Crypto_Function(Key, Data | Full_FV), (| represents splicing) 4. The original data, Truncated MAC and possibly a part of Freshness Value (if the bus space allows) are combined for transmission; 5. The receiver reconstructs the expected full FV according to the received part of FV and the locally maintained FV state (such as the expected counter value or time window), and compares it with the received FV. If the FV verification is passed, the receiver uses the same pre-shared key as the sender, the received data and the reconstructed full FV to calculate the local MAC using the same algorithm, and compares the MAC. If the two are completely matched: the verification is successful, the receiver is sure that the message comes from a legitimate sender and is not tampered with, and the message is fresh. If the two are not matched: the verification fails, the message is considered invalid or tampered, and is discarded immediately.

[0030] TLS two-way authentication secure transmission protocol in which HSM (S101) participates: Main processes in which HSM (S101) participates: 1. Store pre-set device certificate and root certificate, corresponding to step two below; 2. Use ECDHE in HSM (S101) to generate temporary keys, corresponding to step three below; 3. Key negotiation generates pre-master key, corresponding to step six below; 4. Certificate verification, use RSA to sign, corresponding to steps five and seven below; 5. Calculate master key and session key through pre-master key, corresponding to step eight below.

[0031] The steps of the TLS process are roughly introduced as follows, and the specific process can be referred to Figure 4 : First step: Client Hello, the client initiates a connection to the server, here the client refers to the external diagnostic instrument equipment, after a successful handshake using the TLS dedicated TCPIP port assigned in the code, a Client Hello message is sent, containing: supported TLS version, client random number: a random string generated by the client, used for subsequent key generation, supported cipher suite list: a list of encryption algorithm combinations supported by the client, sorted by priority; For example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; ECDHE: key exchange algorithm; RSA: authentication algorithm; AES_128_GCM: symmetric encryption algorithm; SHA256: hash algorithm for integrity check, and supported elliptic curve list.

[0032] Second step: Server Hello, here the server refers to the vehicle Ethernet gateway controller, the server responds with a Server Hello message; containing: selected TLS version; server random number: a random string generated by the server, the generation of the random number can call HSM (S101) to obtain a true random number to improve security, used for subsequent key generation; selected cipher suite: a cipher suite selected from the list provided by the client: this example uses the algorithm combination TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256; In addition, some extension information will also be issued, indicating the elliptic curve point format, renegotiation information and whether to use the extended master key, these parameters will affect the format of the subsequent ECDHE key exchange and the generation of the master key.

[0033] Third step: Server Certificate, the specific content sent is the certificate, which is released in advance by the software requirements and stored in the secure Data Flash area of the HSM (S101) through the configuration of the HSM (S101), this example is an X509 format EDDSA root certificate and a preset device certificate on the same chain, after receiving the certificate chain sent by the server, the client will verify whether it is signed by a trusted CA (check the trust chain), whether the domain name in the certificate matches the SNI, whether it is within the valid period, whether it is revoked, etc.

[0034] Fourth step: Key exchange Server Key Exchange, which is the core step of ECDHE key exchange, the vehicle Ethernet gateway calls the HSM (S101) to generate a temporary ECDH key pair containing a public key and a private key, and sends a temporary elliptic curve public key parameter (for example: EC Diffie-Hellman curve name: x25519, public key length and public key content); The HSM (S101) uses the generated ECDH temporary private key to sign the random number sent by the client and the server random number and the temporary public key parameter and send it after the public key parameter, which is sent together with the third part of the data.

[0035] Fifth step: Two-way authentication only step: Gateway controller requests the certificate of the client diagnostic instrument CertificateRequest, the sending content includes: the public key algorithm type accepted by the gateway controller, the supported signature algorithm list and the supported certificate authority list which only trusts the certificates issued by which CA, after sending the certificate request, the gateway server then sends Server Hello Done to indicate that the hello message of the server has been sent.

[0036] Sixth step: The client diagnostic instrument sends the certificate chain, the gateway controller calls the HSM (S101) to perform RSA algorithm to judge the integrity of the certificate, and performs extraction of the certificate information, validity period judgment and whether it is issued by a trusted CA, which is the same as the client's certificate chain verification process in step three.

[0037] Seventh step: Client Key Exchange Client Key Exchange and Certificate Verify, the client also generates a temporary ECDH key pair, and the client sends its temporary elliptic curve public key parameter to the server. At this time, the key exchange is completed: the client has: its own temporary private key + the server's temporary public key; The server has: its own temporary private key + the client's temporary public key; Both sides independently calculate the same pre-master key using the ECDH algorithm; Certificate Verify: This is a key step for the client diagnostic instrument to prove that it indeed has the private key corresponding to the certificate it sends, the client diagnostic instrument uses its ECDSA private key to sign all handshake messages so far (not just a certain random number), the client diagnostic instrument sends this signature, and the gateway controller server uses the ECDSA public key in the client certificate to perform RSA calculation through the HSM (S101) to perform signature verification, if the verification fails, the handshake will be terminated immediately.

[0038] Eighth step: Generate encryption key and switch Generate Master Secret: Client Diagnostics and Gateway Control Server use the Pre-Master Secret, Client Random, Server Random, to generate the Master Secret via a PRF (Pseudo-Random Function, based on SHA256) Derive Session Keys: From the Master Secret, derive the actual symmetric encryption key (AES-128 key), GCM mode's initialization vector, etc. See the Key Calculation and Derivation flowchart in Figure 3 Change Cipher Spec: Client sends this message to inform the server: "From now on, I will send encrypted data using the agreed encryption suite and key." Client Finished: Client sends the first encrypted Finished message, which contains a digest of all handshake messages, for the server to verify the integrity of the handshake process and the correctness of the keys.

[0039] At this point, the TLS handshake is complete, and a secure, two-way authenticated encrypted channel has been established. Subsequently, the client and server begin using symmetric encryption algorithms (such as AES) and session keys to encrypt application layer data, in this case, a heartbeat message, and message authentication codes to ensure data integrity.

[0040] After the TLS handshake is complete, open the TCPIP 13400 port that allows DOIP communication in the gateway controller product, and periodically monitor whether the heartbeat signal is lost and whether the heartbeat signal value is incorrect. If the heartbeat is lost or the value is incorrect, immediately call TCPIP_Close to close the open port.

[0041] Security OTA process involving HSM (S101): For details, refer to Figure 5. HSM (S101) plays a key role in the signature verification stage after flashing. The OTA steps are described as follows: First, prepare the upgrade firmware and signature. Download the new firmware from the cloud, which is the final firmware binary file compiled by the developer. Calculate the hash of the firmware: the signature server calculates the cryptographic hash (such as SHA-256) of the firmware file. Perform RSA data signature on the just-calculated Hash digest (core security step). Here, the car manufacturer uses the reserved RSA private key to sign the hash generated by the upgrade package firmware, which is used to pass the upgrade package and corresponding signature information to the vehicle Ethernet gateway controller during the flashing stage.

[0042] ​The RSA public key is released to the component development supplier, i.e. the manufacturer of the vehicle Ethernet gateway controller, and is configured and solidified into the HSM (S101) core D-flash area of the vehicle Ethernet gateway in the R&D stage, so that the key is securely stored.

[0043] Next, the OTA upgrade process is performed, which can be performed by remote upgrade, for example, the Ethernet DoIp protocol, and the initiator can be an Ethernet OTA Master node in the vehicle (S102) or an external diagnostic instrument device for OBD diagnosis. The gateway controller receives the OTA upgrade instruction to perform FLASH erasing, and after erasing is completed, enters the next stage: security verification.

[0044] In the security verification stage, the vehicle Ethernet gateway controller recalculates the hash value of the received firmware file. The algorithm execution needs to call the API interface of the HSM (S101) to perform HASH operation to obtain the HASH value. The vehicle Ethernet gateway controller uses the public key stored in the HSM (S101) to decrypt the digital signature attached in the OTA firmware package to obtain the original HASH value. If the two hash values are completely consistent, it proves that the firmware has not been tampered with during transmission, i.e. integrity, and the firmware indeed comes from the legitimate developer, i.e. authenticity.

[0045] Only after verification is successful, the device will invalidate the old firmware, enable the new firmware effective flag, and reset the security trust root to the HSM (S101). After restarting, it is combined with the HSM (S101) to start safely, forming a double insurance. After verification, the system is started normally.

[0046] The HSM (S101) mainly participates in this stage: the HSM (S101) stores the RSA public key required for verification. This RSA public key must correspond to the RSA private key used to sign the OTA upgrade package. The RSA private key is kept secret by the automobile manufacturer, which has higher security. The HSM (S101) also participates in the calculation of the Hash digest. The HSM (S101) calls the RSA algorithm to obtain the Hash digest by signing, and the security start related to the calculation of the updated software firmware security start trust root key and the operation of updating the HSM (S101) core security storage area.

Claims

1. An information security system for an in-vehicle Ethernet gateway controller based on HSM, characterized in that: include: The vehicle-mounted Ethernet gateway main controller (S100) serves as the system's main processor, running application software such as OTA upgrade software and integrated information security software modules. The hardware security core HSM (S101) is integrated into the CPU chip of the vehicle Ethernet gateway main controller (S100). It is an independent coprocessor core with a secure isolation environment. It integrates a cryptographic algorithm engine, a true random number generator, and protected non-volatile memory. The protected non-volatile memory is used to store the root key, certificate, secure boot verification public key, and secure boot trust root. HSM (S101) has a circuit breaker mechanism that cannot be turned off once it is turned on. It only performs encryption and decryption operations through hardware acceleration. The main core has no right to tamper with the keys stored in it. The diagnostic instrument or vehicle OTA Master node (S102) is connected to the vehicle Ethernet gateway main controller (S100) via the OBD interface. It is pre-loaded with a trust certificate and ECDHE private key, which are used to initiate the TLS two-way security authentication process, the security refresh process and the vehicle gateway diagnostic request. The security refresh process loads an upgrade package with a digital signature. The internal vehicle network (S103) is used to connect the in-vehicle CAN, CANFD, LIN and Ethernet buses to realize signal interaction between the in-vehicle Ethernet gateway main controller (S100) and the in-vehicle Ethernet nodes.

2. The information security system for an in-vehicle Ethernet gateway controller based on HSM according to claim 1, characterized in that: The Code Flash area of ​​the HSM (S101) is designated as a dedicated code execution area, storing only the HSM core firmware code; the Data Flash area is designated as a dedicated data storage area, storing only the root key, certificate, secure boot root of trust, and security log, and the data in the Code Flash and Data Flash areas can only be rewritten through the flash driver of the HSM core; after the fuse mechanism is enabled, the burning tool cannot rewrite the Code Flash area, Data Flash area, and security-related configuration words of the HSM (S101), and the HSM core firmware has a self-update function to prevent hardware loss caused by incorrect firmware burning.

3. The information security system for an in-vehicle Ethernet gateway controller based on HSM according to claim 1, characterized in that: The keys stored in the HSM (S101) support "one key per item" configuration. During the production process, a special programming tool is used to load different root keys and secure boot verification public keys into the HSM (S101) of each vehicle Ethernet gateway controller. The key loading process is subject to confidentiality control procedures to prevent unauthorized access to key data.

4. A method for information security of an in-vehicle Ethernet gateway controller based on HSM, characterized in that, The information security system for an in-vehicle Ethernet gateway controller based on any one of claims 1-3 includes the following steps: S1: Secure boot verification. When the system is powered on, HSM (S101) calls its stored secure boot trust root to perform encryption verification on the software firmware data of the OTA boot program and App application to be started by the vehicle Ethernet gateway controller. If the verification passes, the main core is released and the software is allowed to start; if the verification fails, the startup is prohibited. S2: SECOC Real-time Secure Communication. When the vehicle Ethernet gateway controller interacts with CAN bus signals, it calls the API interface of HSM (S101) to perform symmetric encryption operation on the original CAN message to generate an authentication code. The original message and the authentication code are then combined and transmitted. The receiver calls HSM (S101) to verify the authentication code and freshness value of the received message. If the verification is successful, the message is received; otherwise, it is discarded. S3: TLS transport layer security authentication. The vehicle Ethernet gateway controller disables port 13400 of the DOIP protocol and only opens the TCPIP port of the TLS protocol. The external diagnostic instrument issues a trust certificate through the TLS port. The HSM (S101) participates in certificate chain verification, ECDHE temporary key generation and negotiation of pre-master key, master key and session key. After authentication, port 13400 is opened to execute DOIP protocol interaction. S4: Security refresh verification. During OTA upgrade, the cloud OTA server or diagnostic tool upgrade system uses the RSA private key to sign the upgrade firmware. After receiving the upgrade firmware, the vehicle Ethernet gateway controller calls the HSM (S101) to calculate the firmware hash value and uses the preset RSA public key to decrypt the signature. If the hash values ​​match, the verification is successful, the new firmware is enabled, and the secure boot trust root in the HSM (S101) is updated.

5. The method according to claim 4, characterized in that: The encryption verification operation in step S1 is either an AES-128 CMAC operation or an RSA signature operation. If it is an RSA signature operation, HSM (S101) decrypts the signature of the secure boot root of trust using the RSA public key to obtain the first hash value, and simultaneously reads the firmware data to be booted to calculate the second hash value. If the first hash value and the second hash value are consistent, the verification is successful. If it is an AES-128 CMAC operation, HSM (S101) calculates the CMAC value of the firmware data to be booted, and compares it with the CMAC value of the stored secure boot root of trust. If they are consistent, the verification is successful. After the OTA upgrade is successful, the vehicle Ethernet gateway controller calls the API interface of HSM (S101) to recalculate the secure boot root of trust of the firmware data and updates it to the protected non-volatile memory of HSM (S101).

6. The information security method for an in-vehicle Ethernet gateway controller based on HSM according to claim 4, characterized in that: The specific process of SECOC real-time secure communication in step S2 includes: S21: The sending application generates data to be transmitted. The SECOC module obtains the current freshness value (FV) from the freshness value manager, and the freshness value automatically increments in counter mode. S22: The SECOC module concatenates the data to be transmitted with the complete freshness value, and calls HSM (S101) to perform AES-CMAC operation using the pre-shared symmetric key to generate the complete CMAC; S23: The sender combines the original data, the truncated CMAC (Truncated MAC), and a portion of the freshness value and transmits them through the internal vehicle network (S103); S24: The receiver reconstructs the complete freshness value based on the received partial freshness value. After comparing the reconstructed complete freshness value with the locally maintained FV state, it calls HSM (S101) to calculate the local CMAC using the same pre-shared symmetric key, received data, and the reconstructed complete freshness value. If the local CMAC matches the received Truncated MAC, the verification is successful.

7. The information security method for an in-vehicle Ethernet gateway controller based on HSM according to claim 4, characterized in that: The specific process of TLS transport layer security authentication in step S3 includes: S31: The diagnostic tool sends a Client Hello message to the vehicle Ethernet gateway controller, which includes the supported TLS versions, client random numbers, a list of cipher suites, and a list of elliptic curves. S32: The vehicle Ethernet gateway controller returns a Server Hello message, which includes the selected TLS version, the server random number generated by the HSM (S101), and extended information; S33: The vehicle Ethernet gateway controller sends the X509 format EDSA root certificate and device certificate chain stored in the HSM (S101), and calls the HSM (S101) to generate an ECDH temporary key pair, and sends the temporary elliptic curve public key parameters and the random number and public key parameters after the HSM is signed; S34: The vehicle Ethernet gateway controller sends a certificate request and a Server Hello Done message. The diagnostic tool returns the certificate chain. The HSM (S101) uses the RSA algorithm to design and verify the certificate validity. S35: The diagnostic tool generates an ECDH temporary key pair and sends the public key parameters. Both parties calculate the pre-master key using the ECDH algorithm. The HSM (S101) combines the client's random number and the server's random number to generate the master key and session key. The diagnostic tool sends a ChangeCipher Spec and an encrypted Client Finished message. After the vehicle Ethernet gateway controller verifies the message, it opens port 13400 and periodically monitors the heartbeat signal. If the heartbeat is lost or erroneous, the port is closed.

8. The information security method for an in-vehicle Ethernet gateway controller based on HSM according to claim 4, characterized in that: The specific process of security refresh verification in step S4 includes: S41: The cloud-based OTA server or diagnostic upgrade system calculates the SHA-256 hash value of the upgrade firmware, signs the hash value using the RSA private key retained by the car OEM, and generates an upgrade package containing the upgrade firmware and digital signature. S42: After receiving the upgrade package, the vehicle Ethernet gateway controller erases the old firmware in the FLASH, calls HSM (S101) to calculate the SHA-256 hash value of the upgrade firmware, and uses the pre-set RSA public key in HSM (S101) to decrypt the digital signature to obtain the original hash value. S43: Compare the hash value calculated by HSM (S101) with the original hash value obtained from designing. If they match, the verification is successful. The vehicle Ethernet gateway controller disables the old firmware and sets the validity flag of the new firmware. At the same time, HSM (S101) is called to update the secure boot trust root. If they do not match, the upgrade is terminated and the old firmware is retained.

9. The information security method for an in-vehicle Ethernet gateway controller based on HSM according to claim 5, characterized in that: For seamless OTA products, the OTA bootloader and the App application are integrated in the same software firmware, and step S1 only performs a security boot verification once; after the OTA upgrade is successful, the vehicle Ethernet gateway controller directly calls the API interface of HSM (S101) to calculate and update the security boot trust root of the integrated software firmware, without the need to separately verify the OTA bootloader and the App application.

10. The information security method for an in-vehicle Ethernet gateway controller based on HSM according to claim 4, characterized in that: The secure boot verification in step S1 supports two modes: serial boot and parallel boot. In serial boot, HSM (S101) first verifies the OTA boot program. After the verification is successful, the main core is released to run the OTA boot program. Then, the OTA boot program calls HSM (S101) to verify the App application. In parallel boot, HSM (S101) synchronously verifies multiple software modules. After all verifications are successful, the main core is released. If any module fails verification, the main core remains in a reset state.

Images