CN110708388B - Vehicle body safety anchor node device, method and network system for providing safety service - Google Patents

Abstract

The present disclosure provides a body safety anchor node (VSAN) device, a method of configuring the body safety anchor node device in a local vehicle network or a domain network to provide a global safety service, and a network system providing the safety service to a vehicle. The VSAN device includes a processor, a secure memory, a secure random number generator, and a cryptographic algorithm engine, the processor configured to: sending a security service confirmation to the communication node in response to the security service request from the communication node; and/or sending a security service notification to the communication node and receiving a security service response from the communication node. Through the scheme, the vehicle development and maintenance cost is reduced on the basis of improving the safety performance of the vehicle network, and the reaction time of safety events is shortened.

Description

Vehicle body safety anchor node device, method and network system for providing safety service

Technical Field

The present disclosure relates to a security service, and more particularly, to a vehicle body security anchor node apparatus for providing a security service in a local vehicle network or a domain network, a method of configuring a vehicle body security anchor node in a local vehicle network or a domain network to provide a security service, and a network system for providing a security service to a vehicle.

Background

With the development of automobile informatization, the number of electronic nodes of an automobile body is remarkably increased. The electronic nodes can provide various services such as sensing monitoring, automatic and intelligent operation and display, communication interconnection and the like. Data communication scenes between nodes of a vehicle body, between functional domains and between the functional domains and external networks are more and more, and the speed and bandwidth of network communication are continuously increased. With the attendant increased threat and challenge in information security. In order to prevent property and physical security loss of vehicle manufacturers and end users caused by malicious attacks, information security threats from all aspects need to be fully considered when designing electronic network architectures of vehicles, information security requirements are defined, and information security functions of electronic nodes for communication and whole vehicle networks are planned.

In general, a communication node needs to have a highly reliable hardware Security module, also referred to as a Security Anchor (Security Anchor), or a corresponding functional module as a basic part of a Security trust chain, providing functions such as physical storage to prevent tampering and support secure access, secure random number generation, and implementation of encryption algorithms. Fig. 1 shows the topology of an existingvehicle network 100. Ecus (electric Control units) 101 to 108 as communication nodes in thevehicle network 100 are communicatively connected to each other via abus 110. There is a need for secure communication for each ECU.

In order to realize important information safety of the vehicle body, each related communication node is provided with a safety anchor in the prior art, which significantly increases the system complexity and the overall cost of each communication node. As long as a link is broken, the entire system is no longer secure. The background security service center is difficult to obtain a comprehensive and accurate security state report, and cannot take timely and effective emergency measures to reduce the loss caused by security accidents. In addition, in order to preset, update and maintain the above security data contents, a lot of production line time is required, increasing the manufacturing cost of the vehicle and the risk of information leakage. Updating the above data through a diagnostic configuration at a 4S store faces the same difficulties.

Accordingly, there is a need for improvements to security service solutions in existing vehicle networks.

It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.

Disclosure of Invention

According to an embodiment of the present disclosure, an In-Vehicle Security Anchor Node (VSAN) device for providing Security services to a local Vehicle network or a local area network through a set of secure communication protocols is provided. The vehicle body safety anchor node device is the only safety anchor on a local vehicle network or a network domain, is used as a node with the highest safety performance, uniformly monitors network safety events, and provides timely and accurate network safety state reports to a backstage online safety center or a vehicle body controller. The vehicle body safety anchor node device can be used as an online safety center agent, can conveniently manage a certificate chain and a key system related to a whole vehicle, can generate effective identities for all communication nodes in a local vehicle network or a domain network based on the hardware fingerprint characteristics (such as hardware serial numbers) of communication nodes in the vehicle without depending on an external certificate chain system, and supports identity authentication between the communication nodes. The unique vehicle body safety anchor node equipment can reduce the processing reaction time of safety events and reduce the loss caused by network attack and security holes.

According to an aspect of the present disclosure, a body security anchor node (VSAN) device for providing global security services to all communication nodes in a local vehicle network or a domain network is provided, wherein the body security anchor node device comprises a processor, a secure memory, a secure random number generator, and a cryptographic algorithm engine, the processor being configured to:

sending a security service confirmation to a communication node in the local vehicle network or a domain network in response to a security service request from the communication node; and/or sending a security service notification to the communication node and receiving a security service response from the communication node for the security service notification.

According to an embodiment of the present disclosure, sending a security service confirmation to a communication node in the local vehicle network or domain network in response to a security service request from the communication node comprises at least one of:

sending an acknowledgement to the communication node whether communication is allowed or not, in response to the communication node's request to initiate communication;

verifying an identity of the communication node based on at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information stored in the secure memory in response to a request for authentication of the communication node, and transmitting an authentication result to the communication node;

generating, by the secure random number generator, a high-strength random number in response to a request of the communication node to allocate the high-strength random number, and transmitting the high-strength random number to the communication node;

transmitting, to the communication node, at least one of the key and the digital certificate stored in the secure memory in response to a request of the communication node to acquire or update at least one of the key and the digital certificate;

in response to a request of the communication node for at least one of reading, storing and deleting a data file, verifying an operation authority of the communication node for the data file and sending confirmation to the communication node to allow or deny the operation;

in response to a request of the communication node to access firmware, transmitting at least one of a key, a digital certificate, and a raw hash value corresponding to the firmware stored in the secure memory to the communication node;

sending an acknowledgement of an encryption mode of data transmission to the communication node in response to a request for the encryption mode of data transmission by the communication node, wherein the encryption mode of data transmission comprises at least one of asymmetric encryption, symmetric encryption and signature;

recording a security event of the communication node in response to a request of the communication node to report the security event; and

and responding to the request of the communication node for encrypted data transmission, and sending or receiving a data message encrypted in a pre-agreed encryption mode from the communication node to the communication node.

According to an embodiment of the present disclosure, sending a security service notification to the communication node, and receiving a security service response from the communication node for the security service notification comprises at least one of:

sending a notification of authentication to the communication node and receiving a response of an authentication result from the communication node;

sending a notification of an encryption of a data transmission to the communication node and receiving a response from the communication node of the encryption of the data transmission, wherein the encryption of the data transmission comprises at least one of asymmetric encryption, symmetric encryption and a signature;

sending a notification of at least one of the renewal key and the digital certificate to the correspondent node and receiving a response from the correspondent node of the at least one of the renewal key and the digital certificate; and

and sending a notification of encrypted data transmission to the communication node, and sending or receiving a data message encrypted in a pre-agreed encryption mode from the communication node to the communication node.

According to another aspect of the present disclosure, there is provided a method of configuring a vehicle body security anchor node (VSAN) device as described above in a local vehicle network or a domain network to provide a global security service, including: communicatively connecting the body safety anchor node device with all communication nodes in the local vehicle network or the domain network through a vehicle bus, and configuring the body safety anchor node device to provide safety services to the communication nodes.

According to yet another aspect of the present disclosure, a network system for providing safety services to vehicles is proposed, comprising at least one local communication network and/or at least one domain network, each of the local communication network and the domain network having at least one communication node,

each of the local communication networks or each of the domain networks is configured with a body safety anchor node (VSAN) device as described above communicatively connected to each of the communication nodes in the local vehicle network or the domain network through a vehicle bus and providing global safety services to all of the communication nodes.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The above and other features and advantages of the present disclosure will become more apparent by describing in detail exemplary embodiments thereof with reference to the attached drawings.

FIG. 1 is an exemplary schematic diagram of the topology of an existing electronic network inside a vehicle;

fig. 2 is a schematic diagram of an exemplary structure of a conventional communication node;

