ISRN Sensor Networks

Volume 2014 (2014), Article ID 891467, 20 pages

http://dx.doi.org/10.1155/2014/891467

Research Article

On Formal and Automatic Security Verification of WSN Transport Protocols

Vinh Thong Ta,¹ Levente Buttyán,1,2 and Amit Dvir³

¹Laboratory of Cryptography and Systems Security (CrySyS), Budapest University of Technology and Economics, Budapest 1117, Hungary

²MTA-BME Information Systems Research Group, Magyar tudósok körútja 2, Budapest 1117, Hungary

³Computer Science Department, College of Management Academic Studies, 7 Yitzhak Rabin Boulevard, 75190 Rishon LeZion, Israel

Received 21 October 2013; Accepted 17 December 2013; Published 4 March 2014

Academic Editors: J. Li, S. Srinivasan, and Y. Yu

Copyright © 2014 Vinh Thong Ta et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

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 ACK 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 Timer.

Consider the following:

  Src(s, d, apID, , sID, earAtmp).

Process PR2: Reseting (Launching) Both the and ACT Timers.

Consider the following:

  , Src(s, d, apID, , sID, earAtmp).

In our formal proofs, we apply the proof technique that is usual in process algebras, such as the applied calculi. Namely, we define an ideal version of the protocol run, in which we specify the ideal/secure operation of the real protocol. This ideal operation, for example, can require that honest nodes always know what is the correct message they should receive/send and always follow the protocol correctly, despite the presence of attackers. Then, we examine whether the real and the ideal versions, running in parallel with the same attacker(s), are weak prob-timed bisimilar.

Definition 6. Let the processes Prot() and () specify the real and ideal versions of some protocol Prot, respectively. We say that Prot is secure (up to the strictness of the ideal version) if Prot() and () are probabilistic timed bisimilar: Prot() ().

The strictness of the security requirement, which we expect a protocol to fulfill, depends on how ideally/securely we specify the ideal version. Intuitively, Definition 6 says that Prot is secure if the attackers, who can observe the output messages on public channels, cannot distinguish the operation of the two instances.

The main difference between the ideal and the real systems is that, in the ideal system, honest nodes are always informed about what kind of packets or messages they should receive from the honest sender node. This can be achieved by defining hidden or private channels between honest parties, on which the communication cannot be observed by attacker(s). In Figure 1 we show the difference in more detail. In the ideal case, three private channels are defined which are not available to the attacker(s). Src, Int, and Dst denote the processes for the source, the intermediate, and the destination nodes. Channels , , and are defined between processes Src and Dst, Int and Dst, and Src and Int, respectively. In the rest of the paper, we refer to the source, intermediate, and destination nodes as , , and . Whenever sends a packet pck on public channel , it also informs about what should receive, by sending at the same time pck directly via private channel to , so when receives a packet via it compares the message with pck. The same happens when sends a packet to . Whenever, an honest node receives an unexpected data, it interrupts its normal operation. The channels and can be used by the destination to inform and about the messages to be retransmitted. We recall that the communication via a private channel is not observable by the environment; hence, it can be seen as a silent transition. Note that, for simplicity, we omitted to include the upper layer and channel in the figure, but we put them in our specification. Finally, we also add additional public channels and for signalling that the cache has been emptied and that the number of packets to be retransmitted is larger than , respectively. These additional channels are defined only for applying bisimilarities in the security proofs, but they do not affect the correctness of the protocol.

(a)

(b)

Figure 1: The difference between the real and ideal version of the DTSN and the SDTP protocols.

With this definition we ensure that the source and intermediate nodes are not susceptible to the modification or forging of ACK and NACK messages since they make the correct decision either on retransmitting or deleting the stored packets. Namely, this means that the honest nodes only handle the messages received on public channels when they are equal to the expected messages received on private channels.

The Attacker Model . We assume that an attacker can intercept the information output by the honest nodes on public channels and modify them according to its knowledge and computation ability. The attacker’s knowledge consists of the intercepted outputs during the protocol run and the information it can create. The attacker(s) can modify the elements of the plaintexts, such as the base number and the bits of the ACK/NACK messages, the EAR and RTX bits, and sequence number in data packets. The attacker can also create entire data or control packets including data it possesses. Further, attacker(s) can send packets to its neighborhood. We also assume several attackers who can share information with each other.

