# Formal Verification of Safety & Security Related Timing Constraints for a Cooperative Automotive System

- 5 Citations
- 5.9k Downloads

## Abstract

Modeling and analysis of timing constraints is crucial in real-time automotive systems. Modern vehicles are interconnected through wireless networks which creates vulnerabilities to external malicious attacks. Violations of cyber-security can cause safety related accidents and serious damages. To identify the potential impacts of security related threats on safety properties of interconnected automotive systems, this paper presents analysis techniques that support verification and validation (V&V) of safety & security (S/S) related timing constraints on those systems: Probabilistic extension of S/S timing constraints are specified in PrCcsl (probabilistic extension of clock constraint specification language) and the semantics of the extended constraints are translated into verifiable Uppaal models with stochastic semantics for formal verification. A set of mapping rules are proposed to facilitate the translation. An automatic translation tool, namely ProTL, is implemented based on the mapping rules. Formal verification are performed on the S/S timing constraints using Uppaal-SMC under different attack scenarios. Our approach is demonstrated on a cooperative automotive system case study.

## Keywords

Automotive system Safety and security PrCcsl Uppaal-SMC## 1 Introduction

Model based development (MBD) is rigorously applied in automotive systems in which the software controllers interact with physical environments. The continuous time behaviors of those systems often rely on complex dynamics as well as on stochastic behaviors. Formal verification and validation (V&V) technologies are indispensable and highly recommended for development of safe and reliable automotive systems [11, 12]. Conventional V&V, i.e., testing and model checking have limitations in terms of assessing the reliability of hybrid systems due to both stochastic and non-linear dynamical features. To ensure the reliability of safety critical hybrid dynamic systems, *statistical model checking (SMC)* techniques have been proposed [7, 8, 19]. These techniques for fully stochastic models validate probabilistic performance properties of given deterministic (or stochastic) controllers in given stochastic environments.

Modern vehicles are being equipped with communication devices and interconnected with each other through wireless networks. Vehicular Ad Hoc Networks (Vanet) [28] are the technologies of wireless networks that establish communication among vehicles and roadside units (RSU). Nevertheless vehicular communication contributes to the safety and efficiency of traffic, it introduces vulnerabilities to vehicles. Transmitted information can be corrupted or modified by attackers, resulting in serious safety consequences (e.g., rear-end collision). Analysis of the potential impacts of cyber-security violations on safety properties is crucial in automotive systems. However, traditional automotive system design often addresses the correctness of safety properties without consideration of security breaches. There is still a lack of techniques that enable an integrated analysis of safety & security (S/S) properties. Moreover, message transmission in Vanet that pertains to S/S requires restrictions by time deadlines [10]. In this paper, we focus on S/S related timing constraints and propose analysis techniques that support formal verification on interconnected automotive systems.

East-adl [9, 22] is an architectural description language for modeling of automotive systems. The latest release of East-adl has adopted the time model proposed in Timing Augmented Description Language (Tadl2) [5], which expresses and composes basic timing constraints, i.e., repetition rates, end-to-end delays. Tadl2 specializes the time model of MARTE, the UML profile for Modeling and Analysis of Real-Time and Embedded systems [30]. MARTE provides Ccsl, a Clock Constraint Specification Language, that supports specification of both logical and dense timing constraints, as well as functional causality constraints [16, 23]. A probabilistic extension of Ccsl, called PrCcsl [14], has been proposed to formally specify timing constraints associated with stochastic properties in weakly-hard real-time systems [4], i.e., a bounded number of constraints violations would not lead to system failures when the results of the violations are negligible.

In this paper, we present a formal analysis of S/S related timing constraints for interconnected automotive systems at the design level: 1. To identify vulnerabilities of automotive systems under malicious attacks, we adopt and modify the behavioral model of a cooperative automotive system (CAS) [13] in Uppaal-SMC by adding it with the models of an RSU-aided (Raise) communication protocol in Vanet and malicious attacks. The modification results in a refined behavioral model of the system, i.e., more details in terms of vehicular communication and security breaches are depicted; 2. Probabilistic extension of S/S timing constraints are specified in PrCcsl and the semantics of the extended constraints are translated into verifiable models with stochastic semantics for formal verification; 3. A set of mapping rules are proposed to facilitate the translation, based on which an automatic translation tool ProTL is implemented; 4. Formal verification is performed on the S/S timing constraints using Uppaal-SMC under different attack scenarios.

The paper is organized as follows: Sect. 2 presents an overview of PrCcsl and Uppaal-SMC. CAS is introduced as a running example in Sect. 3. Section 4.1 presents the Uppaal-SMC model of CAS complemented with model of Raise protocol and three types of attacks. S/S related timing constraints are specified in PrCcsl and translated into verifiable Uppaal-SMC models in Sect. 5. The applicability of our approach is demonstrated by performing verification on CAS case study in Sect. 6. Sections 7 and 8 present related works and conclusion.

## 2 Preliminary

In our framework, S/S related timing constraints are specified in PrCcsl. Uppaal-SMC is employed to perform formal verification on the timing constraints.

