Research Article | Open Access

# On Formal and Automatic Security Verification of WSN Transport Protocols

**Academic Editor:**S. Srinivasan

#### Abstract

We address the problem of formal and automated security verification of transport protocols for wireless sensor networks (WSN) that may perform cryptographic operations. The verification of this class of protocols is difficult because they typically consist of complex behavioral characteristics, such as real-time, probabilistic, and cryptographic operations. To solve this problem, we propose a probabilistic timed calculus for cryptographic protocols and demonstrate how to use this formal language for proving security or vulnerability of protocols. The main advantage of the proposed language is that it supports an expressive syntax and semantics, allowing for studying real-time, probabilistic, and cryptographic issues at the same time. Hence, it can be used to verify systems that involve these three properties in a convenient way. In addition, we propose an automatic verification method, based on the well-known PAT process analysis toolkit, for this class of protocols. For demonstration purposes, we apply the proposed manual and automatic proof methods for verifying the security of DTSN and SDTP, which are two of the recently proposed WSN transport protocols.

#### 1. Introduction

Numerous transport protocols have been proposed specifically designed for applications of wireless sensor networks (WSN), requiring particularly reliable delivery and congestion control (e.g., multimedia sensor networks) [1]. Two of the latest protocols are the distributed transport for sensor networks (DTSN) [2] and its secured version, the secure distributed transport protocol for sensor networks (SDTP) [3]. In DTSN and SDTP the intermediate nodes can cache the packets with some probability and retransmit them upon request, providing reliable transmission, energy efficiency, and distributed functionality.

Unfortunately, existing transport protocols for WSNs (including DTSN) do not include sufficient security mechanisms or totally ignore the security issue. Hence, many attacks have been found against existing WSN transport protocols [4]. Broadly speaking, these attacks can be classified into two groups: attacks against reliability and energy depleting attacks. Reliability attacks aim to mislead the nodes so that loss of a data packet remains undetected. In the case of energy depleting attacks, the goal of the attacker is to perform energy-intensive operations in order to deplete the nodes’ batteries [4]. In particular, using a fake or altered acknowledgment message, an attacker can give the sender the impression that data packets arrived safely when they may actually have been lost. Similarly, forging or altering negative acknowledgment packets to trigger unnecessary retransmission can lead to faster draining of the node’s batteries. While futile retransmissions do not directly harm the reliability of service, they are still undesirable. Systematic mathematical and automated methods are needed for finding the weaknesses in these protocols; however, this is a very hard task due to their complexity. This served as a motivation and challenge for our work, to which we proposed solutions.

In this paper, we address the problem of formal and automated security verification of WSN transport protocols, which typically consist of the following behavioral characteristics: (b1) storing data packets in the buffer of intermediate sensor nodes; (b2) probabilistic and real-time behavior; (b3) performing cryptographic operations such as one-way hashing, computing message authentication codes (MACs); and so on. We propose a formal and an automated verification method, based on the application of process algebra and a model checking framework, respectively. For demonstration purposes, we apply the proposed methods for specifying and verifying the security of the DTSN and the SDTP protocols, which are representative in the sense that DTSN involve the first two behavioral characteristics (b1-b2), while SDTP covers all of the three points (b1–b3). Specifically, the main contributions of this paper are the followings.(i)We propose a probabilistic timed calculus, called , for cryptographic protocols. To the best of our knowledge, this is the first of its kind in the sense that it combines the following three features: (i) it supports formal syntax and semantics for cryptographic primitives and operations; (ii) it supports time constructs similar to the concept of timed automata that enables us to verify real-time systems; (iii) it also includes the syntax and semantics of probabilistic constructs for analysing systems that perform probabilistic behavior. The basic concept of is inspired by previous pieces of work [5–7] proposing solutions separately for each of the three discussed points. In particular, is derived from the applied -calculus [5], which defines an expressive syntax and semantics supporting cryptographic primitives to analyse security protocols; a probabilistic extension of the applied -calculus [6]; and a process calculus for timed automata proposed in [7]. We note that, although in this paper the proposed calculus is used for analysing WSN transport protocols, it is also suitable for reasoning about other systems that include cryptographic operations, as well as real-time and probabilistic behavior.(ii)Using we specify the behavior of the DTSN and SDTP protocols. We propose the novel definition of *weak probabilistic timed bisimilarity* and used it to prove the weaknesses of DTSN and SDTP, as well as the security of SDTP against some attacks.(iii)We provide an approach for the automatic security verification of the DTSN and SDTP protocols with the PAT process analysis toolkit [8], which is a powerful general purpose model checking framework. To the best of our knowledge PAT has not been used for this purpose before; however, in this paper we show that the power of PAT can be used to check some interesting security properties defined for these systems/protocols.

The structure of the paper is as follows: note that, instead of putting into a separate section, we discuss the related pieces of work inside each section, where we compare them with our methods. In Section 2, we start with the introduction of DTSN and SDTP. In Section 3, we discuss the base calculus, , which is a modified variant of the well-known applied -calculus [5], designed for analysing security protocols. The extension of , called , with timing and probabilistic modelling elements is given in Section 4. The security analysis of DTSN and SDTP, based on , is provided in Section 5. The well-known model checking framework PAT and automatic verification of SDTP are given in Section 6. We also verified the DTSN protocol in PAT and found attacks against it; however, due to lack of space we do not discuss it in the paper. Interested readers can find more details in our longer report [11]. Finally, we conclude the paper and give an outlook on future pieces of work in Section 7.

#### 2. The DTSN and SDTP Protocols

##### 2.1. DTSN: Distributed Transport for Sensor Networks