FIG. 3 is a schematic diagram of a prior art secure boot process using HSM unit verification of a communication node;

FIG. 4 is a schematic diagram of a topology of a vehicle network according to an exemplary embodiment of the present disclosure;

FIG. 5 is a schematic block diagram of a body safety anchor node VSAN according to an exemplary embodiment of the present disclosure;

fig. 6 is a schematic block diagram of a communication node according to an example embodiment of the present disclosure;

FIG. 7 is a schematic diagram of an interaction between a communication node and a VSAN in accordance with an exemplary embodiment of the present disclosure;

FIG. 8 is a schematic process diagram for providing vehicle network security services using a VSAN and a communication node in accordance with an exemplary embodiment of the present disclosure;

FIG. 9 is a schematic diagram of a process by a VSAN to generate identity information for all communication nodes while a vehicle is off-line or in after-market repair, according to an exemplary embodiment of the present disclosure; and

fig. 10A and 10B are further details of a communication node during a secure boot process according to an embodiment of the disclosure.

Detailed Description

Exemplary embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art. In the drawings, the size of some of the elements may be exaggerated or distorted for clarity. The same reference numerals denote the same or similar structures in the drawings, and thus detailed descriptions thereof will be omitted.

Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, etc. In other instances, well-known structures, methods, or operations are not shown or described in detail to avoid obscuring aspects of the disclosure.

In the following, the term "communication node" is used in a unified way to denote an electronic node communicating with other electronic nodes, sensors, network domains, devices and networks outside the vehicle in a local vehicle network or domain network. Communication nodes include, but are not limited to, Electronic Control Unit (ECU) nodes in a vehicle network, conventional or intelligent sensors, multimedia video or audio devices, databases, gateways, subsystems with complex functionality, and the like. For a "node", it may be a logical node in the network architecture, and may also be a node device in the network system. The term "authentication" refers to verifying whether a user has the right to access a system, device or function, and hereinafter, unless otherwise stated, authentication is equivalent to authentication. The term "vehicle network" may refer to a partial network of vehicles or a network of vehicles as a whole covering the interior and/or exterior of the vehicle, and may also include a local vehicle network or a domain network, and the scope covered by the vehicle network will not be further differentiated hereinafter.

The vehicle information security requirements mainly comprise data protection, safe starting, intrusion detection and the like. Wherein, the data protection includes: sensitive data is not revealed; the data accessor and the user have legal authority; and the integrity and legitimacy of the data content.

The sensitive data includes data related to vehicle body safety and user property life safety and network communication contents, such as keys and certificates for safety communication, private information of customers, real-time position information and driving information of vehicles, unlocking command messages and the like. Sensitive data typically needs to be encrypted and stored on a secure storage medium that is not easily hacked.

Visitors of the data comprise user keys, mobile phones, other communication nodes in a local vehicle body network, network communication objects outside the vehicle, such as a diagnostic instrument, a background server and the like. When establishing communication connection and communicating with a data visitor, the identity of the data visitor needs to be authenticated and the data access authority of the data visitor is judged.

After receiving the data and before using the data, whether the data is complete and the source is legal needs to be checked, whether the data is tampered is judged, and the integrity and the legality of the data are guaranteed.

According to the function of the whole vehicle electronic network, the general vehicle body information safety function is embodied into three types: the system comprises interconnection communication protection, vehicle body network communication protection and safety access protection. For communication nodes such as ECU devices having rich external interconnection interfaces, for example, Telematics devices, Head up display units (Head units), High Performance computers (High Performance computers), and the like, it is necessary to emphasize protection of interconnection communication services. For communication nodes implementing route forwarding services in a vehicle network, such as gateways, body controllers, etc. at a central location of the vehicle network, it is necessary to heavily consider the protection related to communication within the vehicle network. For communication nodes such as domain controllers and functional modules, there is a need to emphasize secure access related protection of sensitive data.

In order to achieve the above security functions and achieve the security objectives, the entire vehicle network system of the motor vehicle includes various communication nodes, and the background infrastructure needs to have a necessary software hardware platform to support the related protocol algorithms and secure data storage transmission. Therefore, the communication nodes in the vehicle network need to have the capability to process and maintain the following safety-related data content: a digital certificate comprising a root certificate and a certificate chain; asymmetric keys such as public and private keys and symmetric key data; generating a real-time random number; a security polynomial; sensor data (user biometric, password, etc.); and a secure boot.

For example, mutual authentication between communication nodes in a vehicle network and between a communication node and an off-board device is typically achieved through digital certificates and cryptographic keys (e.g., upon startup or wake-up of the communication node). Digital certificates used for signing and authentication are generally public and may include a public key of a public-private key-pair. The root certificate and certificate chain (digital certificate chain) are used to verify that the signature is legitimate, with the root certificate being used for verification of all other digital certificates. Or directly obtaining the public key and the private key data in the public and private key pair. Authentication can also be performed between the communication nodes and the off-board equipment by using a security polynomial or identity authentication based on hardware fingerprints. The security polynomial has a Hash (Hash) characteristic, which is a pre-agreed encryption algorithm that performs authentication (e.g., for diagnosis and secure access) using a result of substituting a challenge number into a security polynomial calculation, and is one of the main ways of performing authentication between communication nodes of a current vehicle internal network.

The paired public and private keys are used as an asymmetric encryption mode, and the overhead is relatively high, so that the communication nodes in the vehicle network can encrypt the transmitted data messages by negotiating the encryption mode of the symmetric keys after the authentication is completed. A symmetric key for symmetric encryption may be generated by a public-private key pair and a randomly generated number. The secure channel used for data transmission is typically protected by symmetric encryption based on a secure key. In general, data transmission between communication nodes in a vehicle network is protected by a symmetric key and a cryptographic algorithm that are commonly held by two or more parties. Any communication node on the vehicle body and the external device are generally encrypted by a public-private key pair which is asymmetrically encrypted, for example, a random number, a challenge number and a security polynomial which both parties have in common in advance are used for realizing secure access.

When software and firmware of any communication node in the vehicle network are started, safe software starting is realized by methods such as digital signature and safe authentication based on a digital certificate or a secret key, and the correctness and the legality of running software are guaranteed.

For the integrity and legitimacy of the data message, any communication node in the vehicle network is then guaranteed by a cryptographic algorithm (e.g. HMAC) signature based on a key held in common by both or more parties. The HMAC can be used as a plaintext signature algorithm to ensure that data is not tampered, but is only used for message data integrity and legality but not for authentication and encryption because the HMAC does not have an encryption function.

The communication node needs a highly reliable hardware Security module, also referred to as Security Anchor (SA), or a module with corresponding functionality as a basic part of a secure trust chain to provide the above-mentioned Security functionality and to achieve Security goals. The safety anchor needs to have at least the following basic parts: 1) a secure memory for providing physical storage functions that are tamper-resistant and support secure access; 2) a secure random number generator for generating a secure random number; 3) an encryption algorithm engine for encrypting and decrypting data using an encryption algorithm. A typical example of a Security anchor for a communication node is a Hardware Security Module (HSM) within the communication node. The reason for using the hardware security module is that the physical hardware-based solution has higher security and reliability than the software-based solution. For example, some hardware security modules may meet the security Standards (Level 4) required by the national Information Processing Standards (FIPS) 140-1, 140-2. By adopting the HSM module as a safety anchor, the safety of a system such as a physical tampering detection mechanism and protection against environmental attacks can be effectively improved. In addition, the encryption and decryption engine adopting hardware can accelerate the process of encryption and decryption algorithms such as RSA, SHA and the like.