### 2.1 Probabilistic Extension of Clock Constraint Specification Language (PrCCSL)

PrCcsl [14] is a probabilistic extension of Ccsl [3, 23] for formal specification of timing constraints associated with stochastic behaviors. In PrCcsl, a clock represents a sequence of (possibly infinite) instants. An event is a clock and the occurrences of an event correspond to a set of ticks of the clock. PrCcsl provides two types of clock constraints, i.e., *expressions* and *relations*, to specify the progression/occurrences of clocks. An *expression* derives new clocks from the already defined clocks [3]. Let \(c1, c2 \in C\), ITE (if-then-else) *expression*, denoted as \(\beta \) Open image in new window *c*1 Open image in new window *c*2, defines a new clock that behaves either as *c*1 or as *c*2 according to the value of the boolean variable/formula \(\beta \). DelayFor (denoted *ref* (*d*) Open image in new window *base*) results in a new clock by delaying the reference clock *ref* for *d* ticks (or *d* time units) of a *base* clock. FilterBy (*c* \(\triangleq \) *base* Open image in new window *u(v)*) builds a new clock *c* by filtering the instants of a *base* clock according to a binary word *w=u(v)*, where *u* is the *prefix* and *v* is the *period*. “*(v)*” denotes the infinite repetition of *v*. This expression results in a clock *c* that \(\forall \ k\ \in N^{+}\), if the \(k^{th}\) bit in *w* is 1, then at the \(k^{th}\) tick of *base*, *c* ticks.

A *relation* limits the occurrences among different events, which are defined based on run and history. A run corresponds to an execution of the system model where the clocks tick/progress. The history of a clock *c* represents the number of times the clock *c* has ticked prior to the current step.

### Definition 1

**(Run).** A run *R* consists of a finite set of consecutive steps where a set of clocks tick at each step *i*. The set of clocks ticking at step *i* is denoted as *R*(*i*), i.e., for all *i*, 0 \(\leqslant \) *i* \(\leqslant \) *n*, \(R(i) \in R\), where *n* is the number of steps of *R*.

### Definition 2

**(History).** The history of clock *c* in a run *R* is a function: \(H_{R}^c\): \(\mathbb {N} \rightarrow \mathbb {N}\). \(H_{R}^c(i)\) indicates the number of times the clock *c* has ticked prior to step *i* in run R, which is initialized as 0 at step 0. It is defined as: (1) \(H_{R}^c(0) = 0\); (2) \(\forall \ i \in \mathbb {N^+},\ c \notin {R}(i) \ \Longrightarrow \ H_{R}^c(i+1) = H_{R}^c(i)\); (3) \(\forall \ i \in \mathbb {N^+}, \ c \in {R}(i) \ \Longrightarrow \ H_{R}^c(i+1) = H_{R}^c(i)\ +\ 1\).

A probabilistic *relation* in PrCcsl is satisfied if and only if the probability of the *relation* constraint being satisfied is greater than or equal to the probability threshold \(p \in [0,\ 1]\). Given *k* runs \(=\) \(\{R_1, \ldots , R_k \}\), the probabilistic subclock, coincidence, exclusion and precedence in PrCcsl are defined as follows:

**Probabilistic Subclock:** Open image in new window , where Open image in new window , representing the ratio of runs that satisfies the relation out of k runs. A run \(R_j\) satisfies the subclock relation between *c*1 and *c*2 “if *c*1 ticks, *c*2 must tick” holds at every step *i* in \(R_j\), s.t., Open image in new window Open image in new window . “ Open image in new window ” returns 1 if \(R_j\) satisfies Open image in new window , otherwise it returns 0.

**Probabilistic Coincidence:** Open image in new window , where Open image in new window , which represents the ratio of runs that satisfies the coincidence relation out of k runs. A run, \(R_j\) satisfies the coincidence relation on *c*1 and *c*2 if the assertion holds: \(\forall i\), \(0 \leqslant i \leqslant n\), \((c1 \in {R}(i)\implies c2 \in {R}(i)) \wedge \ (c2 \in {R}(i)\implies c1 \in {R}(i))\). In other words, the satisfaction of coincidence relation is established when the two conditions “if *c*1 ticks, *c*2 must tick” and “if *c*2 ticks, *c*1 must tick” hold at every step.

**Probabilistic Exclusion:** Open image in new window , where Open image in new window , indicating the ratio of runs that satisfies the exclusion relation out of k runs. A run, \(R_j\), satisfies the exclusion relation on *c*1 and *c*2 if \(\forall i\), \(0 \leqslant i \leqslant n\), \((c1 \in {R}(i)\implies c2 \notin {R}(i)) \wedge \ (c2 \in {R}(i)\implies c1 \notin {R}(i))\), i.e., for every step, if *c*1 ticks, *c*2 must not tick and vice versa.

