KR20220002455A - Improved transmission of data or messages in the vehicle using the SOME/IP communication protocol - Google Patents

Abstract

Improved transmission of data or messages in the vehicle using the SOME/IP communication protocol
A method of transmitting data or messages in an on-board communication network between an entity requesting a service instance and an entity providing a service instance by means of a SOME/IP communication protocol is described, the method comprising: (a) an instance of a service preliminary mutual authentication between the requesting entity and the providing entity in view of the initiation of a subsequent communication associated with (i) the providing entity granting its access to the requesting entity and the service instance; verifying the existence and mutual validity of a pre-assigned certificate, and (ii) that the security level of the service provided by the providing entity is not lower than the minimum security level pre-assigned to the service at the requesting entity and at the providing entity and (b) if the certificate verification and the security level verification are successful, sending at least one communication message associated with a service instance from the providing entity to the requesting entity and vice versa. .

Description

Improved transmission of data or messages in the vehicle using the SOME/IP communication protocol

FIELD OF THE INVENTION The present invention relates generally to the transmission of data or messages on an on-board network of a vehicle, and more particularly to the transmission of data or messages on an on-board network of a vehicle by means of the SOME/IP communication protocol.

Specifically, the present invention relates to a method for transmitting data or messages via an on-board network of a vehicle between at least one entity requesting a service instance and an entity providing a service instance via the SOME/IP communication protocol according to the preamble of claim 1 . is about

SOME/IP (Scalable Service-Oriented Middleware over IP) communicates messages and messages via an onboard Ethernet network between devices of different sizes, functions and operating systems, for example from cameras to telematic entertainment and information units. It is a communication protocol developed for the automotive sector to transmit The SOME/IP protocol provides service-oriented communication and is based on a list of services declared a priori in each application. For each application there exists a so-called "manifest" in which all the services provided and the service that the application must access are specified. The service or the data it provides is transmitted to the vehicle according to events that are when the providing device periodically sends a message or a state change occurs or subsequently requests or calls a remote procedure in the providing device performed by the requesting device. It can be accessed from any device connected to the onboard communication network of

The SOME/IP protocol is a payload of UDP or TCP messages transmitted over a communication network based on the Internet Protocol (IP), and is based on data serialization in protocol data units (PDUs).

Currently, the SOME/IP protocol is characterized by weak security in the exchange of information inside the vehicle, so that external devices gain access to the on-board transport means and intercept messages therefrom, to the information exchanged between the two entities. Approaching, or sending spoofed messages towards receiving entities, can impersonate the sending entity without making the receiving entity aware of the spoofed transmission.

In the document "Specification of manifest AUTOSAR AP Release 17-10" of October 17, 2017 and in J. Kreissl's article entitled "Absicherung der SOME/IP Kommunikation bei Adaptive AUTOSAR" of November 15, 2017, SOME/IP We propose to use the TLS protocol to encapsulate messages. However, the TLS protocol is only for protecting unicast transmission and is specific to the transmission protocol.

In communication, authentication refers to the process of verifying the identity of a subject/entity. Authorization refers instead to the rules that determine what a subject/entity is allowed to do. Although these two concepts are orthogonal and independent, both are important in designing a system that operates safely. User authentication in the prior art is generally a requirement for authorizing a specific entity to perform a predetermined task.

In the TLS protocol, authentication of entities communicating with each other is implemented through digital certificates. During the initial phase of establishing a session, the server and client need to present their digital certificates together to each other along with proof that they are the legitimate owners of the certificates. To this end, a digital certificate is used to associate the identity with some cryptographic parameters such as a public key that can be verified. However, the TLS protocol does not have the means to attach any meaning to the content of digital certificates. Thus, while the TLS protocol enables entities communicating with each other to be authorized, the TLS protocol itself cannot verify whether an entity is authorized to initiate communication. In fact, this verification is left to higher level protocols and applications.

The aforementioned documents propose to use the TLS protocol to establish secure communication paths between different devices, and to use server and client-side certificates to obtain mutual authentication. No additional verification is performed other than validation of the digital certificate. These documents do not provide further details on how to verify whether communication between two entities should be allowed, ie, how to prevent an application from accessing an unauthorized service.

