Abstract
Information technology has become eminent in the development of modern cars. More than 50 Electronic Control Units (ECUs) realize vehicular functions in hardware and software, ranging from engine control and infotainment to future autonomous driving systems. Not only do the connections to the outside world pose new threats, but also the in-vehicle communication between ECUs, realized by bus systems such as Controller Area Network (CAN), needs to be protected against manipulation and replay of messages. Multiple countermeasures were presented in the past making use of Message Authentication Codes and time stamps and message counters, respectively, to provide message freshness, most prominently AUTOSAR’s Secure Onboard Communication (SecOC). In this paper, we focus on the latter ones. As one aspect of this paper, using an adequate formal model and proof, we will show that the currently considered solutions exhibit deficiencies that are hard if not impossible to overcome within the scope of the respective approaches. We further present a hardware-based approach that avoids these deficiencies and formally prove its freshness properties. In addition, we show its practicability by a hardware implementation. Finally, we evaluate our approach in comparison to counter-based solutions currently being used.
1. Introduction
Information technology has become an integral part of modern vehicles. More than 50 interconnected Electronic Control Units (ECUs) realize vehicular functions in hardware and software ranging from engine control and connected infotainment systems to future autonomous driving systems. The in-vehicle communication between ECUs is realized with bus systems like CAN (Controller Area Network Bus [1]). Further, vehicles communicate with the outside world (e.g. with their manufacturer’s backend systems, with the garage’s On-Board-Diagnose (OBD) devices) via different communication interfaces. Usually, these interfaces are not strictly separated from the in-vehicle network (the OBD port for example must have access to a car’s ECUs to extract error codes). This poses serious security threats, one of the possible attack vectors being in-vehicle communication. The vehicle owner can for example install a tuning box to suppress or inject messages that control engine operations in order to achieve more horsepower. This in turn may damage the engine and violate the warranty. Moreover, third-party devices connected to the OBD port can inject messages to the regular in-vehicle network. In [2], Koscher et al. have shown various attack techniques like Packet Sniffing and Targeted Probing, Fuzzing, and Reverse-Engineering.
Multiple countermeasures were presented in the past to protect in-vehicle networks (see Section 2.4). Early work can be traced back to EVITA [3] that introduced Message Authentication Code (MAC) truncation in order to cope with the small bandwidth of field buses such as CAN. This approach has been adapted by AUTomotive Open System ARchitecture AUTOSAR in SecOC [4]. Including a freshness value in a message’s MAC can in principle prohibit fuzzing or replay attacks. Most of the current approaches consider a monotonic counter value.
In this paper, we discuss our new counter-based approach BusCount based on our ideas introduced in [5], present its full formal verification, discuss its implementation and provide a practical evaluation. We further oppose it to a generic system that captures the principles of today’s counter-based approaches for freshness protection. The principle idea of our approach is to use the messages that are sent on a specific bus as a pulse generator for the counter of this bus, resulting in only one counter per bus. To cope with the loss of counter values e.g. caused by technical problems or an attack, our approach includes counter synchronization. Further, it requires the sending and reception of messages to be processed simultaneously to MAC generation and verification. Therefore, we propose a hardware-based solution: The CAN controller is enhanced by the functionality to maintain a counter and to manage MAC generation and verification while the main ECU processors can be inactive at times.
In the next section, we present the principles of in-vehicle communication based on CAN, our attack model, the protection goals we will address, current work concerning the security of CAN-based communication, and finally the characteristics of the counter-based approaches currently being discussed. Section 3 then describes the details of our approach BusCount. The following Section 4 briefly introduces our Security Modeling Framework SeMF that is then used in Sections 5 and 6, respectively, to formally model and verify both the generic counter approach and our bus counter approach. Based on these results, in Section 7.1 we present a comparison of the security aspects of both approaches while Section 7.2 introduces our proof of concept implementation showing its practicability and design decisions that substantiate our formal proof. Finally, we conclude with Section 8.
2. Principles of In-Vehicle Communication
CAN bus is the core technology for onboard communication in vehicles. Brakes, acceleration, and many further essential features are controlled by ECUs that communicate using CAN bus messages. An overview of different network structures is given in [6]. The CAN network is accessible via the OBD port allowing repair shops to access the car network. Modern vehicles also have connections through infotainment systems as well as telematic control units (TCUs) connecting the CAN bus to the outside world. By connecting the in-vehicle communication with the outside world, the necessity arose to protect its messages against malicious entities.
In this section, we describe the basics of CAN bus communication, the attacker model we take as a basis, the most relevant protection goals, and the current approaches for protecting these goals.
2.1. Basics of CAN Communication in Vehicles
The CAN bus, specified in [1], is a field bus where each entity connected to it is able to send messages and listen to every message sent on the bus. The maximum transfer rate of the highspeed-CAN is 1 Mbit/s.
A standard CAN message consists of 7 segments (Figure 1): “Start of frame” bit, a message identifier, a control field, a data field, a checksum, a confirmation field, and an “end of frame” sequence.
The 11 bit identifier which is the second section of a CAN message also represents the message’s priority which is used to handle collisions. The CAN bus uses Carrier Sense Multiple Access/Collision Resolution (CSMA/CR) to prevent collisions: All ECUs start sending a CAN message simultaneously and monitor its identifier while sending. In case a dominant 0 overwrites a 1 the ECU with the lower priority stops its transmission, thereby avoiding collisions.
During the transmission of the message every ECU calculates the CRC (cyclic redundancy check) over the message and checks the correctness of it as soon as it gets transmitted by the sender. In case of a problem (e.g. if the CRC check has failed) an ECU interrupts a transmission with an error frame that invalidates the message for all receivers. Furthermore, an error counter is increased by 1 for every receiver and by 8 for the sender. Every successfully transmitted message decrements the counter. If a counter reaches 128, the ECU disables its CAN connection. This mechanism ensures that damaged ECUs do not block the entire bus communication.
Successors of CAN, like CAN FD or CAN XL, differ mainly in the frequency of transmitting data payload. CAN FD can transmit up to 64 bytes while CAN XL can handle 2048 bytes.
2.2. Our Attack Model
Attacks on in-vehicle communication have been presented first by Kocher et al. in [2]. These attacks concern manipulation of brake control and vehicle acceleration via CAN Bus by message injection. In the real world, attacks on vehicle networks have been observed that manipulate in-vehicle communication by attaching devices to the bus system, like tuning devices, AdBlue emulators [7], unauthorized OBD dongles [8], etc.
In our attack model, an attacker can send arbitrary messages on any bus she has access to. Moreover, she can overhear and record all communication on a bus she is connected to and replay all recorded messages. Finally, an attacker is able to flip bits of messages or send an error frame. This enables her to invalidate messages for other ECUs after having recorded them herself. In our scenario, an attacker does not have access to any cryptographic keys. This also includes that the attacker cannot manipulate ECUs by e.g. corrupting firmware which in turn implies that legitimate ECUs always act correctly. Furthermore, the attacker is not able to manipulate processes or storage of ECUs by physical attacks. In addition, the attacker is not able to produce a counter overflow as a sufficient counter length is chosen to prohibit this sort of attacks.
2.3. Protection Goals
A secure CAN bus communication in a vehicle needs to fulfill a set of requirements to prevent previously introduced attacks. These include e.g. data integrity, confidentiality, and availability. In the following, we explain those requirements we specifically address in this paper.
Data Origin Authenticity: A message in a vehicle network should be accepted if and only if it has authentically for the recipient been sent by another valid member of the network. This property prevents attackers from manipulating messages or sending messages on the bus system from additional devices or replaced components without the intended recipient noticing.
Immediacy: Contrary to many other IT-systems, it is important for an automotive system to receive and process messages within a certain time frame. Once this time frame has passed, messages might be authentic, but can still cause fatal results, e.g. if breaking signals sent by the anti-lock braking system are processed too late. Immediacy expresses the fact that a message sent at time is accepted until if and only if does not exceed a specified limit.
Non-repeatability: The last important property for an automotive network is non-repeatability: If a message is accepted at time , the same message is not accepted at any later point in time. Thus, an attacker cannot eavesdrop on a message and successfully replay it at a later point in time.
Many articles do not distinguish between the two above properties and use the more abstract concept of “message freshness” with “message replay” seeking to violate freshness. We adapt to this notation and distinguish the specific characteristics when necessary.
2.4. State of the Art CAN Bus Security
The security of bus communication in current vehicle networks has already been discussed in literature and standardization. Early work on MAC truncation for secure CAN bus communication can be traced back to [3]. In this section, we give an overview of state of the art with a focus on replay protection in CAN bus systems and compare the techniques.
A lot of CAN bus security approaches introduce message authentication mechanisms, but not all introduce replay protection. The latest example of an approach without freshness values is TOUCAN: A proTocol tO secUre Controller Area Network presented by Bella et al. [9], which introduces a 24 bit truncated Chaskey MAC and a SPECK64 encryption for each CAN message.
A more exotic approach for replay protection is used in LCAP by Hazem et al. [10]. LCAP appends a truncated element of a hash chain to the CAN message and encrypts the resulting message. An HMAC secures the transmission of the last element of the hash chain to initialize the communication. Woo et al. [11] periodically change HMAC keys to prevent replay attacks.
Nürnberger and Rossow [12] developed VatiCAN, an HMAC based authentication procedure that sends a MAC in a separate message following the original CAN message. The MAC is then validated with a delay of about 4 ms. Replay protection is implemented with a monotonically incremented counter, its starting value being a random nonce generated by a central component for every message ID. The authors recommend this procedure only for a few CAN messages since it increases the bus load. Van Bulck et al. improved this approach in [13] by introducing software isolation and attestation as well as key update mechanisms.
Hartkopp et al. presented a further approach to introduce freshness to CAN messages. MaCAN [14] formally verified in [15] introduces a central trusted time server which distributes time information over the network. This information is used as freshness value for message authentication.
AUTOSAR specifies the protection of communication in vehicle networks based on a MAC and a freshness value. The specification of the Secure Onboard Communication (SecOC) [4] module suggests to add a truncated timestamp or message counter and a truncated authenticator to every message. The specific counter mechanism is based on splitting the counter (with a maximal length of 96 bits) into three different parts: the so-called “trip counter” that only changes essentially with every new trip, a “reset counter” that is reset periodically, and the actual “message counter”. Only the trip counter is stored in non-volatile memory, thus mitigating loss of counter values in case of sudden ECU shutdown. The truncated freshness value has a length between 0 and 8 bit. The truncated authenticator consists of the first 24 to 28 bits of the MAC covering the full freshness value and the message.
Similar to SecOC many approaches in literature use counters and an application-level protocol to ensure replay protection. Kurachi et al. [16] suggest attaching a truncated MAC (8 bit) and a truncated monotonic counter (4 bit) to a message. A monitoring node verifies messages during transmission and overwrites invalid messages with an error frame. ECUs do not verify messages. Groll et al. [17] suggest an initialization phase to form groups of ECUs. These groups generate a shared symmetric key using an asymmetric key exchange. Within these groups, ECUs use the shared secret for authentic and confidential encryption. A counter should be part of the message to protect against replay attacks. Lin et al. presented an approach in [18] with symmetric keys for message authentication. A sender calculates a MAC for every receiver. Every ECU also holds two counters for replay protection per message ID, the last counter it has sent and the last one it has received. Every receiver can verify the MAC and process its corresponding message. The LeiA protocol by Radu et al. [19] is another solution that transfers MAC and counter value in a separate message. Every ECU has a session key for each relevant message ID derived from a long-term symmetric key and renewed after a certain period. VeCure [20] is a CAN authentication framework similar to VatiCAN. The authentication value is also transmitted via a separate message, but contrary to VatiCAN the second message includes a Node-ID besides a Message Counter and a four byte HMAC value.
Alternatively, several approaches suggest the use of CAN+ [21], a protocol extension for CAN allowing to transport 120 bit additional data. The first approach is CANAuth presented by Van Herrewege et al. [22]. Another one is LiBrA-CAN [23]. LiBrA-CAN introduces (Linearly) Mixed MAC, which mixes multiple MACs of one message generated with different keys allowing receivers to verify a MAC even though they do not know all keys. The approach allows making sure receivers cannot impersonate a sender in a properly organized group. Both approaches send counter values in their messages to protect against replay attacks.
Some works are also considering the implementation of a secure CAN bus controller. Their approaches introduce the calculation of MACs, denial of service countermeasures, or intrusion prevention mechanisms. [24] implemented a CAN controller including a physical unclonable function implementation, key generation and storage, and encryption and decryption allowing authenticated communication over CAN. However, the approach does not consider replay protection. Ueda et al. presented a CAN controller with integrated HMAC in [25]. To ensure replay protection a truncated monotonic value of 4 bits is part of every message. Messages which are not authentic are destroyed while correct messages update the counter.
A new approach by Groza et al. [26] suggests replacing CAN IDs with a specific MAC-based algorithm that preserves the order of CAN IDs. In predefined time intervals the counter included in the MAC is incremented thus the IDs change. This approach increases the resistance against reverse engineering and denial of service attacks related to a specific ID. It does not provide data integrity and authenticity which needs an additional security protocol as mentioned in the paper. Moreover freshness is not guaranteed since the counter used in the MAC of the CAN ID does not change with every message. In case of constantly changing counter values (IDs) and if a significant limitation of ID range is acceptable this can be a viable alternative to transfer of fresh counter values.
We observed that most of the presented approaches (cf. Table 1) have similar ways to ensure replay protection and authentication of messages. All approaches add a MAC to a CAN message. While a MAC provides authenticity of a message, only in combination with a freshness value replay and delay attacks can be mitigated. Most approaches introduce a counter value to provide freshness since the usage of time or nonce values has disadvantages, discussed e.g. in [27]. The transmission of MAC and freshness values is either realized in an additional message or achieved by including truncated values in the same message. The verification of a complete message is performed by the receiver or an additional node. In the following section, we present a detailed generic model covering the characteristics of the current counter-based approaches for freshness. This model is then compared to our approach based on formal verifications of the security goals.
2.5. The Generic Counter Concept
Considering the recent research, we simplified the approaches in order to generate an abstract model to evaluate the security of software-based freshness techniques compared to our approach. Since a large majority of approaches favor counters for freshness values, we focus on this technique.
Figure 2 illustrates the abstract protocol we assume. To transmit a CAN message which contains the and payload data an ECU first calculates a MAC covering and a local counter derived by incrementing the previously used one (steps 1 and 2). For our analysis, the choice of the MAC algorithm is not important. In the next steps, , and the authentication tag are concatenated (step 3) and the values are transmitted (step 4). Note that this transmission is not necessarily processed with one CAN message only, different techniques could apply here. Finally, a receiver gets the message, verifies the MAC and tests if its local counter is smaller than the counter in . The check is not necessarily performed by the same entity which later processes . If both checks are successful, the local counter is set to the counter in and the message can be processed. Otherwise, the message is discarded.
Only some approaches consider an explicit synchronization of counter values which is necessary in case an ECU loses its counter value, e.g. due to a software error, a power loss (engine stop or malfunction) or an ECU without persistent memory. Most approaches that use synchronization introduce a central system sending an authenticated message containing the current counter value. In case a sender has an incorrect counter, the value needs to be provided by a dedicated entity or some client. In both cases the counter value is transmitted in the payload CAN message with a reserved ID. This message is secured identically to regular messages.
Even though the generic counter protocol is fairly simple it represents the characteristic properties of all above mentioned protocols that increment counters after successful validation of the message. The fact that the local counters of message recipients only change when a message is accepted is a very important characteristic property. Consequently, these protocols cannot prohibit so-called delay attacks, as will be formally shown in Section 5.2. For such an attack, the adversary with the abilities described in Section 2.2 stores and then invalidates a message and all subsequent ones related to the same counter. The reinserted message will then be accepted by the intended recipients at any later point in time if no further countermeasures are taken.
3. BusCount: A Hardware Based Bus Counter Solution
In this section we describe BusCount, our approach for a hardware based secure CAN bus communication, which eliminates the possibilities of attackers with the abilities presented in Section 2.2. We first introduce our approach to ensure immediacy, non-repeatability, and authenticity of messages on the bus and then elaborate on the synchronization mechanism for freshness values.
In a bus system, each participant can see and thus count every message written to the bus. Hence, the number of messages sent on a particular bus is an inherent part of the system that can serve as a bus specific counter [5] known by all devices connected to it. Consequently, there is no need to send counters. Each bus of a vehicle system is equipped with its own counter. Its value changes automatically with each new message: An ECU sending/receiving a message reduces its local counter value by 1 and authenticates/verifies the message including the counter with a MAC. This idea can be also applied to any other bus network.
The procedure of BusCount is described in more detail as follows (see Figure 3 for a schematic representation):
First, a sender ECU starts transmitting a message which is composed of a message ID and the payload . As soon as the transmission starts, the local counter of the sender is temporarily decremented (step 1.1). The counter is decremented instead of the usual incrementation because 0 is the dominant bit on the CAN bus thus a lower counter can overwrite a larger counter. This property is used for the synchronization of the counter explained in the next section. A receiver ECU, when receiving the start of the message, decrements its local counter and uses the result as its new counter value (step 2.1). Since sending and receiving of messages is processed simultaneously and thus the sender also receives its own message, it decrements its counter analogously. After the counters are decremented the sender starts sending and both receiver and sender start calculating the MAC over the message and their respective local counter using a shared key . Finally, the tag of the sender’s MAC is transmitted (step 1.3) and received (step 2.3). All ECUs now evaluate the tag.
If the evaluation is positive can be processed. Otherwise, the receivers whose verification failed immediately transmit an error frame which has the effect that is discarded by every ECU. Note that this effects also ECUs that do not implement the protocol: They will discard messages overwritten with an error frame. In case multiple errors occur, a synchronization is necessary.
3.1. Synchronization
Multiple transmission failures may indicate that an ECU is not synchronized. This situation can occur e.g. if the ECU is switched off without having been able to store the current correct counter value in persistent storage. Consequently, a synchronization between all entities of a bus is necessary. Our synchronization concept utilizes the mechanism used for collision resolving which is based on the fact that sending a 0 always overwrites a 1 on the CAN bus. Hence, in BusCount counters are decremented instead of the usual incrementation.
The mechanism is illustrated in Figure 4. One ECU initializes the synchronization by sending a predefined synchronization ID (Step 1.1). At the same time, each receiving ECU including the initiator of the synchronization, receiving the start of message bit, decrements its local counter. Now all ECUs, having identified the message as synchronization message, simultaneously start to send their respective newly decremented local counter in the data frame (Step 2.1 and 2.2). The lowest counter will overwrite larger counters and ECUs with larger counters stop sending (Step 3). An ECU with the lowest counter value (the actual sender of the synchronization message) sends a MAC over the ID and the counter value (Step 4.1 or 4.2). Each ECU as a recipient of this message verifies the correctness of the MAC and compares the counter to its local one. In case one check by any of the receivers fails, the rest of the message is overwritten with an error frame and is discarded by all controllers. Otherwise, every receiver replaces its local counter with the counter of the synchronization message.
In case multiple ECUs have the lowest counter in the network, each sends the same message without noticing each other. This concept has been used for example in [28] to implement a key exchange on a CAN bus.
In contrast to other approaches that use a counter for every message ID, our approach allows to synchronize all participants of a bus communication with just one message. Further, no central entity is needed for the process, any ECU connected to the bus can initialize it. The only condition for it to work is that at least one ECU owns and processes the correct counter value.
In Section 7.2 we will discuss design decisions and introduce our proof of concept implementation. In the next section we will briefly introduce the Security Modeling Framework SeMF that is then used in Sections 5 and 6, respectively, to formally model and verify both the generic counter approach and our bus counter approach with respect to the desired security properties. The achieved results will then be discussed in Section 7.1.
4. The Security Modeling Framework SeMF
We use our Security Modeling Framework SeMF (see [29] for a detailed description) to formally model and verify the two counter systems discussed in this paper. SeMF is a powerful modeling framework that we have already successfully applied to a variety of different domains and abstraction levels. For example, we used it to verify that specific security properties of service based systems are preserved under composition [30]. We also applied it to model and verify the integration of device authentication based on TPM attestation with secure channel establishment via SSL [31]. Another example is [32] where we proved preservation of specific security properties for the composition of abstract security patterns.
The basic idea of SeMF is to describe the system behavior by sequences of actions that capture essential changes in the system. As underlying formal semantics SeMF uses prefix closed formal languages (see e.g. [33]) whose alphabet is composed of the actions in the system. More specifically, it uses a set of agents (where the term “agent” can denote any entity acting in the system such as a human being, an ECU, etc.), and a set of actions (e.g. specifying sending and receiving messages on a bus) performed by the agents. The system’s behavior is then formally described by a prefix closed formal language ( denoting the set of all words composed of elements in with denoting the empty word), i.e. by the set of its possible sequences of actions. A system model further comprises the agents’ local views (denoted by for agent ). The local view of different agents usually differs since it describes which parts of the system behavior the agents can actually see (an ECU for example may see its own internal actions, but not those of other ECUs). A system model finally includes the so-called agents’ “initial knowledge” which is defined to be prefix closed and to contain . This concept is used in order to specify system constraints and assumptions.
Security properties are defined in terms of the system specification. The underlying formal semantics then allows formal validation, i.e. allows proving that a specific formal model satisfies specific security properties.
The following notations are used: For and , denotes the set of all continuations of in . For and , denotes the number of occurrences of any action of in , denotes its alphabet (i.e. the set of its actions), is its set of prefixes, denotes its first and its last action. For and , denotes the last action before in performed by agent (in case is ’s first action, ). For , the function enumerates strictly monotonically increasing the actions of in their order of occurrence: for all , for , and for we define .
We extend SeMF by a formal specification of actions and a homomorphism to extract any parameter of an action:
Definition 1 (Set of actions). Leta set of parametersand forletthe set of possible values ofwitha set of action names anda set of agents. Then the setof actions of a systemcan be defined as follows:The sending of a message on a CAN bus can for example be formalized by . See Sections 5.1 and 6.1 for the concrete sets of actions of the two models introduced in this paper. In order to express relations between parameters of different actions, we need to extract them from the actions:
Definition 2 (Parameter extraction). Letbe defined as in Definition 1. We define a homomorphismbyThe security property provided by a MAC mechanism can be formally specified by the concept of authenticity introduced in [34] : A set of actions is authentic for agent P after a sequence of actions has happened if in all sequences that P considers possible after , some time in the past an action in must have happened. Formally:
Definition 3 (Authenticity). A set of actionsis authentic forafter a sequence of actionswith respect toiffor all.
The following weaker property describes that in all sequences of a language that contain a specific action , this action is preceded by one of the actions contained in :
Definition 4 (Precedence). Forthe propertyholds if for allwithfollows. We simply writeif from the context the language referred to is clear.
Additionally to authenticity, we require the counter systems to provide immediacy and non-repeatability. In order to define a respective security property within SeMF we introduce the concept of a phase class that allows modeling that a particular action occurred within a particular period of the system. We base our definition on the concept of a introduced in [35]. Here a subset of is a phase for if it is a prefix closed language consisting only of words which, as long as they are not maximal, show the same continuation behavior within the phase as within . Our definition transforms this to arbitrary subsets of , not requiring them to be prefix closed:
Definition 5 (Phase class). Let. A languageis a phase class forif the following holds:1.2.withandholds:Thus, a phase class is characterized by being closed with respect to concatenation. Maximal words in a phase class, denoted by , are those for which holds for all (i.e. no matter whether or not exists ).
A phase class can be a very complex construct. However, in many cases phase classes are of interest that can be defined by the actions that start and terminate, respectively, the words. The following definition takes into account that an action can occur more than once in a word. Each starting action occurring in a word starts a word of . The word ends with the first occurrences of an action in :
Definition 6 ((S,T)-phase class). Let,, withfor all. Then ,is a phase class forstarting withand terminating with respect toif1is a phase class for,23for allmaximal inthe following holds: Forwithit followsor there existssuch that, , andfor all.
We call such a phase class an -phase class for . If all words in the phase class terminate with the first occurrence of any , we simply call it an -phase-class for , denoted by .
It can easily be shown that an -phase class for a prefix closed language is itself prefix closed. -phase classes are a very useful concept for the concrete specification of freshness properties. We can further combine these two concepts with authenticity:
Definition 7 (Authenticity within a phase class). Letbe the behavior of a system,, anda phase class for agent’s initial knowledge. A set of actionsis authentic forafterwithinand with respect toandif (i) it is authentic forafterand if (ii) for allfor which existsandsuch thatandit follows. If the property holds for all, we denote this property shortly by.
5. Formalization and Verification of the Generic Counter Approach
In this section, we introduce our SeMF model of the generic counter system described in Section 2.5 (denoted by GenCnt henceforth) and formally prove to which extend it satisfies the protection goals data origin authenticity, immediacy and non-repeatability of messages.
5.1. The Formal Generic Counter Model
Our SeMF model shall be as simple as possible. It needs to include ECUs connected to a bus whose messages shall be proven to be protected. It also needs to reflect our attack model introduced in Section 2.2, hence must include devices (e.g. ECUs) that an attacker can use to monitor, record, resent and manipulate messages sent on the bus. It is obvious that messages sent on one bus may be accepted by ECUs connected to another bus if the key used for protecting these messages is the same for both buses. Hence we disregard this aspect and restrict our model to one group of honest devices, all owning the same MAC key for message protection, and a further device representing dishonest behavior. All devices are connected to the same bus. Our model can easily be extended, for example by adding more groups, keys and buses, in case other aspects than those addressed in this paper shall be investigated. A special honest device is the Fresh Value Master () that is responsible for the synchronization of ECUs regarding their counter. We assume all honest devices to act according to a given specification (see Section 5.1.3). only sends synchronization messages, i.e. messages with . Other honest devices receive synchronization messages and send and receive functional messages with . We do not distinguish between different types of functional messages and use just one with its corresponding message counter. can send and receive all types of messages but does not own the MAC key and can thus not generate MACs.
We use four different types of actions: sending and receiving (i.e. accepting) of messages, reading a message without processing it, and an action that models an ECU losing the correct message counter (denoted by genCnt henceforth). This action comprises any situation in which an ECU is not synchronized anymore, i.e. owns a counter smaller than the current correct counter value.
While in many systems (e.g. in [4]) messages only contain a truncated message counter and MAC, respectively, in our model the counter’s complete value is included. This way we model the assumption that the recipients always succeed in determining the counter values used by the senders (after all, this aspect is not in the focus of our investigations).
5.1.1. Agents, Parameters and Actions
For the formal specification of actions according to Definition 1, we use the following sets:(1)Set of agents: with whose members are connected to the only bus of the system. denotes the synchronization master and denotes a further device being connected to the bus but not being member of .(2)set of action names: (3)set of parameters: with , being the key all honest ECUs use for MAC generation and verification, while for . Further, , and ( being an arbitrary set of messages).(4)The set of actions is then defined as follows:(1) sends a message on . The message’s MAC (not explicitly modelled by a parameter of this action) is generated with and covers and . if none of the entire message bits as illustrated in Figure 1 has been written to the bus by . may or may not have generated the MAC. For , the parameter denotes ’s MAC generation and verification key , denotes its local counter value after having performed the action, and denotes the counter value resulting from ’s previous action (see Section 5.1.3 for the specific operations regarding an ECU’s counter). The message can be a functional message, indicated by , in which case the counter contained in the message’s payload is explicitly modelled by , or a synchronization message with . In this case the message’s payload only contains the counter determined by the sender and the parameter contains the constant . Note that there is the possibility that the message is altered (by a technical error or by ) after having been sent and may thus only cause a action (see below).(2) denotes reading a message without processing it (i.e. without accepting it). The action does not change the local message counter if (see Prop.A10 below).(3) denotes the successful reception and processing of a message by .(4)With the action we model the fact that has lost the correct counter value for some reason. This action comprises any situation in which an ECU is not synchronized anymore. As a consequence, its counter is set to a value smaller than the correct counter value.
The idea of a generic counter-based system is that counter values should be strictly monotonically increasing. However, in real systems message transmission may fail due to transmission errors of the bus (e.g. by flipping a bit). Such a message is not accepted in which case the sender simply repeats it, using the same counter as before. We abstract from this since incidents of this type are not security relevant and assume all messages sent by an honest ECU not to suffer from physical failures of the system. This leads to the following definition of the correct counter for a specific action.
Definition 8. Letand. Then the correct counter for actioninis defined as follows:This definition assumes that the very first message of any action sequence of the system is sent by an honest ECU.
5.1.2. Introducing a Phase Class into the Model
In the GenCnt system, only messages with correct counters shall be received and accepted, i.e. their values shall be strictly monotonically increasing. Each counter therefore identifies a phase of the system that starts with sending the message containing it. Hence we use send actions to identify phase classes: Each send actions starts a new phase class, and the phase class ends with the next send action that in turn starts a new phase class. The formal definition of this particular -phase class is based on Definition 6:
Definition 9. Forandwithwe defineFrom a recipient’s point of view, when having performed a receive action containing a specific counter, the phase class “activating” this counter starts with the send action that writes this particular message onto the bus. Considering the characteristics of a CAN bus as described in Section 2.1, there cannot be any other send action between these two actions on the bus. Recall that a message manipulated by is considered to have been sent by her. Consequently we do not have two consecutive actions. Hence for each receive action occuring in a sequence of actions, the corresponding send action, denoted by , is unique. Consequently, each determines a unique phase class with . Thus for a specific receive action we can rename the phase class it determines and denote it by . For the sake of completeness, for a send action we define .
For the rest of the paper we will use the particular phase class determined by a action with denoting all ECUs’ initial knowledge that we assume to be identical. In Section 5.2 we will explain how this phase class can be used to model immediacy and non-repeatability.
5.1.3. Agents’ Local View and Initial Knowledge
The definition of the ECUs’ local view must take into account that they can see the messages sent on the bus they are connected to but cannot see who sent them nor the local parameters of the sender. Further, except for these send actions, ECUs can only see their own actions. Hence for all and for all we define as follows:
(1)(2)(3)
Agents’ Initial Knowledge The agents’ initial knowledge captures the constraints and assumptions that we know to hold for our system. If not specified otherwise, the properties refer to .
Prop. A1. A receive action on is always preceded by the corresponding send action that writes the message onto the bus. Obviously, the parameter values of , , and in and are identical (we forgo the formal specification of this statement). The only actions that can happen in between are and actions by ECUs other than sender and receiver. Formally:
For all with holds
(1)(2)
Prop. A2. Only members of own and can use . Since does not own this key and honest ECUs use only to generate and verify a MAC, the MAC key contained in a send or receive action being equal to the ECU’s key and this being equal to is equivalent to the ECU being member of .
.
Prop. A3. A action performed by an honest ECU (i.e. a member of ) must be preceded by the respective send action of an agent having generated the MAC, i.e. owning the key used for MAC generation:
Again, obviously, the parameter values of and in and the send action are identical.
Prop. A4. The parameter of an action performed by an honest ECU denotes the local message counter the ECU has used in its previous action. For the very first action of an ECU it is defined as the minimal value (which we assume without loss of generality to be equal to 1) of .
. If for all with holds , it follows .
Prop. A5. is the only ECU that sends synchronization messages. It does not perform any other action.
.
Prop. A6. It is obvious that synchronization messages including a wrong (i.e. too small) counter value open possibilities for all kinds of attacks. Hence we assume that a synchronization message sent by always contains the correct counter value according to Definition 8.
.
Prop. A7. When an honest agent different to receives (i.e. accepts) a synchronization message, it verifies that the message’s payload (which contains the counter) is greater than the local counter used in its previous action and then sets its local counter to the value of the message counter:
.
Prop. A8. An honest agent other than only sends functional messages. When doing so, it increments the counter used in its previous action by 1, uses this value as its new local counter value and as the value of for MAC generation.
.
Prop. A9. When an honest agent different to receives (i.e. accepts) a functional message, it verifies that the message’s counter is greater than the local counter used in its previous action and then sets its local counter to the value of the message counter:
.
Prop. A10. An important property of the generic counter system is that an ECU increases its counter value only in case it has received and accepted a message with a bigger counter value. Hence an action by an honest ECU does not change ’s local counter value:
Prop. A11. An action performed by an honest ECU resets the ECU’s counter value to a value smaller than the correct one:
Prop. A12. When an honest ECU performs two actions with its local genCnt value of the first one being bigger than or equal to the local genCnt value of the second one, it must have performed a action in between.
For , if and and then there exists with and .
This concludes our system model specification. In the next section, we will show that the model allows certain states which violate a property that can be used for the specification of authenticity, immediacy and non-repeatability.
5.2. Formal Verification of the Generic Counter Concept
As stated in Section 2.5, the security requirements the generic counter system (denoted by ) shall satisfy are data origin authenticity, immediacy and non-repeatability. More precisely, an honest ECU shall accept only messages authentically generated and sent by another honest ECU, thus providing data origin authenticity. Further, the message must contain the correct counter which ensures that no counter is accepted twice (since the correct counter is strictly monotonically increasing), thus providing non-repeatability. In order to express this, we use the phase class as defined in Definition 9 with being a action. Each time an honest receives a message, the message must authentically for have been sent by a member of the same group, and this send action must be the one to trigger ’s action , i.e. must be the start action of the phase class determined by . Since the time period between sending and receiving messages on a CAN bus is very short, we can assume that it never exceeds the specified limit which implies immediacy. This can be formalized as follows:
Theorem 1. Letandwith. Then the following property holds:
Proof 1. Assume one of the honest ECUs different to that is member of the group receives (i.e. accepts) a message. Without loss of generality assume it is and for some . By definition, keeps this action, thus is also contained in each . Further, is contained in . So let arbitrarily chosen. Since , Prop.A2 implies that . Further, by Prop.A3, there is an action before ’s receive action containing the same message, message ID and counter value and with . Applying again Prop.A2 it follows . Hence the message received in has authentically for been sent by a member of , i.e. data origin authenticity is satisfied.
Therefore and (Prop.A5) or and (Prop.A8) (we disregard the fact that in principle could itself be the originator of this message and assume this issue to be addressed by e.g. unique message IDs). By Prop.A1 is preceded by that starts the phase class identified by . By definition, the local view of does not reveal the sender, hence assume and , i.e. assume that the authentic action is not performed in the required phase class. Assume further that after having performed their respective last actions before (denoted by and , respectively), and are synchronized, i.e. own the same counter which is the correct one for these actions. Let us assume performs , performs and .
Assume and . Then Prop.A8 implies . Since is the last action of before , Prop.A4 implies that . Prop.A3 implies and it follows . This situation, depicted in Table 2 , is the basis for the subsequent case-by-case analysis (note that it is irrelevant whether precedes or vice versa).
5.2.1. Losing the counter
Assume that receives the message sent by in by performing an action (i.e. ). Then (Prop.A1) and Prop.A9 implies . Prop.A9 also requires . This is the case, as by Prop.A4 we can conclude and thus which by the assumption of and being synchronized before is equal to , hence is satisfied. Since with action , receives and accepts , Prop.A12 implies that performs an action between and , and Prop.A11 implies that is smaller than the correct counter value for this action which in turn is equal to or bigger than . Assume that between and there have been send actions by members of other than with correct counters, increasing its value to without changing ’s counter value (e.g. because it does not perform any action other than between and ). It follows . On the other hand, in receives and accepts the message sent in with the counter . So assuming ’s action to be its last action before , Prop.A4 and Prop.A9 imply . Both inequalities are satisfied for . Thus may very well receive and accept the message sent in by .
The resulting sequence of actions is depicted in Table 3. While it satisfies data origin authenticity, it violates immediacy, assuming that only the time period between writing a message onto the bus and reading it does not exceed the specified limit. It also violates non-repeatability as the message sent in is accepted twice.
It is not surprising that counter loss without timely synchronization opens up attack possibilities. The same result can be shown in case sends a synchronization message in . We then need to consider the fact that between and , may have sent messages that increase the correct counter of accordingly. Further, instead of applying Prop.A8 we need to take into account that the counter is sent as the message’s payload, i.e. modeled by the parameter , and apply Prop.A5.
We will now investigate whether sending of synchronization messages prohibits the above described attack. Assume therefore that with the action sets its local genCnt value to and that between the action and , receives one or more synchronization messages with being the last one before . Since is the counter accepted by in and since the counter sent in a synchronization message is contained in its payload, . Assume further these are the only messages sent on the bus. Then again by Prop.A4 and Prop.A7, which implies . According to Prop.A1, is preceded by an action in which the synchronization message received by is written to the bus. The property further implies that between and , does not perform any further action, hence happens after ’s action and in particular after . Recall now that we have assumed to be the correct counter value of both and and that . If was , Prop.A6 would imply . Yet what accepts in is . Thus and since by Prop.A8 an honest agent other than only sends functional messages, it follows .
While by Prop.A3, is preceded by an action , this does not necessarily interfere with the attack we are constructing here, assuming that does not receive (i.e. accept) this message but only performs a action which does not change its local counter. This attack is illustrated in Table 4.
This attack uses an important characteristic of the generic counter system , captured in Prop.A10: It causes to keep the too small and thus incorrect counter since it does not correctly receive and accept the synchronization messages sent by between and . The attack again violates immediacy and non-repeatability.
5.2.2. Not losing the counter
Let us now consider the case in which only performs actions between and and in particular does not perform an action , i.e. does not receive and accept the message sent by in . As above, by Prop.A1 and Prop.A3 we know . Since by Prop.A10 a action does not change ’s counter, consecutive application of Prop.A4 to the sequence of these actions implies and by Prop.A9 it follows . This equation is always satisfied which means that there is no contradiction to . Therefore this sequence (illustrated in Table 5) is another example for violation of immediacy based on invalidation and replay of messages. Note that it does not violate non-repeatability as the message is only received and accepted once.
The only case in which the desired properties hold is if by performing , receives and accepts the message sent in and does not lose the correct counter value, i.e. does not perform a action between and . In this case sets its local counter to (Prop.A9) and without losing the correct counter will not accept the same counter in action anymore, as and thus as is required by Prop.A9.
Our proof indicating possible attacks is based on the fact that certain messages are not received but only read by . This can easily be accomplished by an attacker with the abilities described in Section 2.2. All she has to do is to monitor the respective message and then invalidate it and all following ones related to the relevant counter by changing a CRC bit or overwriting the message with an error frame. This will cause all ECUs connected to the bus to reject the messages. Since actions do not change the ECUs’ local counter, any message containing a bigger counter will still be considered correct.
In Section 7.1 we will discuss the results achieved by the proof and compare them to the formal proofs of the bus counter-based system to be introduced in the next section.
6. Formalization and Verification of BusCount
In this section, we introduce the formal model and verification of our hardware-based counter approach.
6.1. The Formal Bus Counter Model
We model the bus counter-based system (denoted by henceforth) as similar as possible to the generic counter model. One important difference is that it does not need a central freshness value master since all ECUs send synchronization messages simultaneously. Hence the set of agents is defined as with .
As in , the system has only one bus all agents are being connected to. Further, members of are honest and own the key , while , not being member of this group, does not own this key. We use the same set of action parameters, but a different specification of agents’ behavior (after all, we model a different system). The set of actions is defined as follows:(i) denotes a send action as described in Section 5.1.1, except that the counter value is covered by the MAC but not transmitted. As in the model, the message may be altered (by a technical error or by ) after having been sent and may thus only cause a action (see below).(ii) denotes agent reading a message without processing it afterwards. In contrast to the respective action of the GenCnt model, the action of the model changes the state of an being member of by decrementing its local bCnt value (stored with the last action and thus modeled by the parameter ) (see Prop.B13 in Section 6.1.1 below). This captures the fact that reacts to the “start of message” bit on but discards the respective message (e.g. because the CRC verification fails) in which case it does not perform the receive action. Note that the sender of a message always reads its own action bey performing a action.(iii) denotes the successful reception and processing of a message by .(iv)As in the system, with we model the fact that has lost the correct counter value for some reason and thus is no longer synchronized. Since in the system counter values decrease, its counter is set to a value bigger than the correct counter value (see Section 6.1.1 for more details).
6.1.1. Agents’ Local View and Initial Knowledge
Again, the agents’ local view is defined analogously to the generic counter model: All agents see their own actions completely and see the messages sent on the CAN bus they are connected to but cannot see who sent them nor the values of parameters stored locally by the sender. Further, agents cannot see actions and performed by other agents.
As already pointed out in Section 5.1.3, with specifying the agents’ initial knowledge we capture the characteristics of our system. In the following, we list all properties we assume to be satisfied by the agents’ initial knowledge with reference to the respective property in Section 5.1.3 (if any) in which case we omit the formalization. Analogously to Section 5.1.3, if not specified otherwise, the properties refer to . We denote the correct counter for a specific action in by . In Lemma 2 (see Section 6.2) we will show how its value is determined.
Prop. B1 (analogous to first statement of Prop.A1). A and action, respectively, on is always preceded by the corresponding send action that writes the message onto the bus. Obviously, the parameter values of and in and are identical (we forgo the formalization of the latter statement).
For all with holds .
Prop. B2 (Prop.A2). Only members of own and can use . Since does not own this key and honest ECUs use only to generate and verify a MAC, the MAC key contained in a send or receive action being equal to is equivalent to the ECU being member of .
Prop. B3 (Prop.A3). A action performed by an honest ECU (i.e. a member of ) must be preceded by the respective send action of an agent having generated the MAC, i.e. owning the key used for MAC generation. Again, obviously, the parameter values of and in and are identical.
Prop. B4 (Prop.A4). The parameter of an action performed by an honest ECU denotes the local bCnt value as result of the ECU’s previous action. For the very first action of an ECU it is defined as the maximal value of , denoted by . Formally:
. If for all with holds , it follows .
Prop. B5. In Section 7.2.2 we will discuss which starting value of to choose in order to avoid counter overflow. Further, as explained in Section 2.2, we assume that memory failures and attacks cannot cause counter overflow. Hence we can assume that such a failure never results into a local counter value stored by an ECU being smaller than the correct one (see Prop.B17 below). For our formal model we assume that the local counter value of ECUs is always sufficiently large such that counter decrementation can result into the value 0 only in the last phase class of an action sequence. Formally:
Prop. B6 (analog to Prop.A8). When an honest ECU sends a synchronization message, it includes as its message payload the local bCnt value of its previous action decremented by 1 but does not change the local bCnt value.
.
Prop. B7. We assume that there always exists an ECU owning the correct counter value. Since our synchronization concept utilizes the mechanism used for collision resolving (a 0 written to the CAN bus always overwrites a 1), the correct counter always overwrites any incorrect one. Therefore a action containing a synchronization message that is actually performed by an honest ECU always contains the correct counter. Formally:
.
Prop. B8. When monitoring a synchronization message being written to the bus, an honest ECU decrements its previously used counter value by 1 and verifies that the result is less or equal to the counter sent as the message’s payload. The error frame parameter being equal to indicates that this check has been successful (and that the MAC check that we do not formalize explicitly has been successful as well). It then uses this value as its new local counter.
.
While is actually a action, our proofs do not depend on distinguishing between and actions of synchronization messages.
Prop. B9 (analog to Prop.A8). When an honest ECU sends a functional message, it includes as its counter value the local bCnt value of its previous action decremented by 1 but does not change the local bCnt value. (It changes the value of with the action of reading its own message that the ECU performs simultaneously to sending, see Prop.B10 and Prop.B13.)
.
Prop. B10 (analog to Prop.A9). When an honest ECU receives and accepts a functional message, it decrements its previously used counter value by 1 and verifies that the message’s value is equal to the result. It then sets its local bCnt value to the message’s counter.
.
Prop. B11. All honest ECUs, when reading a message, check the message’s MAC, independently of whether or not they accept it. In case of a functional message, this involves the ECU’s local counter, more concretely the counter value used by the ECU in its previous action decremented by 1. If such a check succeeds which is a necessary condition for the error frame being set to , this value is the one that was used to generate the message’s MAC. Note that this assumes that an attacker that owns the correct counter and a MAC cannot guess the corresponding message.
Let with and . Then the following holds:
.
Note that in our very simple model with only one type of functional message, a successful check indicated by actually results into a action. However, considering also actions with allows to extend the model with respect to more types of functional messages without having to change the assumptions.
Prop. B12. As explained in Section 3, if an ECU’s checks concerning for example a message’s MAC fails and it therefore writes an error-frame, all other ECUs join in and write an error-frame as well, no matter whether or not their checks failed. Hence all and actions induced by a specific action have the same value for the parameter . Since a message is only received and accepted if all checks have been successful, the error frame of a action is always set to . Formally:
Let with and . Let further denote the and actions in . Then for all the following holds:
.
Prop. B13 (in contrast to Prop.A10). When an honest ECU reads a message, it always decrements its previously used bCnt value by 1 and uses the result as its new local bCnt value. This behavior is independent of whether or not its checks fail, i.e. independent of the value. Formally:
.
Prop. B14. In a phase class with (i.e. a phase class that starts with a specific action and ends with the next action, see Definition 9), all honest ECUs including the sender either read or receive the message or perform a action. They do not perform any other action.
Let with and maximal in . Then for all exists exactly one such that and .
Prop. B15 (analog to Prop.A6). In every phase class with there is an honest ECU owning the correct counter and performing a or action in this phase class, but no action. Here, owning the correct counter means that the ECU has used and stored the correct counter value in its previous action and can thus use it in the next action.
Let with . Then for all maximal in exists an action with and .
Prop. B16 (analog to Prop.A12). If an ECU is not synchronized at a specific action, i.e. does not use the correct counter relevant for this action, it must have performed an action before. Note that using a counter value refers to the parameter .
Prop. B17 (analog to Prop.A11). As explained in Prop.B5, memory failures never result into decrease of the counter value stored by an ECU. This implies that an action performed by an honest ECU resets the ECU’s counter to a value bigger than the correct one. For formal reasons we assign a counter value higher than the maximal value the system starts with to a action if it is the first action of an action sequence.
(1).(2)Analogously to Section 5.1.2 we model immediacy and non-repeatability by the phase class as defined in Definition 9 determined by a fixed but arbitrary action . In the following section we will show that BusCnt satisfies both properties.
6.2. Formal Proof of bCnt System
The idea of the system is that counter values included in the MACs of sent messages are strictly monotonically decreasing (instead of strictly monotonically increasing as in the system). However, in contrast to the GenCnt system, in each send action inevitably induces a or action and thus a decrement of the counter, no matter whether or not a check failed. In case a system does not suffer any anomalies (i.e. all actors act correctly and counter value change is never caused by physical irregularities), the counter used by the ECUs is always the correct one. Lemma 2 will show how it is determined. For its proof we need the following technical Lemma:
Lemma 1. Let. Let furtherwithfor all. Then for allwiththe following holds:1.2.
Proof 2. If , the assertions follow directly by Prop.B10 and Prop.B12 together with Prop.B8, respectively. Let now . We show the assertions of this case by induction over the number of consecutive phase classes . Induction basis:. Consider and . Let and assume . Then Prop.B13 and Prop.B4 imply . Further, by Prop.B1, . Now by Prop.B9, . Together this leads to .Assume now . Since Prop.B1 requires a send action before any or action and since is the first send action in , there is no other action in before . Prop.B14 implies that is the first and thus Prop.B13 implies . being the first action in , it is the first action of as well and Prop.B4 implies . By Prop.B9 it follows . Further, by Prop.B1, . Together we can conclude .
In case , we can argue analogously by replacing every occurrence of by and applying Prop.B6 instead of Prop.B9.
Induction hypothesis: For and , let assertions 1 and 2 hold.
Induction step: Consider with and . First we again assume . being a action, Prop.B13 implies which by Prop.B4 and Prop.B14 is equal to . Further, by Prop.B9, and . Since Prop.B1 implies , it follows .
Assume now . As above, Prop.B13 implies . Since by Prop.B14 all ECUs perform a or action in the previous phase class ( actions are excluded by definition), this holds in particular for and . Hence for all maximal in there exist or actions performed by and performed by , being the previous actions of and , respectively. Prop.B4 implies which by induction hypothesis is equal to . This in turn is equal to by Prop.B1. Again by induction hypothesis, the latter expression is equal to . Prop.B4 implies equality to which by Prop.B9 is equal to . Prop.B1 finally implies equality to , hence .
Again, in case , the analogous proof is achieved by replacing every occurrence of by and applying Prop.B6 instead of Prop.B9.
Lemma 2. Letandas defined in Lemma 1. Let furtherand. Then the following holds:1.2.Further, for all(i.e. withandholds(i)(ii)(iii)(iv)
Note that item 1 implies that the parameter of actions concerning a functional message never reaches the value 0 unless there occur no more actions after the action . The analogous statement holds for the parameter of actions concerning synchronization messages.
Proof 3. We prove assertions 1 and 2 by induction over the length of a word . Induction basis:, i.e. . Since Prop.B1 requires a action before any or action, cannot be a or action. Since further by definition does not contain any action, . Prop.B4 implies . If , by Prop.B9 it follows . Further, by Prop.B5 which implies . Thus item 1 holds for containing a functional message. If on the other hand , by Prop.B6 it follows which as above implies the assertion, thus item 2 holds for . Induction hypothesis: Let . Then for all holds:(1)(2) Induction step: Consider . (1) Assume . By Prop.B14 and the fact that does not contain any actions, it follows that is a or action. This in turn is preceded by a action (see Prop.B1). So we have ( may or may not be equal to ). Let a maximal word in , i.e. starts with and ends with , and all other actions in between are and actions, the last one being . By Prop.B1, for all these and actions holds . Since all ECUs perform exactly one or action in , there is exactly one or action performed by , being the last action performed by before .(a)Assume . If as well, Lemma 1 implies . Since contains a functional message, Prop.B9 implies . By Prop.B1 this is equal to . Prop.B1 also implies , hence by induction hypothesis it follows . Finally, since is the action directly following , . Further, since and by Prop.B5 , it follows . If on the other hand , Lemma 1 implies . Using Prop.B9, we can then deduce which by Prop.B1 is equal to . As above, the assertion follows.(b)Assume . In this case we can use Prop.B6 to deduce . If , the rest of the proof is identical to the case where this is combined with a functional message of , if , the arguments regarding being a synchronization message apply. This ends the proof for the case .(2)Assume . Then Prop.B1 implies that there is an action which is either equal to or occurs before . (a) Let . By Prop.B1 it follows and . Since is the last send action before the action , the number of send actions before these two actions including is identical, i.e. . If , the induction hypothesis implies . If , the induction hypothesis implies . (b) Let with . Then Prop.B14 and the fact that does not contain any actions implies that is a or action. Again, by Prop.B1 it follows and the equivalent equations for the parameters and . Now we can again conclude that the number of send actions before is identical to those before and as above, by induction hypothesis for the cases and , respectively, it follows the assertion. This concludes the proof of assertions 1 and 2.We now prove assertions (i)–(iv) of the Lemma. So assume the first statement holds regarding functional messages. Then it holds in particular for two consecutive actions and in a word , each sending a functional message. Then . The only difference between a action containing a synchronization message and one containing a functional message is that the value minus the cardinality of actions happening before and including is assigned to the counter of in the first case and to the message of in the second case. Hence, the respective statements for all other combinations of synchronization and functional actions can be shown analogously.
The above Lemma uses properties that describe the behavior of honest agents when sending, receiving or reading a message and shows the resulting counter value. This behavior does not depend on whether or not any involved send action is performed by an honest ECU. Hence the counter value included in actions of sequences in can be considered the correct one for actions in .
Definition 10. Forandwe defineWe now consider again and first show a Lemma whose important statement is that a synchronization message received by an ECU never contains a counter smaller than the correct one for this action. In general the Lemma states that an honest ECU owning the correct counter before processing a or action (denoted by the parameter of the action), also owns the correct counter afterwards (denoted by the parameter ).
Lemma 3. Letand. Then the following holds:
Proof 4. Assume . Then by Prop.B13 . The same follows by Prop.B10 for being a action of a functional message. So let and . Prop.B12 implies and thus by Prop.B8 it follows . In case of the assertion holds. So let , i.e. . Prop.B16 implies that before , performs a action and by Prop.B17, if , it follows . For simplicity we assume that is the last action of in before . By Prop.B14, every ECU performs only one action per phase class, hence happens in the phase class that ends with , i.e. in the phase class directly occuring before the one including . Lemma 2 implies that . So we have . This constitutes a contradiction, hence holds. In case is not the previous action of , we can argue analogously.
Let . Since is the first action and not a action, Lemma 2 implies . As above, we have which by Prop.B17 is equal to . This implies . However, since happens before the action (and after the action ), by Lemma 2. So again this constitutes a contradiction, hence always holds.
We can now prove our main Theorem. As in Section 5.2, the property we want to prove is that whenever an honest ECU receives and accepts a message (action ), the action having triggered and starting the phase class determined by must have authentically for the ECU been performed by an agent being member of the same group, and the message must contain the correct counter. In contrast to the proof regarding the GenCnt system, for the BusCnt system (formally denoted by ) we can show that this property is always satisfied, i.e. that both immediacy and non-repeatability hold.
Theorem 2. Letandwith. Then the following property holds:
Proof 5. Analogously to Section 5.2, without loss of generality we assume to perform a receive action and consider an arbitrary (which by definition of and contains ). Since , by Prop.B2 it follows . Further, by Prop.B3 there is an action before the receive action by containing the same message ID, message and counter value and with . Again by Prop.B2 it follows which proves that the message received in has authentically for been generated and sent by a member of .
Further, by Prop.B1 the receive action by is preceded by a send action triggering .
Let maximal in with . Since , Prop.B12 implies and thus for all with . By Prop.B15 one of the actions in is performed by an ECU owning the correct counter, i.e. there exists with and . Lemma 3 implies . Recall that Prop.B1 and Prop.B3 imply that the values of the parameters and in and are identical.(1)Assume and assume further that when sending the message, is synchronized, i.e. includes the correct counter as the message’s counter value. By Prop.B9 it follows . Since all and actions in have , Prop.B11 implies , hence . It follows . Now if , the number of actions until is smaller than the number of actions until . Since by Lemma 2 the correct counter minus any number of actions is always bigger or equal to 0, it follows that the correct counter for is different to the one for . More specifically, it is smaller, i.e. . Further, again by Lemma 2, the number of send actions having occurred until is equal to those having occurred until a or action induced by , i.e. . This implies . This constitutes a contradiction to our assumption that is synchronized in and sends . Thus .(2)Assume and is synchronized which by Prop.B7 implies that it sends the correct counter as the message’s payload, i.e. . Further, being a or action with , Prop.B8 implies . Hence it follows and thus . Assume . As above, Lemma 2 implies and . Since by Prop.B1 , it follows . This again constitutes a contradiction, thus it follows .(3)Assume is not synchronized in . By Prop.B16 it has performed an action before , denoted by . If , by Prop.B17, is set to a value bigger than the action’s correct counter value: . If , Prop.B17 implies as well. Assume for simplicity that ’s next action after is . Then . Let . Then by Prop.B9, . Now is the first action after since a action in between would imply another action by (Prop.B14). Lemma 2 implies . Hence not being synchronized results into . If is not ’s last action before we can argue analogously only with a longer sequence of actions and counters in between and to consider, being decreased step by step. By Prop.B1 always holds. Hence . By Lemma 2 and the definition of , , and since owns the correct counter in , by Prop.B15 it follows and Lemma 3 implies . Together these statements imply . Further, Lemma 2 implies , no matter whether or not and are identical. Hence and therefore . Prop.B11 implies , and by Prop.B12 it follows and therefore , a contradiction to the assumption we started the proof with. Hence in the case of . If , we can decude and thus the same contradiction by exchanging the parameter by and applying Prop.B6 instead of Prop.B9 to deduce . Further, Lemma 2 implies and it follows . With the same arguments as above, this implies . Prop.B8 implies and again by by Prop.B12 it follows and therefore . So again the assumption of not being synchronized leads to a contradiction. This concludes our proof.The above, proof shows that our approach indeed satisfies data origin authenticity as well as immediacy and non-repeatability. In contrast, the generic counter system violates the latter ones. In the next section, we will discuss the security related differences in more detail. We will then introduce our proof of concept implementation showing its practicability and design decisions that substantiate our formal proof.
7. Evaluation
In this section, we will evaluate both the security and the practicability of our bus counter approach. More specifically, in the next section we will discuss the formal proof results concerning the satisfaction of the security requirements immediacy and non-repeatability by the generic and the BusCnt system, respectively, and highlight the differences. In Section 7.2 we will then demonstrate the feasibility of our BusCnt approach based on a practical implementation and discuss design decisions.
7.1. Security Aspects
One fundamental difference between our approach and the generic counter-based approach is that in the BusCnt system the pulse generator is an integral component of the system itself: The very writing onto the bus causes a change of the local bus counter values of all ECUs connected to it as they inevitably read (part of) the message (even if not accepting it) and decrement their counters. By this read action, the message’s counter and thus its MAC is invalidated. Hence, any subsequent message written onto the bus must use a smaller counter in order to be accepted. This prohibits message delay and replication.
Another important aspect is the assignment of computations to the controller that in traditional CAN communication systems is processed by the application layer. This concerns in particular MAC calculation and verification and checks regarding the size of the message’s counter. Performing these checks on controller level enables to use the error frame mechanism of CAN in case of a failed check which in return results in invalidation of the respective message and prevention of its acceptance by any of the ECUs connected to the same bus.
These two aspects together allowed to formally prove that the BusCnt system satisfies both immediacy and non-repeatability, provided at least one of the ECUs owns the correct counter. The inevitable decrease of the counter value with every new message prohibits message delay, and the checks performed by the controllers allow immediate invalidation of any manipulated message.
One of the core assumptions of our proof is the correctness of at least one counter value in the bus network. It is based on two observations: First, ECUs are designed to be safe and thus hardware or software failures occur significantly less often compared to regular PC hardware. Second, an incorrect counter value may be the result of the shutdown process, as an ECU may not be able to store the counter value in time to persistent storage. However, the likelihood for this failure to occur is reduced in our approach since only a single value per bus needs to be stored. In contrast, traditional counter-based approaches use various counters for different types of messages. Moreover, a bus has a large number of ECUs connected to it and only one needs to store the correct counter value at the end of a ride. Therefore, the probability that our assumption does not hold is insignificant.
On the other hand, an ECU not being synchronized, i.e. not owning the correct counter, may in principle cause a safety problem: If it sends a functional message, MAC verification by ECUs owning the correct counter will fail and result into an error frame. If the ECU itself receives a functional message containing the correct counter, its own MAC verification will fail and cause an error frame as well. Too many error frame events will cause the ECU to change into an inactive state. This safety problem can be minimized by adequate synchronization approaches as discussed in Section 7.2.2 below.
In contrast to the BusCnt system, our proof of the generic counter-based approach indicates that it exhibits several weaknesses. First, it cannot ensure immediacy and non-repeatability (neither of synchronization nor of functional messages) in case an ECU loses its counter. Once being active again the ECU will accept any replayed message whose counter is still in the required range (i.e. bigger than its own counter). This violates immediacy, assuming that only the period between writing a message onto the bus and reading it does not exceed a specified limit. It also violates non-repeatability since the attack is possible even if the replayed message has already been accepted before.
The counter synchronization mechanism of GenCnt does not prohibit this attack as synchronization messages themselves are susceptible to delay attacks, i.e. recorded and then invalidated by an attacker by destroying their CRC or by interrupting the message with an error frame. These messages will then not be accepted by the ECUs with the consequence that an unsynchronized ECU cannot be synchronized. It will therefore accept delayed synchronization and functional messages at any later point in time the attacker chooses for a replay, thus violating immediacy. Hence, the synchronization mechanism of the generic counter-based system is no guarantee for ensuring immediacy and non-repeatability.
Even if no counter loss occurs, violation of immediacy by a delay of messages cannot be prohibited. This is due to the fact that the counter value stored by the intended recipients of a message does not change as long as all messages relevant for the respective counter are invalidated by the attacker and thus not accepted. Consequently, the intended recipients will accept any relayed message since it still contains a counter being valid from their point of view.
One question that comes to mind is whether it would be sufficient to equip the Fresh Value Manager FvM of the GenCnt system with the ability to perform all security checks by the controller in order to avoid the above-described attacks. However, it turns out that this measure alone is not enough. First, the FvM behavior would need to be changed as it must increment its own local counter value with every sent message, independently of whether or not the message is accepted. In other words, the determination of what is the correct counter for a message would need to be adapted to the one used for the BusCnt system. Otherwise, the FvM would not be able to detect the repetition of a message as it would still consider the old counter to be correct. Since the sender of a message that has caused an error frame normally simply resets its counter and resends the message, the FvM would additionally need to adjust the sender’s counter. Secondly, the system would need to be changed to using one single counter per bus since otherwise the FvM is not able to assign an error frame to the counter used in a message that has been interrupted before writing the message ID to the bus. All these changes result in a system that is in some of its main aspects equivalent to the BusCnt system.
There are some assumptions in our proof regarding the satisfaction of immediacy and non-repeatability by the BusCnt system that need to be substantiated by specific design decisions. This concerns for example the size of the counter that must prohibit overflow. In the BusCnt system, an attacker can accelerate the pulse generator by inserting messages onto the bus. Independently of being accepted, they will cause the connected ECUs to decrement their counters faster than they normally would. However, in Section 7.2.2 below, we discuss the counter length necessary to avoid counter overflow even in the presence of such an attack and show how this length can be implemented in praxis. Other assumptions concern storage errors that we assume never to result in a counter being smaller than the correct one as this could lead to counter overflow as well. This is an issue for all counter-based approaches, adequate measures for detection of such incidents is out of the scope of this paper.
A final security aspect concerns the truncation of MACs which in principle enables an attacker to construct its own message and to determine the corresponding truncated MAC by brute force. This holds in particular for synchronization messages. So if an attacker was able to construct and insert a synchronization message containing e.g. the counter 0…0 with a correct MAC, it could take over the whole bus communication. This is an issue for all approaches using MAC truncation (e.g. for AUTOSARs SecOC). As a counter-measure, we have chosen a specific number of failed synchronization messages as indicator of a brute force attack which we deem small enough to recognize such attacks and on the other hand big enough to not cause unnecessary dysfunction of the bus. See Section 7.2.2 for more details on this aspect.
7.2. Practical Aspects
To evaluate the practical aspects of our work we implemented a proof of concept of BusCount to demonstrate the general feasibility of the mechanisms. Moreover, we want to show the suggested approach can be implemented at a low cost. We first introduce our development setup and describe the design decisions before presenting the evaluation we performed bsaed on this implementation.
7.2.1. Setup
For the implementation of our security enhanced CAN controller, we chose a low-cost FPGA (ICE40HX8K-B-EVN) with only 7680 logic cells and a maximum frequency of 12 MHz. The FPGA is connected with a CAN transceiver (MCP2561) that converts logical CAN messages into physical signals for a CAN bus.
We used an open-source implementation1 as a basis for our CAN controller. We extended the controller with an SLCAN2 protocol to communicate with a connected ECU. The ECU is simulated by a Raspberry Pi 2B running a default Linux SocketCAN3. The software does not need to be modified besides the fact that the payload is reduced by the length of the MAC. A second FPGA with the same setup was introduced to perform MAC verifications and synchronization tests. The correctness of the CAN implementation and the compatibility with regular CAN bus devices was evaluated with a remaining bus simulation using a Vector VN5610 in combination with CANoe v9. The hardware setup of our proof of concept (see Figure 5) contains:
7.2.2. Design Decisions
We decided to use a truncated MAC value with a size of 24 bit to be compatible with AUTOSAR SecOC. Since CAN has a very limited message size per package we decided to use the counter implicitly. This requires more explicit synchronizations yet does not disrupt the system’s functionality due to the fast synchronization mechanism of our protocol. Corresponding to the 24 bit MAC the remaining payload of a CAN message is 40 bits. The counter transferred with the described synchronization mechanism would then also be restricted to these 40 bits. A CAN bus can transmit up to 17,543 messages per second [36], thus a 40 bit counter suffices for about 725.4 days of non-stop communication before an overflow occurs. An attacker may even reduce the duration by starting CAN messages and stopping them immediately with an error frame. This increases the number of messages sent by an attacker (15 bits per message) compared to a regular sender (minimum 44 bits per message) to about 51,459 messages per second . We consider a counter value that could overflow after only 247.3 days not sufficient in an attack scenario, thus we increased the counter by additional 18 bits which can be transmitted using the extended message ID of the CAN specification for synchronization messages. The 58 bit counter is sufficient for about 82,884.75 years . In order to counter brute force attacks and to increase the security of the truncated MAC we suggest renewing the key regularly by deriving it from the current counter value.
Furthermore, we needed to make sure the synchronization cannot be attacked by a brute force attack. An attacker may try to forge a synchronization message setting the counter to 0 which would lead to an overflow or would establish the number 0 as the counter value of all subsequent messages. Since we suggest to transfer only a 24 bit MAC, attacks cannot be prevented by the key size. For this reason we count the number of failed synchronizations. If more than 16 failed synchronizations during a car ride or 128 failed synchronizations in total have been detected, the ECUs need to consider the bus no longer trustworthy and must enable the driver to safely stop the car. The 128 synchronizations give an attacker a 0.000977% chance to forge a synchronization message successfully. A recovery process for a car network is out of the scope of this paper. Compared to the generic counter-based approach, our synchronization solution has the advantage that it is independent of functional disruptions regarding a central entity (fresh value master): Any ECU can initialize synchronization, and all ECUs join in, sending their respective synchronization messages simultaneously. This mechanism allows the synchronization of all ECUs connected to one bus during the transmission time of only one message.
The bus counter-based security protocol does not change the CAN frame and thus it can work with default CAN controllers in one network. The adaptation to CAN FD and CAN XL is also possible. Further, it is compatible with SecOC with respect to the message structure.
The introduction of error frames in conjunction with security checks potentially changes the safety considerations of ISO26262 regarding CAN bus communication. A CAN controller sending a message which results in an error frame increments its error counter by 8 while receiving controllers increment their error counter by 1. Successful message transfer reduces the counter by 1. If an error counter exceeds the value 128, the respective controller changes into bus-off mode and is not able to send or receive data anymore and a hardware reset is necessary. However, there are only two cases that our security mechanisms could cause a bus-off state. In the first case, the attacker is the sender of unauthorized messages by delay, replay, or forging of messages. In this scenario, the attacker performs a denial of service attack which she could also perform in every other secure or non-secure CAN BUS by inserting error frames. The second scenario is the startup of a vehicle where every CAN controller is out of synchronization. In the worst case, ECUs might join the network one by one, each of them sending an error frame caused by a failed check based on its wrong counter value, and then initiate a synchronization. To prevent this we suggest that after waking up and before starting to send error frames, a CAN controller first initiates a synchronization in case of an invalid message. Thus, the ECU is in sync as soon as it joins the network.
7.2.3. Performance Evaluation
The CAN controller implementation we adapted to work on the ICE40HX8K consumed 4,483 of the 7,680 logic cells. The remaining logic cells need to be sufficient for processing a MAC algorithm, the synchronization, and the counter mechanism. Moreover, the MAC algorithm needs to be fast enough to calculate the MAC during the transmission of the truncated MAC value (). The time consumed by the sending process is longer since much more bits are transmitted prior to the truncated MAC value. Finally, the MAC algorithm needs to calculate the MAC over at most 131 bits (58 bit counter value + 29 ID + 4 bit data length + 40 bit data) for classic CAN.
The remaining 3,197 cells are not sufficient to implement a regular cipher, like AES or HMAC with SHA2, with low latency together with the counter and synchronization mechanism. For this reason, we evaluated several lightweight ciphers regarding their number of rounds, state size, and table size. Based on these results we implemented our CAN controller in combination with the two CBC-MAC algorithms Present80 [37] and Prince [38] and the HMAC algorithm SipHash [39]. All three have a block size of 64 bit, so two blocks need to be processed at most. We evaluated the number of cycles each algorithm needs for this task. Table 6 shows the results of our evaluation. The number of cycles as well as the number of logical cells needed for the CAN controller including the different ciphers.
The smallest (in terms of cells needed) but also the slowest algorithm was Present80. Our implementation of the controller with Present80 needed 5,599 logic cells and 68 cycles for two blocks. Prince only needed 30 cycles while increasing the number of logic cells needed to 5,947. SipHash was only slightly larger with 6,024 logic cells, but needs only 13 cycles to compute a MAC over two blocks. Since the security of Present80 is lower and the number of blocks increases drastically regarding CAN FD (10 blocks for 579 bits of authentic data) and CAN XL (258 blocks for at most 16,466 bits of authentic data), we recommend SipHash for a fast and size efficient MAC algorithm in our approach. Additionally, cryptanalysises [40,41] of SipHash did not reveal problems with this cryptographic primitive.
8. Conclusions and Future Work
In this paper, we have presented a detailed discussion and formal evaluation of our hardware-based approach BusCount for the security protection of automotive CAN networks. We further opposed this to the characteristics of counter-based approaches currently being used.
The fundamental difference between currently considered approaches and ours is that in ours the pulse generator is an integral component of the system itself: The very writing onto a bus causes a change of the counter values of all ECUs connected to it as they inevitably read the message (even if not accepting it) and decrement their counters. Since the number of messages sent on the bus cannot be manipulated, the correct counter value cannot be manipulated as well. By this read action, the message’s counter and thus its MAC is invalidated. Another important aspect is the assignment of MAC calculation and verification and checks regarding the size of the message’s counter to the controller. This enables to use the error frame mechanism of CAN communication in case of a failed check which results in invalidation of all messages whose MAC is not based on the correct counter value. These messages will then not be accepted by any of the ECUs. Software-based approaches do not have this possibility since they verify the MAC on application-level after the controller completely received the message.
We formally proved that our bus counter approach satisfies data origin authenticity as well as immediacy and non-repeatability (also denoted by message freshness), both during regular operation and in case an ECU loses its counter. Our proof is based on the assumption that simultaneous loss of counter values does not occur, i.e. that there is always at least one ECU per bus owning the correct value. This assumption seems appropriate, given the low possibility of it being violated. It enables our synchronization mechanism to take advantage of the physical characteristics of a CAN bus and ensures that always the correct counter value is sent.
On the other hand, current counter-based systems cannot assure message freshness if an ECU loses its counter. Immediacy is even violated in case an ECU does not lose its counter: An attacker can invalidate all messages relevant for a specific counter and insert them again at a later point in time without the ECU being able to notice this manipulation. This is due to the fact that the ECU’s local counter value only changes if it actually accepts a message.
Compared to other approaches, our bus counter mechanism offers several practical advantages: It avoids the necessity to include (parts of) the counter in the messages which saves bandwidth, and it requires only one counter per bus to be stored instead of one counter per message ID favored by currently discussed approaches. This reduces both storage capacities and the risk of ECUs being unsynchronized.
The synchronization solution of BusCount has the advantage that it is independent of functional disruptions regarding a central fresh value master that is being used by other counter-based approaches: Any ECU can initialize synchronization, and all ECUs join in, sending their respective synchronization messages simultaneously. This mechanism allows the synchronization of all ECUs connected to the same bus during the transmission time of only one message.
It must be noted that our approach cannot be realized with currently available ECUs. On the other hand, it does not change the CAN frame and can thus work with default CAN controllers in one network. It can also be adapted to CAN FD and CAN XL and is compatible with SecOC with respect to the message structure. Moreover, our proof of concept implementation described in Section 7.2 shows that our approach is not only theoretically interesting, but is functionally working in a CAN network. However, an implementation needs to respect a couple of considerations. One of them is that our approach allows pulse acceleration, hence the counter must be sufficiently long in order to prohibit counter overflow during the lifetime of a car. We consider 58 bits as suggested in Section 7.2.2 adequate. Further, a concrete synchronization mechanism must for example prohibit brute force attacks on truncated MACs of synchronization messages and must ensure a synchronized network as soon as possible after the startup process.
In the future, we plan to extend our attack model and address an adversary that can manipulate devices connected to the bus. One possible countermeasure that at least reduces the severity of this attack is to assign specific roles to different ECUs and to enable ECUs to authentically identify the sender of messages. Hence, we plan to investigate how our approach can be extended by sender authentication mechanisms. Further, we will explore whether and how techniques to protect the devices’ integrity can be integrated in order to prohibit manipulation of genuine ECUs.
Data Availability
No data were used to support this study.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This research work has been partly funded by the German Federal Ministry of Education and Research (BMBF) and the Hessen State Ministry for Higher Education, Research and the Arts within their joint support of the National Research Center for Applied Cybersecurity ATHENE and by the BMBF project VITAF (ID 16KIS0835).