**Probabilistic Precedence:** Open image in new window , where Open image in new window , which denotes the ratio of runs that satisfies the precedence relation out of k runs. A run \(R_j\) satisfies the precedence relation if the condition \(\forall i\), \(0 \leqslant i \leqslant n\), \({(H^{c1}_{R}(i) \geqslant H^{c2}_{R}(i))}\) and \((H^{c2}_{R}(i)=H^{c1}_{R}(i)) \implies (c2 \notin \ {R}(i))\) hold, i.e., the history of *c*1 is greater than or equal to the history of *c*2, and *c*2 must not tick when the history of the two clocks are equal.

### 2.2 UPPAAL-SMC

UPPAAL-SMC [31] performs the probabilistic analysis of properties by monitoring simulations of the complex hybrid system in a given stochastic environment and using results from the statistics to determine whether the system satisfies the property with some degree of confidence. Uppaal-SMC provides a number of queries related to the stochastic interpretation of Timed Automata (STA) [8] and they are as follows, where *N* and *bound* indicate the number of simulations to be performed and the time bound on the simulations respectively: 1. *Probability Estimation* estimates the probability of a requirement property \(\phi \) being satisfied for a given STA model within the time bound: *Pr*[*bound*] \(\phi \); 2. *Hypothesis Testing* checks if the probability of \(\phi \) is satisfied within a certain probability \(P_0\): *Pr*[*bound*] \(\phi \) \(\ge \) \(P_0\); 3. *Simulations*: Uppaal-SMC runs multiple simulations on the STA model and the *k* (state-based) properties/expressions \(\phi _1,..., \phi _k\) are monitored and visualized along the simulations: *simulate* *N* \([\le \) \(bound]\{\phi _1,..., \phi _k\}\).

## 3 Running Example

The cooperative driving of CAS requires prompt and secure information transmission among vehicles. We adopt a roadside unit aided (Raise) [33] communication protocol in Vanet to achieve the data transmission. Each vehicle periodically broadcasts its own position and velocity to its immediate following vehicle through wireless connection. The authentication of the identities of each vehicle and verification of messages sent by the vehicles is performed by RSU. For further details of Raise, refer to Sect. 4.1. The following S/S properties on CAS are considered:

R1. The follower vehicle should not overtake its leading vehicle when the vehicles run at a positive direction of x-axis.

R2. When the lead vehicle detects a stop sign, all the three vehicles must stop within a given time, e.g., 2000 ms.

R3. If the distance between a vehicle and its preceding vehicle is less than minimum safety distance, the vehicle should decelerate within a certain time (200 ms).

R4. If the distance between a vehicle and its preceding vehicle is greater than the maximum safety distance (e.g., 100 m), the vehicle should accelerate within a certain time, e.g., 300 ms.

R5. When the lead vehicle starts to turn left (or turn right), the two follower vehicles should finish turning and run in the same lane within a given time.

R6. Authenticity: If a vehicle receives a message, its preceding vehicle must have sent a corresponding message before, i.e., the protocol should be resistant to message spoofing attack.

R7. Secrecy: Symmetric keys of vehicles should be kept confidential to attackers.

R8. Integrity: The content of messages must not be modified during transmission, i.e., the protocol should be resistant to message falsification attack.

R9. Freshness: The vehicles should not accept an “obsolete” message, namely, the difference between the current time and the *timestamp* of the accepted message should be less than the predefined time threshold.

R10. The symmetric key agreement (i.e., mutual authentication) process between RSU and three vehicles should be completed within a certain time, e.g., 600 ms.

R11. A vehicle should send messages to its subsequent vehicle periodically with a period 200 ms and a jitter 100 ms.

Among the above S/S requirements, R1–R5 are safety [20] properties, which specify that the system should not cause undesirable results on its environment and aim at protecting human lives, health and assets from being damaged. R6-R11 are security properties, which refer to the inability of the environment to affect the system in an undesirable way and aim to guarantee the confidentiality and integrity of transmitted information. The interdependencies among those S/S properties are conditional dependencies [17], i.e., violations of security properties can lead to the violations on safety properties. The events associated with those S/S properties can be interpreted as logical clocks in PrCcsl, which provides a way to express S/S properties in the logical time manner [16]. Therefore, S/S properties can be interpreted as logical timing constraints, i.e., the temporal and causality clock *relations* in PrCcsl.

## 4 Modeling and Refinement of CAS in UPPAAL-SMC

The behaviors of CAS are modeled as a network of stochastic timed automata (NSTA) in Uppaal-SMC described in [13]. In this section, we refine the CAS model by adding it with the models of Raise protocol and security attacks.

### 4.1 Modeling of RAISE Protocol in UPPAAL-SMC

We present a simplified version of Raise protocol [33] and its Uppaal-SMC model. The original Raise protocol is modified to facilitate the communication mechanism of CAS, i.e., each follower vehicle receives messages from its immediate preceding vehicle and RSU. Furthermore, timing constraints are also appended to restrict the time duration of each step (e.g., encryption and decryption) during communication process. There are two phases in Raise protocol, i.e., *symmetric key agreement* and *information transmission*.

**Symmetric key agreement (SKA)**is performed to obtain symmetric key \(k_i\) for guaranteeing security of communication and generates pseudo identities \(ID_i\) of vehicles for covering their real identities. The shared symmetric key between