Fig. 2 shows an exemplary schematic structure of acommunication node 200 in an existing vehicle network. Eachcommunication node 200 comprises aprocessor 201, a memory (RAM)202, amemory 203 such as Flash memory, Read Only Memory (ROM) for storing firmware and other important data, aclock 204 for providing a timing reference, apower management unit 205, acommunication interface 206 for communicating with other communication nodes, functional domains or vehicle external devices in the vehicle network via a bus,peripheral devices 207 for supporting peripheral functions of thecommunication node 200, and a separately provided securityanchor HSM unit 208.

Fig. 3 shows a schematic diagram of a secure boot process of a communication node using HSM unit verification.

The secure boot process is divided into an offline generation sub-process 300A of the secure firmware and a sub-process 300B in thecommunication node 301. In the off-line securefirmware generation sub-process 300A, the compiled firmware files are first obtained in step 300-1, and then the HASH (HASH) value of the firmware files is calculated in step 300-2, for example, using the SHA algorithm. In step 300-3, the computed hash value is cryptographically signed by aprivate key 311, e.g. based on the RSA encryption algorithm. In step 300-4, the firmware is combined with the signature data obtained by signing the hash value and stored in the Flash memory of thecommunication node 301.

In the communication node'sstart subprocess 300B, thecommunication node 301 reads thesignature data 314 and thefirmware file 315 in the combined data from the Flash memory and processes them separately. In step 300-5, the RSApublic key 312 corresponding to the RSAprivate key 311 and the corresponding digital certificate orcertificate chain 313 are retrieved from the non-tamperproof secure memory of thesecurity anchor 208 in thecommunication node 301, and thesignature 314 is signed and decrypted to obtain the hash value calculated in step 300-2. Step 300-5 effectively completes the authentication of thecommunication node 301. If thecommunication node 301 does not have access to thefirmware 315, the signature will not be decrypted using thecertificate 313 in thesecurity anchor 208 and the RSApublic key 312.

At the same time as step 300-5,communication node 301 performs the hash value calculation again forfirmware 315 at step 300-6 to obtain a new hash value. In step 300-7, the Bootloader ofcommunication node 301 compares the hash values obtained in steps 300-5 and 300-6, respectively. If the comparison result shows that the two are consistent, thecommunication node 301 is indicated to have legal operation authority on the firmware and the hash value of the firmware is not tampered (i.e. the data of the firmware is complete and legal), and the secure boot is successful; if the comparison result is that the two are not consistent, it indicates that thecommunication node 301 has no legal operation authority on the firmware, or the firmware data is tampered, and the secure boot fails.

Through the process, the local safety anchor of the communication node provides key guarantee for the safety, the legality and the integrity check of the firmware.

However, the applicant has found that the above-mentioned security service method has many disadvantages.

In order to realize important information security of a vehicle network inside a vehicle, independent security anchors are arranged inside related communication nodes, which will significantly increase the system complexity of each communication node and the cost of the whole vehicle.

The information safety of the whole vehicle system is composed of the information safety of each subsystem, and is similar to a safety chain. However, as soon as one link in the safety chain is broken, the entire system is no longer safe. The safety anchors of the information safety architecture of the existing vehicle network are distributed on the communication nodes connected on each bus of the vehicle network, and the software and hardware of each communication node are designed by a plurality of different suppliers according to different design standards, so the safety performance of the architecture is not optimal relatively, and needs to be further improved.

In the existing vehicle network architecture, the information security module of each communication node is mainly responsible for the security requirements of the communication node, and an overall information security management and supervision node is not provided for managing the security state of each bus in the whole vehicle network. Therefore, it is difficult for the background security service center in remote communication with the vehicle to obtain a comprehensive and accurate security status report on the vehicle network, so that it is impossible to effectively take emergency measures in time to reduce the loss due to a security accident when a security failure occurs.

In addition, in order to preset, update and maintain various security data contents of the vehicle, all important information security-related communication nodes need to be operated by means of factory offline configuration and online update or 4S shop diagnostic configuration and the like. For example, in the off-line configuration stage of the factory, the above security data needs to be written separately to each important information security-related communication node through a diagnostic command, which takes a lot of production line time. Meanwhile, a factory production equipment system needs to manage a large amount of sensitive safety data, the requirement on information safety is very high, and the manufacturing cost of the vehicle and the risk of information leakage are increased.

The same difficulties are encountered when updating the above data in a 4S store by means of a diagnostic arrangement. For example, by updating the above security data online, the Public Key Infrastructure (PKI) is managed and distributed, usually in the background, through a trusted online security center (OTC), and the relevant data is upgraded by means of online updating (OTA). This requires the vehicle to have a secure online environment and significant online time to download data that upgrades important information security communication nodes on all vehicle networks.

Fig. 4 illustrates the topology of avehicle network 400 according to an exemplary embodiment of the present disclosure. Thevehicle network 400 has a plurality of communication nodes 401-1 to 401-6, such as ECUs, that are communicatively connected to each other by abus 404 in the vehicle network. It should be understood that the number ofcommunication nodes 401 shown in fig. 4 is merely exemplary, and other numbers of communication nodes may be employed depending on the application. The bus architecture of theVehicle network 400 is further provided with an individual Vehicle body Security Anchor Node (VSAN) 402 for providing a Vehicle Security service function to all communication nodes 401-1 to 401-6 In the Vehicle network and a set of communication protocols for providing Security services. The VSAN402 is in two-way communication with a back-officeonline security center 403 that is remote from the vehicle.

Details of portions of some local vehicle network (or domain network) 400 in fig. 4 will be described in detail below, respectively.

Figure 5 is a schematic structural diagram of a VSAN according to an exemplary embodiment of the present disclosure.

VSAN402 includes a processor 4021, asecure memory 4022, a securerandom number generator 4023, a cryptographic algorithm engine 4024, and acommunication interface 4025. VSAN402 may also include other units not shown in the figure, such as a memory (RAM) for storing data used by processor 4021 when running, a clock, a power management unit, and the like. The VSAN402 may be viewed as a security anchor HSM unit shared by thevarious communication nodes 401, providing various security services in thevehicle network 400. Generally, the VSAN402 is not involved in the own service logic of eachcommunication node 401, and mainly provides security service-related services.

The VSAN402, as a body information security server in thevehicle network 400, performs security service communication with thecommunication node 401 through a request-acknowledgement (request-confirmation) and notification-response (notification-response) protocol based on a client-server model, and provides a security service function including, for example:

(1) a data communication port;

(2) a secure memory;

(3) a secure random number generator;

(4) an encryption algorithm engine;

(5) an online security center agent;

(6) safety starting inspection;

(7) monitoring and managing the online security event;

(8) authentication of identity management based on hardware fingerprints.

The processor 4021 of the body security anchor node VSAN402 is configured to send a security service confirmation to acertain communication node 401 in thevehicle network 400 in response to a security service request received on thebus 404 through thecommunication interface 4025 from thecommunication node 401, and/or to actively send a security service notification to thecommunication node 401 and receive a security service response from thecommunication node 401 returned for the security service notification.

Thesecure memory 4022 provides protection for the Core Security Parameters (CSPs) of the corresponding nodes in the vehicle network, and these core Security parameter data include public and private key keys (especially private keys), symmetric keys, digital certificates and digital certificate chains (especially root certificates), signature information, user private information, vehicle sensitive configuration parameters, and so on. The data storage protection comprises the following steps: carrying out validity check on a visitor of the data; the integrity of the data is protected, and the data is prevented from being physically damaged or maliciously tampered; and data is encrypted to prevent information leakage. Thesecure memory 4022 may employ Read Only Memory (ROM), Electrically Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), and optical, electromagnetic, magnetic memory (e.g., Flash memory) with access rights, among others.

