RU2797357C2 - Improvements in vehicle data or message transmission using scalable service oriented middleware over ip communication protocol - Google Patents

Abstract

FIELD: communications.

SUBSTANCE: invention relates to providing the possibility to carry out secure exchange of information in the communication network between onboard objects of a vehicle. It is achieved in that the method for transmitting messages in a data network on board a vehicle between an entity requesting a service instance and an entity offering a service instance via the SOME/IP communication protocol includes a step of mutual authentication between the requesting entity and the offering entity, taking into account transmission of data associated with the service instance, including checking for the existence and mutual validity of a pre-issued certificate between the requesting entity and the offering entity that permits access to the service instance, and verifying that the level of security at which the service is offered by the offering entity is not less than the minimum security level pre-assigned to the service by the requesting entity and the offering entity, and the step of transmitting at least one data message associated with the service instance from the offering entity to the requesting entity and vice versa, if the certificate verification and the security level verification are successful.

EFFECT: possibility to carry out secure exchange of information in the communication network between onboard objects of a vehicle.

11 cl, 9 dwg

Description

The present invention generally relates to the transmission of data or messages over the onboard network of a vehicle, and more specifically relates to the transmission of data or messages over the onboard network of a vehicle using the SOME/IP communication protocol.

In particular, the invention relates to a method for transmitting data or messages using the on-board network of a vehicle between at least one entity requesting a service instance and an entity offering a service instance via the SOME/IP communication protocol, according to the scope of the claimed legal protection.

SOME/IP, Scalable Service Oriented Middleware over IP, is a communication protocol developed for the automotive sector to transfer messages and messages over an Ethernet network running on board a vehicle between devices of various sizes, functions and operating systems, e.g. from cameras to telematic entertainment and information devices. The SOME/IP protocol provides service-oriented communication and is based on a list of services that are advertised a priori by each application. For each application, there is a so-called "manifest", which specifies all the services offered and the services that the application needs access to. The service or data it provides may be available to a device connected to the vehicle's on-board communication network after events in which the offering device cycles messages or when a status change occurs, or subsequently to requests or remote procedure calls on the offering device made requesting device.

The SOME/IP protocol is based on providing data series in Protocol Data Units (PDUs) as the payload of UDP or Transfer Control Protocol (TCP) messages sent over an Internet Protocol (IP) communications network.

Currently, the SOME/IP protocol is characterized by a lack of security in the exchange of information inside the vehicle, so it may happen that external devices can access the on-board communications, and from there they can intercept messages, gaining access to information exchanged between two objects, or by sending bogus messages to the address of the receiving entity, assuming the role of the transmitting entity without the receiving entity being aware of the spoofed transfer.

In the document "Characteristics of the Manifesto of AUTOSAR AP Open Automotive Systems Architecture Release 17-10" dated October 17, 2017 and the article by J. Kreissl "Securing communication using SOME / IP in adaptive AUTOSAR" dated November 15, 2017, it is proposed to use the transport layer security protocol ( TLS) to form a data packet of SOME/IP messages. However, the TLS protocol is only intended to secure unicast transmissions and is specific to the transmission protocol.

In data transmission, authentication means the process of verifying the identity of a subject/object. Instead, authorization refers to the rules that determine that a subject/object is allowed to act. The two concepts are distinct and independent, but both are important in building systems that function safely. In the prior art, user authentication is typically a requirement for authorizing a particular entity to perform a predetermined operation.

In the TLS protocol, authentication of objects interacting with each other is carried out using digital certificates. At the initial stage of establishing a session, the server and client must provide each other with their digital certificate, along with proof that they are the rightful owners of the certificate. For this purpose, digital certificates are used to communicate identity information with some cryptographic parameters, such as a public key that can be verified. However, the TLS protocol has no means to give any meaning to the content of digital certificates. Therefore, although it allows authentication of entities communicating with each other, TLS by itself cannot verify whether an entity is also authorized to initiate communication. In fact, this check is left to higher level protocols and applications.