*RSU*and \(v_i\) is \(k_i=g^{ab}\), where

*g*,

*a*,

*b*are three positive random numbers. As shown in Fig. 3,

*Encry*(

*msg*,

*k*) (

*Decry*(

*msg*,

*k*)) denotes the encryption (decryption) of message

*msg*with key

*k*, where

*k*can be either a public key or symmetric key.

*Sign*(

*msg*,

*k*) generates signature of

*msg*with a private key

*k*. We use \(PK_i\) to denote the public key of \(v_i\) and \(SK_i\) to represent the corresponding private key. “||” is the concatenation operation on messages.

Initially, \(v_i\) randomly picks *g* and *a* (step 1), encrypts “*g*||*a*” and sends the encrypted result (\(m_i\)) to *RSU* (step 2). Upon receiving \(m_i\), *RSU* decrypts the message (step 3). It then generates *b* and \(ID_i\), signs and sends the signed message (\(rm_i\)) to \(v_i\) (step 4 and 5). \(v_i\) verifies the \(rm_i\)’s signature (step 6) and sends back the signature of \(g||a||b||ID_i\) (step 7). Finally, *RSU* verifies the signature \(s_i\) (step 8). If all the steps are completed correctly, the key agreement process succeeds.

**Information transmission (IT)**initiates after the SKA is completed. The traffic information (i.e, brake, direction, position and speed) of \(v_i\) is integrated into a message \(msg_i= brake_i||direction_i||x_i||y_i||speed_i\). As presented in Fig. 4, initially, \(v_i\) generates the message authentication code (MAC) of \(msg_i\) with the symmetric key \(k_i\) (generated in SKA). Then, \(v_i\) concatenates the MAC code with

\(msg_i\) and sends it to *RSU* and \(v_{i+1}\) (step 1). Upon receiving \(vm_i\), \(v_{i+1}\) checks the freshness of the message (step 2), i.e., if the time interval between the current time and the time when \(vm_i\) is sent is greater than the predefined threshold, \(v_{i+1}\) drops \(vm_i\). At the same time, *RSU* checks the authenticity of \(vm_i\) (step 3). If \(mac_i\) is correct, *RSU* computes the hash code \(h_i\) of message \(msg_i\) (step 4). Afterwards, it encrypts \(h_i\) and sends the encrypted result \(hm_i\) to \(v_{i+1}\) (step 5). \(v_{i+1}\) decrypts \(hm_i\) and get the hash code *h* (step 6). Furthermore, to ensure the consistency of the message, \(v_{i+1}\) itself also computes the hash code of \(msg_i\) (step 7). It then verifies whether the hash code calculated by itself is the same as the decrypted hash code and decides to accept or reject \(msg_i\) (step 8).

*synchronization channels*[31] and global variables. The cryptographic operations in Raise refer to public and private key encryption and decryption, i.e., a message encrypted by public key can be decrypted using the corresponding private key, and vice versa. The automaton of cryptographic device [6] is adopted to model the encryption and decryption. Figure 5 presents the STA capturing behaviors of vehicle \(v_i\) and RSU in SKA.

*startEn*(resp.

*startDe*) and

*finDe*(resp.

*finEn*) are channels for indicating the starting and finishing of encryption (resp. decryption). The encryption/decryption result is denoted

*en_res*/

*de_res*. In the STA, names of locations indicate the corresponding steps pictured in Fig. 3.

The SKA (or IT) succeeds if each step of the SKA (IT) is completed correctly within a given time interval, modeled by invariant “t \(\le \) d” (the value of *d* varies in different steps). If timeout occurs (i.e., “t \(\ge \) d”), *fail* location will be activated and the procedure is restarted from the initial step.

### 4.2 Modeling of Attacks in UPPAAL-SMC

We present the modeling of three types of attacks commonly used in the security analysis, i.e., message falsification, message replaying and message spoofing attacks [2]. The models of attacks are illustrated in Fig. 7, where the *ls* parameter (*ls* \(\in [0, 100]\)) serves as an indicator of level of adversarial strength while *qc* (*qc* \(\in [0, 100]\)) is an indicator of the adversarial channel quality.

**Message Falsification Attack**(MFA) aims to falsify messages transmitted from \(v_i\) to \(v_{i+1}\), which is modeled as MFA STA in Fig. 7. As described earlier, in Raise, RSU verifies the authenticity of messages by checking the correctness of the MAC code of messages. To deceive the RSU on the validity of the modified message and avoid exposing itself to RSU, MFA attempts to obtain the symmetric key and utilizes the key to compute the MAC code of the falsified message. At s1 state, MFA eavesdrops on \(rm_i\) (generated at step 5 in Fig. 3), which contains the information for symmetric key generation (i.e.,

*g*,

*a*,

*b*). It tries to decrypt \(rm_i\) when receiving it via

*sendrm*[

*i*]?. The probability that the decryption can succeed is