The securerandom number generator 4023 is a high-performance random or pseudo-random number generator with hardware-based algorithms, which is a critical loop for many security algorithms and protocols. Other communication nodes in the vehicle network may request the VSAN to assign the required secure random number via a secure communication protocol.

The encryption algorithm engine 4024 is configured to encrypt and decrypt data using an encryption algorithm, and to de-sign signature data using a key. In addition to the RSA (public key encryption algorithm) algorithm, other asymmetric encryption algorithms for information security may also be used, such as BCC (Block Check symbol) algorithm, SM2 (elliptic curve public key cryptography) algorithm, and the like.

The VSAN402 and thecommunication unit 401 are communicatively connected to each other through abus 404 of thevehicle network 400.Bus 404 includes, but is not limited to, an Ethernet, Flexray, CAN bus.

Thecommunication interface 4025 of the VSAN402 is used to connect to thevehicle network 400 via thebus 404 for data communication with thecommunication node 401. Thecommunication interface 4025 may also have Telematics service function for bidirectional communication with the backgroundonline security center 403 remote from the vehicle via a wired network or a wireless network. The backgroundonline security center 403 may be a server or a domain server on a public network cloud or a virtual local area network (VPN). The VSAN402 may not have a Telematics service function, and communicates with the remotebackground presence center 403 through a secure channel provided by the Telematics node of the vehicle. According to the information security requirements, data communication between the VSAN402 and the Telematics node can also perform bidirectional authentication and data encryption, and the Telematics node also corresponds to acommunication node 401.

The VSAN402, acting as an online security center agent, may advantageously manage all communication nodes and security function-related digital certificate chains and key systems in the vehicle network for which security services are provided, updating and/or replacing expired or expired digital certificates and keys. Since sensitive data of relevant digital certificates, signatures, key systems, encryption algorithms, and the like are stored in thesecure memory 4022 of the VSAN402 and are not stored in theFlash memory 4013 of thecommunication node 401, the possibility of malicious tampering of the sensitive data can be reduced.

The VSAN402 may also collectively supervise and manage security events reported by thecommunication node 401 in thevehicle network 400 and security events recorded by the VSAN402 itself as the most secure nodes in thevehicle network 400, provide timely and accurate reports of network security status to the backgroundonline security center 403, and provide notifications of network security status to other communication nodes (e.g., another ECU) in a local vehicle network or domain network that is providing security services by the VSAN402, such as a communication node that is different from the communication node that the VSAN402 is currently providing security services.

In addition, the VSAN402 may also provide identity management and authentication based on hardware fingerprints to thecommunication nodes 401 with low security performance without relying on an external certificate chain system, so as to improve the information security level of these communication nodes. For example, the following hardware serial numbers of each communication node such as an ECU are unique worldwide: production serial number, IEEE802.11 Mac address, IMEI, SIM-ICCID, SIM-IMSI, etc. These hardware serial numbers are pre-stored in the VSAN402 and thecommunication node 401. The identity information of the communication node is obtained by using the information as the hardware fingerprint and the random number generated by the securerandom number generator 4023 through a hash algorithm. The securerandom number generator 4023, as a hardware random number generator, may generate a high-strength pseudo random number that is very close to a true random number, further improving the information security level. VSAN402 also has a hardware fingerprint such as a hardware serial number as described above.

An exemplary structure of thecommunication node 401 is shown in fig. 6. Thecommunication node 401 includes a processor 4011, amemory 4012, astorage 4013 such as a Flash memory, a Read Only Memory (ROM) for storing firmware and other important data, aclock 4014, aperipheral device 4015, acommunication interface 4016, apower management unit 4017, and the like. In contrast to thecommunication node 200 in fig. 2, thecommunication node 401 no longer comprises an HSM unit as a security anchor. When a security service is required, processor 4011 ofcommunication node 401 communicates data regarding the security service with VSAN402 viacommunication interface 4016. For example, thecommunication node 401 may send a security service request to the body security anchor node VSAN402 and receive a security service confirmation from the VSAN402 and, in response to receiving a security service notification from the VSAN402, send a security service response to the security service notification to theVSAN 402. Generally, thecommunication interface 4016 communicates with other communication nodes and the VSAN402 via thebus 404 of thevehicle network 400.

The backendonline security center 403 is used for bidirectional communication with the VSAN402, providing the VSAN402 with data on keys (asymmetric and symmetric keys), digital certificates and certificate chains, signature information, user private information, etc., and update information of these data, and timely and accurately acquiring a network security status report of thevehicle network 400 and the operating conditions of the VSAN402 and therespective communication nodes 401 from theVSAN 402.

Data communication and interaction between the VSAN402 and thecommunication node 401 during the provision of security services will be described in detail below.

As shown in fig. 7, a VSAN402 communicates with acommunication node 401 for security services based on a client-server model of request-response and notification-response protocols. When thecommunication node 401 needs to acquire security service from the VSAN402, a Request message (Request) is transmitted to the VSAN402, and the VSAN402 receives the Request and transmits an acknowledgement message (Confirmation) corresponding to the Request to thecommunication node 401 in response to the Request. When the VSAN402 needs to provide a service to thecommunication node 401 or acquire data related to a security service, the VSAN402 transmits a Notification message (Notification) to thecommunication node 401, and after receiving the Notification from theVSAN 401, thecommunication node 401 transmits a response message (response) corresponding to the Notification to theVSAN 401 as a response to the Notification. Thus, all security service communication data actively sent fromcommunication node 401 is in the form of a request message, while security service communication data actively sent from VSAN402 is in the form of a notification message.

The process of security services for a vehicle network including a VSAN according to an example embodiment of the present disclosure is described below with reference to fig. 8, taking as an example the interactive communication of acommunication node 401 with the VSAN402 at start-up or wake-up.

Thecommunication node 401 first boots or wakes up in step S801, and the boot program Bootloader initializes the boot.

After the start-up initialization is completed, thecommunication node 401 transmits a request for starting secure communication to the VSAN402 at step S810. The VSAN402, in response to receiving the request, determines whether secure communications are possible based on the current state and sends an acknowledgement back to thecommunication node 401 whether secure communications are allowed. Thecommunication node 401 receives the confirmation returned by the VSAN402, and if the confirmation allows the secure communication to be started, thecommunication node 401 continues to execute the next step S820; if the initiation of secure communication is not allowed in the acknowledgement, thecommunication node 401 waits for a predetermined time and then again transmits a request to initiate secure communication to theVSAN 402. Similarly, VSAN402 may also send a notification tocommunication node 401 requesting initiation of communication. Thecommunication node 401 determines whether secure communication is possible according to its own state in response to the received notification, and sends a response that allows secure communication back to theVSAN 402. The VSAN402 continues to perform step S820 if the communication is permitted or transmits a notification to start secure communication again after waiting for a predetermined time if the communication is not permitted, based on the received response from thecommunication node 401.

After determining that the secure communication is allowed, thecommunication node 401 and the VSAN402 perform bidirectional authentication in step S820, and mutually verify the identity of each other to determine that the two parties have the right to perform secure communication. First,communication node 401 requests authentication ofcommunication node 401 byVSAN 402. Thecommunication node 401 sends a request for authentication to theVSAN 401 and waits for an authentication result returned by theVSAN 401. At least one of a key of thecommunication node 401, a digital certificate, a security polynomial, and identity information based on a hardware fingerprint of thecommunication node 401 is also included in the transmitted request message for authentication for use by the VSAN402 at the time of authentication. VSAN402, in response to receiving an authentication request message fromcommunication node 401, compares at least one of a key, a digital certificate or certificate chain (in particular, a root certificate), a security polynomial, and previously recorded identity information based on the hardware fingerprint ofcommunication node 401 stored in secure memory with corresponding identity information in the request. When the identity information of the two is consistent or matched (for example, the public and private keys are matched), determining that thecurrent communication node 401 is a legal communication object and is authorized to perform secure communication with theVSAN 402; when the identity information of the two is not consistent or matched, it is determined that thecurrent communication node 401 has no authority to securely communicate with theVSAN 402. The VSAN402 sends a confirmation message of the authentication result back to thecommunication node 401.