DTSN [2] is a reliable transport protocol developed for sensor networks where intermediate nodes between the source and the destination of a data flow cache data packets in a probabilistic manner such that they can retransmit them upon request. The main advantages of DTSN compared to a transport protocol that uses a fully end-to-end retransmission mechanism is that it allows intermediate nodes to cache and retransmit data packets; hence, the average number of hops that a retransmitted data packet must travel is smaller than the length of the route between the source and the destination. Intermediate nodes do not store all packets but only store packets with some probability , which makes it more efficient. Note that, in the case of a fully end-to-end reliability mechanism, where only the source is allowed to retransmit lost data packets, retransmitted data packets always travel through the entire route from the source to the destination. Thus, DTSN improves the energy efficiency of the network compared to a transport protocol that uses a fully end-to-end retransmission mechanism.

DTSN uses special packets to control caching and retransmissions. More specifically, there are three types of such control packets: Explicit Acknowledgment Requests (*EARs*), Positive Acknowledgments (), and Negative Acknowledgments (). The source sends an *EAR* packet after the transmission of a certain number of data packets or when its output buffer becomes full or when the application has not requested the transmission of any data during a predefined timeout period or due to the expiration of the timer (*EAR_timer*).

The activity timer and the EAR timer are launched by the source for ensuring that a session will finish in a finite period of time. The activity timer is launched when the source starts to handle the first data packet in a session, and it is reset when a new packet is stored or when an ACK or a NACK has been handled by the source. When the activity timer has expired, depending on the number of unconfirmed data packets, the session will be terminated or reset. The EAR timer is launched whenever an EAR packet or a data packet with the EAR bit set is sent.

An may take the form of a bit flag piggybacked on the last data packet or an independent control packet. An is also sent by an intermediate node or the source after retransmission of a series of data packets, piggybacked on the last retransmitted data packet [2]. Upon receipt of an *EAR* packet the destination sends an or a packet, depending on the existence of gaps in the received data packet stream. An refers to a data packet sequence number , and it should be interpreted such that all data packets with sequence number smaller than or equal to were received by the destination. A refers to a base sequence number and it also contains a bitmap, in which each bit represents a different sequence number starting from the base sequence number . A should be interpreted such that all data packets with sequence number smaller than or equal to were received by the destination and the data packets corresponding to the set bits in the bitmap are missing.

Within a session, data packets are sequentially numbered. The Acknowledgment Window (*AW*) is defined as the number of data packets that the source transmits before generating and sending an *EAR*. The output buffer at the sender works as a sliding window, which can span more than one *AW*. Its size depends on the specific scenario, namely, the memory constraints of individual nodes.

In DTSN, besides the source, intermediate nodes also process and packets. When an packet with sequence number is received by an intermediate node, it deletes all data packets with sequence number smaller than or equal to from its cache and passes the packet on to the next node on the route towards the source. When a packet with base sequence number is received by an intermediate node, it deletes all data packets with sequence number smaller than or equal to from its cache and, in addition, it retransmits those missing data packets that are indicated in the packet and stored in the cache of the intermediate node. The bits that correspond to the retransmitted data packets are cleared in the packet, which is then passed on to the next node on the route towards the source. If all bits are cleared in the , then the packet essentially becomes an referring to the base sequence number, and it is processed accordingly. In addition, the intermediate node sets the *EAR* flag in the last retransmitted data packet. The source manages its cache and retransmissions in the same way as the intermediate nodes, without passing on any and packets.

*Security Issues in DTSN.* Upon receiving an packet, intermediate nodes delete from their cache the stored messages whose sequence number is less than or equal to the sequence number in the packet, because the intermediate nodes believe that acknowledged packets have been delivered successfully. Therefore, an attacker may cause permanent loss of some data packets by forging or altering packets. This may put the reliability service provided by the protocol in danger. Moreover, an attacker can trigger unnecessary retransmission of the corresponding data packets by either setting bits in the bit map of the packets or forging/altering packets. Any unnecessary retransmission can lead to energy consumption and interference. Note that unnecessary retransmissions do not directly harm the reliability, but it is clear that such inefficiency is still undesirable.

The destination sends or packets upon reception of an . Therefore, attacks aiming at replaying or forging information, where the attacker always sets the *EAR* flag to or , can have a harmful effect. Always setting the *EAR* flag to prevents the destination from sending an or packet, while always setting it to forces the destination to send control packets unnecessarily.

##### 2.2. SDTP: A Secure Distributed Transport Protocol for WSNs

SDTP is a security extension of DTSN aiming at patching the security holes in DTSN. SDTP ensures that an intermediate node can verify if an acknowledgment or negative acknowledgment information has really been issued by the destination, if and only if the intermediate node actually has in its cache the data packet referred to by the ACK or NACK. Forged control information can propagate in the network but only until it hits an intermediate node that cached the corresponding data packet; this node can detect the forgery and drop the forged control packet.

In particular, the security solution of SDTP works as follows [3]: each data packet is extended with an MAC and a MAC, which are computed over the whole packet with two different keys, an *AC*K key () and a key (). Both keys are known only to the source and the destination and are specific to the data packet; hence, these keys are referred to as per-packet keys.

When the destination receives a data packet, it can check the authenticity and integrity of each received data packet by verifying the two MAC values. Upon receipt of an packet, the destination sends an or a packet, depending on the gaps in the received data buffer. If the destination sends an referring to a data packet with sequence number , the destination reveals (included in the packet) the corresponding key; similarly, when it wants to signal that this data packet is missing, the destination reveals the corresponding key by including it in the packet. Any intermediate node that stores the packets in question can verify if the or message that it receives is authentic by checking if the appropriate MAC in the stored data packet verifies correctly the key included in the packet. In case of successful verification, the intermediate node deletes the corresponding data packets (whose sequence number is smaller than or equal to ) from its cache.