*ls*%, modeled by probabilistic choices [31] (dashed edges) with probability weight as \(\frac{ls}{100}\) and \(\frac{100-ls}{100}\). If the decryption succeeds, MFA obtains the symmetric key of \(v_i\) based on the decrypted result (\(getKey(de\_res)\)). Finally, it modifies the content of message using the key, and tries to send the modified message to \(v_{i+1}\) (

*sendvm*[

*i*]!). The probability that the message can be sent successfully is (100-

*qc*)%. In our setting, MFA modifies the \(speed_i\) field in the message into a random value in [100, 120], and changes the direction as \(direction_i=4\), which indicates that the \(v_i\) is running at the positive direction on y-axis.

**Message Replaying Attack** (MRA) targets to replay obsolete messages that contain old information. The MRA STA represents an MRA that replays messages sent by \(v_i\). Upon capturing a message (via *sendvm*[*i*]?), MRA stores the message (*m = vm[i]*) and tries to replay it at a later time (i.e., after *10* s). The probability that the attacker can replay the message successfully is (100-*qc*)%.

**Message Spoofing Attack** (MSA) impersonates a vehicle (\(v_i\)) in order to inject fraudulent information into its subsequent vehicle (\(v_{i+1}\)). Similar to MFA, MSA STA first obtains the symmetric key of \(v_i\) by detecting and decrypting \(rm_i\). It then fabricates a new message whose content is “\(brake_i=0,\ speed_i=0,\ direction_i=4,\ x_i=0,\ y_i=10\)” (denoted “*encode(i)*”) and tries to send the message to \(v_{i+1}\) (*sendvm*[*i*]!), with the probability of the message being sent successfully as (100-*qc*)%.

## 5 Representation of S/S Related Timing Constraints in UPPAAL-SMC

To enable the formal verification of S/S related timing constraints (given in Sect. 3), we first investigate how to specify those constraints in PrCcsl. Then, translation from PrCcsl specifications of the constraints into verifiable STA is demonstrated. Furthermore, a tool ProTL that supports the automatic transformation based on the proposed translation rules is introduced.

### 5.1 Specifications of S/S Related Timing Constraints in PrCCSL

*ac*is a clock that always ticks while

*nc*represents a clock that never ticks. R1 is specified as an exclusion

*relation*between

*xdir*(the event that the vehicles are running at the positive direction of x-axis) and

*ovtake*(the event that the position of follower \(v_1\) on x-axis is greater than that of leader \(v_0\)). Similarly, R7 and R9 can be specified as exclusion

*relations*.

PrCCSL specifications of R1–R11

Req | PrCCSL Specification |
---|---|

R1 | Open image in new window , Open image in new window , Open image in new window |

R2 | Open image in new window , Open image in new window , Open image in new window |

R3 | |

R4 | |

R5 | |

R6 | |

R7 | |

R8 | |

R9 | |

R10 | |

R11 | Open image in new window , Open image in new window , Open image in new window , Open image in new window , Open image in new window |

In the specification of R2, *stopD* is a clock generated by delaying *stopSign* (the event that the leader vehicle detects a stop sign) for 2000 ms. *vstop* refers to the event that three vehicles are completely stopped, which should occur no later than *stopD*. Hence, R2 is expressed as a causality *relation* between *vstop* and *stopD*. R3–R5 can be specified in a similar manner.

R6 (authenticity) is expressed as a subclock *relation* between *msgRec* and *msgSent*, where *msgRec* (*msgSent*) represents the event that a message is received (sent) by the follower (leader) vehicle. R8 is specified as a coincidence *relation* between *msgRec* and *validMsg*, where *validMsg* is a clock that ticks with *msgRec* when the received message *rMsg* is identical with the sent message *sMsg* (i.e., *rMsg == sMsg*). For R10, *startSKA* (*finSKA*) represents the starting (completion) of SKA. *startSKADe* is a clock constructed by delaying *startSKA* for 600 ms. R10 delimits that *finSKA* must occur before *startSKADe*. R11 states that two consecutive occurrences of *msgSent* must has a interval of [*period − jitter, period + jitter*]ms (i.e., [100, 300] ms). In the specification of R11, *fclk* is a clock generated by filtering out the \(1^{st}\) tick of *msgSent*. *sentDe1* and *sentDe2* are two clocks generated by delaying *msgSent* for 100 ms and 300 ms. R11 can be interpreted as: \(\forall i\ \in \mathbb {N}^{+}\), the \(i^{th}\) tick of *fclk* should occur later than the \(i^{th}\) tick of *sentDe1* but prior to the \(i^{th}\) tick of *sentDe2*.

### 5.2 Translation of PrCCSL into STA

We present how the S/S related timing constraints specified in PrCcsl can be transformed into STA and probabilistic queries in Uppaal-SMC. We first describe how clock tick and history (introduced in Sect. 2) can be represented in Uppaal-SMC. Using the mapping, we then demonstrate that *expressions* and *relations* in PrCcsl can be translated into STA and queries.

*e*, e.g.,

*e*= 0.000001.