The VSAN402 further determines the authentication (i.e., authentication) result in step S830, if the two identity information are consistent or matched, the authentication is successful (i.e., "no" branch in step S830, the next step S840 is continued, if the two identity information are not consistent or matched, the authentication is failed (i.e., "yes" branch in step S830), step S831 is performed, the VSAN402 records the security event 1, indicating that the authentication to thecommunication node 401 is failed, then the communication with thecommunication node 401 is terminated in step S832, and a notification of the authentication failure with the communication node is sent to other communication nodes in the local vehicle network or the domain network to which the VSAN402 provides security service.

According to an embodiment of the present disclosure, another approach may also be adopted in the authentication process for thecommunication node 401. VSAN402 has only a root certificate stored in its secure memory for verifying the key or digital certificate (certificate chain) in the authentication request message ofcommunication node 401. The key or digital certificate (certificate chain) is stored in Flash memory of thecommunication node 401, and when thecommunication node 401 requests authentication, the key or digital certificate (certificate chain) is put in a request message to the VSAN402, and the VSAN402 compares or matches the root certificate with the received key or digital certificate (certificate chain) in response to the request. When the verification using the root certificate passes, the identity information of the root certificate is consistent or matched, and when the verification fails, the identity information of the root certificate is inconsistent or not matched.

Communication node 401 receives an acknowledgement message from VSAN402 that includes the authentication result. If the authentication of thecommunication node 401 by the VSAN402 is successful, thecommunication node 401 may continue to perform step S840, otherwise the authentication of thecommunication node 401 fails and no further secure communication with the VSAN402 is possible.

After thecommunication node 401 requests the VSAN402 to authenticate thecommunication node 401, the VSAN402 further notifies thecommunication node 401 to authenticate the VSAN402, verifies the identity of the VSAN402, and completes the bidirectional authentication.

Similar to thecommunication node 401 sending the authentication request, the VSAN402 also sends an authentication notification to thecommunication node 401 in step S820, and waits for an authentication result returned by thecommunication node 401. At least one of a key of VSAN402, a digital certificate, a security polynomial, and identity information based on a hardware fingerprint of VSAN402 is also included in the transmitted authentication notification message for use bycommunication node 401 in authentication.Communication node 401, in response to receiving the authentication notification message from VSAN402, compares at least one of the key, the digital certificate or certificate chain, the security polynomial, and the previously recorded identity information based on the hardware fingerprint of VSAN402 stored in Flash memory with the corresponding identity information in the notification. When the identity information of the two is consistent or matched (for example, the public and private keys are matched), the VSAN402 is determined as a legal communication object and is authorized to perform secure communication with thecommunication node 401; when the identity information of the two is not consistent or matched, it is determined that the VSAN402 has no authority to securely communicate with thecommunication node 401. Thecommunication node 401 sends a response message of the authentication result back to theVSAN 402.

In step S833,communication node 401 further determines the authentication (i.e., authentication) result, and if the two identity information are consistent or matched, the authentication is successful (i.e., "no" in step S833 and proceeds to next step S840. if the two identity information are not consistent or matched, the authentication is failed (i.e., "yes" in step S833), step S834 is performed, thecommunication node 401 records a security event indicating that the authentication on VSAN402 is failed, and then terminates the communication with VSAN402 in step S835.

VSAN402 receives a response message including the authentication result fromcommunication node 401. If thecommunication node 401 successfully authenticates the VSAN402, the VSAN402 may continue to perform step S840, otherwise, if the authentication of the VSAN402 fails, no further secure communication with thecommunication node 401 is possible, and the VSAN402 records the security event 1, indicating an authentication failure with thecommunication node 401.

According to another embodiment of the present disclosure, for acommunication node 401 with a weak security function configuration, the VSAN402 may be requested to authenticate thecommunication node 401 through identity information based on a hardware fingerprint. Prior to authentication, it is desirable that the secure memory of VSAN402 has stored therein hardware fingerprint-based identity information ofcommunication node 401.

Fig. 9 illustrates the process of generating identity information by the VSAN402 for allcommunication nodes 401 when a vehicle is off-line or in after-market maintenance. In step S910, VSAN402 first generates and stores hardware fingerprint-based identity information of VSAN402 in a secure memory based on its hardware fingerprint, such as the hardware serial number above, plus a random number generated by a random number generator. Then, in step S920,communication node 401 sends an identity generation request including the hardware fingerprint ofcommunication node 401 toVSAN 402. In response to receiving the request, the VSAN402 generates and stores hardware fingerprint-based identity information of thecommunication node 401 in a secure memory according to the hardware fingerprint of thecommunication node 401 and a random number generated by a random number generator in step S930. Finally, the VSAN402 sends back to thecommunication node 401 an identity generation confirmation message including identity information of both the VSAN402 and thecommunication node 401 in step S940. Thecommunication node 401 stores its identity information in Flash memory.

In the subsequent authentication, thecommunication node 401 may perform authentication using only the hardware fingerprint-based identity information or perform bidirectional authentication with the VSAN402 using the hardware fingerprint-based identity information in response to the authentication request of theVSAN 402. The authentication of thecommunication node 401 by the VSAN402 may select at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information according to the level of information security service. For thecommunication node 401 with a stronger security function configuration, the same authentication method as the VSAN402 may be used. In addition, the identity information based on the hardware fingerprint is mainly used for authentication, and is not generally used in subsequent encrypted transmission.

Communication between thecommunication node 401 and the VSAN402 before the bidirectional authentication is successful may be performed through a clear text message. The data communication in steps S840 and S850 after the bidirectional authentication in S830 is performed by encrypting the protected cipher text message.

In step S840 of fig. 8, thecommunication node 401 and the VSAN402 perform a cryptographic negotiation, and confirm at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information used in the next encryption transmission, and an encryption scheme. The cryptographic negotiation may be actively proposed by either one of the parties and the other party makes a selection and/or confirmation of the negotiation result, or may be actively proposed only by one of the parties (e.g., communication node 401) and the other party (e.g., VSAN 402) makes a selection or confirmation, as desired.

According to an embodiment of the present disclosure, in step S840, thecommunication node 401 sends a request for an encryption scheme for data transmission to the VSAN402, where the encryption scheme includes at least one of asymmetric encryption, symmetric encryption, signature, and the like, and waits for a confirmation message of a result of selection of the encryption scheme by theVSAN 402. The VSAN402 selects at least one of the encryption schemes in response to the received request message for the encryption scheme and sends the selection result back to thecommunication node 401 in the form of an acknowledgement message. It is also possible that the VSAN402 sends a notification message of the encryption scheme of the data transmission to thecommunication node 401, and waits for a response message of the encryption scheme selection or confirmation result sent back by thecommunication node 401 in response to the notification message of the encryption scheme of theVSAN 402.

After both determine the encryption mode of the data transmission, parameters used in the encryption transmission may also be negotiated, and these parameters include, but are not limited to, the key used in the encryption, the digital certificate, the security polynomial, the high-strength random number, and so on.

For example,communication node 401 may send a request message to obtain or update at least one of a key and a digital certificate, a request message to assign a high-strength random number, and the like to VSAN402, and wait for an acknowledgement returned byVSAN 402. VSAN402 may send a corresponding acknowledgement message in response to the request message fromcommunication node 401 to obtain or update at least one of the key and the digital certificate, the request message to assign the high-strength random number, and the like. For example, VSAN402 may retrieve at least one of the stored key and digital certificate or digital certificate chain from secure memory, add an acknowledgement message corresponding to the request message to retrieve or update at least one of the key and digital certificate, and send it back tocommunication node 401. The VSAN402 may also generate a high strength random number for assignment by the secure random number generator and send the random number back to thecommunication node 401 in an acknowledgement message. After receiving the acknowledgement packet, thecommunication node 401 applies the corresponding data as the parameter of the encrypted transmission to the subsequent encrypted communication.

The symmetric key is typically generated from an asymmetric key plus a random number, so the VSAN402 can generate a high-strength random number from a secure random number generator, plus the asymmetric key stored in secure memory, generate a symmetric key, store the symmetric key in secure memory, and send back to thecommunication node 401 in the form of an acknowledgement message. Since the encryption and decryption overhead of the asymmetric key (such as a public and private key) is relatively large, in the authenticated data communication, thecommunication node 401 and the VSAN402 in the vehicle network may negotiate to use the symmetric key for ciphertext transmission.

Similarly, the VSAN402 may also actively send a notification message of at least one of the renewal key and the digital certificate (certificate chain) to thecommunication node 401, and wait to receive a response message of thecommunication node 401 to the renewal key and the digital certificate. This is mainly used when the VSAN402 obtains the key and the digital certificate update from the back-end online security center, and at this time, the VSAN402, as an online security center agent, can conveniently manage all thecommunication nodes 401 in the vehicle network and the digital certificate chain and key system related to the security function, and update and/or replace the failed or expired digital certificates and keys. Upon receiving the notification, thecommunication node 401 stores the update of the key and/or the digital certificate contained in the notification message in the Flash memory, and returns a response of the update to theVSAN 402. After receiving the response from thecommunication node 401, the VSAN402 continues the bidirectional encrypted communication in step S850.

Thecommunication node 401 acquires not only the key, the digital certificate, the security polynomial, the hardware fingerprint-based identity information, and the high-strength random number for communication between thecommunication node 401 and the VSAN402 from the VSAN402, but also the key, the digital certificate, the security polynomial, the hardware fingerprint-based identity information, and the high-strength random number for authentication and encryption communication between different communication nodes from theVSAN 402.

After thecommunication node 401 and the VSAN402 complete the password negotiation, bidirectional encrypted communication is started in step S850. The VSAN402 may transmit or receive a data packet encrypted in a pre-agreed encryption manner from thecommunication node 401 to thecommunication node 401 in response to the request message for encrypted data transmission transmitted by thecommunication node 401. Thecommunication node 401 may also send or receive data messages encrypted in a pre-agreed encryption manner from the VSAN402 to the VSAN402 in response to the notification message of encrypted data transmission sent by theVSAN 402.

Thecommunication node 401 can request the corresponding rights and information from the VSAN402 for access to the data file. For example,communication node 401 may send a request to VSAN402 for at least one of a read, store, and delete operation on a data file, and an operation to encrypt and sign the data file symmetrically or asymmetrically. The VSAN402 verifies whether thecommunication node 401 has the authority to perform the corresponding operation on the data file in response to the above-mentioned request from thecommunication node 401, and transmits confirmation of permission or rejection of the operation to thecommunication node 401. After receiving the confirmation message of the VSAN402, thecommunication node 401 executes a corresponding file operation if the permission allows.

Fig. 10A and 10B show further details of thecommunication node 401 during a secure boot process according to an embodiment of the present disclosure. The safe starting process is divided into an offline generation subprocess of the safe firmware and a starting subprocess in the communication node. Referring to the embodiment shown in FIG. 10A, in the secure firmwareoffline generation sub-process 1000A, the compiled firmware file is first obtained in step 1000-1, and then the HASH (HASH) value of the firmware file is calculated in step 1000-2, for example, using the SHA algorithm. In step 1000-3, the computed hash value is cryptographically signed by aprivate key 1011, e.g. based on the RSA encryption algorithm.Private key 1011 comes from backendonline security center 403. In step 1000-4, the firmware is combined with the signature data obtained by signing the hash value and stored in the Flash memory of thecommunication node 401.

In the communication node'sstart subprocess 1000B, thecommunication node 401 reads thesignature data 1014 and thefirmware file 1015 in the combined data from the Flash memory and processes them separately. Before performing step 1000-5,communication node 401 needs to obtain the RSA public key 1012 needed to decrypt the signature fromVSAN 402.Public key 1012 is stored in secure memory ofVSAN 402. The secure memory of VSAN402 also storesdigital certificate 1013.Digital certificate 1013 and public key 1012 come from backendonline security center 403. Therefore,communication node 401 needs to communicate with VSAN402 to obtainpublic key 1012.Communication node 401 sends a request to VSAN402 to access the firmware and waits to receive an acknowledgement fromVSAN 402. VSAN402, in response to a request received fromcommunication node 401, retrieves from secure memory thepublic key 1012 and/or digital certificate corresponding toprivate key 1011 used for signature encryption of the firmware, and sends public key 1012 back tocommunication node 401. Thecommunication node 401 uses thepublic key 1012 to sign-decrypt thesignature 1014 stored in the Flash memory in step 1000-5 to obtain the original hash value of the firmware calculated in step 1000-2. Authentication of thecommunication node 401 needs to be completed before thepublic key 1012 is obtained from the VSAN402 to ensure that thecommunication node 401 has access to thefirmware 1015.

Concurrently with step 1000-5, the processor of thecommunication node 401 re-performs the hash value calculation on thefirmware 1015 in step 1000-6 to obtain a new calculated hash value. In step 1000-7, the Bootloader ofcommunication node 401 compares the original hash values obtained in steps 1000-4 and 1000-5, respectively, with the computed hash value. If the comparison result is that the two are consistent, it indicates that thecommunication node 401 has legal operation authority for the firmware and the hash value of the firmware is not tampered (i.e. the data of the firmware is complete), and the secure boot is successful; if the comparison result is that the two are not consistent, it indicates that thecommunication node 401 has no authority for legally operating the firmware, or the firmware data is tampered, and the secure boot fails. In the process of FIG. 10A, the secure memory, secure random number generator, and cryptographic algorithm engine in VSAN402 actually constitute the security anchor forVSAN 402. It can be seen that the security anchor in the exemplary embodiment of the present disclosure shown in figure 10A is moved from thecommunication node 401 into theVSAN 402. The processor of thecommunication node 401 still needs to be burdened with the tasks of signature decryption and hash value calculation.

Referring to the embodiment shown in FIG. 10B, the offline generation ofsecure firmware sub-process 1000C on the left is similar to sub-process 1000A in FIG. 10A, with steps 1100-1 through 1100-3 being substantially identical to steps 1000-1 through 1000-3. 1000A differs from 1000C in that in step 1100-4 only the resultingsignature 1014, encrypted for the original hash value signature of the firmware, is retained. Thefirmware file 1015 is stored in Flash memory of thecommunication node 401 and thesignature 1014 is stored in memory of theVSAN 402.

In thechild sub-process 1000D of thecommunication node 401, thecommunication node 401 reads thefirmware file 1015 from Flash memory and thesignature 1014 is decrypted by the VSAN402 using thecertificate 1013 stored in secure memory and/or thepublic key 1012 corresponding to theprivate key 1011 that encrypted the signature in step 1100-3. Bothdigital certificate 1013 and public key 1012 come from backendonline security center 403. VSAN402 decryptssignature 1014 using a processor based onpublic key 1012 anddigital certificate 1013 in step 1100-5, obtainingoriginal hash value 1016 of the firmware. Thecommunication node 401 performs a hash operation on the firmware file to obtain a computed hash value of the firmware in step 1100-6. In step 1100-7, the Bootloader program ofcommunication node 401 is required to compare the original hash value with the computed hash value, and therefore the original hash value needs to be obtained fromVSAN 402.Communication node 401 sends a request to VSAN402 for access to firmware and waits to receive the raw hash value fromVSAN 402. In response to the received request to access the firmware, the VSAN402 decrypts thesignature 1014 of the firmware based on at least one of a key and a digital certificate corresponding to thefirmware 1015 stored in the secure memory as described above to obtain an original hash value of the firmware, and transmits the original hash value to thecommunication node 401. It is noted that the two-way authentication betweencommunication node 401 and VSAN402 has been completed beforecommunication node 401 sends a request to VSAN402 to access the firmware. After receiving the acknowledgement packet containing the original hash value, thecommunication node 401 completes the hash value comparison of step 1100-7. If the comparison result is that the two are consistent, it indicates that thecommunication node 401 has legal operation authority for the firmware and the hash value of the firmware is not tampered (i.e. the data of the firmware is complete), and the secure boot is successful; if the comparison result is that the two are inconsistent, it indicates that thecommunication node 401 has no legal operation authority on the firmware, or the firmware data is tampered, and the secure boot fails. In the process of fig. 10B, the secure memory, secure random number generator, and cryptographic algorithm engine in VSAN402 still effectively constitute a security anchor for VSAN402 located outside ofcommunication node 401.

Compared to the process shown in fig. 10A, the exemplary embodiment of fig. 10B hands off the task of decrypting the signature to the processor of the VSAN402 for completion, fully utilizes the processing power of the VSAN402 and reduces the processing burden on thecommunication node 401, and may free up more processing power for thecommunication node 401, such as an ECU, for other tasks.

The embodiments shown in fig. 10A and 10B may also be applied to a firmware remote upgrade procedure of thecommunication node 401. The firmware, including the software update, is downloaded to the Flash memory of thecommunication node 401 on the one hand, and the hash value, signature and public key and digital certificate corresponding to the firmware are written to the secure memory of the VSAN on the other hand. The corresponding certificate chain or root certificate may also be written in the secure memory of VSAN402 to verify the legitimacy of the corresponding digital certificate and public key. By analogy withsubprocesses 1000B and 1000D, it can be checked whether the firmware upgrade was successful.

According to the embodiment of the disclosure, the two-way authentication of encrypted communication in a preset time period after the two-way authentication is successful can be negotiated between the VSAN and the communication nodes and among the communication nodes. Both may also negotiate a validity period for keys, digital certificates, security polynomials, etc. used for encrypted communications, during which the encryption settings and parameters are not updated.

According to the embodiment of the present disclosure, the VSAN402 may perform integrity check on the received security service request message from thecommunication node 401 in any data communication situation after the bidirectional authentication, see step S860 in fig. 8. When the request message is incomplete (e.g., yes branch of S860), a security event 2 is recorded by the processor of VSAN402 in step S861, indicating that a message integrity failure has occurred, and communication withcommunication node 401 is terminated in step S862. If the request message is complete (no branch of S860), the following steps are continued. VSAN402 may also perform integrity checking on received response messages fromcommunication node 401 for security service responses returned by security service notifications issued byVSAN 402.

Similarly, thecommunication node 401 may also perform integrity check on the received security service confirmation message and security service notification message from the VSAN402 in any data communication situation after the bidirectional authentication. When the confirmation message or notification message is incomplete, a security event is recorded by the processor of thecommunication node 401 indicating a message integrity failure and communication with the VSAN402 is terminated. If the message is confirmed or the notification message is complete, the following steps are continued. This part of the steps is not shown in fig. 8 for the sake of simplicity. Eachcommunication node 401 may notify the VSAN402 of the security events recorded by each communication node by sending a request to the VSAN402 to report the security events.

According to embodiments of the present disclosure, VSAN402 may Log security events in a correlation Log (Log) in response to a received request fromcommunication node 401 to report these security events. At the same time, VSAN402 may also record its own recorded security events (such as security events 1 and 2 above) in the associated record. The VSAN402, as a supervisory node for vehicle network security, collects and aggregates the security events recorded by the various communication nodes in the vehicle network and reports the relevant events and relevant recorded information to theonline security center 403 in the event of detected anomalies.

For example, when a vehicle network encounters a Denial of service (DOS) attack, one or more communication nodes repeatedly send a message or meaningless data intensively for a limited period of time, which occupies network bandwidth and service resources resulting in network congestion and resource exhaustion. For another example, a malicious communication node on the vehicle network falsifies the identities of other communication nodes to obtain secret data or obtain control authority of some functions. The VSAN402 can effectively prevent security attacks against the vehicle network by recording security events from other communication nodes and self-recording and combining the backgroundonline security center 403, and can timely find faults of the vehicle network and take countermeasures.

These security events include, but are not limited to: 1) the communication node fails authentication; 2) the signature of the communication message of the communication node is invalid; 3) a secure boot failure of the communication node; 4) the communication of the vehicle network encounters DOS attacks; 5) network attacks reported by the communication node; 6) counterfeit identity attacks in vehicle networks; 7) failures of other communication nodes than the communication node with which the VSAN communicates, such as node fault code information defined in Diagnostic Services (Diagnostic Services), and the like.