When an ACK packet is received by an intermediate node or the source, the node first checks if it has the corresponding data packet. If not, then the ACK packet is simply passed on to the next node towards the source. Otherwise, the node uses the ACK key obtained from the ACK packet to verify the ACK MAC value in the data packet. If this verification is successful, then the data packet can be deleted from the cache and the ACK packet is passed on to the next node towards the source. If the verification of the MAC is not successful, then the ACK packet is silently dropped.

When a NACK packet is received by an intermediate node or the source, the node processes the acknowledgment part of the NACK packet as described above. In addition, it also checks if it has any of the data packets that correspond to the set bits in the bitmap of the NACK packet. If it does not have any of those data packets, it passes on the NACK without modification. Otherwise, for each data packet that it has and that is marked as missing in the NACK packet, it verifies the NACK MAC of the data packet with the corresponding NACK key obtained from the NACK packet. If this verification is successful, then the data packet is scheduled for retransmission, the corresponding bit in the NACK packet is cleared, and the NACK key is removed from the NACK packet. After these modifications, the NACK packet is passed on to the next node towards the source.

The and key generation and management in SDTP are as follows. The source and the destination share a secret which we call the session master key, and we denote it by . From this, both the source and destination derive an master key and a master key for a given session as follows: where PRF is a pseudorandom function [9] and SessionID is a session identifier.

SDTP assumes a preestablished shared secret value, such as a node key shared by the node and the base station, which can be configured manually in the node before its deployment. Denoting the shared secret by , the session master key is then derived as follows:

The ACK key and the NACK key for the th packet (i.e., whose sequence number is ) are computed as follows:

Note that both the source and the destination can compute all these keys as they both possess the session master key . Moreover, PRF is a one-way function; therefore, when the ACK and NACK keys are revealed, the master keys cannot be computed from them; and consequently, as yet unrevealed ACK and NACK keys remain secrets too.

*Security Issues in SDTP.* The rationality behind this security solution is that the shared secret is never leaked, and hence only the source and the destination can produce the right ACK and NACK master keys and per-packet keys. Since the source never reveals these keys, the intermediate node can be sure that the control information has been sent by the destination. In addition, because the per-packet keys are computed by a one-way function, when the ACK and NACK keys are revealed, the master keys cannot be computed from them; hence, the yet unrevealed ACK and NACK keys cannot be derived. These issues give the protocol designers an impression that SDTP is secure; however, we will formally prove that SDTP is still vulnerable and showing a tricky attack against it.

#### 3. : The Calculus for Cryptographic Protocols

is the base calculus for specifying and analysing cryptographic protocols, without supporting real-time and probabilistic systems. can be seen as a modified variant of the applied -calculus [5], designed for analysing security protocols and proving their security properties in a convenient way. Our goal is to extend with time and probabilistic modelling elements *adopting the concept of timed and probabilistic automata*, and to do this, we need to modify the applied -calculus in some points. Namely, we replace process replication with recursive process invocation; we add definition for positive integers and comparison rules for them; we also define syntax for cache/buffer entry.

##### 3.1. Syntax and Semantics

We assume an infinite set of *names* and *variables* , where . Further, we define a set of distinguished variables that model the cache entries for entities that store data. In the set , we distinguish channel names, and other kinds of data. Channel names are denoted by with different indices such that , . The set of nonnegative integers is denoted by , and its elements range over with different indices that are corresponding to the numbers , , , and so forth.

Further, we let the remaining data be denoted by , , and . The variables are denoted by , , , and the cache entries by with different indices. The names and variables with different indices are different. We let be the set of function symbols. To verify security protocols, in our case, the function symbols capture the cryptographic primitives such as hash, encryption, and MAC function. Finally, we assume the type system of the terms as in the case of the applied -calculus.

We define a set of terms as
where represents “or." In particular, a term can be the following.(i) models a communication channel between honest parties.(ii), , and are names and are used to model some data.(iii), , and are variables that can represent any term; that is, any term can be bound to variables, similarly as in case of the applied -calculus [5].(iv) is a cache entry.(v)Finally, is a function with arity and is used to construct terms and to model cryptographic primitives and messages. Complex messages are modelled by the function *tuple* with terms: *tuple*(), which we abbreviate as (). The function symbol with arity zero is a constant. For example, digital signature, encryption, and message authentication code (MAC) can be modelled by the functions , , and , where models the message to be signed, to be encrypted, and to be MAC-ed, respectively, and models the secret key. Verification of signatures and MACs, as well as decryption, is modelled by equations. For instance, the equation says that, if we decrypt the encryption *enc*(, ) with the right key, then we will get the message as a result. If incorrect key is used for decryption then the process will get stuck and will not continue to run.(vi) ranges over special functions for modelling nonnegative integers. Formally, let be the base element of set and is formally defined as the function named by . Each further integer is defined as a constructor function named by 1, 2, and so forth. Let the function be the function that increases the integer by one. Numbers , are modelled by functions , ,, respectively. The relation between these integers is defined by and .

