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.