At least one of the advantages or effects described below can be obtained by using the body safety anchor node VSAN providing the safety service function and the communication node supporting the VSAN as described above, constituting a vehicle network of a motor vehicle based on a set of safety communication protocols, and a method for providing the safety service function based on the VSAN, the communication node, and the vehicle network.

The unique security anchor VSAN and the matched security communication protocol on the local vehicle network or the domain network are adopted to provide trusted security services (such as security storage, random number generation, encryption engine, security starting inspection and the like) for all communication nodes such as the ECU in the vehicle network, so that the total number of the security anchors on the vehicle network is reduced, and the complexity, the development cost and the part cost of the system are reduced.

The security architecture can uniformly monitor network security events by a node VSAN with the highest security performance while reducing security anchors, and provide timely and accurate network security status reports to a background online security center or a communication node such as a vehicle controller. As an online security center agent, the background online security center can conveniently manage the certificate chain and the key system related to the vehicle in time (for example, update or replace some digital certificates and keys which are expired or expired), and the cost of security management and maintenance is reduced.

The unified security monitoring node can also timely and completely record and report security events and various exceptions occurring on the vehicle network, thereby timely providing reliable and complete security information for the backstage online security center, reducing the processing reaction time of the security events and reducing the loss caused by network attack and security loophole.