The internal operation of communication entities in the system is modelled by *processes*. Processes can be specified with the following syntax and inductive definition:
(i)The process represents the sending of message on channel , followed by the execution of . Process represents the receiving of some message, which is bound to in .(ii)In the composition , processes and run in parallel. Each may interact with the other on channels known to both or with the outside world, independently of the other. For example, the communication between the sending process and receiving process can be described as the parallel composition . The communication can be described as a reduction step of the parallel composition, namely, . In the resulted process, proceeds to (meaning that has been sent), while proceeds to (meaning that has been received and now it can be used in for further computations).(iii)A choice can behave as either or depending on the first visible/invisible action of and . If the first action of is enabled but the first action of ’s is not then is chosen, and vice versa. In case that both actions are enabled the behavior is the same as a nondeterministic choice.(iv)A restriction is a process that makes a new, private (restricted) name and then behaves as . The scope of is restricted to and is available only for the process within its scope. A private channel restricted to is defined by , which does not allow the attackers to eavesdrop on the channel.(v)A typical way of specifying infinite behavior is by using parametric recursive definitions, like in the -calculus [10]. Here is an identifier (or invocation) of arity . We assume that every such identifier has a unique, possibly recursive, definition , where ’s are pairwise distinct. The intuition is that behaves as with each replaced by , respectively.(vi)In processes *else *; *else *; and *else *: if , and , respectively, then process is “activated”; else they behave as . When is the **nil** process, we simply remove the else-branch from the processes.(vii)The process **nil** does nothing and is used to model the termination of a process behavior.(viii)Finally, (or *let *) mean that every occurrence of (or ) in is bound to . We adopt the notion of *environment*, well-known in process algebra, which is used to model the attacker(s) who can obtain the (publicly) exchanged messages and can modify them. Moreover, we adopt the notation of the extended process and active substitution in the applied -calculus [5] to model the information that the attacker(s) (or the environment) is getting to know during the system run. The definition of the *extended process* is as follows:
(i) is a plain network that we already discussed above.(ii) is a parallel composition of two extended process.(iii) is a restriction of the name to .(iv) is a restriction of the variable to .(v) means that the binding of to , denoted by , is applied to *any* process that is in parallel composition with . Intuitively, the binding applies to any process that comes into contact with it. To restrict the binding to a process , we use the variable restriction over , namely, . Using this, the equivalent definition of process can be given by ). Active substitutions are always assumed to be cycle-free. We define , , , and for the sets of free and bound variables and free and bound names of , respectively. These sets are defined as follow:
The concept of bound and free values is similar to local and global scope in programming languages. The scope of names and variables is delimited by binders (i.e., input) and or (i.e., restriction). The set of bound names contains every name which is under the restriction inside . The set of bound variables consists of all those variables occurring in that are bound by restriction or input . Further, we define the set of free names and the set of free variables. The set of free names in , denoted by , consists of those names occurring in that are not restricted names. The set of free variables contains the variables occurring in which are not restricted variables () or input variable (). A plain process is closed if it contains no free variable. An extended process is closed when every variable is either bound or defined by an active substitution.

As in the applied -calculus, a frame () is an extended process built up from the **nil** process and active substitutions of the form by parallel composition and restrictions. Formally, the frame of the extended process, , is . The domain of the frame (denoted by ) is the set .

Intuitively, the frame accounts for the static knowledge exposed by to its environment but not for dynamic behavior. The frame allows access to terms that the environment cannot construct. For instance, after the term (not available for the environment) is output in resulting in , becomes available for the environment. Finally, let range over substitutions (i.e., variable bindings). We write for the result of applying to the variables in .

###### 3.1.1. Labeled Transition System ()

The operational semantics for processes is defined as a labeled transition system where represents a set of extended processes, is a set of labels, and .

Specifically, the labeled semantics defines a ternary relation, written as , where is a label of the form , , , where is a variable of base type and is a term. The transition represents a silent move that is used to model the internal operation/computation of processes. These internal operations, such as the verification steps made on the received data, are not visible for the outside world and, hence, to the attacker(s). The transition means that the process performs an input of the term from the environment on the channel and the resulting process is . The label is for output action of a free variable . Finally, the label is when a term is output on . In the following, we give some examples for labeled transitions.

*Silent Transition (Internal Computations/Verification) Rules for Processes*(*Let*)let ; let .(*If1*).(*If2*) **nil** .(*If3*).(*If4*) **nil** .

*Action Transition (Message Input/Output) Rules for Processes * (In) ; (Open) .*Let* binds a variable to a term in a process; rules *If1*–*If4* check the relation of two terms or integers. Rule (In) says that, when a term is received, it is bound to every occurrence of in . Rule (Open) defines the output of a restricted name. Note that these rules are examples from the full list of rules, which can be found in [11]. From rule (Open) and the fact that is equivalent to , we have two additional output rules(Out-1),
(Out-2).

For instance, based on the labeled transition system, we have the following transitions:

After sending the terms and on public channel (modeled by action transitions and , resp.), and become available for the environment (attacker), whose fact is specified by the active substitutions and .

Similarly as in [5], we define an *equational theory *, that is, a set of equations of the form . This allows us to define cryptographic primitives and operations, such as one-way hash function and MAC computation. For instance, the function Tuple models a tuple of terms , and its inverse function returns the th element of a tuple of elements, where . We abbreviate the tuple as in rest of the paper:

We model the keyed hash or MAC function with symmetric key with the binary function MAC. The MAC verification is defined in the form of the following equation:

Function computes the message authentication code of message using secret key . The shared key between node and node is modelled by function . The MAC verification defined by the function is successful (returns a special name ) if the keys match each other.

We can also model many other cryptographic operations and primitives such as symmetric and asymmetric encryption, digital signature, and one-way hash function. However, in this paper we omit to detail them because we do not use these operations. An interested reader can find more details in our longer report [11].

#### 4. : Extending with Timed and Probabilistic Syntax and Semantics