To describe the activity of the attacker(s), we apply the concept of the environment, used in the applied -calculus [5] that models the presence of the attacker(s) in an implicit way. Every message that is output on a public channel is available for the environment; that is, the environment can be seen as a group of attackers who can share information with each other, for instance, via a side channel.

5.1. Security Analysis of the DTSN Protocol

The security properties we want to check in case of the DTSN protocol is that how secure it is against the manipulation of control and data packets. In particular, can the manipulation of packets prevent DTSN from achieving its design goal? In this section we demonstrate how to formally prove the security or vulnerability of DTSN using .

First of all, we assume that, in both DTSN and SDTP, each action (verification, sending, and receiving on public channel) takes an equal amount of time and the function in Definition 5 returns . This assumption does not change the correctness of the protocols. We define the ideal version of the process Prot(params), denoted by (params), which contains the ideal version of DTSN(params):

 /* The Ideal Version of the DTSN Protocol for the Given Topology */ 

   in   ,

where process () contains (params) instead of DTSN (params).

To prove or refute the bisimilarity relation, we define Prot(params) and (params) such that the source and intermediate nodes output the constants CacheEmptyS and CacheEmptyI on the public channel , respectively, whenever they have emptied their buffers after processing an ACK or a NACK message. This is defined by the following code fragment (for ), where process checkEi corresponds to the th cache entry:

 checkEi(s, d, apID, , sID, acknum)  /* Cache entry is emptied and the number of the empty caches is increased *

 let (, nbrEcacheS) (, inc (nbrEcacheS)) in 

  /* Here we add the resetting of the two timers on process Src *

    let (earAtmp = 0) in

 /* If the cache has been emptied (emptycacheS = 3) then CacheEmptyS is output *

 [emptycacheS = 3]

 .  Src(s, d, apID, , sID, earAtmp)

 else   Src(s, d, apID, , sID, earAtmp).

The specification of intermediate node is similar to the case of the source, but nbrEcacheI and CacheEmptyI are used instead of nbrEcacheS and CacheEmptyS, respectively. The constants CacheEmptyS and CacheEmptyI are output whenever the number of the empty cache entries, emptycacheS, emptycacheI, is , which means that the buffers of S and I are emptied, respectively.

Lemma 7. With the defined attacker model , the DTSN protocol is insecure against message manipulation attacks.

According to Definition 5 processes Prot(params) and (params) are not weak prob-timed bisimilar because each point of the definition is violated. The following proof show that DTSN is vulnerable to the manipulation of control packets: in SC-1 the attacker increases the base number in ACK packets causing the stored packets to be deleted from the cache although they should not be, while in SC-2 the attacker forces the destination node to send unnecessary ACKs or NACKs.

 (i)Scenario SC-1. This scenario can happen beside the topology that includes the attacker within the transmission range of both and . We show that the trace of probabilistic timed transitions in the real system, denoted by , cannot be simulated with any corresponding trace in the ideal system. The trace describes the scenario where the source sends the first packet (sequence number ) to the intermediate node on channel . Because is public, this packet is obtained by the attacker(s) (i.e., the environment), who, instead of forwarding it, sends an ACK with base number to . received this message on , empties its buffer, and outputs the constant CacheEmptyS on the public channel . As CacheEmptyS will not be output in if node has not sent anything, the first point of Definition 5 is violated. (ii)Scenario SC-2. We prove that DTSN is susceptible to the attacks that cause futile energy consumption, by showing the violation of the second point of Definition 5. This scenario can happen in the topology that includes the attacker within the transmission range of both and . The following trace in the real system cannot be simulated by the ideal system: sends a correct packet towards , which is intercepted by . Then forwards the packet to but setting the EAR bit in it to , requiring to send an or a . Let the series of silent transitions describe the verification steps made by after receiving the incorrect packet from . Although at this time there is not any difference in the message outputs, the ideal system still cannot simulate this silent trace, because in this case performs only one comparison step, which takes less time units.

5.2. Security Analysis of the SDTP Protocol

We define the ideal version of process ProtSDTP(params), denoted by (params), in the same concept as in (params). The only difference is that, in SDTP, the processes Src and Int are defined such that, whenever the MAC verification made by and on the received ACK/NACK message fails or an unexpected message is received, and output a predefined constant BadControl via the public channel . Note that this extension does not affect the correctness of SDTP and only plays a role in the proofs of weak prob-timed bisimilarity.

Since the main purpose of SDTP is using cryptographic means to patch the security holes of DTSN, we examine the security of SDTP according to each discussed attack scenario to which DTSN is vulnerable.

(i) Proving SC-1. We prove that SDTP is not vulnerable to the attack scenario (SC-1) by showing that (params) can simulate (according to Definition 5) the transition trace produced by ProtSDTP(params). In SDTP the packet sent by includes the ACK MAC and NACK MAC. Hence, when the attacker sends the ACK to , in both the real and the ideal systems, the source node outputs the constant BadControl on the channel , because either the MAC verification fails (in the real system) or the received packet is not the expected one (ideal system). Recall that the MAC verification fails because the attacker does not possess the ACK/NACK keys of the source.(ii) Proving SC-2. Similarly, SDTP is not vulnerable to the attack scenario (SC-2) either. (params) can simulate the transition trace produced by ProtSDTP(params). After receiving an incorrect packet with EAR bit set to 1, in both the real and the ideal systems, the destination node outputs the constant BadControl on the channel , because either the MAC verification fails (in the real system) or the received packet is not the expected one (ideal system). Hence, they consume equal time units.

As we can see, with the security extensions SDTP could eliminate the essential weaknesses of DTSN; however, we will prove that it is still vulnerable, by showing a trace in the real system ProtSDTP(params), which cannot be simulated in (params).

Lemma 8. The SDTP protocol is insecure besides the attacker model .

To prove the vulnerability of SDTP using prob-timed bisimilarity, we relax the definition of the ideal version such that the honest nodes only compare the received ACK/NACK messages with the expected ones. When they receive a data packet they proceed in the same way as the real version, namely, without any comparison with the expected message that it receives on private channels.

Proving SC-3. We consider the trace that refers to the topology . The trace describes the following scenario: has received the first packet from , it replaces the MACs computed by with the MACs it computes on the same data (denoted by , ), and it sends the modified packet to . Node forwards the packet to , which, instead of forwarding it to , sends back the ACK message for this data packet to , including the corresponding ACK key for the MAC . As the result, node deletes its buffer and outputs the constant CacheEmptyI on the public channel . This transition cannot be simulated by any corresponding transition trace in (params). Because, in this case, the ACK sent by A2 will be received on ; then, node interrupts its operation. Hence, CacheEmptyI will never be output.

Note that we also performed verification and showed other weaknesses of SDTP; the reader can find them in our technical report [11].

6. Automated Security Verification Using the PAT Process Analysis Toolkit

Related Methods. SPIN model checker [14] and UPPAAL [15] are general purpose model checking tools. CPAL-ES [16] and ProVerif [13] are automatic verification tools developed for verifying security protocols. The main drawback of them is that they lack semantics and syntax for defining the systems that include probabilistic and real-time behavior. Hence, they cannot be used to verify WSN transport protocols such as DTSN and SDTP. PRISM model checker [17] supports probabilistic and real-time systems but its limited specification language does not enable us to verify protocols/sytems that may perform complex computations.

Our Method. Our method is based on the PAT process analysis toolkit. PAT [8] is a self-contained framework to specify and automatically verify different properties of concurrent (i.e., supporting parallel compositions construct), real-time systems with probabilistic behavior. It provides a user friendly graphical interface, a featured model editor, and an animated simulator for debugging purposes. PAT implements various state-of-the-art model checking techniques for different properties such as reachability, LTL properties with fairness assumptions, refinement checking, and probabilistic model checking. To handle large state spaces, the framework also includes many well-known model checking optimization methods.

One of the biggest advantages of PAT compared with other solutions is that it supports probabilistic and timed, CSP-like behavioral syntax and semantics, which are important in our case. Currently it contains eleven modules to deal with problems in different domains including real-time and probabilistic systems. PAT has been used to model and verify a variety of systems, such as distributed algorithms, and real-world systems like multilift and pacemaker systems. However, PAT (so far) does not provide syntax and semantics for specifying cryptographic primitives and operations, such as digital signature, MAC, encryptions and decryptions, and one-way hash function. Hence, we model cryptographic operations used by SDTP in an abstract, simplified way. Note that the simplification has been made in an intuitive way and does not endanger the correctness of the protocol.

PAT is basically designed as a general purpose tool not specifically for security protocols. It provides a CSP [18] like syntax, but it is more expressive than CSP because it also includes the language constructs for time and probabilistic issues. PAT also provides programming elements like communication channels, array of variables and channels, similarly to Promela [19] (Process Meta Language), the specification language used by the SPIN [19] model-checker. PAT handles time in a tricky way; namely, instead of modeling clocks and clock resets in an explicit manner, to make the automatic verification more efficient it applies an implicit representation of time (clocks).

Next, we briefly introduce the features provided by the main modules of PAT that we use to verify the security of DTSN and SDTP.

Communicating Sequential Programs (CSP#) Module. The CSP# module supports a rich modeling language named CSP# (a modified variant of CSP) that features process algebra operators like (conditional or nondeterministic) choices, interrupt, parallel composition, interleaving, hiding, asynchronous message passing channel, and mathematical operators like summation, multiplication.

It also provides low-level constructs like arrays, if-then-else, and while. The modeling of communication among processes is based on message passing via communication channels. Communication channels sending and receiving on a channel can be defined with the following syntax:

(1)(declaration of channel channame):channel channame size;(2)(output of the msg tuple (m1,m2,m3) onchanname):channame!m1.m2.m3;(3)(input a msg (m1,m2,m3) on thechannel channame): channame?x1.x2.x3;

channel is a keyword for declaring channels only, channame is the channel name, and size is the channel buffer size. It is important that a channel with buffer size sends/receives messages synchronously. A process is a relevant specification element in PAT that is defined as an equation = ProcExp, where ProcExp defines the behavior of process . PAT defines special processes to make coding be more convenient: process Stop is the deadlock process that does nothing; process Skip terminates immediately and then behaves exactly in the same way as Stop.

Events are defined in PAT to make debugging more straightforward and to make the returned attack traces more readable. A simple event is a name for representing an observation. Given a process , the syntax describes a process which performs first and then behaves as . An event can be a simple event or can be combined with assignments which update global variables as in the following example: , where is a global variable.

A sequential composition of two processes and is written as in which starts first and starts only when has finished. A (general) choice is written as , which states that either or may be executed. If performs an event first, then takes control. Otherwise, takes control. Interleaving represents two processes, which run concurrently, and is denoted by .

Real-Time System (RTS) Module. The RTS module in PAT enables us to specify and analyse real-time systems and verify timing properties. To make the automatic verification more efficient, unlike timed automata that define explicit clock variables and capture real-time constraints by explicitly setting/reseting clock variables, PAT defines several timed behavioral patterns to capture high-level quantitative timing requirements, such as wait, timeout, deadline, waituntil, timed interrupt, and within. For instance, process interrupt[t] behaves as until time units elapse and then it switches to .

Probability RTS (PRTS) Module. The PRTS module supports means for analyzing probabilistic real-timed systems by extending the RTS module with probabilistic choices and assertions. The most important extension added by the PRTS module is the probabilistic choice (defined with the keyword pcase):

 prtsP = pcase  [prob1]: prtsQ1 [prob2]: prtsQ2  [probn]: prtsQn ;

where prtsP, prtsQ1,…, prtsQn are PRTS processes which can be normal processes, timed processes, probabilistic processes, or probabilistic timed processes. prtsP can proceed as prtsQ1, prtsQ2, , prtsQn with probabilities prob1, prob2,…, probn, respectively.

PAT supports a probabilistic assertion, which is a query about the system’s probabilistic behaviors, namely, the reachabiliy of a defined goal with some probability:

 #assert prtsP() reaches cond with prob/pmin/pmax.

this returns respectively the probability, the minimal probability, and the maximal probability of the event that process prtsP()reaches a state where the boolean expression cond is true.

6.1. On Verifying SDTP Using the PAT Process Analysis Toolkit

We verify SDTP assuming the topologies Top1: , Top2: , and Top3: . Following the concept in Section 5, we define public (symmetric) channels between each node pair and define additional symmetric channels chASPck, chASAck, chASNack, chASEAR, chADPck, chADAck, chADNack, and chADEAR, between the attacker(s) and its (their) honest neighbors.

As already mentioned earlier, PAT does not support language elements for specifying cryptographic primitives and operations in an explicit way. We specify the operation of SDTP with the implicit representation of MACs and ACK/NACK keys. First, recall that in SDTP the per-packet ACK and NACK keys are generated as

Following this concept, in PAT we define the ACK key and NACK key for the packet with sequence number by the “pair” n.Kack and n.Knack, respectively. To reduce the verification complexity we made abstraction on the key generation procedure and model the session ACK/NACK master keys by the unique constants Kack and Knack. Then we specify the packets sent by the source node as follows: sq.ear.rtx.sq.sq.Kack.sq.sq.Knack, where the first part sq.ear.rtx contains the packet’s sequence number and the EAR and RTX bits, respectively; the second part sq.sq.Kack and the third part sq.sq.Knack represent the ACK MAC and NACK MAC computed over the packet with sequence number sq without the EAR and RTX bits, using the per-packet ACK and NACK keys sq.Kack and sq.Knack. An ACK message has the following forms: acknbr.acknbr.Kack, where acknbr.Kack is the corresponding ACK key of acknbr. A NACK message has the format acknbr.nckb1.acknbr.Kack.nckb.Knack, where nckb.Knack is the NACK key of the packet to be retransmitted. The NACK message can include more bits, in a similar way.

By default, the attackers do not possess the two master keys Kack and Knack of honest nodes but only their own key Katt. Because honest nodes are specified to wait for these MACs format, the attackers should compose the MACs in this format as well, namely, sqA.sqA.Katt. The attackers cannot use the master keys to construct the per-packet ACK/NACK keys, and when they obtain a MAC, for example, sq.sq.Kack, they cannot use sq.Kack, only in case they receives sq.Kack.

We distinguish the following scenarios and examine the possible ability of the attacker(s). The behaviors of the attackers are defined as the processes procA1() and procA2(). In our model, by default the attackers have two sequence numbers seqA1 and seqA2 which are the smallest (i.e., ) and the largest possible sequence numbers, respectively. The attackers can include earA , rtxA   in their data packets. The attackers, in addition, possess the predefined values for requiring retransmission in NACK messages.

Process procA1(), which defines the behavior of the first attacker , is specified as an external choice among the following four activities (each of them is composed of additional choice options).

(1)Without Receiving Any Message. (i) sends a data packet, with seqA1.earA.rtxA or seqA2.earA.rtxA, to ; (ii) sends an ACK, for the packet seqA1 or seqA2, to or to ; (iii) sends a NACK, with the ack numbers seqA1 or seqA2, and a combination of , to or to .(2)After Receiving a Data Packet (chSAPck?seq.ear.rtx). (i) sends a data packet, with the sequence number seq, seqA1, or seqA2, and different values ear/rtx bits, to ; (ii) sends an ACK, with the ack number seq, seqA1, or seqA2, to or ; (iii) sends a NACK, with the ack number seq, seqA1, or seqA2, and a combination of , to or to .(3)After Receiving an (chIAAck?ack). (i) sends a data packet, with the sequence number ack, seqA1, or seqA2, to ; (ii) sends an ACK, with the ack number ack, seqA1, or seqA2, to or to ; (iii) sends a NACK, with the ack number ack, seqA1, or seqA2, and a combination of , to or to .(4)After Receiving a with 1–4 Bits (chIANack?ack.b1 chIANack?ack.b1.b2 chIANack?ack.b1.b2.b3 chIANack?ack.b1.b2.b3.b4). (i) sends a data packet, with with the sequence number ack, seqA1, or seqA2, to ; (ii) sends an ACK, with the sequence number ack, seqA1, or seqA2, and a combination of , to or to ; (iii) sends a NACK to or to . We recall that the attacker, besides the self-generated data, can only use the information in the received messages. Hence, when the attacker receives the NACK ack.b1, it can only use (besides its own data) ack and b1.

We denote the attackers with this kind of behavior by . The SDTP protocol with the second topology is specified as the parallel compositions of each honest node and the attacker A1:

Again, each process is recursively called, in such a way that is equivalent to replication of many instances of the processes. For the second topology , the scenarios and PAT codes are the same as in the case of the first topology except that the used channels at each corresponding step are changed as follows. In the first topology, A1 receives data packets from S on chSAPck, which is changed to chIAPck in the second case because now data packets come from I. Similarly, the inputs on chSAAck and chSANack are changed to chDAAack and chDANack, respectively. The outputs by A on chIAPck, chIAAck, chIANack, chSAAck, and chSANack are changed to chDAPck, chDAAck, chDANack, chIAAck, and chIANack, respectively. The attacker process procA2() describing the behavior of A2 is specified in the same way as procA1() but with different channels.

The SDTP protocol with the second topology is specified as the following parallel compositions:

For the third topology S-A1-I-A2-D, we apply the specification of both processes A1 and A2. The SDTP protocol with the third topology is specified as the parallel compositions of each honest node and the two attackers:

Assertions. The assertion, denoted by violategoal1, for verifying the provision of reliable delivery of packets, is as follows:

 #define violategoal1 OutBufL BufI num ,

where the (global) variables OutBufL, BufI are the number of the occupied cache entries at the source and intermediate node, respectively, while the variable num is the number of those packets that the destination has not received and that require to be retransmitted. Hence, (OutBufL == 0) and (BufI == 0) represent that the cache of and are emptied, but at the same time (num > 0) means that has not received all of the packets.

The following PAT code is applied for asking if these bad states can be reached in SDTP:

(B1)#assert SDTP() reaches violategoal1p1;(B2)#assert SDTP() reaches violategoal1p1 with pmax.

For the topology Top2, we run PAT to model-check (B1) and get the result Not Valid. This means that, in the presence of the defined attacker(s) , SDTP cannot be corrupted such that has not received some packets and required retransmissions but the buffers of and are emptied. Assertion (B2) also results in Not valid.

Now let us consider the topology Top3 that includes two attackers and . We specify the bad states for SDTP (and DTSN), and we run the model checking to see if these bad states can be reached. The bad states and the verification goals can be defined in PAT’s language in the form of logical formulas and assertions, respectively.

Let the number of buffer entries that are freed at node after receiving an ACK/NACK message be freenum, and let the number of packets received in sequence by node be acknum. The bad state violategoal2 specifies the state where (freenum > acknum) (see Algorithm 1).

    PAT code:

        #define violategoal2 (freenum > acknum)

B5. #assert SDTPsubA1subA2() reaches violategoal2

B6. #assert SDTPA1A2() reaches violategoal2

Algorithm 1

We run the PAT model checker with the attacker processes (see Algorithm 2).

subA1() =

  /* A1 sends a data packet to I, without receiving any message, OR */

  A1NotRcvSndPck2I()

  /* After receiving a data packet on channel chSAPck */

     chSAPck?seq.ear.rtx.seq1.seq2.Kack.seq3.seq4.Knack ->

    (

    /* A1 sends a data packet to I, OR */

       A1RcvPckSndPck2I()

    /* A1 forwards the packet unchanged to I */

          chIAPck!seq.ear.rtx.seq1.seq2.Kack.seq3.seq4.Knack -> subA1()

   )

