Reading time
14 minutes

In this paper, Elektrobit presents a multi-level security architecture to protect an Automotive Ethernet network against malicious attacks. Such a protection is of key importance to enable automated driving.

The individual driver assistance functions available in vehicles today are, step by step, evolving into highly complex interrelated systems designed to make fully automated driving possible. The path leads from alarm-based support functions to assisted driving, such as lane departure warning systems, to functions that take partial control of the vehicle, such as the highway chauffeur or valet parking and finally to completely autonomous cars. Along with these developments, the requirements for transmission rates that must be able to handle large amounts of data are increasing significantly, thus turning Automotive Ethernet into a key technology for future vehicles.

 

Dependability and security

To make automated driving possible, Automotive Ethernet must provide not only a high bandwidth but also, and most importantly, dependable and secure communication. The technical literature describes the close relation-ship between dependability and security (see Figure 1). Dependability includes all attributes that must be taken into account in a safety-critical system to prevent serious and unacceptable consequences in case the system fails. These attributes are availability, reliability, and integrity as well as safety and maintainability. Security, on the other hand, is specifically concerned with the protection against malicious attacks of human origin and, in addition to availability and integrity, also includes the aspect of confidentiality.

 

 

Secure communication

There is no clear line of separation between dependability and security as security-relevant attacks may also impair dependability: These types of attacks may affect the availability of services by disrupting the reception of correct sensor data and/or control data. Integrity can be compromised by malicious manipulation of sensor or control data on the network. Confidentiality can be compromised when unauthorized third parties intercept or record control data. All of the above must be prevented for the entire vehicle network and during the entire life cycle.

Protection against external attacks is very important where automated driving functions are concerned. Attacks on the communication network can occur in the form of deliberately inserted faulty messages (e.g., braking commands) or intentional interference with the transmission of correct messages (e.g., manipulation, delay or removal of existing messages, replay of messages, etc.). Points of attack in the vehicle are external nodes, such as on-board diagnostic interfaces (OBD) or wireless connections (see Fig. 2), hacked existing nodes such as infotainment control devices with a low level of security protection or exchanged and manipulated control devices.

 

 

Dynamic threats

Since cars have a relatively long life cycle, attack patterns can change over time. Based on Moore’s law, the available processing power of computers still doubles approximately every 2 years. This fact can be used for ever larger and more sophisticated attacks. A data encryption method that was considered secure eight years ago, for example, can be attacked because key sizes are now too short.

 

Multi-level security architectures

A security architecture designed with multiple levels can effectively counteract these external threats. This concept prevents that passing a single security barrier already results in a successful attack and serious damage.

The security architecture developed by EB consists of four levels that protect the system layer by layer. Level 1, “Restricted Network Access”, strictly limits access to the network making it as difficult as possible for malicious attackers to get into the communication network. This level already offers very effective protection. If it is passed nevertheless, level 2, “Secure On-Board Communication”, makes sure that all security-relevant messages that are exchanged are protected against manipulation by attackers. Should an attack manage to get past this level of protection as well, level 3, “Data Usage Policies”, protects by requiring a user-specific validation. Before sensitive message content is processed further, it is checked in a user-specific context. The last level of security, level 4, is “Detection & Defense”. On this level the entire communication pattern is checked for anomalies. If an attack is detected, defense mechanisms ensure that the breached security of levels 1-3 is restored. This multi-level architecture provides comprehensive protection against attacks on the availability, integrity and confidentiality of the system.

 

Level 1 – Restricted Network Access

The first level of the security architecture aims to restrict the access to the in-vehicle network by using four measures: (1) centralized off-board connection, (2) security zones, (3) device authentication, and (4) frozen network configuration.

The first measure is aimed at reducing the number of control devices with off-board connections to limit the potential points of attack to a few very well-protected control devices. In the “Intelligent Antenna Module”, for example, an application layer gateway completely decouples the external network from the internal network to protect these control devices. This means that direct access to an internal network node from the outside is not possible.

The second measure is the division of the network into several security zones. An actual, physical separation is usually not possible. This is why the division occurs by means of virtual LANs (VLANs) in accordance with IEEE 802.1Q. Here, a VLAN tag is inserted between the Ethernet Header and the data. This tag provides unique iden-tification for all Ethernet messages of a VLAN. The VLAN tag is added or removed at the switch or directly in the control device. This makes it possible to achieve a clear and efficient separation of data traffic involving external devices (e.g., diagnostic test devices) and purely internal communication. Further security zones are formed based on vehicle domains, such as infotainment system or powertrain, or on the type of message (e.g., audio/video, time-sensitive control data, non-time-sensitive control data) via separate VLANs, where a control device may belong to several security zones.