The above documents suggest using the TLS protocol to establish secure connections between different devices, suggesting using server and client side certificates to obtain mutual authentication. No further verification is performed other than checking the validity of digital certificates. These documents do not contain additional information on how to confirm whether communication between two objects should be allowed or not, i.e. to prevent an application from accessing a service for which it is not authorized.

The TLS protocol has some disadvantages. Several security layers are not officially supported by the latest version of the standard (TLS 1.3), so it is effectively limited to the more expensive "confidentiality" security layer. Even if a version of the TLS 1.2 standard is used that supports a set of cipher sequences that work only in authentication mode, the level of security will depend on some mutable local parameters (allowed set of cipher sequences) for which there is no guarantee that the security level that designers and developers.

However, unlike traditional Internet servers, automotive engine control units (ECUs) are physically accessible on the vehicle, making it easy to edit the contents of insecure configuration files.

The purpose of the present invention is to provide an extension of the SOME/IP protocol that allows secure exchange of information in a communication network between transport entities.

According to the present invention, this object is achieved by means of a method for transmitting data or messages over the on-board communication network of a vehicle, having essential features, in accordance with the scope of the claimed legal protection.

Specific embodiments of the invention characterize particular cases of its implementation, the content of these options should be understood as an integral part of the present description.

Thus, the present invention is based on the principle of confirming which entities requesting an instance of a given service and which entities offering an instance of a given service are authorized to communicate with each other on board the vehicle (flow matrix), whereby each service or each an application whose execution provides a service can only be accessed by objects with validated permissions. An object is an on-board device or an application executed by an on-board device. Verification of the authority of an object on board the vehicle is to request or provide a service, whether it be an on-board device or a specific application with which the device performs a given function among the many functions performed, it is certified by a certification body external to the vehicle, such as a vehicle manufacturer or a Tier 1 on-board component supplier.

The verification of the authority of the vehicle entity to request or provide a service instance is mutually verified by both the entity requesting the service instance and the entity offering the service instance, and the authentication code is associated with any subsequent information message between the participating entities defined in accordance with the SOME/IP protocol, which is passed between the service-offering entity and the service-requesting entity if the authorization check of both entities is positive.

The authentication code is generated by the sending entity using a cryptographic function that takes as input a secure message and a symmetric encryption key associated with the service instance and returns a fixed-length byte string as output. The symmetric key associated with the corresponding service instance is used, which is exchanged between authorized entities before the start of data transmission during the data session establishment stage. This allows the receiving entity holding the same symmetric key to verify that the message has not been modified since it was created (integrity) and that it was generated by the entity holding the symmetric key (authentication).

Therefore, the claimed invention takes advantage of the integration into the SOME/IP middleware to obtain both the functions of authentication of the communication objects and the authorization to initiate a data transfer during the establishment of each secure communication session. Unlike the prior art, a different secure session must be established for each individual instance of the SOME/IP service, i. the technical solution is carried out with the detailing of the service instance.

Each application (or on-board device) is associated with a different digital certificate for authentication purposes. In addition, the same digital certificates are extended to define the set of services that an application (or on-board device) has the right to offer/request. Thus, digital certificates can be used to the advantage of vehicle manufacturers to define an allowed traffic matrix declaring the entire set of communications that can actually be established.

Whenever a new connection is initiated by an application that wishes to access a service, certificates are exchanged, similar to the TLS protocol. Similar to the TLS protocol, the validity of the digital certificate provided by the entity requesting the data transfer is initially checked. Unlike the TLS protocol, the invention also provides for checking whether the entity is also authorized to initiate a data transfer by checking the correspondence between the current instance of the service and the rules declared in its certificate. In other words, both authentication and authorization for access to a service instance are checked in accordance with the declared method during the establishment of a secure session, before application data is exchanged.

Preferably, thanks to the invention, it is possible to provide at least two levels of security for data transmission between different on-board objects of the vehicle in accordance with the needs, respectively, the first level of security "authentication", in which it is guaranteed that the message has reached the receiving object, originating from a certified (authorized) entity and has not been altered in transit over the network, and a second, higher level of security, "confidentiality", which prevents unauthorized third parties from decrypting the contents of a message as it travels over the network.