According to an embodiment of the present disclosure, a vehicle network comprising the VSAN and the communication node above is also presented for providing information security functions in a vehicle. By using the vehicle network, the information security function of the motor vehicle is further improved, and the management and maintenance costs are effectively reduced.

Those skilled in the art will appreciate that the various modules and functions of the VSAN and the communication node described above may be implemented in hardware, software, or a combination of hardware and software. The individual modules and functions may also be combined with each other. In addition, according to actual needs, some steps may be selected and implemented or the sequence of the steps may be adjusted according to the method steps listed in the embodiments of the present disclosure.

In an exemplary embodiment of the present disclosure, there is also provided a computer-readable storage medium, on which a computer program is stored, the program comprising executable instructions which, when executed by, for example, a processor, may implement the steps of the method for providing security services described in any one of the above embodiments. In some possible embodiments, various aspects of the disclosure may also be implemented in the form of a program product comprising program code for causing a VSAN or a communication node to perform the steps described in the method for providing security services in this specification when the program product is run on the VSAN or the communication node.

Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims (17)

1. A body security anchor node (VSAN) device for providing global security services to all communication nodes in a local or regional vehicle network, the VSAN device comprising a processor, a secure memory, a secure random number generator, and a cryptographic algorithm engine, the processor configured to:

sending a security service confirmation to a communication node in the local vehicle network or a domain network in response to a security service request from the communication node; and/or

