Method for securing communications according to the V2X standard; Associated device and protocol

Abstract

Method for securing communications according to the V2X standard; Associated device and protocol.This method (200), implemented between a transmitting device and a receiving device of an automatic driving system, consists of: synchronizing (100) the vital computers of the transmitting and receiving devices temporally from at least one common external time source; generating (220) a V2X standard message by the transmitting device by timestamping said message by requesting a current date from the vital computer of the transmitting device and incorporating said current date into a field of the V2X standard message; transmitting (230) the V2X standard message by the transmitting device; receiving (240) the V2X standard message by the receiving device; and verifying (260) the temporal validity of the received V2X standard message by comparing a current date given by the vital computer of the receiving device with the transmission date incorporated in the received V2X standard message. Figure for the abbreviation: Figure 4.

Description

Title of the invention: Method for securing communications according to the V2X standard; Associated device and protocol

[0001] The present invention relates to the field of autonomous vehicles and, more particularly, to securing communications between devices of an automatic driving system.

[0002] Automated driving relies on the communication of information to extend the operating ranges of the vehicles involved. The operating range of a vehicle, or ODD (Operational Design Domain of the vehicles), is the area of ​​vehicle use such that the operation of the entire automated driving system is guaranteed.

[0003] The V2X standard aims to standardize communications between devices in an automatic driving system.

[0004] The V2X standard (“Vehicle-to-Everything”) allows a vehicle to exchange information with other elements of its environment, whether with another vehicle V2V (“Vehicle-to-Vehicle”), with infrastructure equipment V2I (“Vehicle-to-Infrastructure”), with a pedestrian V2P (“Vehicle-to-Pedestrian”), etc.

[0005] The V2X standard is based on communications according to the IEEE 802.11 standard (i.e. of the Wi-Fi type), in particular the IEEE 802.1 lp-2010 standard, but an evolution of V2X, cellular V2X or C-V2X (“Cellular V2X”), envisages communications according to the 4G LTE or 5G standard (i.e. of the GSM type), in particular the LTE-V2X standard (3GPP standard, version of 2016).

[0006] In order to be able to operate a vehicle under delegated driving, it is necessary to be able to demonstrate its safety.

[0007] Document CN111726784 proposes, for example, a strategy to increase the overall safety of an automatic driving system by establishing cooperation between road users and road infrastructure equipment by taking advantage of the V2X standard.

[0008] However, this strategy does not guarantee the security level of each contribution to the overall operation of the system, particularly communications. Therefore, the actual security level achieved by the proposed system is not defined.

[0009] Thus, it is not currently possible to determine the level of safety offered by an automatic driving system based on standard connectivity information.

[0010] It is therefore necessary to have a person on board the vehicle to take control of it in case of danger. This safety-conscious person may be a driver who monitors the vehicle's progress without touching the steering wheel, but is ready to do so when there is danger.

[0011] The invention therefore aims to solve this problem, in particular by proposing communication devices that guarantee the level of security of communications at the V2X standard between the devices of an autonomous driving system.

[0012] To this end, the invention relates to a method for securing V2X standard communications between a transmitting device and a receiving device of an automatic driving system, characterized in that said method comprises: a time synchronization step of the vital computers of the transmitting and receiving devices from at least one common external time source; a generation step of a V2X standard message by the transmitting device consisting of timestamping the message by requesting a current date from the vital computer of the transmitting device and incorporating the current date as the message date in a field of the V2X standard message; a transmission step of the V2X standard message by the transmitting device; a reception step of the V2X standard message by the receiving device;and, a step to verify the temporal validity of the V2X standard message received by the receiving device by comparing a current date given by the vital computer of the receiving device with the transmission date incorporated in the received V2X standard message.

[0013] According to particular embodiments, this process comprises one or more of the following characteristics, taken individually or in all technically possible combinations:

[0014] - the time synchronization step of the vital computers of the devices transmitter and receiver uses at least one second external time source, called an auxiliary external time source, which may be different for the transmitter and receiver devices, the time synchronization of the vital computer of the transmitter device, respectively of the receiver device, being done taking into account the time references delivered by the first and second external sources.