In particular, the "authentication" security layer ensures that only authorized entities can send messages associated with a particular service, providing message authentication. Before a SOME/IP packet containing a message relating to a service instance is sent, the transmitting entity, whether it be the offeror or the requester, is appended with an authentication code (MAC) generated by symmetric encryption mechanisms. When the receiving entity receives the message, this code can be verified: if the verification is successful, the receiving entity can determine that the message was sent by a trusted and certified (authorized) transmitting entity and has not been modified in transit over the network. In other words, the receiving entity can be sure of the authenticity and integrity of the message. In addition, by adding a sequence number, the strength of which is guaranteed by the above authentication code in the Data Maintenance field, it is possible to prevent attacks by replication, which are characterized by the interception of valid information packets and subsequent retransmission by third parties of the same packet for a new request for the same action. In the case of the "authentication" security level, although a third party is able to intercept information transmitted over the vehicle's communication network, it cannot inject false messages that can be easily detected because they lack a message authentication code generated using a cryptographic key obtained exchange after mutual recognition by the offering and receiving entities, and is therefore ignored by the receiving entity. This mode balances the importance of preventing third parties from taking physical actions, which can even be dangerous, on board the vehicle with false commands, with the possibility that the data exchanged is not confidential, in order to protect computing and transmission resources.

The "confidentiality" security level includes all the properties offered by the previous "authentication" security level, i.e. it guarantees the authenticity and integrity of messages exchanged on the vehicle communication network and prevents replication attacks. In addition, before transmission of each message, the content of the message is encrypted using an encryption function to prevent unauthorized access to it by unauthorized persons. It also provides confidentiality, i.e. data secrecy. Thus, a third party trying to intrude into the vehicle's data network cannot enter messages into the network because they will be recognized by checking the authentication code, and also cannot decode the transmitted data without having the necessary key to decrypt the semantic meaning of the messages. This mode provides the highest level of security at the expense of higher computing resources, especially in terms of message latency.

The Data Support field may advantageously include, in addition to the sequence number, any other parameters required by the selected symmetric cryptographic algorithm, such as a sync message which may be the same as the sequence number.

Additional features and advantages of the invention will be described in more detail from the following detailed description of its implementation, given as an example, which does not limit the scope of the claimed legal protection, with reference to the following illustrations:

Fig. 1 shows known communication modes between a service requesting entity or client and a service offering entity or server in a vehicle communication network;

Fig. 2 is a schematic representation of a known format of a message transmitted over a vehicle communication network in accordance with the SOME/IP protocol, including header and payload;

Fig. 3 is a schematic representation of a multicast configuration over a vehicle communications network to which the invention pertains;

Fig. 4 is a high level schematic of a session establishment between a requesting entity and an offering entity connected to a vehicle communication network in accordance with the invention;

Fig. 5 is a schematic representation of the properties of a vehicle object or an application executed by a vehicle object connected to a vehicle communication network in accordance with the invention;

Fig. 6 is a flowchart describing the principle of mutual authentication between an entity requesting a service instance and an entity offering a service instance, in accordance with the claimed method;

Fig. 7 is a schematic representation of an example of an authentication request message format in accordance with the claimed method;

Fig. 8 is a schematic representation of an example of an authentication response message in accordance with the claimed method; And

Fig. 9 is a schematic representation of an example of a message transmitted over a vehicle network in accordance with the improved SOME/IP protocol according to the invention.

In FIG. 1 depicts two different types of data transfer between a server or offering entity "OF" (illustrated "software") and a client or requesting entity "RQ" (illustrated "30"). The first type of communication, called "Request/Response", involves sending a request to a service instance by the requesting "RQ" entity, and possibly as a consequence, sending a response by the offering "OF" entity. The second type of communication, called Publish/Subscribe, involves activating a subscription to one or more events associated with a service instance by the requesting RQ entity and sending periodic or event-triggered notifications by the offering OF entity.

In FIG. Figure 2 shows the format of a message transmitted over a vehicle communication network in accordance with the SOME/IP protocol. interface, message type, and return code. The message also includes content of variable size "P" (in the illustration "IN").