In PrCcsl, a logical clock represents an event and the instants of the clock correspond to the occurrences of the event. A logical clock *c* is represented as a *synchronization channel* *c*! in Uppaal-SMC. The history of *c* is modeled as the STA shown in Fig. 8: whenever *c* occurs (*c*?), the value of its history is increased by 1 (i.e., *h++*).

Based on the mapping patterns of tick and history, the PrCcsl *expressions* (including ITE, DelayFor and filterBy), as well as *relations* (including subclock, coincidence, exclusion and precedence), can be represented as STA and queries shown in Fig. 9.

*expressions*trigger the ticks of the new clock (denoted

*res*!) based on the occurrences of existed clocks. To represent

*relations*, observer STA that capture the semantics of standard subclock, coincidence, exclusion and precedence

*relations*are constructed. Each observer STA contains a “

*fail*” location (see Fig. 9), which indicates the violation of the corresponding

*relation*. Recall the definition of PrCcsl in Sect. 2, the probability of a

*relation*being satisfied is interpreted as a ratio of runs that satisfies the

*relation*among all runs. It is specified as

*Hypothesis Testing*queries in Uppaal-SMC, \(H_0\): \(\frac{m}{k} \geqslant p\) against \(H_1\): \(\frac{m}{k} < p\), where

*m*is the number of runs satisfying the given

*relation*out of all

*k*runs. As a result, the probabilistic

*relations*are interpreted as the query (see Fig. 9): \(Pr[bound]([\ ]\ \lnot STA.fail)\ge p\), which means that the probability of the “

*fail*” location of the observer STA never being reached should be greater than or equal to

*p*. The STA of

*expressions*and

*relations*are composed to the system NSTA in parallel. Then, the probabilistic analysis is performed over the composite NSTA that enables us to verify the S/S related timing constraints over the entire system using Uppaal-SMC.

**Tool support:** Manual translation of PrCcsl specifications into Uppaal models for verification can be time-consuming and error-prone. To improve the accuracy and efficiency of translation, we implement a tool ProTL (Probabilistic-Ccsl TransLator) [26] that provides a push-button transformation from PrCcsl specifications into corresponding STA & queries. Furthermore, verification and simulation support is provided in ProTL by employing the Uppaal-SMC as the backend analysis engine. ProTL encompasses the following features: (1) An editor for editing PrCcsl specification of requirements (stored as *“.txt”* files); (2) Automated transformation of PrCcsl specifications into Uppaal-SMC STA; (3) Integration of the STA and the system behavioral model (imported by users); (4) A configuration palette for setting parameters (e.g., time bound of simulation, number of simulations) used for verification and simulation; (5) Automatic generation of probabilistic queries (introduced in Sect. 2) based on user-specified parameters; (6) Capability of performing verification and simulation on PrCcsl specifications against the integrated model and generated queries.

The GUI of ProTL is implemented by applying the Python package TKINTER [27]. The implementation of *Translator* is achieved by the ANother Tool for Language Recognition (ANTLR) [24], a parser generator that can constructs lexical parsers for a language by analyzing user-defined syntax of the language. We specified the syntax of PrCcsl in Backus-Naur Form (BNF) and apply ANTLR to generate a *parser* that can analyze and recognize encodings in the format of PrCcsl. The *parser* reads the PrCcsl specifications and generates abstract syntax trees (AST), i.e., an intermediate form that has tree structures. By traversing AST, the information (i.e., operators and parameters) of PrCcsl can be extracted and utilized for generation of corresponding STA.

## 6 Experiment

To identify vulnerabilities of system to external malicious attackers, we combine the refined CAS system model (including the models of Raise protocol) with models of three different attackers. Formal verification on S/S related timing constraints (R1–R11) for the combined model is performed by Uppaal-SMC. The combined CAS model contains the stochastic behaviors in terms of the unpredictable environments (e.g., the traffic signs are randomly recognized by the leader vehicle of CAS and the probability of each sign type occurring is equally set as 16.7%), as well as the indeterministic behaviors modeled by weighted probability choices in the STA of attacks (see Fig. 7). In our setting, *ls* and *qc* are configured as 10 and 90, respectively. To estimate the probability of an attack being launched on CAS successfully, *Probability Estimation* query is applied to check the probability that the “*attack*” location in each attack STA is reachable from the system NSTA. The time bound of the verification is set as 10000. The probability of message falsification, message replaying and message spoofing attack being successfully completed by the corresponding attacker is within the range of [0.109, 0.209], [0.563, 0.663] and [0.143, 0.243], respectively.

*relation*(as described in Sect. 5.1) whose probability threshold is 95%. The verification results are demonstrated in Table 2, in which “\(\surd \)” denotes the corresponding requirement is satisfied while “\(\times \)” indicates the violation of the requirement: Under the message replaying attack, all the S/S timing constraints are established as valid with 95% level of confidence. In the message falsification attack, the secrecy and integrity properties (R7 and R8), as well as three safety properties (R3–R5), are violated. The MSA damages the authenticity (R6) and secrecy (R7) of communication, and leads to the violations of four safety properties, i.e., R1 and R3–R5.

Verification results of timing constraints under different attacks