We propose a time and probabilistic extension to , denoted by . Our calculus is tailored for the verification of security protocols, especially for verifying protocols that need to cache data, such as transport protocols for wireless sensor networks. This is a new probabilistic timed calculus for cryptographic protocols and, to the best of our knowledge, the first of its kind. The design methodology of is based on the terminology proposed in previous works, it can be seen as the modification and extension of them and contains some novelties.

Namely, the timed extension of is based on the timed calculus proposed in [7, 12], and it is also based on the syntax and semantics of the well-known timed automata. The probabilistic extension is inspired by the syntax and semantics of the probabilistic extension of the applied -calculus proposed in [6] and the probabilistic automata in [7]. The main difference between our work and the related methods is that we focus on extending , which is different from the calculus used in those works. In addition, we combine both timed and probabilistic elements at the same time. Finally, we also propose a new definition called *weak probabilistic timed bisimilarity* for proving the existence of the attacks against security protocols.

The concept of is based on the concept of probabilistic timed automata; hence, the correctness of comes from the correctness of the automata because the semantics of is equivalent to the semantics of the probabilistic timed automata, and we show that each process in has an associated probabilistic timed automaton.

*Basic Time Concepts.* First of all, we provide some notations related to clocks and time constructs, borrowed from the concept of timed automata. Assume a set of nonnegative real valued variables called clocks. A clock valuation over is a mapping assigning nonnegative real values to clocks. For a time value let denote the clock valuation such that , for each clock .

The set of clock constraints is generated by the following grammar: where ranges over , , is a real number, and . We write when the valuation satisfies the constraint . Formally, ; if and only if ; if and only if .

##### 4.1. Syntax

In the following, we turn to define probabilistic timed processes for :

We will discuss the meaning of processes by showing the connection between the modeling elements of a probabilistic timed automata and . For this purpose, we recall the definition of probabilistic timed automaton [12]: a probabilistic timed automaton *Aut* is defined by the tuple (, , , , , , , ), where(i) is a finite set of locations and is the initial location;(ii) is a set of actions that range over *act*;(iii) is a finite set of clocks;(iv): is a function that assigns location to a formula, called a location invariant, that must hold at a given location;(v): is the set of clock resets to be performed at the given locations;(iv) is the set of edges; we write when (, *act*, , , ) , where *act*, are the action and the time constraint defined on the edge and is the set of the clocks to be reset at ;(iiv) is a finite set of probability distributions; each is a function for any , where () is the probability of an edge according to distribution and the sum of the edges from a given location is .

Let us denote the set of processes in by , and we let range over processes in . In , each probabilistic timed process corresponds to a location in an automaton, such that there is an initial process for location . The set of actions corresponds to the set of actions known in . The set of clocks to be reset at a given location , , is defined by the corresponding process . The clock invariant at the location corresponds to the process , and the edge guard can be defined by . More specifically,(i) can be an extended process without any time construct;(ii) performs as the first (not timed) action with the distribution , at any time, and then it behaves like ; note that can be , , , and the silent action ; for instance, if is , where is the plain process in , then is ; this process corresponds to the automaton edge , where and corresponds to locations and , respectively;(iii) represents a time guard of an action and says that the first action of is performed if the guard (time constraint) holds; this process intends to model the edge in the automaton syntax, where corresponds to , while the explicit appearance of the target location is omitted in the process; in the transition, the action is performed according to the distribution ; when an action has a time guard *true* it means that the action can be performed at any time;(iv) represents a clock invariant over ; this process corresponds to the location invariant in an automaton; like in timed automaton, this means that the system cannot “stay” in process once the time constraint becomes invalid; if it cannot move from this process via any transition, then it is a deadlock situation; invariants can be used to model timeout;(v)in the timed process , first, the clocks in the set are reset and then it behaves like with the reset clock values;(vi) and describe the first-action choice and the parallel composition of two processes, respectively; process behaves like with probability , and it behaves as with (); corresponds to a location from which two edges start, and they are chosen based on the first enable action of and ; for parallel composition, we define as a location, instead of the parallel composition of two automata; process corresponds to a location from which two edges start: and , where and correspond to and , respectively;(vii) is a process variable to which one of the timed processes , , and can be bound; Note that this differs from [10], as for our problem, we restrict process variables () to be only those processes that have time constructs defined on it; the reason we do this is that we want to avoid the recursive process invocation for extended processes, which may lead to an infinite invocation cycle (e.g., , where the process variable is bound to ); hence it is not well-defined.

*Definition 1. *We extend the definition of free and bound variables in Section 3 with the set of clock variables. The set of free variables and bound variables of , denoted by and , respectively, are as follows. (i): edge guards contains free clock variables.(ii): invariant contains free clock variables.(iii): clocks to be reset are bound clock variables.(iv); .(v); .(iv); .The free and bound clock variables of choices and parallel composition are the union of the free and bound clock variables of each process. The reason that the set of clock variables is divided into bound and free parts is to avoid conflicts of clock valuations. For instance, let us consider the process , in which the clock is reset, and this affects the invariant . Further, in the parallel composition the clock variable is the shared variable of the two processes; however, the reset of affects the behavior of process . This is undesirable since the operational semantics of a process also depends on the behavior of the environment (which is hard to control).

Hence, we define the notion of processes that do not contain any conflict of clock variables, using the following inductive definition and the predicate (which refers to "non-conflict of clock variables"):(1);(2);(3) if and only if ;(4) if and only if ;(5);(6) in both cases, if and only if .

Rule 1 holds because an extended process does not include any clock variables. Rule 2 says that the recursive process invocation of plain processes is nonconflict because a plain process does not contain clock variables. Rule 3 comes from the fact that action is free from clock variables. Rule 4 says that the outermost clock resettings do not cause the conflict of variables in process Apt. Rules 5 and 6 say that if guard and invariant constructs are placed outside then their clock variables cannot be reset within , to avoid conflict. For the full list of rules please check our report [11].

