Method and vehicle bus system to forward ASIL relevant information from a data source to a data sink

FIELD OF THE INVENTION

The present disclosure relates to a method and vehicle bus system VBS to forward ASIL relevant information from a data source to a data sink.

BACKGROUND OF THE INVENTION

ASIL compliant VBSs are cost-intensive components of a vehicle.

SUMMARY OF THE INVENTION

It is an object of the invention to propose a method to forward ASIL relevant information in a VBS of a vehicle from a data source and to a data sink which allows to produce a VBS with reduced cost. It is a further object of the invention to propose a VBS for forwarding ASIL relevant information in a vehicle from a data source and to a data sink which can be produced with reduced cost.

The invention provides a method to forward Automotive Safety Integrity Level ASIL relevant information in a vehicle bus system of a vehicle from a data source to a data sink, wherein the vehicle bus system comprises the data source, an application processor with a trusted execution environment, a vehicle network and the data sink, a data source key being stored securely in the data source and in the trusted execution environment of the application processor, a telematics control unit key being securely stored in the data sink and in the trusted execution environment of the application processor; wherein the application processor comprises a trusted execution environment and an untrusted execution environment; wherein the data source uses a data source key to sign application data or to sign periodic keep alive packets and adds an error-detecting code to generate a signed data packet, wherein the data source forwards the signed data packet to the untrusted execution environment of the application processor; wherein the untrusted execution environment requests a signature verification of the signed data packet from the trusted execution environment, wherein the trusted execution environment verifies the signature of the signed data packet using the data source key stored in the trusted execution environment and prepares a signed message for the vehicle network by signing the signed data packet with the telematics control unit key stored in the trusted execution environment and sends the signed message back to the untrusted execution environment, wherein the untrusted execution environment sends the signed message to the vehicle network, wherein the signed message is forwarded within the vehicle network and is sent to the data sink, wherein the TCU signature of the signed message is verified by the data sink using the telematics control unit key stored in the data sink and the signed message is processed by the data sink.

This method makes it possible to provide a performance capability of an ASIL compliant VBS by using an application processor which is not designed as a safety capable system component. Therefore the inventive method allows to use cheaper components as application processor and as vehicle network. Additionally the inventive method allows it to design the VBS on the basis of ASIL compliant data sources which are cheaply available on the market. The advantage of this method is that only a part of the components of the VBS have to be designed as ASIL compliant components. According to the invention an “ASIL island” is established within the system of the VBS, wherein the safety relevant data are generated on this “ASIL island” which is designed as data source. The way down from the data source to the data sink is a passive signal path which can be compared with a cable. The correct/preemptive and unmanipulated transmission of the data is ensured: by an ASIL compliant message authentication in the data source, by the creation of an additional message which is authenticated with a TCU key which is done in a non ASIL compliant environment and which enables the data sink to verify the message using a common key, by cyclic keep alive packets, which means that a heartbeat is added in order to enable to quickly detect a missing transmission.

On the market several cost effective ASIL compliant data sources are available. By the inventive method it is possible to design a VBS which is ASIL compliant as a whole using such cost effective data sources.

It is further provided that a network failure is detected by the data sink by detecting a lack of periodic keep alive signed messages and countermeasures against a loss of safe state are triggered.

It is further provided that in the case that the content of the signed message is altered by malicious software that intruded into the untrusted execution environment or the vehicle network the signature verification which is done by the data sink fails due to an altered content of the signed message and countermeasures against a loss of safe state are triggered.

It is further provided that in that in the case that a data source failure is detected by the data source an error message is proactively prepared before a next cyclic keep alive message is due, the error message is forwarded from the data source to the data sink, wherein the data sink receives the error message and countermeasures against a loss of safe state are triggered.

It is further provided that the data source comprises a microcontroller and the data source key is implemented into the microcontroller during production of the data source.

It is further provided that the trusted execution environment of the application processor comprises a key storage device,

- wherein the TCU key is stored in the key storage device and wherein the TCU key is provided by a key management system of a manufacturer of the vehicle or the TCU to the application processor. It is further provided that the application processor is run with an operating system of the ASIL QM safety level, by which safety relevant data are allowed to pass through and data integrity is ensured.

A VBS with a data source key and a TCU key which are stored in such a way in the data source and in the application processor allows the application processor to verify a signed data packet and to generate a signed message out of the signed data packet.

It is further provided that the application processor is configured to communicate with a plurality of data sinks using the same pre-shared secret which is the telematics control unit key.

It is further provided that the signed data packet and the signed message are signed using HMAC.

The invention provides a vehicle bus system for forwarding ASIL relevant information from a data source and to a data sink, wherein the vehicle bus system comprises the data source, an application processor, a vehicle network and the data sink, wherein the application processor comprises a trusted execution environment and an untrusted execution environment, wherein the trusted execution environment of the application processor comprises a key storage device, wherein a data source key is stored securely in the data source and in the trusted execution environment, wherein a telematics control unit key is stored securely in the key storage device and in the data sink.