The TLS protocol itself has several shortcomings. Multiple levels of security are not officially supported in the latest version of the standard (TLS 1.3), so they are actually limited to the more expensive "confidentiality" security level. Even assuming the application of the TLS 1.2 standard version, which supports a set of cipher suites operating in an authentication-only mode, the security level is dependent on some modifiable local parameters that will not ensure that designers and developers actually respect the desired security level ( It will depend on the set of allowed cipher suites).

However, unlike a typical Internet server, the automotive ECU is physically accessible in the vehicle, making it easy to edit the contents of unprotected configuration files.

It is an object of the present invention to provide an extension of the SOME/IP protocols that allow the secure exchange of information within a vehicle communication network.

According to the invention, this object is achieved by a method for transmitting data or messages over an on-board communication network of a vehicle having the features mentioned in claim 1 .

Certain embodiments are the subject of dependent claims, the content of which should be understood as an integral part of the description of the invention.

In summary, the present invention identifies which of the entities requesting an instance of a given service and the entities providing an instance of the given service (traffic matrix) are authorized to communicate with each other in the vehicle, whereby each service Or it is based on the principle that execution ensures that each application performing a service can only be accessed by authorized entities. An entity is an onboard device or an application executed by the onboard device. The authority for an on-vehicle entity to request or provide a service, whether an on-vehicle device or a specific application for which the device has performed a predetermined function among a plurality of executable functions, is authorized by the vehicle manufacturer or the first-tier supplier of onboard components It is certified by a certification body outside the vehicle.

The authority of the entity of the vehicle to request or provide a service instance is mutually verified by both the entity requesting the service instance and the entity providing the service instance, and if verification of the authority of both entities provides a positive result, the authentication code is associated with any subsequent communication message between the associated entity, defined according to the SOME/IP protocol, transmitted between the providing entity and the requesting entity.

The authentication code is generated by the sending entity via an encryption function that receives as input a message to be protected and a symmetric encryption key associated with the service instance and returns a fixed size byte string as output. During the step of establishing a communication session, the symmetric key associated with the corresponding service instance exchanged between the authorized entities prior to initiating communication is used. It enables the receiving entity, possessing the same symmetric key, to verify that the message has not been modified since it was created (integrity) and that it was created by an entity that knows the symmetric key (authentication).

Therefore, the solution of the present invention takes advantage of integration in SOME/IP middleware to obtain both the authentication function of communicating entities and the authority to initiate communication during establishment of each secure communication session. Unlike the prior art, a different secure session must be established for each different SOME/IP service instance, ie, the solution of the present invention operates on a per service instance basis.

Each application (or onboard device) is associated with different digital certificates for authentication purposes. Also, the same digital certificate is enhanced to declare a set of authorized services that an application (or onboard device) can provide/request. In this way, digital certificates can be used for the benefit of car manufacturers to define the allowed traffic matrix, declaring the full set of communications that can actually be established.

Whenever a new communication is initiated by an application trying to access a service, a certificate exchange occurs, similar to the TLS protocol. Similar to the TLS protocol, the validity of a digital certificate presented by the entity requesting communication is initially verified. Unlike the TLS protocol, the present invention also provides verification of whether an entity is authorized to initiate communication, verifying correspondence between the current service instance and the rules declared in that service instance's certificate. In other words, authentication and authorization to access a service instance are verified according to the method of the present invention during establishment of a secure session prior to exchange of application data.

Advantageously, it is possible by the present invention to provide at least two security levels for communication between different different onboard entities of the vehicle as required, wherein in a first security level of "authentication" the message is authenticated ( It is guaranteed that it has reached the receiving entity originating from the authorized) entity and has not been modified during transmission over the network, and at a higher security level, “confidentiality”, that during transmission over the network, unauthorized third parties do not decode the content of the message. is prevented from