In the following, for each process we add rules that associate each process with the invariant and resetting functions and , respectively. Note that we only give the two most important rules in this paper; the full list can be found in [11]. Consider the following: (*rk*) ; (*ri*) .

Rule *rk* says that the set of clocks to be reset in is and the clock resets occur in , and rule *ri* says that the invariant of process is the intersection of and the invariant predicate in .

##### 4.2. Operational Semantics

The formal semantics of follows the semantics of probabilistic timed automata. Namely, a state is defined by the pair (, ), where is the clock valuation at the location with label with the time issues defined at the location. The initial state consists of the initial process and initial clock valuation (, ). Note that the initial process is the initial status of a system behavior, while typically contains the clocks in the reset state. The operational semantics of is defined by a probabilistic timed transition system (PTTS).

A probabilistic timed transition system can be seen as the labeled transition system extended with time and probabilistic constructs. In our model, we follow the concept of [7, 12], but we also improve them with language elements and a new definition of bisimilarity for proving/refuting the security properties of protocols.

*Definition 2. *Let be the set of actions. A probabilistic timed transition system is defined as the tuple , where (i) is a set of states, and is an initial state;(ii) is the set of probabilistic timed labeled transitions; a transition is defined between the source and target state, and the label of the transition is composed of the actions, the time stamp (duration), and the probability of the action; when we denote the transition from to by ; the appearance of on the arrow means that the transition is performed with the probability according to the distribution ; the label says that performing either a visible or invisible (silent) action () consumes time units; we interpret as the time for executing action , and there is no idling time at before performing an action;(iii) is the *until* predicate and is defined at a state with a time duration ; whenever , we use the notation ;(iv)the scheduler chooses nondeterministically the distribution of action transition steps.

The probabilistic timed transition system should satisfy the two axioms, Until and Delay (in both cases denotes logical implication): for all , , for all , .

These two axioms define formally the meaning of the notions delay and until. Basically, axiom *Until* says that if the system stays in state until time units then it also stays in this state before . While the axiom *Delay* says that if the system performs an action at time then it must wait until . Note that the meaning of until differs from time invariant, because, in case of until, the system waits (stays idled) at least time units in a given state, whilst time invariant says that the system must leave a given state when time units have elapsed (if it cannot move from the state then we get deadlock).

In addition, are the smallest set satisfying the following rules:(*u1*);(*u2*);(*u3*) if ;(*u4*) if ;(*u5*) if ;(*u6*) if ;(*u7*) if ;(*u8*) if ;(*u9*) if .

Rules (*u1*-*u2*) are the Until axioms for the states (, ) and (, ). In *u3* the system stays in the state (, ) until time units if this is valid to the state (, ) as well. Rules (*u4*-*u5*) come from the definition of the clock reset and invariant. In rule (*u4*) represents the clock valuation where the clocks in are reset. Rules (*u6*–*u8*) say that the system stays until time units at the state with , , and if it stays time in the state with one of the two processes and . Rule *u9* is concerned with the until predicate for (recursive) process variable , which comes directly from the definition of recursive process invocation. Note that is a plain process defined in .

We define the satisfaction predicate , , on clock constraints. For each we use the shorthand if and only if satisfies , for all valuation . The set of past closed constraint, , is used for defining semantics of location invariant, for all , : . Intuitively, this says that if the valuation , which is defined as for all clocks , satisfies the constraint then so does . We adopt the variant of time automata used in [7], where location invariant and clock resets are defined as functions and assigning a set of clock constraints and a set of clocks to be reset , respectively, to a process.

The probabilistic timed transition (action) rules for are given as follows. We provide the connection of each PTTS transition with the edge syntax well-known in probabilistic timed automata. Consider the following:(*a1*) if ;(*a2*) if ;(*a3*) if ;(*a4*) if ;(*a5*) if ;(*a6*) if ;() if ;() if ;(*a8*) if ;(*a9*) if .

In rule *a2* and in the rest of the rules . represents the valuation where the clocks in are reset. Each rule should be interpreted that the PTTS transition on the left side can be performed if there is an edge in a corresponding automaton. For instance, rule *a1* applies if there is an edge in the corresponding automaton. Rule *a1* says that after performing action with time units the system gets to the process with the clock valuation after time units elapsed. Rule *a2* says that, by the time proceeds to , the clocks in will have been reset. In the rules *a3* and *a4* the timed transition can be performed if holds, which means that the valuation must satisfy the clock guard . Rules *a5-a6* describe the case when process is activated (the rules for activating are similar). and in rules *a7/a-b* mean that in distribution the first and second transitions (edges) are chosen with probabilities and (). In *a8,* to avoid conflict of clock variables, we require that after performing the transition process cannot perform resetting at the beginning. The last rule is the action rule for recursive process variable . It can be proven, based on the rules *u1–u9* and *a1–a9*, that probabilistic timed transition system of satisfies axioms *Until* and *Delay*; hence, it is well defined.

Theorem 3. *For all process and for all closed valuation , PTTS(, , ) is indeed the probabilistic timed transition system defined in probabilistic timed automata.*

We defined rules for renaming the clock variables and we showed that the *ncv* property is preserved by clock renaming; hence, the restriction we made to process without conflict of clock variables is harmless [7]. Based on the rules of renaming we also added new rules for *structural equivalent resulted from renaming*. We omit the discussion of these rules in detail because we do not use them, but the reader can find it in our longer report [11].