[0015] - The time synchronization step of a vital computer consists of: launching by the vital computer of the execution of a time server; sending a request to the common external time source and receiving a response containing an initial date; sending a request to the secondary external time source and receiving a response containing a second date; checking the consistency between the first and second dates, and, in case of inconsistency, the previous steps are iterated, and, in case of consistency, an internal time reference is established by considering that it is a common time base for all components of the system; and maintaining the internal time reference.

[0016] - the step of generating a message in the V2X standard further consists of calculating, by the sending device, an authentication code relating to the fields of the message in the V2X standard and a step of incorporating the calculated authentication code into a field of the message, and, in that the method includes a step of verifying the integrity of the V2X standard message received by the receiving device by calculating an expected authentication code from the fields of the received V2X standard message and comparing the expected authentication code and the authentication code present in the received V2X standard message.

[0017] - an authentication code is calculated from the different fields of the message to the V2X standard using a hashing algorithm, preferably the SHA-256 algorithm with a dynamic secret hash key known to the different devices of the automatic driving system.

[0018] - the authentication code is embedded in the optional field or a field extension specific to the V2X standard.

[0019] The invention also relates to a communication device compatible with the V2X standard, characterized in that it comprises a vital computer and a radio communication module, the device being configured to implement the transmitting device-side steps and / or the receiving device-side steps of the previous process.

[0020] Preferably, the vital calculator is a vital platform of the type "2oo2".

[0021] Preferably, the vital platform is designed to guarantee a high level of safety complying with SIL 4 or ASIL D.

[0022] The invention also relates to a communication protocol compatible with the V2X standard according to which each message in the V2X standard includes a field incorporating a message date of the message in the V2X standard and optionally a field incorporating an authentication code of the message in the V2X standard.

[0023] The invention and its advantages will be better understood upon reading the following detailed description of a particular embodiment, given solely by way of illustration and not limitation, this description being made with reference to the accompanying drawings in which:

[0024] [Fig-1] Fig. 1 is a schematic representation of one embodiment of a automatic driving system according to the invention;

[0025] [Fig.2] Fig.2 is a timing diagram of the synchronization process of an internal time source such as that of Fig.2; and,

[0026] [Fig. 3] [Fig. 3] is a block representation of the communication security method according to the invention implemented in the system of [Fig. 1]; and,

[0027] [Fig.4] The [Fig.4] is a representation of the structure of a V2X message as modified according to the present invention.

[0028] While remaining compatible with the V2X standard, the invention implements safe mechanisms enabling: synchronization of the communication devices of the automatic driving system; timestamping of a message by the communication device sending this message; and control of the temporal validity of this message by the communication device receiving this message.

[0029] Preferably, the invention also implements secure mechanisms enabling: securing the data contained in a sent message (and consequently the date with which the message was time-stamped) and controlling the integrity of the received message.

[0030] Fig. 1 schematically represents an automatic driving system 1.

[0031] This system comprises first and second communication devices 2 and 3 enabling exchanges according to the V2X standard.

[0032] In the embodiment of [Fig.1], the first device 2 is associated with infrastructure equipment 4, and the second device 3 is mounted on board a vehicle 5.

[0033] In the embodiment described here in detail, the infrastructure equipment 4 is a three-color traffic light, located at the intersection of two roads. The state of this equipment can take three possible values, which are identified by the color of the light ("green", "orange" or "red").

[0034] The purpose of the V2X communication, between the first device 2 as a transmitting device and the second device 3 as a receiving device, is then to inform the vehicle 5 of the presence of an intersection and the state of the traffic light which protects it, so that the vehicle's control computer 7 determines an appropriate trajectory for the vehicle 5.

[0035] The first communication device 2 comprises:

[0036] - a geolocation module 21;

[0037] - a V2X 22 radio communication module;

[0038] - an annex communication module 23;