In particular, the "authentication" security level provides message authentication by allowing only authenticated entities to send messages associated with a particular service. Before a packet according to the SOME/IP protocol containing a message related to a service instance is transmitted by a sending entity, an authentication code (MAC) generated through a symmetric encryption mechanism, whether a providing entity or a requesting entity, is attached to the packet. When the receiving entity receives the message, this code can be verified: if validation is successful, the receiving entity indicates that the message originated from a trusted and authenticated (approved) transmitting entity and upon transmission over the network. It can be judged that it has not been modified. That is, the receiving entity can be sure of the authenticity and integrity of the message. In addition, by adding a sequence number whose reliability is guaranteed by the aforementioned authentication code in the Support Data field, valid information packets can be intercepted and subsequent follow-up by a third party to the same packet for a new request of the same operation. It is possible to prevent attacks by duplication characterized by retransmission. For the "authentication" security level, although a third party can intercept information transmitted over the vehicle communication network, it cannot inject a false message, which is followed by mutual recognition of the providing entity and the receiving entity, followed by the ciphering key Since there is no message authentication code generated using This mode balances the importance of preventing a third party from triggering potentially dangerous physical actions within the vehicle through erroneous commands, as the data exchanged has the potential to be non-confidential, which saves computational and transmission resources. it is to protect

The "confidential" security level includes all the attributes provided in the previous "authentication" security level, ie, ensures the reliability and integrity of messages exchanged in the vehicle communication network and prevents attacks by duplication. Also, before transmission of each message occurs, the payload of that message is encrypted with an encryption function to prevent unauthorized entities from accessing the message. It also ensures confidentiality, i.e. the confidentiality of data. Therefore, a third party attempting to break into the vehicle communication network cannot inject the message into the network, which means that the messages are recognized through verification of the authentication code, so it is not possible to decrypt the transmitted data, and the semantic meaning of the messages Because it doesn't have the key it needs to decrypt. This mode provides the highest level of security at the expense of a higher computational burden, especially in terms of latency of message transmission.

Said support data field may advantageously contain in addition to the sequence number any other parameters required by the selected symmetric encryption algorithm, for example an initialization vector which may match the sequence number.

The effect of the present invention is individually indicated in the corresponding parts of the specification.

Additional features and advantages of the present invention will become more apparent from the following detailed description of embodiments of the present invention, given by way of non-limiting example with reference to the accompanying drawings.
1 shows a known mode of communication between an entity requesting a service or client and an entity providing a service or server in a vehicle communication network.
Figure 2 schematically shows a known message format transmitted over a vehicle communication network according to the SOME/IP protocol including a header and a payload.
3 is a schematic diagram of a multicast communication configuration through a vehicle communication network according to the present invention.
Fig. 4 is a high-level schematic diagram of establishing a communication session between a providing entity and a requesting entity connected to a vehicle communication network according to the present invention;
5 is a schematic diagram of a property declaration of a vehicle entity or an application executed by a vehicle entity connected to a vehicle communication network according to the present invention;
6 shows a sequence diagram illustrating a mutual authentication scenario between an entity requesting a service instance and an entity providing a service instance according to the method of the present invention.
7 schematically shows an example of the format of an authentication request message according to the method of the present invention.
8 schematically shows an example of the format of an authentication response message according to the method of the present invention.
9 schematically shows an example of a message format transmitted over a vehicle network according to the improved SOME/IP protocol according to the present invention.

Figure 1 shows two different types of communication between a server entity or providing entity OF and a client entity or requesting entity RQ. The first type of communication, called "Request/Response", involves sending a request to a service instance by a requesting entity RQ and optionally as a result, sending a response by a providing entity OF. . 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 entity RQ and sending periodic or event-triggered notifications by the providing entity OF. include

2 shows the format of a message transmitted through a vehicle communication network according to the SOME/IP protocol. The message includes a header H including a message identifier, a message length, a request identifier and a plurality of identifying fields of protocol version, interface version, message type and return code. The message also includes a variable size payload P.