Attacks | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | R9 | R10 | R11 | Average Time | Mem (Mb) |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|

Message Falsification | \(\surd \) | \(\surd \) | \(\times \) | \(\times \) | \(\times \) | \(\surd \) | \(\times \) | \(\times \) | \(\surd \) | \(\surd \) | \(\surd \) | 40.20 | 57.94 |

Message Replaying | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | 68.33 | 61.49 |

Message Spoofing | \(\times \) | \(\surd \) | \(\times \) | \(\times \) | \(\times \) | \(\times \) | \(\times \) | \(\surd \) | \(\surd \) | \(\surd \) | \(\surd \) | 58.11 | 40.23 |

*Simulations*queries. The simulation results in Fig. 10 illustrate how an MSA drives the system to undesirable states.

## 7 Related Work

Formal verification of (non)-functional properties of automotive systems containing stochastic behaviors were investigated in several works [13, 14, 15]. In these works, systems are by default resilient to security threats and the safety properties are analyzed under no malicious attack scenarios, which is inadequate for design of automotive systems interconnected via wireless communications. Combined analysis of safety and security (S/S) properties for interconnected cyber physical systems have been addressed in earlier works [1, 21, 29], which are however, limited to theoretical frameworks and high-level descriptions of S/S properties without the support for formal verification. Pedroza et al. [25] proposed a SysML based environment called AVATAR for the formal verification of S/S properties, which enables assessment of the impacts of cyber-security threats on functional safety. Wardell et al. [32] proposed an approach for identifying security vulnerabilities of industrial control systems by modeling malicious attacks as PROMELA models amenable to formal verification. However, those approaches lack precise probabilistic annotations specifying stochastic properties regarding to S/S aspects. Kumar et al. [18] introduced the attack-fault trees formalism for descriptions of attack scenarios and conducted formal analysis by using Uppaal-SMC to obtain quantitative estimation on impacts of system failures or security threats. On the other hand, our work is based on the probabilistic extension of S/S related timing constraints with the focus on probabilistic verification of the extended constraints.

## 8 Conclusion

This paper presents a model-based approach for probabilistic formal analysis of safety and security (S/S) related timing constraints for interconnected automotive system in East-adl at the early design phase. The behavioral model of automotive system in Uppaal-SMC is refined by adding the models of vehicular communication protocol and malicious attacks, which facilitates to exploit the impacts of adversary environment on S/S of the system. Timing constraints are specified in PrCcsl and translated into stochastic timed automata (STA) amenable to formal verification using Uppaal-SMC. A set of translation rules from PrCcsl to STA, as well as the corresponding tool support for automating the translation are provided. We demonstrate our approach by performing formal verification on a cooperative automotive system (CAS) case study. Although, we have shown the one-to-one mapping patterns from a subset of PrCcsl operators to STA for conducting formal verification on timing constraints using Uppaal-SMC, as ongoing work, systematic and formal translation techniques covering a full set of PrCcsl constraints are further studied. Furthermore, new features of ProTL with respect to analysis of Uppaal-SMC models involving wider range of variable/query types (e.g., *urgent channels*, *bounded integers*) are further developed.

## Notes

### Acknowledgment

This work is supported by the EASY project funded by NSFC, a collaborative research between Sun Yat-Sen University and University of Southern Denmark.

## References