*Weak Probabilistic Timed (Prob-Timed) Labeled Bisimulation.* We provide a novel bisimilarity definition, called *weak prob-timed labeled bisimulation* for , which enables us to prove or refute the security of probabilistic timed systems.

Our proposed definition makes use of the definition of static equivalence proposed in the applied -calculus [5], which says that the outputs of static equivalent processes cannot be distinguished by the environment (or attackers). The main advantage of static equivalence is that it only takes into account the static knowledge exposed by two processes to show the behavioral equivalence of them. This method is much easier to use than using the well-known *observation equivalence* [5], where we have to consider the dynamic behavior of processes.

Let the extended process be . The *frame * of is the parallel composition that models all the information that is output so far by the process , which are in this case.

*Definition 4 ( static equivalence for extended processes ). *Two extended processes and are statically equivalent, denoted as , if their frames are statically equivalent. Two frames and are statically equivalent if they include the same number of active substitutions and the same domain, and any two terms that are equal in are equal in as well. Intuitively, this means that the outputs of the two processes cannot be distinguished by the environment.

In our proposed *weak prob-timed labeled bisimulation*, we extend the static equivalence with time and probabilistic elements. The meaning of *weak* is that in this paper we want to examine whether the attackers can distinguish the behavior of two processes, based on the information they can *observe*. Hence, in weak prob-timed labeled bisimulation, we do not require the equivalence of the probability of two action traces, because practically an observer cannot distinguish if an action is performed with 1/2 or 1/3 probability.

Nevertheless, we also proposed the definition of *strong prob-timed labeled bisimulation* in our longer report [11], which we do not discuss in this paper, because we found that, for analysing the security of DTSN and SDTP, it is sufficient to use the weak prob-timed labeled bisimulation. *Strong prob-timed labeled bisimulation* is stricter, since it also distinguishes two processes based on the probability of their corresponding action traces.

*Definition 5 ( weak prob-timed labeled bisimulation for processes). *Let , and let be two probabilistic timed transition systems for processes. Weak prob-timed labeled bisimilarity (

*≈*

_{pt}) is the largest symmetric relation , with , where each is the pair of a closed process and the

*same*initial valuation , , such that implies that (1);(2)if for a scheduler , then such that for the same , with for some function , and ;(3)if for a scheduler and , then such that for the same , with for some function , and ; again, represents the domain of . and are the extended processes we get by removing all the probabilistic and timed elements from and , respectively.

The arrow is the shorthand of the action trace , where represents a series (formally, a transitive closure) of sequential transitions . on is the sum of the time elapsed at each transition and represents the total time elapsed during the sequence of transitions. Note that and are the same as and , respectively. Moreover, a process is closed if its nontimed and “nonprobabilistic” counterpart is closed.

Intuitively, in case that and represent two protocols (or two variants of a protocol), then this means that (i) the outputs of the two processes cannot be distinguished by the environment based on their behaviors; (ii) the time that the protocols spend on the performed operations until they reach the corresponding points is in some relationship defined by a function . Here depends on the specific definition of the security property; for instance, it can return itself; hence, the requirement for time consumption would be . In particular, the first point means that and are statically equivalent; that is, the environment cannot distinguish the behavior of the two protocols based on their outputs; the second point says that and remain statically equivalent after silent transition (internal computation) steps. Finally, the third point says that the behavior of the two protocols matches in transition with the action .

#### 5. Security Analysis of DTSN and SDTP Using

We formally prove the insecurity of the DTSN and SDTP protocols using the weak prob-timed bisimilarity defined in . We also specified the behavior of the two protocols using the syntax of ; however, since these descriptions are a bit complicated, for shortening and making the paper readable, we only discuss the most important parts. For the detailed descriptions, the reader is referred to our longer research report [11].

We assume the network topology , where “” represents a bidirectional link, while , , and denote the source, an intermediate node, and the destination node, respectively. We also include the presence of the application that uses DTSN and SDTP, because it sends packet delivery requests to the source and it receives delivered packets. In the rest of the paper we refer to the application as the *upper layer*. Note that the attack scenarios which can be found and proved in this topology are also valid in other topologies including more intermediate nodes. Moreover, we assume that each node has three cache entries, denoted by , , and , . For brevity we let range over from index to index , and the same is true for and . We define symmetric channels between the upper layer and the source, ; the upper layer and the destination, ; the source and intermediate node, ; the intermediate node and the destination, . Moreover, we define additional channels and for sending and receiving error and session end signals.

We define processes *upLayer*, *Src*, *Int*, and *Dst* for specifying the behavior of the upper layer, the source, intermediate, and destination nodes. The DTSN protocol for the given topology is specified by the parallel composition of these four processes: *Prot**params* let = in ; *INITDTSN* *DTSN**params* *upLayer* Int(,* * ackNbr, nackNbr, toRTX1, nxtsq).

We refer to the tuple of parameters (*cntsq, s, d, apID, **, sID, earAtmp, **, **, ackNbr, nackNbr, toRTX1, nxtsq*) by (*params*). The process *Prot*(*params*) describes DTSN with variable initializations. The *let* construct is used to initialize the value of the cache entries to and the current sequence number to . The unique name is used to represent the empty content. In the following, we give a brief overview of the main processes in our specification. Each main process is composed of additional subprocesses, which we skip discussing here. The processes are recursively invoked in a way to model replication. Interested readers can find the full description in [11].

We introduce two clock variables: for the activity timer and for the ear timer. According to the specification of the DTSN protocol [2], to model timeout we make use of the clock invariant defined on the process *Src*. The initial state of DTSN for the given topology is specified as the process *Prot(params)*, which simply resets the timers at the beginning. We define the time amount of the activity and ear timers by and , respectively. We assume that the activity timer is launched after the upper layer has sent the first request for the source, which is specified in *INITDTSN*().