It is further provided that the vehicle bus system is safety capable, that the application processor is not safety capable, that the vehicle network is not safety capable and that the data sink is safety capable.

Such a VBS is ASIL compliant as a whole respectively safety capable as a whole even though an application processor is used which is not designed as a safety capable system component. Therefore the VBS can be built with a cheaper application processor. Additionally the invention allows it to design the VBS on the basis of ASIL compliant data sources which are cheaply available on the market. The advantage of such a VBS is that only a part of the components of the VBS have to be designed as ASIL compliant components. The inventive VBS makes it possible to design a VBS which is ASIL compliant as a whole using cost effective data sources.

It is further provided that the data source (DS) is safety capable, that the application processor (AP) is not safety capable, that the vehicle network (VN) is not safety capable and that the data sink (DSI) is safety capable.

According to the invention a VBS is a vehicle bus system.

According to the invention a TCU is a Telematics Control Unit. The TCU comprises a data source and an application processor, wherein it is possible that both components are structurally united or structurally separated.

According to the invention ASIL is an abbreviation for Automotive Safety Integrity Level. ASIL is a risk classification scheme defined by the ISO 26262 - Functional Safety for Road Vehicles standard. “ASIL compliant” and “safety capable” are used as synonymous terms, wherein both terms mean a standard which is higher than “ASIL QM”. According to the invention the hazard level “ASIL QM” is used as synonymous term to “not safety capable”.

According to the invention signed data packets (SDP) as well as signed messages (SM) comprise ASIL relevant information.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features and advantages of the present invention will become apparent to those skilled in the art to which the present invention relates upon reading the following description with reference to the accompanying drawing, in which:

Figure 1 shows a VBS of a vehicle in a schematic view. Figure 1 shows an electronic control unit VBS of a vehicle V in a schematic view. The VBS comprises a data source DS, an application processor AP, a vehicle network VN and a data sink DSI. The application processor AP comprises a trusted execution environment TEE and an untrusted execution environment UEE.

The VBS allows to forward ASIL relevant information from the data source DS to a data sink DSI.

The data source DS comprises a data source key DSK and uses the data source key DSK to sign application data AD or to sign periodic keep alive packets KAP and adds an error-detecting code EDC to the application data AD or to the cyclic keep alive packets KAP to generate a signed data packet SDP. Figure 1 shows both ways of generating a signed data packet SDP.

The information exchange between the data source DS and the application processor AP is secured . In other words, a shared secret is memorised securely by the data source DS and the application processor. FIMAC (hash-based message authentication code) using for example SFIA-2 or SFIA-3 (Secure Flash Algorithm 2 or 3) as hashing algorithm can be used in this context unications between the data source DS and the application processor is the data source key DSK and is securely memorized in the data source DS and in the application processor AP. More precisely, secure storage of the data source key DSK means that the key loaded inside the application processor is protected with respect to confidentiality and integrity.

According to a preferred embodiment, the application processor comprises a trusted execution environment TEE allowing achieving this secure storage of the data source key DSK. Further, as the data source is a more complex component due to its ASIL compliance, it has to be able to store the data source key DSK securely. For example, the data source may comprise an embedded secure element used for that purpose.

During production of the telematics control unit TCU, the manufacturer can generate the data source key DSK and write it into the two components. This is possible as the manufacturer is in full control of all components installed in the TCU.

A telematics control unit TCU comprises the application processor AP and the data source DS. According to an embodiment, the trusted execution environment TEE of the application processor AP comprises a key storage device KSD. The data source key DSK is stored in the data source DS and in the key storage device KSD of the trusted execution environment TEE.

Another symmetric authentication key referred as the TCU key TCUK can also be stored in the key storage device KSD.

The data source DS forwards the signed data packet SDP to the untrusted execution environment UEE of the application processor AP.

The untrusted execution environment UEE requests a signature verification of the signed data packet SDP from the trusted execution environment TEE.

The trusted execution environment TEE verifies the signature, for example a MAC signature, of the signed data packet SDP using the data source key DSK stored in the trusted execution environment TEE and prepares a signed message SM for the vehicle network VN by signing the signed data packet SDP with the TCU key TCUK and sends the signed message SM back to the untrusted execution environment UEE.

The untrusted execution environment UEE sends the signed message SM to the vehicle network VN.

The signed message SM is forwarded within the vehicle network VN and is sent to the data sink DSI.

The information exchange between the application processor AP in the TCU and the data sink DSI is also secured using HMAC. the SHA-2 or SHA-3 algorithms can be advantageously used. For that purpose, the TCU key TCUK is also stored securely by the data sink DSI.

Symmetric techniques such as HMAC can be used during system operation since the involved hashing algorithms are less complex to execute than authentication techniques based on asymmetric encryption. However, according to an example, an asymmetric technique such as public key cryptography is used in order to achieve secure key distribution.