[0039] - a vital calculator 24; and

[0040] - a routing module 25.

[0041] The geolocation module 21 is specifically designed to receive geolocation signals emitted by a constellation of satellites 11. These signals include, in particular, a clock signal. The constellation of satellites 11 consists of Consequently, an example of a common external time reference source is provided. The geolocation module 21, for instance, runs a time server 41 which, in response to a query, provides a date based on the time reference of the common external source.

[0042] The V2X radio communication module 22 enables the generation of messages according to the V2X standard, the transmission of messages according to the V2X standard with the other communication devices of the automatic driving system 1, in particular the second communication device 3, and the processing of messages according to the V2X standard.

[0043] The auxiliary communication module 23 establishes a link with an external network 12, for example an IP network, such as the Internet. The module 23 is connected to the external network 12 by a wired (e.g., Ethernet) or wireless (e.g., 4G / LTE) link. This link enables communication between the first device 2 and a remote control unit 13, which allows an operator to manage the infrastructure equipment.

[0044] This connection primarily allows the first device 2 to communicate with an external platform 14 constituting a first secondary external time reference source. This external platform runs, for example, a time server 42, which, in response to a query, provides a date according to the time reference of the common external source.

[0045] The vital computer 24 constitutes, in particular, an internal time reference source. The vital computer 24 executes, for example, a time server 43, which, in response to a query, provides a date based on the time reference of the internal source. The vital computer 24 of the first device is synchronized from the common external source and the first secondary external source. According to the invention, a date provided by the vital computer 24 makes it possible, in particular, to timestamp V2X messages transmitted by the device 2.

[0046] The vital calculator 24 is advantageously responsible for verifying the validity of the information from the controller 6, for example by correlating it with the measurements taken by the measuring means 15.

[0047] The vital computer 24 is also responsible for securely signing or verifying the integrity of the "HMAC field" of a V2X message.

[0048] The routing module 25 allows the different modules 21, 22, 23 and 24 to interface with each other and with a controller 6 of the infrastructure equipment 4 and means 15 for measuring the state of the infrastructure equipment 4.

[0049] The routing module 25 is connected, via an external connection, to the controller 6. This controller 6 is used to determine the current state of the infrastructure equipment 4. Alternatively, it is also used to determine the future state of the equipment Infrastructure 4. The future state is either the state of the infrastructure equipment at the next time step, or the next state to which the infrastructure equipment will switch over. In the latter case, the future state includes temporal information corresponding to the time scheduled for this switchover.

[0050] The measuring means 15 make it possible to measure the lamp current of each of the three lamps of the traffic light 4 and to apply a measurement signal adapted to the router 25.

[0051] The second communication device 3 is preferably identical to the first device 2 just described.

[0052] The second device 3 thus comprises:

[0053] - a geolocation module 31;

[0054] - a V2X 32 radio communication module;

[0055] - an annex communication module 33;

[0056] - a vital calculator 34; and

[0057] - a routing module 35.

[0058] The geolocation module 31 is designed to receive geolocation signals emitted by the satellite constellation 11, which constitutes a common time reference source for devices 2 and 3. The geolocation module 31 executes, for example, a time server 51 which, in response to a query, indicates a date according to the time reference of the common external source.

[0059] The second device 3 is connected so that the communication module 33 is now connected to a second external time reference source associated with the vehicle 5, for example to a time server 52 run by the vehicle's control computer 7.

[0060] The vital computer 34 constitutes, in particular, an internal time reference source. For example, it runs a time server 53 which, in response to a query, provides a date based on the time reference of the internal source. The vital computer 34 of the second device is synchronized from the common external source and the second auxiliary external source. According to the invention, a date provided by the vital computer 34 can, in particular, be used to timestamp V2X messages sent by the device 3.

[0061] The vital computer 34 is also responsible for securely signing or verifying the integrity of the "HMAC field" of a V2X message.