As third measure the participation to the network is limited to authenticated network nodes only. Unused switch ports are permanently deactivated or will only be activated for normal communication after the connected node has been successfully authenticated. The authentication of the network node is done by the switch firmware or the microcontroller directly connected to the switch.

A frozen network configuration is the fourth measure. Both, the ARL tables in the switch for transferring Ethernet frames as well as the ARP tables in the control devices for L2/L3 address translation are statically configured or frozen after a learning phase. This prevents that a new node is able to send or receive messages. Alternatively (or additionally) the switches and receiving control devices are supplied with access control lists for comparison of header address fields (e.g. IP source addresses) of received messages and rejection of messages that do not match the list.

 

Level 2 – Secure On-Board Communication

The second level of the multi-level security architecture secures onboard communication by two means: (1) data authentication and (2) data encryption.

Data authentication is achieved by means of symmetric cryptography. The sender uses the data of a message, a secret key specifically assigned to the connection and a freshness value (timestamp or counter) to calculate a Message Authentication Code (MAC), which is added to the message. The receiver performs the same calculations and compares the calculated value to the MAC value from the received message. This way the receiver is able to effectively detect whether data has come from an unauthorized sender, has previously been recorded and is being re-transmitted (replay attack) or has been changed during transmission, for example, by a malicious intermediary device (man-in-the-middle attack). The calculation of a data signature, that is, the use of an asymmetric crypto-graphy method, is not currently seen as an alternative for onboard communication because it would increase the calculation effort significantly.

The second measure is to encrypt the data with a secret key (symmetric cryptography) to prevent unauthorized third parties from eavesdropping.

Different protocols standardized by IEEE, IETF or AUTOSAR are available on different communication levels to realize the two measures as shown in Table 1.

 

 

One of the main considerations in selecting the protocol is the communication level on which it operates.

 

 

As Figure 3 shows, MACsec (IEEE 802.1AE) operates on OSI layer 2 and therefore always only directly between two neighboring Ethernet nodes. IPsec (IETF 4302, 4303) operates on OSI layer 3 and already allows a secure end- to-end connection as shown in Figure 3 by the continuous line between the sender and the receiver. TLS (IETF 5246) operates on OSI layer 4 with the TCP transport protocol. SecOC (AUTOSAR) operates above the transport layer, which is why it is mainly independent from the underlying network protocols. Besides TCP, for example, it can also be used with the UDP transport protocol, which is most commonly used in vehicles. A special feature of SecOC is the option to transmit the message authentication code calculated for data authentication in parts only (MAC truncation), so that it can also be used in combination with slower vehicle networks (CAN, CAN-FD, FlexRay).

In our security architecture, we use SecOC as an onboard system together with an extension for encrypted transmission and TLS for communication with vehicle-external devices.

As a basic principle of cryptography the same key should not be used for different functions and devices and a key should not be used for a long period of time. Data authentication, key exchange and data encryption thus each require a different key. If the key for data encryption is compromised, for example, the other keys are not affected and a new key can be assigned via the existing encrypted key exchange. To limit the amount of data for which a key is used, every key is assigned a specific lifetime for which it is valid, depending on its use. Moreover, communication can be divided into separate groups with separate connection keys according to the respective vehicle domain or other functional aspects.

For efficient execution of cryptographic functions and secure key storage a hardware security module (HSM) shall be used. The distribution of the keys to the ECUs in the vehicle is a very complex task. The usual methods em-ployed in the IT world, such as the Internet Key Exchange Protocol IKEv2 (IETF 4306) and X.509 certificates (IETF 5280), are not suitable for in-vehicle key management. Those methods would consume too many resources and an online connection to a Certification Authority Server (CA server) would be required but cannot be guaranteed at all times or would take too long. Instead, one ECU in the vehicle assumes the role of the key master and centrally distributes the keys to the other ECUs. The key exchange is realized by means of symmetric encryption and will be triggered through a diagnosis request, an elapsed period of time or from a service backend server outside the vehicle. The key master is the only ECU that communicates with the service backend server regarding key manage-ment. It uses asymmetric cryptography methods for this purpose.

 

Level 3 – Data Usage Policies

The third level of the Elektrobit ́s multi-level security architecture is based on the principle of “Data Usage Policies”. Application-specific knowledge is used to verify and, if necessary, restrict received data (sensor values or critical actuator commands) considering the sequences of the values, the condition of the vehicle or other sensor data.