Most of the electronic control units (ECUs) in a vehicle participate in the cryptographic system based on public-key cryptography of a modern vehicle. It is to be noted that a TCU is a particular example of an ECU. A given ECU receives its own private key during ECU production. Each ECU manufacturer is able to share its public key with the vehicle manufacturer who will further distribute it to other ECUs in the vehicle during vehicle production or via any other communication method. During connection establishment between the TCU and the data sink DSI, both nodes are able to use the public keys of the other entity to encrypt the handshake messages. They are also able to use their own private keys to decrypt encrypted messages. This secure execution channel can be used to exchange a shared cryptographic key for symmetrically encrypting all further communication or to ensure integrity and authentication of further communication using, e.g. HMAC techniques as described above. This process can be advantageously repeated at each vehicle reboot. If the TCU needs to share the same data with more than one data sink the public-key cryptography can also be used to share the same cryptographic key for HMAC-operation with more than one data sink. Since the HMAC operation with the pre-shared secret is applied at the AP the same key can be used to secure data originated in the ASIL compliant data source DS but also to secure data belonging to other services or applications that are offered by the TCU independently of the data source DS.

The message authentication code of the authenticated message AM is verified by the data sink DSI and the authenticated message AM is processed by the data sink DSI.

The data source DS is safety capable, the application processor AP is not safety capable, the vehicle network VN is not safety capable and the data sink DSI is safety capable.

A network failure is detected by the data sink DSI by detecting a lack of the periodic keep alive packets KAP which are also transferred signed messages SM. In this case the data sink DSI triggers countermeasures against a loss of safe state. A system intrusion is detected by the data sink DSI in the case that the content of the signed message SM is altered by malicious software that intruded into the untrusted execution environment UEE or the vehicle network VN, wherein the signature verification which is done by the data sink DSI fails due to an altered content of the signed message SM and countermeasures against a loss of safe state are triggered.

A hardware failure of the data source DS is detected by the data sink DSI. In order to initiate the hardware failure detection an error message is proactively prepared by the data source DS before a next periodic keep alive packet is due. This timing reduces latency of error reporting. The error message is forwarded from the data source DS to the data sink DSI, wherein the data sink DSI receives the error message and countermeasures against a loss of safe state are triggered.

The data source DS comprises a microcontroller MC and the data source key DSK is implemented into the microcontroller MC and into the trusted environment TEE of the application processor AP during production of the TCU using for example a key management entity KME of a manufacturer of the data source DS.

The TCU key TCUK is for example stored in the key storage device KSD, wherein the TCU key TCUK is provided by a key management system KMS of a manufacturer of the vehicle to the key storage device KSD of application processor AP.

The described invention can be advantageously used for systems combining ASIL compliant and not ASIL compliant components. It allows achieving ASIL compliance across the complete system. Data source DS and data sink DSI are ASIL compliant but the components in between are often not ASIL compliant. Thanks to the invention, ASIL compliance is achieved for the complete system while adding minimal extra load on the ASIL compliant components. Indeed, additional complexity increases their cost and adds further difficulty to maintain and verify said ASIL compliance.

It is also to be noted that periodic keep alive packets KAP are beneficial in order to enable ASIL compliance for the full system. Since the one or several nodes between the data source and the data sink may not be ASIL-compliant, it is not ensured that the data sink will be notified in case of failure of any node in-between. Using the keep-alive packets the data sink will notice that the overall system does not work properly anymore because no further keep-alive packets are received. The data sink can initiate proper countermeasures to ensure the overall system reaches a safe state even in the case of other nodes not functioning properly anymore.

Advantageously, the use of cryptographic techniques such as HMAC avoids man-in-the- middle from preventing the data sink to notice a system failure by sending further data packets instead of the failing data source or TCU. The data sink DSI is able to notice that the emulated packets sent by the man-in-the-middle are not issued by the data source DS because the man-in-the-middle does not have access to the shared cryptographic key of the current session that has been shared during the initial secure key distribution process, for example after vehicle boot up. The man-in-the-middle can also not emulate the whole key distribution process because he lacks access to the private key of the TCU which is needed to decrypt the messages of the data sink during the initial key distribution.

Additionally, the use of periodic keep alive packets ensure that the data sink DS is able notice a failure of another subsystem in a timely manner. Advantageously, both techniques ensure that the data sink can reach a safe state in a short amount of time independently of the behaviour of all non-ASIL compliant components in the system without adding further load to the ASIL-compliant data source.

REFERENCE NUMERALS:

AD application data

AP application processor

DS data source

DSI data sink

DSK data source key

ECU electronic control unit

EDC error-detecting code

KAP keep alive packets

KME key management entity

KMS key management system

KSD key storage device

HMAC hash-based message authentication code

MAC message authentication code

MC microcontroller

SHA-2 Secure Hash Algorithm 2

SHA-3 Secure Hash Algorithm 3

SDP signed data packet

SM signed message

TEE trusted execution environment

TCU telematics control unit

TCUK TCU key

UEE untrusted execution environment

V vehicle

VBS vehicle bus system

VN vehicle network