On Formal and Automatic Security Verification of WSN Transport Protocols

,


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.

ISRN Sensor Networks
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][6][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.

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 0 or 1, can have a harmful effect.Always setting the EAR flag to 0 prevents the destination from sending an  or  packet, while always setting it to 1 forces the destination to send control packets unnecessarily.

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: = PRF (; " master key"; SessionID) ,   = PRF (; " master key"; SessionID) , 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:  = PRF (; "session master key"; SessionID) .(2) The ACK key  ()   and the NACK key  ()  for the th packet (i.e., whose sequence number is ) are computed as follows: = PRF (  ; "per packet  key"; ) ,  ()  = PRF (  ; "per packet  key"; ) . ( 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.

𝑐𝑟𝑦𝑝𝑡: 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 N and variables V, where N ∩ V = 0. Further, we define a set of distinguished variables E that model the cache entries for entities that store data.In the set N, 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 I, and its elements range over   with different indices that are corresponding to the numbers 0, 1, 2, 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 F 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 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 (vii) The process nil does nothing and is used to model the termination of a process behavior.
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.
ISRN Sensor Networks (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 V(), V(), (), 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 V() 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 V() 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, 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 .

Labeled Transition System (
→).The operational semantics for processes is defined as a labeled transition system (P, G, → ) where P represents a set of extended processes, G is a set of labels, and → ⊆ P × G × P.
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.

Action Transition (Message Input/Output) Rules for Processes
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 For instance, based on the labeled transition system, we have the following transitions: After sending the terms  1 and  2 on public channel  (modeled by action transitions →, resp.),  1 and  2 become available for the environment (attacker), whose fact is specified by the active substitutions { 1 / 1 } and { 2 / 2 }.
Similarly as in [5], we define an equational theory , that is, a set of equations of the form  1 =  2 .This allows us to define cryptographic primitives and operations, such as oneway hash function and MAC computation.For instance, the function Tuple models a tuple of  terms  1 ,  2 , . . .,   , and its inverse function i returns the th element of a tuple of  elements, where  ∈ {1, . . ., }.We abbreviate the tuple as ( 1 ,  2 , . . .,   ) 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:  (, ) ; ℎ ( (, ) , ) =  (10) 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].

𝑝𝑟𝑜𝑏 𝑡𝑖𝑚𝑒 : 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 C of nonnegative real valued variables called clocks.A clock valuation over C is a mapping V : C  → R ≥0 assigning nonnegative real values to clocks.For a time value  ∈ R ≥0 let V +  denote the clock valuation such that The set Φ() of clock constraints is generated by the following grammar: where  ranges over Φ(),   ∈ C,  is a real number, and ∼ ∈ {<, ≤, ≥, >}.We write V ⊨  when the valuation V satisfies the constraint .
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 (L,  0 , ∑, C, IV, , , Π), where (i) L is a finite set of locations and  0 is the initial location; (ii) ∑ is a set of actions that range over act; (iii) C is a finite set of clocks; (iv) IV: L  → Φ(C) is a function that assigns location to a formula, called a location invariant, that must hold at a given location; (v) : L  → 2 C is the set of clock resets to be performed at the given locations; →    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 (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   ≤ 8 ⊳ (‖  ‖  ), in which the clock   is reset, and this affects the invariant   ≤ 8. Further, in the parallel composition (‖  ‖  )|(  ≤ 8 ⊳    ) the clock variable   is the shared variable of the two processes; however, the reset of   affects the behavior of process (  ≤ 8) ⊳    .This is undesirable since the operational semantics of a process also depends on the behavior of the environment (which is hard to control).
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 V 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: 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   .

Operational Semantics. The formal semantics of 𝑐𝑟𝑦𝑝𝑡
follows the semantics of probabilistic timed automata.Namely, a state  is defined by the pair (  , V), where V is the clock valuation at the location with label   with the time issues defined at the location.The initial state  0 consists of the initial process and initial clock valuation ( 0  , V 0 ).Note that the initial process  0  is the initial status of a system behavior, while V 0 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  = (S, ∑ × R ≥0 × Π,  0 , →  , U, ), where (i) S is a set of states, and  0 is an initial state; (ii) →  ⊆ S×(∑ × R ≥0 )×Π×S 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 ( * , , ) ∈ ∑ ×R ≥0 ×Π 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) U ⊆ R ≥0 × S is the until predicate and is defined at a state  with a time duration ; whenever (, ) ∈ U we use the notation U  ; (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): 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, U are the smallest set satisfying the following rules: Rules (u1-u2) are the Until axioms for the states (, V) and ( * ≺    , V).In u3 the system stays in the state ( →   , V) until  time units if this is valid to the state (  , V) as well.Rules (u4-u5) come from the definition of the clock reset and invariant.In rule (u4) V[ :   ] represents the clock valuation V where the clocks in   are reset.Rules (u6-u8) say that the system stays until  time units at the state with  We define the satisfaction predicate ⊨, ⊨ ⊆ Φ(C), on clock constraints.For each  ∈ Φ(C) we use the shorthand ⊨ V() if and only if V satisfies , for all valuation V.The set of past closed constraint, Φ(C) ⊆ Φ(C), is used for defining semantics of location invariant, for all V ∈ V,  ∈ R ≥0 : ⊨ (V + )() ⇒ ⊨ (V)().Intuitively, this says that if the valuation V + , which is defined as V(  ) +  for all clocks   , satisfies the constraint  then so does V.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 Φ(C) and a set of clocks to be reset R(C), 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: In rule a2 V  = V[ :   ] +  and in the rest of the rules V  = V + .V[ :   ] represents the valuation V 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 (V + )() holds, which means that the valuation V +  must satisfy the clock guard .Rules a5-a6 describe the case when process  1   is activated (the rules for activating  2  are similar).() and (1 − ) in rules a7/a-b mean that in distribution  the first and second transitions (edges) are chosen with probabilities  and (1−).In a8, to avoid conflict of clock variables, we require that after performing the transition process  2  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 V 0 , PTTS(  , V 0 , ) 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  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 probtimed 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 that models all the information that is output so far by the process , which are  1 , . . .,   in this case.Definition 4 (static equivalence for extended processes (≈  )).Two extended processes  1 and  2 are statically equivalent, denoted as  1 ≈   2 , if their frames are statically equivalent.Two frames  1 and  2 are statically equivalent if they include the same number of active substitutions and the same domain, and any two terms that are equal in  1 are equal in  2 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.∑   on ⇒  is the sum of the time elapsed at each transition and represents the total time elapsed during the sequence of transitions.Note that ( 2  ) and ( 1  ) are the same as ( 2 ) and ( 1 ), respectively.Moreover, a process   is closed if its nontimed and "nonprobabilistic" counterpart  is closed.

Definition 5 (weak prob-timed labeled bisimulation for 𝑐𝑟𝑦𝑝𝑡
Intuitively, in case that  1  and  2  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  1   and  2  are statically equivalent; that is, the environment cannot distinguish the behavior of the two protocols based on their outputs; the second point says that  1  and  2  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 .

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    , 1 ≤  ≤ 3.For brevity we let   1-3 range over   from index 1 to index 3, and the same is true for   1-3 and   1-3 .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: We refer to the tuple of parameters (cntsq, s, d, apID,   1−3 , sID, earAtmp,   1−3 ,   1−3 , 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 1.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,  + 1, 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(s, d, apID,   1−3 , sID, earAtmp) 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.

𝐼𝑛𝑡(𝑒
ℎ(s, d, apID, sID, sq, ear, rtx, 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).

ISRN Sensor Networks 13
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(  −3 ), 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  (s, d, apID, sID, sq, ear, rtx,   1−3 ) ⊕   (s, d, apID, sID, sq, ear, rtx,   1−3 ) . ( 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 1 − .

Process That Models the Behavior of the Destination:
(  1−3 , ackNbr, nackNbr, toRTX1, nxtsq) 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: 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 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 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  V ,  V , and  V 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  V 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  V and  V 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  0 for signalling that the cache has been emptied and that the number of packets to be retransmitted is larger than 0, respectively.These additional channels are defined only for applying bisimilarities in the security proofs, but they do not affect the correctness of the protocol.
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 M  .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.

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 * /   () 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  ∈ {1,2,3}), where process checkEi corresponds to the th cache entry: 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 3, which means that the buffers of S and I are emptied, respectively.

Lemma 7.
With the defined attacker model M  , 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  1 , cannot be simulated with any corresponding trace in the ideal system.  → *    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.

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 ProtS-DTP(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 ISRN Sensor Networks 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 ProtS-DTP(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 M  .
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 -1--2.The trace describes the following scenario: 1 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 2, 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   ( V ); 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].

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]  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-thenelse, 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: ( 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 V ->  describes a process which performs V first and then behaves as .An event V can be a simple event or can be combined with assignments which update global variables as in the following example: V{ = +1; } -> , 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): 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.
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  ()   =  (  ; "per packet  "; ) ,  ()  = PRF (  ; "per packet  key"; ) .
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.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., 1) and the largest possible sequence numbers, respectively.The attackers can include earA ∈ {0, 1}, rtxA ∈ {0, 1} in their data packets.The attackers, in addition, possess the predefined values 1, . . ., 4 for requiring retransmission in NACK messages.
Process procA1(), which defines the behavior of the first attacker 1, is specified as an external choice among the following four activities (each of them is composed of additional choice options).
( We denote the attackers with this kind of behavior by M   .The SDTP protocol with the second topology is specified as the parallel compositions of each honest node and the attacker A1: SDTPA1 () = procS () ||| procA1 () ||| procI () ||| procD () . ( 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 S-I-A2-D, the scenarios and PAT codes are the same as in the case of the first topology S-A1-I-D 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 == 0 &&BufI == 0 && num  > 0), 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) M   , 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 1 and 2.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).
We run the PAT model checker with the attacker processes (see Algorithm 2).
As a result, the tool returned Valid for the assertions 5 and 6 along with the following trace.
(2) I stores this pck and forwards it (unchanged) to A2.
(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].

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 realtime, 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.
Process PR2: Reseting (Launching) Both the  and ACT Timers.Consider the following:

Figure 1 :
Figure 1: The difference between the real and ideal version of the DTSN and the SDTP protocols.
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( 1 , . . .,   ), which we abbreviate as ( 1 , . . .,   ).The function symbol with arity zero is a constant. ) be the function that increases the integer   by one.Numbers 1, 2, . .., are modelled by functions (0), (1),. .., respectively.The relation between these integers is defined by   < (  ) and   =   .
= , are the action and the time constraint defined on the edge and  is the set of the clocks to be reset at   ; {1, . .., }, where   () is the probability of an edge  according to distribution   and the sum of the edges from a given location  is 1. for location  0 .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; is the set of edges; we write  ,  →   when (, act, , ,   ) ∈ , where act, (iiv) Π = { 1 , . . .,   } is a finite set of probability distributions; each   is a function   :   → [0, 1] for any  = (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   * , 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;   → 1−  2 , where  1 and  2 correspond to  1  and  2  , 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.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 V(  ) and V(  ), respectively, are as follows.
1  [] 2  ,  1  | 2  , and  1  ⊕   2  if it stays  time in the state with one of the two processes  1  and  2  .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 .
The trace  1 describes the scenario where the source sends the first packet (sequence number 1) 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 1 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  2 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 1, requiring  to send an  or a .Let the series of silent transitions (), 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 0 sends/receives messages synchronously.A process is a relevant specification element in PAT that is defined as an equation (1, 2, . . ., ) = 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.
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.rtxcontains 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 ISRN Sensor Networks 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.