In FIG. 3 is a schematic representation of a multicast configuration over a vehicle communications network in which a plurality of RQ entities requesting the same service instance communicate with a single OF entity offering a service instance. The arrows in a continuous line indicate the two-way relationship of mutual authentication "AuthREQ" and "AuthRES", while the dotted arrows indicate a message transfer session "C" in accordance with the secure SOME/IP protocol, which is possible only in case of successful mutual authentication.

In FIG. 4 is a schematic representation of the establishment of a session between a requesting entity "RQ" and an offering entity "OF" having access to the communication network of the vehicle, the session is characterized by mutual authentication with an asymmetric encryption method. The requesting entity "RQ" sends the authentication and authorization certificate "AUTH_RQ" during the service instance request to the offering entity "OF", and the latter responds by sending the authentication and authorization certificate "AUTH_OF" together with the symmetric cryptography key K in encrypted form.

In FIG. 5 is a schematic representation of the properties of a vehicle object "O" or an application executed by a vehicle object "O" connected to a vehicle data network. Entity O or an application executed by entity O may offer multiple services S1, S2, S3, each with a corresponding minimum security level SL (SL1, SL2, SL3 in the illustration), and may request multiple services S4, S5, each with a corresponding minimum security level UB4, UB5. Such an object or application is associated with a fingerprint authentication (in the illustrations "O.P.") and a signature "P". The fingerprint authentication may be a certificate "C", for example, in accordance with the X.509 standard, or a certificate identifier "F where # = 1, 2, ... adapted to point to a centralized registry of vehicle certificates or reproduced in each on-board device ( in the latter case, higher efficiency is achieved because the certificates are available locally when they are requested), e.g. published by a certification body external to the vehicle, such as the vehicle manufacturer or the first level supplier of the on-board component, the corresponding "C#" certificate (where #=1, 2, ...), including the public cryptographic key "K PUB", adapted to work with the corresponding private cryptographic key "K_PRIV", available only to the corresponding object, for encrypting and decrypting data exchanged between requesting and offering objects, according to the well-known asymmetric encryption technology. Certification (ie, the existence and validity of a certificate) certifies the authority of the entity requesting the service instance and the entity offering the service instance to communicate with each other on board the vehicle. The service or application whose execution creates the service can only be accessed by authorized entities.

With reference to FIG. 6-9, the method for securely exchanging information in accordance with the SOME/IP protocol is described below.

In FIG. 6 is a diagram of the mutual authentication flow between the requesting entity "RQ" and the offering entity "OF". In the first step, the requesting RQ entity sends an AuthREQ message over the vehicle communications network to the offering OF entity to which it intends to request the service instance. An exemplary format for an "AuthREQ" authentication request message is shown in FIG. 7. It includes, in particular, the authentication of the fingerprint of the requesting entity "F_RQ".

Upon receipt of the "AUTHREQ" authentication request message, the offering entity "OF" retrieves the certificate of the receiving entity using the fingerprint "F_RQ", for example, by accessing the certificate through a centralized certificate registry that can be accessed at the address associated with the certificate identifier "F_RQ" . The offeror verifies the certificate by verifying the digital signature it contains against the public key contained in the master certificate, called the "root certificate", whose integrity and authenticity are guaranteed by external mechanisms, and if successful, it compares the minimum security level authorized by the requesting entity, validated by a certificate, with a security level of "SL _SE ", to which the service instance is currently being offered. In the event that the minimum security level "SL _RQ " allowed by the requesting entity exceeds the security level that the service instance offers, SL _RQ >SL _SE , the offering entity terminates the connection. Otherwise, if the minimum security level SL _RQ allowed by the requesting entity is equal to or lower than the security level SL _SE that the service instance offers, the offering entity responds by sending an "AuthRES" authentication response message over the vehicle communication network.

An example of an "AuthRES" authentication response message is shown in FIG. 8. It includes, in particular, the fingerprint authentication "F_OF" of the offering entity, the symmetric encryption key "K_SYM" encrypted with the public encryption key "K_PUB_RQ" of the requesting entity "RQ", obtained from the certificate of the requesting entity, denoted by k, where k=encrypt(K_SYM) _{K_PUB_RQ} , and an electronic digital signature "S_OF" affixed with the offeror's private cryptographic key, denoted S, where S=sign(AuthRES) _{K_PRiV_OF} .