3 shows a schematic diagram of a multicast communication configuration on a vehicular communication network in which a plurality of entities RQ requesting the same service instance communicate with a single entity OF providing the service instance. Solid arrows AuthREQ and AuthRES indicate bidirectional communication of mutual authentication, and dotted arrows M indicate a message communication session according to the secure SOME/IP protocol of the present invention, which is possible only when mutual authentication is successful.

4 shows a schematic diagram of the establishment of a communication session between a providing entity OF and a requesting entity RQ facing a vehicle communication network characterized by mutual authentication by means of asymmetric encryption technology; The requesting entity RQ sends an AUTH_RQ authentication and authorization certificate upon request to the service instance of the providing entity OF, and the latter responds with an AUTH_OF authentication and authorization certificate transmission along with a symmetric encryption key K in encrypted form.

5 shows a schematic representation of a declaration for properties of a vehicle entity E or an application executed by a vehicle entity E connected to a vehicle communication network. Entity E or an application executed by entity E may provide a plurality of services S1, S2, S3 each having a minimum security level SL1, SL2, SL3 and a plurality of services having a minimum security level SL4, SL5 respectively S4, S5 can be requested. This entity or application is associated with a certification fingerprint F and a signature S. Said authentication thumbprint can be coordinated to point to e.g. certificate C according to the X.509 standard or the vehicle's centralized certificate register REG, or duplicated on each on-board device (in the latter case more useful as the certificate is available locally when requested) to achieve high efficiency), e.g. certificate identifier F_ID# published by a certificate authority outside the vehicle, such as the vehicle manufacturer or the first-tier supplier of on-board components, with their respective certificates C# (where # = 1, 2, ...) (where # = 1, 2, ...) and a corresponding private encryption key accessible only to the corresponding entity for encryption and decryption of data exchanged between the requesting entity RQ and the providing entity OF according to known asymmetric encryption techniques. Contains the public cryptographic key K_PUB configured to act as K_PRIV. The authentication (ie, existence and validity of the certificate) proves the authority of the entity requesting the service instance and of the entity providing the service instance to communicate with each other onboard the vehicle. A service or application that creates a service when running can only be accessed by privileged entities.

6 to 9, a secure communication method according to the SOME/IP protocol according to the present invention will be described below.

6 shows a flowchart of a mutual authentication scenario between a requesting entity RQ and a providing entity OF. In a first step, the requesting entity RQ sends an AuthREQ authentication request message on the vehicle communication network to the providing entity OF that wants to request a service instance. A possible format of an AuthREQ authentication request message is shown in FIG. 7 . It specifically contains the F_RQ authentication fingerprint of the requesting entity RQ.

Upon receiving the AuthREQ authentication request message, the providing entity OF retrieves the receiving entity's certificate via the F_RQ fingerprint, for example, by accessing the certificate via the REG certificate register referenced at the address associated with the certificate identifier F_RQ. The providing entity verifies the electronic signature contained in the certificate by using the public key contained in the master certificate, referred to as the “root certificate”, whose integrity and authenticity are guaranteed through an external mechanism, and upon successful verification, by the certificate Compare the _{expressed minimum security level SL RQ} allowed by the requesting entity with _{the security level SL SE} currently provided by the service instance. If the minimum security level SL _RQ allowed by the requesting entity is higher than the security level provided by the service instance (SL _RQ > SL _SE ), the providing entity OF stops communication. Otherwise, if the minimum security level SL _{RQ allowed by the requesting entity is equal to or lower than the security level SL SE} provided by the service instance, the providing entity OF responds by sending an AuthRES authentication response message in the vehicle communication network.

A possible format of the AuthRES authentication response message is shown in FIG. 8 . It is specifically a symmetric encryption key K_SYM encrypted by the public encryption key K_PUB_RQ of the requesting entity RQ obtained from the certificate of the requesting entity denoted by k, where the authentication fingerprint F_OF of the providing entity OF, k = encrypt(K_SYM) _{K _PUB_ RQ, and s} the = sign (AuthRES) comprises a _{K_ _ oF PRIV} the s digital signature S_OF attached by a private encryption key of the service entity oF represented by.