- 1.Abdo, H., Kaouk, M., Flaus, J.M., Masse, F.: A safety/security risk analysis approach of industrial control systems: a cyber bowtie-combining new version of attack tree with bowtie analysis. Comput. Secur.
**72**, 175–195 (2018)CrossRefGoogle Scholar - 2.Amoozadeh, M., et al.: Security vulnerabilities of connected vehicle streams and their impact on cooperative driving. IEEE Commun. Mag.
**53**(6), 126–132 (2015)CrossRefGoogle Scholar - 3.André, C.: Syntax and semantics of the clock constraint specification language (CCSL). Ph.D. thesis, Inria (2009)Google Scholar
- 4.Bernat, G., Burns, A., Llamosi, A.: Weakly hard real-time systems. Trans. Comput.
**50**(4), 308–321 (2001)MathSciNetCrossRefGoogle Scholar - 5.Blom, H., et al.: TIMMO-2-USE timing model, tools, algorithms, languages, methodology, use cases. Technical report, TIMMO-2-USE (2012)Google Scholar
- 6.Corin, R., Etalle, S., Hartel, P.H., Mader, A.: Timed model checking of security protocols. In: ACM Workshop on Formal Methods in Security Engineering (FMSE), pp. 23–32. ACM (2004)Google Scholar
- 7.David, A., et al.: Statistical model checking for stochastic hybrid systems. In: Hybrid Systems and Biology (HSB), pp. 122–136. EPTCS (2012)Google Scholar
- 8.David, A., Larsen, K.G., Legay, A., Mikučionis, M., Poulsen, D.B.: UPPAAL-SMC tutorial. Int. J. Softw. Tools Technol. Transf.
**17**(4), 397–415 (2015)CrossRefGoogle Scholar - 9.EAST-ADL: EAST-ADL specification v2.1.9. Technical report, MAENAD (2011). https://www.maenad.eu/public/EAST-ADL-Specification_M2.1.9.1.pdf
- 10.Engoulou, R.G., Bellaïche, M., Pierre, S., Quintero, A.: VANET security surveys. Comput. Commun.
**44**, 1–13 (2014)CrossRefGoogle Scholar - 11.IEC 61508: Functional safety of electrical electronic programmable electronic safety related systems (2010)Google Scholar
- 12.ISO 26262–6: Road vehicles functional safety part 6. Product development at the software level (2011)Google Scholar
- 13.Kang, E.Y., Huang, L., Mu, D.: Formal verification of energy and timed requirements for a cooperative automotive system. In: ACM/SIGAPP Symposium On Applied Computing (SAC), pp. 1492–1499. ACM (2018)Google Scholar
- 14.Kang, E.-Y., Mu, D., Huang, L.: Probabilistic verification of timing constraints in automotive systems using UPPAAL-SMC. In: Furia, C.A., Winter, K. (eds.) IFM 2018. LNCS, vol. 11023, pp. 236–254. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-98938-9_14CrossRefGoogle Scholar
- 15.Kang, E.Y., Mu, D., Huang, L., Lan, Q.: Verification and validation of a cyber-physical system in the automotive domain. In: IEEE International Conference on Software Quality, Reliability and Security Companion (QRS), pp. 326–333. IEEE (2017)Google Scholar
- 16.Khan, A.M., Mallet, F., Rashid, M.: Combining SysML and MARTE/CCSL to model complex electronic systems. In: Information Systems Engineering (ICISE), pp. 12–17. IEEE (2016)Google Scholar
- 17.Kriaa, S., Pietre-Cambacedes, L., Bouissou, M., Halgand, Y.: A survey of approaches combining safety and security for industrial control systems. Reliab. Eng. Syst. Saf.
**139**, 156–178 (2015)CrossRefGoogle Scholar - 18.Kumar, R., Stoelinga, M.: Quantitative security and safety analysis with attack-fault trees. In: High Assurance Systems Engineering (HASE), pp. 25–32. IEEE (2017)Google Scholar
- 19.Legay, A., Viswanathan, M.: Statistical model checking: challenges and perspectives. Int. J. Softw. Tools Technol. Transf.
**17**(4), 369–376 (2015)CrossRefGoogle Scholar - 20.Line, M.B., Nordland, O., Røstad, L., Tøndel, I.A.: Safety vs. Security. In: International Conference on Probabilistic Safety Assessment and Management (PSAM) (2006)Google Scholar
- 21.Macher, G., Höller, A., Sporer, H., Armengaud, E., Kreiner, C.: A combined safety-hazards and security-threat analysis method for automotive systems. In: Koornneef, F., van Gulijk, C. (eds.) SAFECOMP 2015. LNCS, vol. 9338, pp. 237–250. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-24249-1_21CrossRefGoogle Scholar
- 22.MAENAD (2011). http://www.maenad.eu/
- 23.Mallet, F., De Simone, R.: Correctness issues on MARTE/CCSL constraints. Sci. Comput. Program.
**106**, 78–92 (2015)CrossRefGoogle Scholar - 24.Parr, T.: The definitive ANTLR 4 reference. Pragmatic Bookshelf (2013)Google Scholar
- 25.Pedroza, G., Apvrille, L., Knorreck, D.: Avatar: a SysML environment for the formal verification of safety and security properties. In: New Technologies of Distributed Systems (NOTERE), pp. 1–10. IEEE (2011)Google Scholar
- 26.
- 27.Tkinter: Python interface to Tcl/Tk. https://docs.python.org/3/library/tkinter.html
- 28.Raya, M., Hubaux, J.P.: Securing vehicular Ad Hoc networks. J. Comput. Secur.
**15**(1), 39–68 (2007)CrossRefGoogle Scholar - 29.Sabaliauskaite, G., Mathur, A.P.: Aligning cyber-physical system safety and security. In: Cardin, M.A., Krob, D., Lui, P., Tan, Y., Wood, K. (eds.) Complex Systems Design & Management Asia, pp. 41–53. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-12544-2_4CrossRefGoogle Scholar
- 30.Specification, O.: UML profile for MARTE: modeling and analysis of real-time embedded systems. Technical report, Object Management Group (2011)Google Scholar
- 31.UPPAAL-SMC. http://people.cs.aau.dk/~adavid/smc/
- 32.Wardell, D.C., Mills, R.F., Peterson, G.L., Oxley, M.E.: A method for revealing and addressing security vulnerabilities in cyber-physical systems by modeling malicious agent interactions with formal verification. Proc. Comput. Sci.
**95**, 24–31 (2016)CrossRefGoogle Scholar - 33.Zhang, C., Lin, X., Lu, R., Ho, P.H., Shen, X.: An efficient message authentication scheme for vehicular communications. IEEE Trans. Veh. Technol.
**57**(6), 3357–3368 (2008)CrossRefGoogle Scholar

## Copyright information

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.