Upon receipt of the authentication response "AuthRES", the requesting entity "RQ" retrieves the certificate of the offering entity using the fingerprint "F_OF", for example, by accessing the certificate through a centralized certificate registry, which can be accessed at the address associated with the certificate identifier "F_OF ". The requesting entity verifies the certificate by verifying the digital signature contained therein against the public key contained in the master certificate, called the "root certificate", the integrity and authenticity of which is guaranteed by external mechanisms, and if successful, verifies the signature S associated with the message received using the public encryption key "K_PUB_OF" of the offering entity "OF" obtained from the certificate of the offering entity. If the verification of the digital signature is successful, the requesting entity compares the security level SL _SE for which the service instance is currently being offered against both the minimum security level SL _OF that the offering entity must guarantee as specified in the certificate, and against its own minimum security level. allowed by SL _RQ . In case the security level of the offered service instance is below the minimum security level SL _OF that must be guaranteed by the offering entity, SL _SE <SL _OF , or the security level of the offered service is below the minimum acceptable security level SL _RQ , SL _SE <SL _RQ , the requesting entity breaks the connection. In the opposite case, when the security level of the offered service instance is equal to or greater than both the minimum security level SL _OF that the offering entity must guarantee and its own minimum acceptable security level SL _RQ , the requesting RQ entity terminates the session establishment by decrypting with using the private cryptographic key of the receiving object "RQ" of the symmetric key transmitted by the offeror for the subsequent protection of messages, which is indicated by the expression: K_SYM=decrypt(k) _{K_PRIV_RQ} .

The confirmation of the authority of the vehicle entity to request or provide an instance of the service is then mutually verified by both the entity requesting the service instance and the entity offering the service instance by checking the corresponding certificate, and the authentication code is associated with any subsequent message between the entities participating in their exchange in accordance with the SOME/IP protocol that is passed between the offeror and the requester if the credentials of both entities pass.

Once a session has been established between the requesting RQ entity and the offering OF entity, messages can be securely exchanged according to the SOME/IP communication protocol between two authenticated and authorized entities in accordance with the format depicted in FIG. 9 in which the payload is encrypted with the symmetric key "K_SYM" if "confidential" communication takes place.

Preferably, the method described ensures that the message is protected with a different symmetric key for each service instance in a multicast configuration. The key is generated by the offeror and is securely transmitted to a plurality of requesting entities during the session establishment phase. Key regeneration may be convenient for long-term services, such as location data transmission, and should be performed at intervals such that over time the level of security guaranteed by the characteristics of the cryptographic algorithm and the key used is maintained.

The use of a single key in a specific group of entities whose message is for a predefined service instance allows multicasts to be secured quite simply without limiting SOME/IP functionality and without increasing vehicular network usage.

Advantageously, the inventive method is designed to perform operations preferably at the level of service instances, i. e. treating each SOME/IP service instance as a unique entity that a predefined application (or on-board device) can access or be denied access to. This condition is an effective compromise between the need to securely limit data transmission, which requires accepting exceptionally finer granularity, and attention to resources, which requires limiting the number of processes for establishing authentication sessions so as not to cause an unacceptable increase in latency in the transmission of messages and data over a communication network. vehicle.

Unlike the TLS protocol, the claimed method is intended to strictly enforce the level of security configured by the developers of the application or on the on-board device, provided that digital certificates are indicative of a minimum level of security that each entity must comply with in addition to defining a set of service instances, access to allowed to each aircraft application or device (traffic matrix). Therefore, during the session establishment step, the level at which the desired service instance is provided is compared to the requirements of the offering entity and the requesting entity to prevent these entities from violating previously imposed design constraints. Taking into account the guaranteed authenticity and integrity of digital certificates, the claimed method prevents attacks based on the forced lowering of the security level below the requirements set by the developers of the application or on-board device.

Thus, the invention is a personalized approach integrated into the SOME/IP protocol to ease the restrictions imposed by external solutions and ensure compatibility with all different models of media that support the SOME/IP protocol (unicast and multicast). The invention provides an implementation of a simple and effective solution for representing the matrix of traffic allowed in a vehicle (the set of services that each entity can request/offer), while at the same time providing multiple security layers to account for various security requests and possible costs that may arise. .