In process *INITDTSN*(), first of all, the request for sending the first packet with sequence number *cntsq* is sent. Then, the next request, , is enqueued in *upLayer(incr*(*cntsq*)). The parameters of process *Src* are the IDs of the source and the destination; the application ID; the three cache entries, the session ID; and the latest number of EAR attempts. Process *Int* has the content of the three cache entries as parameter. Process *Dst* includes the *cache entries*; the /* numbers* for composing acknowledgment messages; the *packet to be retransmitted;* and the *next expected packet*.

*The Source Handling the Activity Timer Expiration* *InitSrc* .

The process *initSrc* specifies the source node starting with the first packet delivery, when the source does not launch the EAR timer yet but only the ACT (activity) timer. This is defined by the clock invariant construct before *initSrc*. The subprocess *actTimeOut* describes the behavior of the protocol when the ACT timer expires. Similarly, for the EAR timer, we define the process *earTimeOut*.

The three choice options represent the “wait for event” behavior of the source. Each choice option represents a scenario. The last (third) option describes the case when the activity timer has elapsed. The format .*actTimeOut* follows the concept of the timed automaton and says that when the time has elapsed the system should proceed with the process .*actTimeOut*, which describes the defined behavior of *Src* after timeout. is a silent step, moving silently to *actTimeOut*. In this process, we use .*actTimeOut* instead of *actTimeOut*, because we insist on the semantics of timed automaton. The second choice is for the case when the session is terminated, which happens when the constant *SEND* has been sent on the private channel . The session end signal (i.e., the constant *SEND*) is sent on by *Src* according to [2]. We assume that the session termination cannot be interrupted by the timeouts; basically, it can be seen as an atomic action. When the first option has been chosen, it means that in that step the source received the delivery request from the upper layer and that no session end or timeouts happen during this input action. The choices among the possible actions are repeatedly put into each subprocess *initFwdDt*, *initRcvACKS*, and *initRcvNACKS*. Namely, the *session end*, *activity*, and/or * timeouts* options are placed before the action steps to be performed.

*Process That Models the Behavior of an Intermediate Node* . .

In process *Int* the intermediate node may receive a data packet on channel , in which case it handles the received packet according to the definition of DTSN, it can receive and handle an ACK or NACK message, and it can terminate its operation when it gets the session end signal (i.e., the constant *SEND*).

We also add a probabilistic choice in the specification. According to the definition of the DTSN protocol, the probabilistic choice is placed within process *Int*(), which is the specification of node . In particular, after receiving a packet, an intermediate node stores the packet in its cache with probability . To model this behavior, we add the probabilistic choice construct in the subprocess *hndleDtI*, which is responsible for handling a received data packet. Consider the following
Process *strAndFwI*, which describes the case when the intermediate node stores (and forwards) the received packet, is chosen with probability , and process *FwI* that specifies the only forwarding case is selected with probability .

*Process That Models the Behavior of the Destination:* · .

For the process *Dst*, the destination can either receive a data packet on channel or receive a session end signal. In the first case, *Dst* proceeds to *hndleDtDst*, in which the destination performs the verification steps and delivers the packet to the upper layer or sends an ACK or a NACK.

To model the cryptographic primitives and operations in SDTP, we add the following equations into the set of equational theories: *Functions: K(n*, *); K(n, **); MAC(t, K(n, **)). ** **Equations:* CheckMac*(MAC(t, K(n, **)), K(n, **)) = ok*. CheckMac*(MAC(t, K(n, **)), K(n, **)) = ok, *where functions *K*(, ) and *K*(, ) specify the and per-packet keys corresponding to the packet with sequence number . In order to simplify the modelling procedure, without violating the correctness of SDTP, we make an abstraction of the key hierarchy given in [3], where the per-packet keys are computed with a one-way function based on the shared secret unknown to the attacker. Instead, we assume that *K*(, ) and *K*(, ) cannot be generated (but can be intercepted) by the attackers. The attackers can only generate keys that differ from these keys. With this, we model the fact that the shared secret will never be revealed during the protocol.

To model the SDTP protocol, we extend the specification of the DTSN protocol in the following way. First, the source node extends each packet with an ACK MAC and a NACK MAC and then sends it to node , which is accomplished by the following code part in the processes *initSrc* and *Src*.

*The Source Sends a Data Packet in SDTP* let (*ear, rtx, earAtmp*) *=* (*val1, val2, val3*) in* *let (*Kack, Knack*) *=* (*K(sq, ACK*)*, K*(*sq, NACK*)) in* *let *ACKMAC = MAC*((*s, d, apID, sID, sq, ear, rtx*)*, Kack*) in* *let *NACKMAC = MAC*((*s, d, apID, sID, sq, ear, rtx*)*, Knack*) in* *(*s, d, apID, sID, sq, ear, rtx, ACKMAC, NACKMAC*)*. *

In the first row, the variables *ear*, *rtx*, and *earAtmp* are given some values *val1*, *val2*, and *val3*, respectively. In the second row the ACK/NACK keys *Kack* and *Knack* are generated, while in the third and fourth rows the ACK/NACK MACs are computed using the generated ACK/NACK keys. Finally, the following code part in *Src* (*initSrc*) models the case when the EAR (ACT) timer is reset (launched) and the source gets back to the idling state. In the two processes (PR1-2), the clock is reset and then the timeout conditions are defined based on clock invariants (in the form ).

*Process PR1: Reseting (Launching) the *