[0062] The V2X radio communication module 32 is designed to receive a V2X message, to check its integrity, then its temporal validity, before transmitting the information contained in the received V2X message to the control computer 7 via the routing module 35. This information is, for example, the state of the infrastructure equipment 4 associated with the first device 1 from which a message has just been received.

[0063] A vital computer, such as computer 24 or computer 34, is a vital processing platform of the "2oo2" ("two out of two") type, designed to guarantee a high level of safety in the calculations performed, such as determining the internal time reference from the external time references provided by the two common and auxiliary sources to which the clock module is coupled. The vital computer complies, for example, with level 4 of the SIL ("Safety Integrity Level") standard or D of the ASIL ("Automotive Safety Integrity Level") standard.

[0064] The data stream of the synchronization process 100 of the internal time source of a communication device is represented in [Fig.2]:

[0065] - in step 110, the clock module starts the execution of time server 43.

[0066] This is calibrated by querying the common external source and the secondary external source. To do this:

[0067] - in step 130a, module 24 issues a request to the common external source, more specifically the time server 41 of module 21 (the request is for example a request according to the "Network Time Protocol" - NTP standard);

[0068] - in step 140a, the time server 41 of module 21 responds to the request in delivering an initial date based on the temporal reference of the common external source (the request is, for example, an NTP response);

[0069] - in step 130b, module 24 issues a request to the external annex source, that is, time server 42;

[0070] - in step 140b, time server 42 responds to the request by delivering a second date based on the time reference of the first external source annexed;

[0071] - Then, in step 155, if module 24 concludes that there is consistency between the first and second dates between them, the internal time reference is established by considering that it is a common time base for all components of system 1. Otherwise, process 100 loops on step 110 and is iterated again; - In step 160, module 24 maintains the internal time reference.

[0072] Process 100 is executed periodically to eliminate any risk of time drift of the internal time source.

[0073] Once module 24 is synchronized, the date delivered by the time server 43 is used to date the V2X messages sent by device 2.

[0074] A similar description could be made for device 3 in order to synchronize the internal time source which is module 34.

[0075] With reference to [Fig. 3], the communication method 200 comprises:

[0076] A preliminary step of synchronizing the different devices of the system by implementing, on each device, the process 100 described previously.

[0077] Then, on the infrastructure equipment 4 side, for disseminating the status of this equipment, the method includes a step 210 for determining the status of the infrastructure equipment. Determining the status of the infrastructure equipment is a vital function. For example, the vital computer 24 compares the status of the traffic light indicated by the controller 6 and the status corresponding to the lamp current measured by the measuring means 15 in order to determine the vital status.

[0078] At step 220, module 22 formats a message according to the V2X standard, for example a SPAT message.

[0079] The V2X standard defines a SPAT (“Signal Phase and Timing” or “Phase and synchronization of signals”) message allowing infrastructure equipment to inform the environment about its state.

[0080] According to the invention, certain fields in the payload portion of a V2X message are used to pass information useful for the time validity function and, preferably also, information useful for the integrity verification function according to the invention. This ensures compatibility with the V2X standard while enabling message corruption detection to guarantee a high level of security.

[0081] For the time validity function, the message is dated with a message date. The message date embedded in the message is the one returned by the internal time server 43 on request from module 22 when it prepares the V2X message for transmission.

[0082] For the integrity verification function, the message includes an HMAC code (“hash-based message authentication code”).

[0083] For example, a truncated 64-bit HMAC code is generated by the vital computer 24, at the request of module 22, from the various fields of the SPAT message (except the portion intended to incorporate the HMAC code, which then only contains zeros) preferably using the SHA-256 algorithm and a 64-byte dynamic secret hash key known to the various devices of system 1.

[0084] Once the SPAT message payload is prepared, the message is encoded in base 64, then communicated to the radio communication unit of module 22 for transmission (step 230).

[0085] On vehicle 5, the V2X message is received and then decoded by device 3 (step 240).