In this way, attempts to manipulate the displayed data can be detected or the implementation of diagnosis-specific functions can be blocked during normal vehicle operation. Moreover, specific requirements can be defined that must be fulfilled before specific functions may be carried out, for example that diagnosis-specific functions may only be performed when the driver’s door is open. The processing of received messages with implausible content is thus restricted so that bad effects of malicious attacks can be avoided. This type of protection serves as an additional security measure, however, possible side effects have to be considered when designing such data usage policies. Examples from the aviation industry such as the thrust reversal illustrate that. During landing, the thrust reversal of the turbines of a plane provides an additional, or alternative, braking method to the wheels.

After fatal plane crashes occurred because the thrust reversal was triggered maliciously already during the flight, different measures were implemented in form of data usage policies that should ensure that a thrust reversal can only be initiated during landing when the plane is on the ground. One of the criteria, for example, is that the wheels must be turning. On an icy runway, however, the wheels can become blocked and the thrust reversal, which is then the only braking option, cannot be triggered because the wheels are not turning. In that case, the data usage policy is too strong disabling the correct function of the thrust reversal as an important braking option.

Data usage policies of level 3 should be designed considering the full application-specific context. The goal is to identify implausible data that originate from manipulation. All other data should be accepted to ensure the availability of the system functionality.

 

Level 4 – Detection and Defense

On level four, the “Detection and Defense” level, the communication pattern is checked for anomalies and, if necessary, defense measures are initiated. It is assumed that malicious attacks change known communication patterns. Periodic messages are suddenly received in an irregular pattern or the MAC authentication for a message repeatedly fails. An extreme case is the denial-of-service attack in which messages are sent repeatedly with the goal of causing an overload. This significantly impairs normal communication.

Switches already offer many mechanisms to detect anomalies. If a previously set bandwidth limit is exceeded or an IP message has the same target and source address, for example, specific switches are able to detect this in the hardware. In addition, detection algorithms can be implemented in software on selected control devices.

If such anomalies are detected, several modes of defense are available. Identified interfering transmitters are blocked directly using switches, restoring level 1 protection. Once this is done, data encryption keys can be exchanged to restore level 2 protection and the application can switch off specific functions to regain level 3 protection.

These defense mechanisms can therefore restore the protection levels of the security architecture that were compromised by an attacker. The decision whether the journey can be continued without hindrance or whether the driver of an automated vehicle has to take over the steering wheel again will be taken based on the application. A fault memory entry (diagnostic trouble code) is recommended in any case.

The architecture presented here for protection against malicious attacks on availability, integrity and confidential-ity offers a slightly different type of protection on every level (see Table 2). Level 1 offers protection in all three areas. Level 2 protects integrity and confidentiality, but is not able to fend off attacks on availability (such as denial-of-service attacks). Level 3 only offers protection with regard to integrity. Level 4 is able to fend off attacks on availability and offers partial protection for integrity. The security mechanisms thus complete one another on the different levels, with the protection of the first level being the strongest and most important. If the first level is actually compromised, the additional levels help, step by step, to contain the effects of an attack, to explicitly detect the attack and to take the necessary measures.

 

 

Elektrobit has implemented the presented security architecture in the context of the AUTOSAR communication stack (see Figure 5). The levels can be implemented by smart configuration of existing AUTOSAR software modules, but in some cases partial proprietary extensions are required to achieve full functionality. Level 1 is realized by configuring the switches in the Ethernet EthSwt module and EthIf module. The recipient list can be configured in the Tcplp module.

 

 

On level 2 data integrity can be achieved by means of the SecOC module and the CSM /HSM crypto modules. In addition, extensions for encryption (SecOC) and key management (SecKeyM) are necessary. Level 3 is realized in the form of application software components. Level 4 in turn is implemented by configuring the switches and adding a software extension (SecMon) that interacts with the modules related to the other levels.

The multi-level security architecture makes an important contribution to securing communication via Automotive Ethernet. Because security and dependability are interrelated, this is particularly important for automated driv-ing functions, especially in highly complex situations in which the wellbeing of the passengers depends on the functionality of the vehicle’s systems. Here, a great deal of knowledge from the IT sector is applied, where switch configurations, VLAN tagging and many other methods have been widely used for a long time. The automotive sector poses special requirements, but also allows optimizations because of the well-defined environment. The security architecture developed by Elektrobit takes all this into account and integrates these solutions in a way that is also compatible with the AUTOSAR standard.

 

References

[1] A. Avizienis et al. (2004): Basic Concepts and Taxonomy of Dependable and Secure Computing, IEEE Transactions on Dependable and Secure Computing, Vol. 1, N. 1

 

Download our free version of EB tresos evaluation package