subA2() =

  /* A2 sends a data packet to I, without receiving any message, OR */

  A2NotRcvSndAck2I()

  /* After getting a data on channel chIAPck, A2 sends ACK with seqA2 to I */

     chIAPck?seq.ear.rtx.seq1.seq2.Kack.seq3.seq4.Knack -> A2RcvPckSndAck2I()

SDTPsubA1subA2() =

   UpLayer()  procS() subA1() procI() subA2() procD()

Algorithm 2

As a result, the tool returned Valid for the assertions and along with the following trace.

(1)A1 sends to I a data pck seqA2.ear.rtx with the corresponding ACK MACs: seqA2.seqA2.Katt and NACK MACs: seqA2.seqA2.Katt. (2)I stores this pck and forwards it (unchanged) to A2.(3)A2 received this packet and sends to I the ACK for seqA2: seqA2.seqA2.Katt.seqA2.Katt with the 2 keys seqA2.Katt and seqA2.Katt. (4)As result, I deletes all the packets stored in its buffer because the key seqA2.Katt and the MAC seqA2.seqA2.Katt match.

In summary, we get the result that both DTSN and SDTP are susceptible for this sandwich style attack scenario. The main reason for this weakness is that in SDTP the intermediate nodes do not verify the origin of the received messages; they only check if the stored ACK/NACK MACs match the received ACK/NACK keys.