Upon receiving the AuthRES authentication response message, the requesting entity RQ retrieves the providing entity's certificate via the F_OF fingerprint, for example by accessing the certificate via the REG certificate register referenced at the address associated with the certificate identifier F_RQ. The requesting entity uses the public key contained in the master certificate, called the "root certificate", whose integrity and reliability are guaranteed through an external mechanism to secure the digital signature contained in the certificate, and if the verification is successful, the providing entity's certificate Verifies the signature associated with the received message by the public encryption key K_PUB_OF of the providing entity OF obtained from If the validation of the digital signature is successful, the requesting entity sets the security level SL _{SE to which the service instance is currently provided, the minimum security level SL OF} that the providing entity represented by the certificate must guarantee, and its own allowed minimum Compare with security level SL _RQ. When the security level to which the service instance is provided is lower than _{the minimum security level SL OF that the providing entity must guarantee (SL SE} < SL _OF ), or when the security level to which the service is provided is lower than _{its own allowed minimum security level SL RQ} (SL _SE < SL _RQ ), the requesting entity stops communication. If the security level provided by a service instance is _{equal to or higher than the minimum security level SL OF} that the providing entity must guarantee and its own allowed minimum security level SL _RQ, and vice versa, the requesting entity RQ is used for subsequent protection of the messages. By decrypting the symmetric key transmitted by the providing entity through the private encryption key of the receiving entity RQ - Equation K_SYM = decrypt(k) _{K _ PRIV _ RQ} Indicated simply as - completes the establishment of the communication session.

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 providing the service instance through verification of the corresponding certificate, and the two entities of the providing entity and the requesting entity If the authentication verification for ? provides a positive result, then an authentication code is associated with any subsequent communication message between the entities bound according to the SOME/IP protocol transmitted between the providing entity and the requesting entity.

Once a communication session between the requesting entity RQ and the providing entity OF is established, messages may be exchanged according to the SOME/IP communication protocol between two authenticated and authorized entities according to the format shown in FIG. 9 , wherein Payload P is encrypted by the symmetric key K_SYM if "confidential" communication is in progress.

Advantageously, the method described above ensures protection of messages by using a different symmetric key for each service instance in a multicast communication configuration. The key is generated by the providing entity and securely shared with multiple requesting entities during the step of establishing a communication session. Said re-keying may be convenient for long lasting services, for example for the communication of location data and periodic, such as maintaining over time a level of security guaranteed by the encryption algorithm used and characteristics of the key. should be performed with

The use of a single key in a specific group of entities for which communication is associated with a predetermined service instance ensures that multicast communication is transparently protected without limiting the functionality of the SOME/IP protocol and without increasing the use of the vehicle communication network. make it possible

Advantageously, the method of the present invention is designed to work with a granularity, preferably at the level of service instances, ie each instance of the SOME/IP service is accessible or has access to a predetermined application (or onboard device). Consider a unique object that can be rejected. This condition dictates the need for strong communication isolation, which requires the adoption of very fine granularity, and the number of processes for establishing authentication sessions in order not to result in an unsustainable increase in latency of message and data transmission over vehicle communication networks. It is an efficient compromise between attention to resources that require restrictions.

Unlike the TLS protocol, the method of the present invention provides that in addition to defining the set of service instances (traffic matrix) that each onboard application or device is authorized to access, a digital certificate provides a minimum level of security that must be adhered to by each entity. By providing declaring a level, it is designed to strictly respect the security level configured by the designer of the application or onboard device. Thus, during the step of establishing a communication session, the level at which a desired service instance is provided is compared with the requirements of the providing entity and the requesting entity to prevent these entities from violating previously imposed design constraints. Assuming that the authenticity and integrity of the digital certificate is ensured, the method of the present invention prevents attacks based on forcibly lowering the security level below the requirements imposed by the designer of the application or onboard device.

Therefore, the present invention provides a personalized approach integrated into the SOME/IP protocol to relax the constraints imposed by external solutions and to achieve compatibility with all different communication models supported by the SOME/IP protocol (unicast and multicast). indicates the method. The present invention provides a simple and effective solution for expressing the traffic metric (set of services that each entity can request/provide) allowed in a vehicle, while at the same time taking into account different security and overhead requests that may arise at multiple levels. It aims to provide the security of