[0086] In step 250 of the verification of the integrity of the received V2X message, module 32 decodes the received message. At the request of module 32, the vital computer 34 of the second device 3 calculates an HMAC code on the fields of the SPAT message (except for the portion incorporating the HMAC code calculated by the sender, which then contains only zeros) and compares the HMAC code thus calculated with the HMAC code contained in the field of the received V2X message. In case of a negative comparison, the received V2X message is rejected. In case of a positive comparison, the process continues to step 260. This verifies the data integrity and authenticity of the received V2X message.

[0087] Then, in step 260, the vital computer 34 of device 3 extracts the message date embedded in the received V2X message and compares it to the current date of device 3. The latter is obtained by querying the internal time source of device 2. If the message date differs too significantly from the current date of device 3, the V2X message is rejected. Otherwise, the received V2X message is temporally validated. This allows the temporal validity of the received V2X message to be verified.

[0088] In the event of a positive verification, the information contained in the V2X message (in this case the state of the infrastructure equipment 4) is transmitted to the computer 7 for consideration (step 270).

[0089] Figure 4 represents the structure of a SPAT message as an example of a V2X message that can be modified to incorporate a message date and optionally an integrity check code. Note that a non-optional field of the standard is called an extension field.

[0090] The message header portion includes:

[0091] A "Protocol Version" or "Protocol Version" field;

[0092] A "Message ID" or "Message Identifier" field;

[0093] A "Station ID" or "Station Identifier" field.

[0094] The payload portion comprises:

[0095] An optional field “MoY” for “Moment of the Year” or “moment of the year”, i.e., the date of the message;

[0096] A "Desc. Name" or "Description Name" field coded on 63 bytes;

[0097] An "Intersection List" field or "Intersection List" coded on between 1 and 32 bytes;

[0098] An optional "Regional" or "Local settings" field coded on between 1 and 4 bytes.

[0099] According to the invention, the "Desc. Name" field of the textual description of the infrastructure equipment is partially repurposed for message protection. Its content is thus adapted to include:

[0100] A "Shortened DescName" field or "Short Description Name" coded on between 1 and 43 bytes;

[0101] An "HMAC Tag" or "HMAC label" field, which is a 4-byte SHA-encoded tag with predefined content such as the string "%#%#", to indicate the presence of the following HMAC field; and,

[0102] A 16-byte coded "HMAC" field containing the HMAC code calculated for the integrity check function.

[0103] The information in the "HMAC Tag" and "HMAC" fields is formatted in the IA5 string format of the V2X standard for text fields, in order to ensure compatibility with this standard.

[0104] The "Intersection List" field includes at least one "Intersection State" field, coded on between 1 and 32 bytes, which is used by the invention in the following manner:

[0105] An optional "Desc. Name" or "Description Name" field coded on 63 bytes;

[0106] A "Msg Cnt- Rev" or "Message Content" field;

[0107] An "Intersection Status" or "Intersection State Value" field;

[0108] A "MoY" field for "Moment of the Year" which is optional according to the standard but mandatory according to the invention and which is modified to include the message date;

[0109] A "Desc" or "Description" field coded on 63 bytes;

[0110] An optional field "Enable Lanes List" or "List of Lanes Open to the traffic ";

[0111] A “Movement List” field or “Movement List” coded on between 1 and 255 bytes.

[0112] An optional field “Maneu. Assist” or “Maneuvering Assistance”; and,

[0113] An optional "Regional" or "Local settings" field coded between 1 and 4 bytes.

[0114] While the embodiment described above relates to communication from a transmitting device on infrastructure equipment to a receiving device on board a vehicle, the invention is more general. For example, it could be applied to ensure V2X communication messages from a transmitting device on a vehicle to a receiving device associated with infrastructure equipment. This is the case, for instance, of an emergency vehicle (ambulance, police car, etc.) that can request a change in the state of the infrastructure equipment. For example, that the state of the traffic lights protecting an intersection be adjusted to allow this emergency vehicle to quickly cross the intersection in question.

[0115] The invention could, for example, still be applied to guarantee V2X communication messages from a transmitting device equipping a vehicle to a receiving device equipping another vehicle.