Naturally, the principles of the invention, structural elements and embodiments of the invention may differ from those described and depicted in the illustrations, while they do not limit the scope of legal protection and are presented as examples without changing the essence of the claimed invention, in accordance with the scope of the claimed legal protection.

Claims (16)

1. A method for transmitting data or messages in a data communication network on board a vehicle between at least one entity requesting a service instance and an entity offering a service instance via the SOME/IP communication protocol, wherein said offering entity provides a response as a result of the request the specified requesting entity or in which the specified offering entity provides periodic notifications or notifications triggered by events as a result of the subscription to the service by the specified requesting entity, characterized in that the verification of the authorization of the specified at least one requesting entity and at least one offering entity to access the service instance is determined in advance by a certification body external to the vehicle by issuing a pre-issued certificate of the specified requesting entity and the specified offering entity, wherein the certificate of the specified offering entity additionally assigns a minimum security level to this service for the offering entity among the set of predefined security levels, and the certificate of the specified requesting entity assigns the minimum security level to the specified service for the requesting entity among the specified set of predefined security levels, said method includes a preliminary mutual authentication step between said requesting entity and said offering entity, considering the start of a subsequent data transfer associated with the service instance, including: - checking the existence and mutual validity of the specified pre-issued certificate of the specified requesting entity and the specified offering entity, - checking that the level of security with which the service is offered by the offering entity is not lower than the minimum security level pre-assigned for the specified service by the requesting entity and the offering entity, and transmitting at least one information message associated with the service instance from the offering entity to the requesting entity and vice versa if said security level check and said certificate check are successful. 2. The method of claim 1, wherein said plurality of predefined security layers comprises an authentication security layer in which a message authentication code encrypted with a predefined encryption function is associated with each communication message of the service instance, and a privacy security layer, wherein each communication message includes a message authentication code encrypted with a predetermined encryption function and a payload encrypted with said predetermined encryption function. 3. The method of claim 2, wherein said predetermined encryption function includes a symmetric encryption key associated with a respective service instance, transmitted by said offering entity to said receiving entity in a pre-mutual authentication step. 4. The method of claim 3, wherein said message authentication code is generated by the sending entity through said predefined cryptographic function that takes as input said communication message and said symmetric encryption key associated with the service instance and returns a fixed-length byte string . 5. The method according to claim 3 or 4, characterized in that said symmetric encryption key is transmitted by said offering entity to said receiving entity, encrypted with the requesting entity's public encryption key. 6. The method according to any of the preceding claims, wherein the verification that the level of security with which the service is offered by the offering entity is not lower than the minimum security level pre-assigned to said service in the offering entity and the requesting entity is carried out in the offering entity and in the receiving object. 7. A method according to any of the preceding claims, wherein said preliminary mutual authentication step comprises sending from the requesting entity to the offering entity an authentication request message including said pre-issued certificate or an identifier of said requesting entity pre-issued certificate, and sending from from the proposer to the requesting entity of an authentication response message including said pre-issued certificate or the identity of said pre-issued certificate of the offering entity. 8. The method of claim 7, wherein said pre-issued requesting entity certificate and said pre-issued offering entity certificate are stored in the vehicle's centralized certificate registry or reproduced in each on-board device published by a certification body external to the vehicle. . 9. The method according to claim 7 or 8, characterized in that the verification of the existence and mutual validity of the pre-issued certificate of the specified requesting entity and the specified offering entity is carried out by verifying the correctness of the digital signature associated with it using the public key contained in the main certificate, the integrity and the authenticity of which is guaranteed by external mechanisms. 10. The method of claim 7, wherein said authentication response message further comprises an offeror control signature generated by the offeror's private cryptographic key. 11. The method of claim 3, wherein a plurality of entities requesting the same service instance interact with a single entity offering the service instance in a multicast configuration in which said symmetric encryption key associated with said service instance is generated by the specified offering entity and is shared by the specified set of requesting entities.

Images