Sending a security service notification to the communication node and receiving a security service response from the communication node for the security service notification;

and the vehicle body safety anchor node is used as an online safety center agent, manages all communication nodes in the local vehicle network or the domain network and digital certificate chains and key systems related to safety functions, and updates and/or replaces invalid or expired digital certificates and keys.

2. The vehicle body security anchor node apparatus of claim 1, wherein sending a security service confirmation to a communication node in the local vehicle network or domain network in response to a security service request from the communication node comprises at least one of:

sending an acknowledgement to the communication node whether communication is allowed or not, in response to the communication node's request to initiate communication;

verifying an identity of the communication node based on at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information stored in the secure memory in response to a request for authentication of the communication node, and transmitting an authentication result to the communication node;

generating, by the secure random number generator, a high-strength random number in response to the communication node's request to allocate the high-strength random number, and transmitting the high-strength random number to the communication node;

transmitting, to the communication node, at least one of the key and the digital certificate stored in the secure memory in response to a request of the communication node to acquire or update at least one of the key and the digital certificate;

in response to a request of the communication node for at least one of reading, storing and deleting a data file, verifying an operation authority of the communication node for the data file and transmitting a confirmation to the communication node to allow or deny the operation;

in response to a request of the communication node to access firmware, transmitting at least one of a key, a digital certificate, and an original hash value corresponding to the firmware stored in the secure memory to the communication node;

sending an acknowledgement of an encryption mode of a data transmission to the communication node in response to a request for the encryption mode of the data transmission by the communication node, wherein the encryption mode of the data transmission comprises at least one of asymmetric encryption, symmetric encryption, and a signature;

recording a security event of the communication node in response to a request of the communication node to report the security event; and

and responding to the request of the communication node for encrypted data transmission, and sending or receiving a data message encrypted in a pre-appointed encryption mode from the communication node to the communication node.

3. The vehicle body security anchor node apparatus of claim 2, wherein in response to a request for authentication of the communication node, authenticating the identity of the communication node based on at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information stored in the secure memory, and sending the authentication result to the communication node comprises:

the identity information of the communication node is generated based on the hardware fingerprint of the communication node in the identity verification request and the random number generated by the safety random number generator, the identity information of the vehicle body safety anchor node device is generated based on the hardware fingerprint of the vehicle body safety anchor node device and the random number generated by the safety random number generator, and the identity information of the communication node and the identity information of the vehicle body safety anchor node device are sent to the communication node.

4. The vehicle body safety anchor node apparatus of claim 2, wherein the hardware fingerprint of the communication node comprises at least one of: production serial number, MAC address, IMEI, SIM-ICCID, SIM-IMSI.

5. The vehicle body security anchor node apparatus of claim 2, wherein in response to a request for authentication of the communication node, authenticating the identity of the communication node based on at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information stored in the secure memory, and sending the authentication result to the communication node further comprises:

in response to the request for authentication of the communication node, the identity of the communication node is verified based on the root certificate stored in the secure memory and at least one of the key and the digital certificate in the request for authentication, and an authentication result is sent to the communication node.

6. The vehicle body security anchor node apparatus of claim 2, wherein sending at least one of a key, a digital certificate, and an original hash value corresponding to the firmware stored in the secure memory to the communication node in response to a request of the communication node to access the firmware comprises:

decrypting a signature of the firmware based on at least one of a key and a digital certificate stored in the secure memory corresponding to the firmware to obtain an original hash value of the firmware, and sending the original hash value to the communication node.

7. The vehicle body security anchor node apparatus of claim 2, wherein in response to a request for authentication of the communication node, authenticating the identity of the communication node based on at least one of a key, a digital certificate, a security polynomial, and hardware fingerprint-based identity information stored in the secure memory, and sending the authentication result to the communication node further comprises:

when the authentication result is authentication failure, generating a first security event, terminating communication with the communication node and sending a notification of authentication failure of the communication node to other communication nodes in the local vehicle network or domain network.

8. The vehicle body safety anchor node apparatus of claim 1, wherein sending a safety service notification to the communication node and receiving a safety service response from the communication node for the safety service notification comprises at least one of:

sending a notification of authentication to the communication node and receiving a response of the authentication result from the communication node;

sending a notification of an encryption of a data transmission to the communication node and receiving a response from the communication node of the encryption of the data transmission, wherein the encryption of the data transmission comprises at least one of asymmetric encryption, symmetric encryption, and a signature;

sending a notification of at least one of the renewal key and the digital certificate to the correspondent node and receiving a response from the correspondent node of the at least one of the renewal key and the digital certificate; and

and sending a notice of encrypted data transmission to the communication node, and sending or receiving a data message encrypted in a pre-appointed encryption mode from the communication node to the communication node.

9. The vehicle body safety anchor node apparatus of claim 8, wherein sending a notification of authentication to the communication node and receiving a response from the communication node of the authentication result comprises:

when the authentication result is authentication failure, generating a first security event and terminating communication with the communication node.

10. The vehicle body safety anchor node apparatus of claim 1, wherein sending a safety service confirmation to a communication node in the local vehicle network or domain network in response to a safety service request from the communication node comprises:

checking the integrity of the requested message, and when the requested message is incomplete, generating a second security event and terminating communication with the communication node.

11. The vehicle body safety anchor node apparatus of claim 1, wherein sending a safety service notification to the communication node and receiving a safety service response from the communication node for the safety service notification comprises:

checking the integrity of the responding packet, and when the responding packet is incomplete, generating a second security event and terminating communication with the communication node.

12. The vehicle body safety anchor node apparatus of claim 1, wherein the processor is further configured to bi-directionally communicate with an online safety center remote from the vehicle.

13. The vehicle body security anchor node device of claim 12, wherein the processor is further configured to report the vehicle body security anchor node device generated security events and the recorded security events from the communication node to the online security center.

14. The vehicle body security anchor node device of claim 12, wherein the processor is further configured to receive at least one of a digital certificate, a security polynomial, a key, and an encryption algorithm and updates thereof from the online security center.

15. A method of configuring a vehicle body security anchor node (VSAN) device of any of claims 1-14 in a local vehicle network or a domain network to provide global security services, comprising: communicatively connecting the body safety anchor node device with all communication nodes in the local vehicle network or the domain network through a vehicle bus, and configuring the body safety anchor node device to provide safety services to the communication nodes.

16. A network system for providing safety services to vehicles, comprising at least one local communication network and/or at least one domain network, each of said local communication network and said domain network having at least one communication node,

each of the local communication networks or each of the domain networks is configured with a body security anchor node (VSAN) device as claimed in any one of claims 1 to 14 communicatively connected to each of the communication nodes in the local vehicle network or the domain network via a vehicle bus and providing global security services to all of the communication nodes.

17. The network system of claim 16, wherein the communication node comprises any one of: electronic control units, sensors, multimedia video or audio devices, databases, gateways, and vehicle subsystems.

Images