Of course, the principles, manufacturing details and embodiments of the present invention as understood may vary widely as compared to those described and illustrated by way of non-limiting examples only without departing from the scope of the invention as defined in the appended claims.

Claims (11)

A method for transmitting data or messages in a vehicle-mounted communication network between at least one entity requesting a service instance and an entity providing a service instance by means of a SOME/IP communication protocol, wherein the providing entity communicates by means of the requesting entity. provides a response as a result of a request, or the providing entity provides periodic notifications or notifications triggered by events as a result of subscription to a service by the requesting entity;
Authorization for the at least one requesting entity and for the at least one providing entity to access a service instance is predefined by an authentication step external to the vehicle through issuance of a pre-assigned certificate of the requesting entity and the providing entity; , wherein the certificate of the providing entity further assigns a minimum security level to a service for the providing entity from among a plurality of predetermined security levels, and wherein the certificate of the requesting entity is configured for the requesting entity from among the plurality of predetermined security levels. Allocating a minimum security level to the service for
The method comprises a preliminary mutual authentication step between the requesting entity and the providing entity taking into account the initiation of a subsequent communication associated with an instance of a service, the step comprising:
- verification of the existence and mutual validity of the pre-assigned certificate of the requesting entity and the providing entity;
- verification that the security level of the service provided by the providing entity is greater than or equal to the minimum security level pre-allocated for the service at the requesting entity and at the providing entity;
- sending at least one communication message associated with a service instance from the providing entity to the requesting entity or vice versa if the security level verification and the certificate verification are successful. According to claim 1,
wherein the plurality of predetermined security levels are encrypted with a predetermined encryption function, the message authentication code includes an authentication security level and a confidentiality security level associated with each message of communication of the service instance, and each communication message is encrypted with a predetermined encryption function an encrypted message authentication code and a payload encrypted with the predetermined encryption function. 3. The method of claim 2,
wherein the predetermined encryption function includes a symmetric encryption key associated with each service instance delivered by the providing entity to the receiving entity in the preliminary mutual authentication step. 4. The method of claim 3,
wherein the message authentication code is generated by a sending entity via the predetermined encryption function receiving as input a symmetric encryption key associated with the communication message and the service instance and returning a string of fixed size bytes. 5. The method according to claim 3 or 4,
and the symmetric encryption key is communicated by the providing entity to the receiving entity encrypted via a public encryption key of the requesting entity. 6. The method according to any one of claims 1 to 5,
wherein the verification that the security level of the service provided by the providing entity is at least a minimum security level pre-assigned to the service at the providing entity and at the requesting entity is implemented at the providing entity and at the receiving entity. 7. The method according to any one of claims 1 to 6,
The preliminary step of the mutual authentication includes sending, from the requesting entity to the providing entity, a message for an authentication request comprising the pre-allocated certificate or an identifier of the pre-allocated certificate of the requesting entity, and the pre-allocated certificate or sending an authentication response message from the providing entity to the requesting entity comprising an identifier of the pre-assigned certificate of the providing entity. 8. The method of claim 7,
wherein the pre-assigned certificate of the requesting entity and the pre-assigned certificate of the providing entity are stored in a centralized certificate register of the vehicle or issued by a certificate authority external to the vehicle and replicated within each onboard device. 9. The method according to claim 7 or 8,
Verification of the existence and mutual validity of the pre-assigned certificate of the requesting entity and of the providing entity verifies the correctness of the associated digital signature, using the public key contained in the master certificate whose integrity and authenticity are guaranteed by an external mechanism. A method performed by verifying. 8. The method of claim 7,
and the authentication response message further comprises a control signature of the providing entity generated by the private encryption key of the providing entity. 4. The method of claim 3,
A plurality of entities requesting the same instance of a service communicate with a single entity providing an instance of the service in a multicast communication configuration, wherein the symmetric encryption key associated with the service instance is generated by the providing entity and the plurality of requesting entities shared with others, the method.

Images