We also performed verification and showed other weaknesses of SDTP; the reader can find them in our technical report [11].

7. Conclusion

In this paper, we addressed the problem of formal and automated security verification of WSN transport protocols 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 proposed a probabilistic timed calculus for cryptographic protocols and demonstrated how to use this formal language for proving security or vulnerability of protocols. To the best of our knowledge, this is the first such process calculus that supports an expressive syntax and semantics, real-time, probabilistic, and cryptographic issues at the same time. Hence, it can be used to verify systems that involve these three properties. In addition, we proposed an automatic verification method, based on the 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, and showed that (i) DTSN is vulnerable to packet manipulation attacks, (ii) SDTP successfully patched some security holes found in DTSN, and (iii) SDTP is still vulnerable to the sandwich type attack.

In the future, we focus on improving the automatic security verification for this class of systems/protocols. Currently we found that PAT is the most suitable tool because it enables us to define concurrent, nondeterministic, real-time, and probabilistic behavior of systems in a convenient way. However, in its current form it does not support (or only in a very limited way) cryptographic primitives and operations, as well as the behavior of strong (external or insider) attackers. Finally, we believe that our proposed methods can be applied for verifying other similar systems, which we will show in our follow-up work.

Conflict of Interests

The authors declare that there is no conflict of interests regarding the publication of this paper.