[0116] Moreover, although the invention has been presented more specifically on a SPAT message, other types of V2X standard messages can be altered to allow the implementation of the timing and integrity verification functions.

[0117] The invention makes it possible to include in a V2X exchange a temporal signature and, advantageously, also a security signature. These signatures are encoded / decoded by a standard implementation of the radio layers of the V2X standard. They therefore do not disrupt the existing use of the V2X message fields. In other words, an "ordinary" device, that is, one that does not implement the invention, remains capable of processing V2X messages altered according to the invention. This ordinary device would therefore not be able to verify either the temporal validity or the integrity of the messages.

[0118] The invention therefore makes it possible to make the date of a message reliable and to verify the temporal validity of this message in a secure manner.

[0119] The invention makes it possible to achieve high levels of security, in particular SIL 4 (according to EN 50126-1:2017) or ASIL D (according to ISO 26262-1:2018), while remaining compatible with the V2X standard. The proposed solution therefore makes it possible to guarantee the security level of key traffic information while remaining compatible with the communication standard.

Claims

1. Demands Method for securing communications according to the V2X standard, in its SAE J2735:2020-07 version, between a transmitting device (2) and a receiving device (3) of an automatic driving system (1), characterized in that said method comprises: - a time synchronization step (100) of a vital computer (24) of the transmitting device (2) and a vital computer (34) of the receiving device from at least one common external time source (11); - a step (220) of generating a message in the V2X standard by the sending device (2) consisting of dating the message by requesting a current date from the vital computer (24) of the sending device and incorporating the current date as the message date in a field of the message in the V2X standard; - a step (230) of sending the message in V2X standard by the sending device (2); - a step (240) of receiving the message in V2X standard by the receiving device (3); and, - a step (260) for verifying the temporal validity of the V2X standard message received by the receiving device by comparing a current date given by the vital computer of the receiving device with the transmission date embedded in the received V2X standard message; the step (100) for temporal synchronization of the vital computers (24, 34) of the transmitting and receiving devices using at least one second external time source, referred to as the auxiliary external time source, which may be different for the transmitting and receiving devices; the temporal synchronization of each vital computer among the vital computer of the transmitting device and the vital computer of the receiving device consisting of: - launch (110) by the vital computer of the execution of a time server (43, 53); - sending (130a) a request to the common external time source and receiving (140a) a response containing a first date; - sending (130b) a request to the external time source and receiving (140b) a response containing a second date; - checking (155) the consistency between the first and second dates, and, in case of inconsistency, the previous steps are iterated, and, in case of consistency, an internal time reference is established considering that it is a common time base for all components of the system; and, - maintaining (160) the internal time reference.

2. A method according to claim 1, wherein the step (220) of generating a V2X standard message further consists of calculating, by the sending device (2), an authentication code relating to the fields of the V2X standard message and a step of incorporating the calculated authentication code into a field of the message, and, in that the method includes a step (260) of verifying the integrity of the V2X standard message received by the receiving device by calculating an expected authentication code from the fields of the received V2X standard message and comparing the expected authentication code and the authentication code present in the received V2X standard message.

3. A method according to claim 2, wherein the authentication code is calculated from the different fields of the message in V2X standard using a hashing algorithm, preferably the SHA-256 algorithm with a dynamic secret hash key known to the different devices of the automatic driving system.

4. A method according to claim 2 or claim 3, wherein the authentication code is incorporated in the optional field or an extension field specific to the V2X standard.

5. Communication device compatible with the V2X standard, in its SAE 12735:2020-07 version, characterized in that it comprises a vital computer (24, 34) and a radio communication module, the device being configured to implement the transmitting device-side steps and / or the receiving device-side steps of the process according to any one of the preceding claims.

6. Device according to claim 5, wherein the vital computer is a vital platform of the type "2oo2".

7. Device according to claim 6, wherein the vital platform is such as to guarantee a high level of safety complying with the SIL 4 or ASIL D level.

Images