References

J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,” Computer Networks, vol. 52, no. 12, pp. 2292–2330, 2008.

B. Marchi, A. Grilo, and M. Nunes, “DTSN: distributed transport for sensor networks,” in Proceedings of the 12th IEEE International Symposium on Computers and Communications (ISCC '07), pp. 165–172, Aveiro, Portugal, July 2007.

L. Buttyan and A. M. Grilo, “A secure distributed transport protocol for wireless sensor networks,” in Proceedings of the IEEE International Conference on Communications (ICC '11), pp. 1–6, Kyoto, Japan, June 2011.

L. Buttyan and L. Csik, “Security analysis of reliable transport layer protocols for wireless sensor networks,” in Proceedings of the IEEE Workshop on Sensor Networks and Systems for Pervasive Computing (PerSeNS '10), pp. 1–6, Mannheim, Germany, March 2010.

M. Abadi and C. Fournet, “Mobile values, new names, and secure communication,” in Proceedings of the 28th ACM Symposium on Principles of Programming (POPL'01), pp. 104–115, January 2001.

J. Goubault-Larrecq, C. Palamidessi, and A. Troina, “A probabilistic applied pi-calculus,” in Programming Languages and Systems, pp. 175–190, Springer, 2007.

P. R. D'Argenio and E. Brinksma, “A calculus for timed automata,” Tech. Rep., Theoretical Computer Science, 1996.

L. Yang, et al., Pat: process analysis toolkit

T. Dierks and E. Rescorla, “The transport layer security (TLS) protocol version 1. 2,” RFC 5246, Internet Engineering Task Force, 2008.

R. Milner, J. Parrow, and D. Walker, “A calculus of mobile processes, parts I and II,” Information and Computation, vol. 100, no. 1, pp. 1–77, 1992.

T. V. Thong and A. Dvir, “On formal and automatic security verification of wsn transport protocols,” Tech. Rep. 2013/014, Cryptology Eprint Archive, 2013.

R. Lanotte, A. Maggiolo-Schettini, and A. Troina, “Weak bisimulation for prob-abilistic timed automata,” in Proceedings of the International Conference on Software Engineering and Formal Methods (SEFM '03), pp. 34–43, IEEE CS Press, 2003.

B. Blanchet, “Automatic proof of strong secrecy for security protocols,” in Proceedings of the 2004 IEEE Symposium on Security and Privacy, pp. 86–100, Oakland, Calif, USA, May 2004.

A. Perrig, R. Szewczyk, V. Wen, D. Culler, and J. D. Tygar, “SPINS: security protocols for sensor networks,” in Proceedings of the 7th ACM Annual International Conference on Mobile Computing and Networking (MobiCom '01), pp. 189–199, Rome, Italy, July 2001.

J. Bengtsson and F. Larsson, “Uppaal a tool for automatic verification of real-time systems,” Tech. Rep., Uppsala University, 1996.

J. D. Marshall II and X. Yuan, “An analysis of the secure routing protocol for mobile ad hoc network route discovery: Using intuitive reasoning and formal verification to identify flaws,” Tech. Rep., The Florida State University, 2003.

M. Kwiatkowska, G. Norman, and D. Parker, “PRISM 4-0: verification of probabilistic realtime systems,” in Proceedings of the 23rd International Conference on Computer Aided Verification (CAV '11), G. Gopalakrishnan and S. Qadeer, Eds., vol. 6806 of Lecture Notes in Computer Science, pp. 585–591, Springer, 2011.

C. A. R. Hoare, “Communicating sequential processes,” Communications of the ACM, vol. 21, no. 8, pp. 666–677, 1978.

G. Holzmann, The Spin Model Checker: Primer and Reference Manual, Addison-Wesley Professional, 1st edition, 2003.