Formally Verifying Flow Properties in Industrial Systems

∗

Jannik Dreier

, Maxime Puys

, Marie-Laure Potet

, Pascal Lafourcade

and Jean-Louis Roch

Verimag, University Grenoble Alpes, Saint-Martin-d’Hères, France

LIMOS, University Clermont Auvergne, Campus des Cézeaux, Aubière, France

LORIA, University of Lorraine, INRIA, CNRS, France

Keywords:

Security Protocols, Industrial Systems, SCADA, Symbolic Model, Automated Veriﬁcation, Flow Integrity.

Abstract:

In contrast to other IT systems, industrial systems often do not only require classical properties like data

conﬁdentiality or authentication of the communication, but have special needs due to their interaction with

physical world. For example, the reordering or deletion of some commands sent to a machine can cause the

system to enter an unsafe state with potentially catastrophic effects. To prevent such attacks, the integrity of

the message ﬂow is necessary. We provide a formal deﬁnition of Flow Integrity. We apply our framework to

two well-known industrial protocols: OPC-UA and MODBUS. Using TAMARIN, a cryptographic protocol

veriﬁcation tool, we conﬁrm that most of the secure modes of these protocols ensure Flow Integrity given a

resilient network. However, we also identify a weakness in a supposedly secure version of MODBUS.

1 INTRODUCTION

Industrial systems are often used to monitor and con-

trol a physical process such as energy production and

distribution, water cleaning or transport systems. They

are often simply called Supervisory Control And Data

Acquisition (SCADA) systems. Due to their interac-

tion with the real world, the safety of these systems

is critical and any incident can potentially harm hu-

mans and the environment. Since the Stuxnet worm in

2010 (Langner, 2011), such systems increasingly face

cyberattacks caused by various intruders, including

terrorists or enemy governments. As the frequency

of such attacks is increasing, the security of SCADA

systems becomes a priority for governmental agencies,

e.g. (Stouffer et al., 2011) for the NIST or (ANSSI,

2012) for the ANSSI.

While security objectives for IT systems are usu-

ally conﬁdentiality, integrity and availability (CIA), in-

dustrial systems put a particular emphasis on integrity

and availability. One property required by such sys-

tems is that all sent commands are received in the same

order by the industrial machine, which is part of what

we call Flow Integrity. This property is crucial in in-

dustrial systems since most of commands require the

system to be in a speciﬁc state when they are launched.

For instance, if an electric device requires to be un-

∗

This work has been partially funded by the CNRS PEPS

SISC ASSI 2016.

powered to be manipulated, the shutdown command

must arrive before any manipulation command. In-

verting them could cause the device, along with its

environment, to be damaged.

Automated protocol veriﬁcation has been per-

formed during the past twenty years and multiple

efﬁcient tools such as ProVerif (Blanchet, 2001),

AVISPA (Armando et al., 2005), Scyther (Cremers,

2008) or TAMARIN (Meier et al., 2013) have been

developed. However, they focused on cryptographic

protocols for Internet such as TLS (Cremers et al.,

2016) or special applications such as electronic vot-

ing (Kremer and Ryan, 2005) or auctions (Dreier et al.,

2013). The Flow Integrity property differs from the

properties usually veriﬁed in these classical protocols.

For example, we want to ensure that messages are

delivered (a liveness property), which requires a re-

silient channel. As Internet is not resilient, resilient

channels are difﬁcult to model in most tools that were

designed to verify Internet protocols. Moreover, the

order of messages is ensured in most Internet protocols

as the messages have different formats, so reordering

the messages simply aborts the protocol. In the context

of industrial systems most of the protocols are used

to transport commands, meaning that the messages

always have the same format, rendering the ordering

crucial. In order to ensure the correct ordering of the

messages, most of the transport protocols including

industrial ones use timestamps, counters and sequence

Dreier, J., Puys, M., Potet, M-L., Lafourcade, P. and Roch, J-L.

Formally Verifying Flow Properties in Industrial Systems.

DOI: 10.5220/0006396500550066

In Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 4: SECRYPT, pages 55-66

ISBN: 978-989-758-259-2

numbers. These solutions are notoriously difﬁcult

to model and verify using actual tools due to some

theoretical limitations of the tools that often lead to

non-termination. In order to face these limitations,

we use the veriﬁcation tool TAMARIN (Meier et al.,

2013), that allows us to model counters and resilient

channels that can build on previous work concerning

the veriﬁcation of liveness properties (Backes et al.,

2017).

Contributions.

To the best of our knowledge, the

Flow Integrity property has not yet been formalized

in the context of industrial protocols. Hence, we have

two main contributions:

•

We provide a formal deﬁnition of Flow Integrity in

industrial control systems; a property that ensures

that all messages are received without alteration,

and in the same order as they were sent. We also

deﬁne weaker properties, including Non-injective

and Injective Message Authenticity, which ignore

the ordering of messages but ensure that all re-

ceived messages are unmodiﬁed (and cannot be

duplicated in the injective case). We also deﬁne

the corresponding Non-injective and Injective Mes-

sage Delivery properties, making sure that all mes-

sages are delivered (and in the injective case the

correct number of times).

•

We study Flow Integrity for two real industrial pro-

tocols: MODBUS and OPC-UA. Using TAMARIN,

we apply our framework to multiple versions of

these protocols and discover a weakness in a ver-

sion of MODBUS.

Outline.

In Section 2, we discuss related work. Then

in Section 3, we explain our deﬁnitions of the different

properties, and in Section 4 how we modeled these

properties with the TAMARIN prover. In Section 5,

we apply the veriﬁcation of our property to the MOD-

BUS and OPC-UA industrial protocols. Finally, we

conclude in Section 6.

2 RELATED WORK

The notion of integrity can vary a lot depending on the

context. A generic deﬁnition could state that integrity

is the maintenance and assurance of the accuracy and

consistency of some data over its life-cycle. For in-

stance, this notion has been applied in 1987, by Clark

and Wilson in (Clark and Wilson, 1987). They pro-

posed an access control model able to specify and ana-

lyze integrity policies. In such model, data alteration

is restricted to those authorized. In 1998 in a different

ﬁeld, Heintze et. al. (Heintze and Riecke, 1998) ana-

lyzed the consistency of the values of variables during

a program execution. Within their framework, they are

able to ensure properties relying on integrity such as

non-interference (i.e. the modiﬁcation of a variable

should not affect another). Again in a different ﬁeld, in

2005, Umezawa et. al. (Umezawa and Shimizu, 2005)

proposed a methodology to ensure that the description

of hardware components (such as VHDL code) re-

spects some temporal logic properties such as invalid

states for state machines or invalid values for coun-

ters. Their approach relies both on model-checking

and simulation.

In this paper, we studied the integrity of messages

exchanged over a potentially insecure network. Tradi-

tionally, message integrity is used to detect accidental

changes using error detection codes such as Cyclic

Redundancy Checks (CRC). However, such detection

codes do not protect against a malicious intruder since

he can easily recalculate CRCs of the messages he

changes. Similarly the TCP protocol protects against

an accidental reordering of messages, but not against

a malicious intruder that also modiﬁes the sequence

numbers used for this purpose. To guarantee message

integrity in presence of malicious intruders, crypto-

graphic primitives are needed, such as digital signa-

tures or Message Authentication Codes (MAC).

Early works concerning the security of indus-

trial protocols focused on discussing the security

properties supported or not by protocols. In 2004,

Clarke et. al. (Clarke et al., 2004) studied the security

of DNP3 (Distributed Network Protocol) and ICCP

(Inter-Control Center Communications Protocol). In

2005, Dzung et. al. (Dzung et al., 2005) surveyed the

security in SCADA systems including informal anal-

ysis on the security properties offered by various in-

dustrial protocols: OPC (Open Platform Communica-

tions), MMS (Manufacturing Message Speciﬁcation),

IEC 61850, ICCP and EtherNet/IP. In 2006, authors

of the technical documentation of OPC-UA (OPC Uni-

ﬁed Architecture) detailed the security measures of the

protocol. In 2015, Wanying et. al. (Wanying et al.,

2015) summarized the security offered by MODBUS,

DNP3 and OPC-UA. None of these works give any

formal proof of security properties on the protocols.

In more recent works, formal analyses started to

appear for industrial protocols. In (Patel and Yu,

2007) the authors proposed a formal veriﬁcation of

DNP3 using OFMC (Basin et al., 2003, Open-Source

Fixed-Point Model-Checker) and SPEAR II (Saul and

Hutchison, 1999, Security Protocol Engineering and

Analysis Resource). In (Dutertre, 2007), they de-

tailed formal speciﬁcations of MODBUS developed

using PVS, a generic theorem prover in order to help

proving the consistency of an implementation with

the standards. In (Fovino et al., 2009), the authors

proposed a secure version of MODBUS relying on

SECRYPT 2017 - 14th International Conference on Security and Cryptography

well-known cryptographic primitives such as RSA

and SHA2. In (Hayes and El-Khatib, 2013), they

designed another secure version of the MODBUS pro-

tocol using hash-based message authentication codes

and built on SCTP (Stream Transmission Control Pro-

tocol). In (Bratus et al., 2016), authors provided a

Deep-Packet Inspection tool to verify syntactic correct-

ness of DNP3 packets using the Hammer tool (Pat-

terson and Hirsch, 2014). In (Puys et al., 2016), the

authors formally veriﬁed secrecy and authentication

properties of OPC-UA handshake protocols using the

ProVerif tool (Blanchet, 2001). However, none of

these works formally deﬁne or verify Flow Integrity.

In general – outside industrial systems – for-

mal veriﬁcation of authentication properties (Lowe,

1997) is common. As shown by (Lafourcade and

Puys, 2015), this property is supported by many

tools such as AVISPA (Armando et al., 2005),

ProVerif (Blanchet, 2001), Scyther (Cremers, 2008)

and TAMARIN (Schmidt et al., 2012). However, our

deﬁnition of integrity goes beyond the usual authen-

tication properties, as we also consider the ordering

of the messages and ensure their delivery (a liveness

property), which is difﬁcult to express and verify in

most of these tools. We chose TAMARIN to build on

previous work (Backes et al., 2017) concerning the

modeling of resilient channels and the veriﬁcation of

liveness properties.

3 DEFINING AUTHENTICITY,

DELIVERY AND INTEGRITY

Notations.

In our deﬁnitions, we talk about sequences

of messages. Let

∗

denote the set of sequences over a

set

. For a sequence

, we write

for its

-th element,

|s|

for its length, and

idx(s) = {1,.. .,|s|}

for the set

of its indices. We use

[]

to denote the empty sequence,

,. . . ,s

]

to denote the sequence

of length

, and

s ·

to denote the concatenation of the sequences

and

We say that the sequence

.. . s

]

is a subchain of the

sequence

.. . r

]

if there exist sequences

,. . . ,z

such that:

· [s

] · z

· [s

] · . . . · [s

k−1

] · z

n−1

· [s

] · z

= [r

.. . r

]

We denote by

set(S)

the unordered set that con-

tains only once each element of the sequence

, and

multiset(S)

the unordered multiset that contains the

elements of

. To distinguish operations on multisets

from operations on sets we use the superscript

]

: for

example

∪

denotes set union, whereas

∪

]

denotes mul-

tiset union. We use regular set notation

{·}

for sets and

Note that z

can be the empty sequence.

multisets whenever it is clear from the context whether

it is a set or a multiset.

In our model, the messages consist of terms. Let

Fun

be a ﬁnite signature of functions of the set

Fun

and

be a set of variables,

Fun

(V )

denotes the set

of terms built using functions from

Fun

and vari-

ables from

. Unlike classical cryptographic proto-

cols, which are a ﬁnite sequences of messages, we

study transport protocols that aim at transporting com-

mands or data from a party to another, resulting in

potentially inﬁnite sequences of messages. We call the

transported commands the payload of the message, in

contrast to, e.g., protocol headers and other additional

values added by the protocol. To be able to identify

the payload inside a larger protocol message, we use

types. We assume that this part of the message is of

type

for data, and the rest of the message has other

types (e.g. H for hash or S for signatures).

Deﬁnitions & Intruder Model.

We suppose a set

of agents that exchange messages over a network

which can be (partly

) controlled by a Dolev-Yao in-

truder (Dolev and Yao, 1981). A classical Dolev-Yao

intruder has access to all messages on the public net-

work and can modify, inject, delete or delay them.

He is however limited by the cryptographic primitives

used: he can only decrypt a ciphertext or forge a sig-

nature if he knows the corresponding keys. This is

known as the perfect cryptography assumption.

We deﬁne Flow Integrity for the ﬂow of messages

between two agents

and

. More precisely, we

deﬁne the integrity of message payload, i.e., we only

aim at protecting the contents of the message, as this

is what is required by the applications in industrial

systems. This is modeled by syntactic subterms of

type

(for data) in the messages. We restrict our

integrity deﬁnitions to the payload only as we can

have false attacks otherwise. For example, consider

a protocol that sends each message together with a

signature on the message, and a random value. The

message cannot be modiﬁed due to the signature, but

the random value is unprotected. If we considered the

random value in our deﬁnitions the protocol would

not ensure any kind of integrity, although the payload

actually cannot be modiﬁed.

Deﬁnition 1.

Let

A,B,D

be the sequence that contains

the subterms of type

of all messages sent by agent

to agent

, and the sequence

A,B,D

contains the

subterms of type

of all messages received by agent

B from A.

For example, given a protocol that sends the mes-

sage

of type

together with its hash

h(m)

of type

The degree of control by the intruder will depend on the

type of network and the channel hypotheses.

Formally Verifying Flow Properties in Industrial Systems

A,B,D

only contains the messages, and not the hashes.

Since

might not only send messages to

but also to

another agent

, and

might receive messages from

and

, we deﬁne the ordered sequence of messages

that

sends to

, and the ordered sequence of mes-

sages that B received from A.

Note that we understand the notions of origin and

destination from the agents perspective, i.e., a message

is in

A,B,D

believes that it came from

. Simi-

larly, a message

that

wanted to send to

, but was

received by C, is still in S

A,B,D

We now deﬁne several notions of integrity, authen-

ticity and delivery. We have three levels of integrity,

authenticity and delivery, where at each level integrity

is deﬁned as the conjunction of the corresponding au-

thenticity and delivery properties. Intuitively, the au-

thenticity properties ensure that message have not be

altered during transmission, and the delivery properties

ensure that messages are not lost.

The ﬁrst notion of authenticity requires that all re-

ceived messages were sent by the sender, but messages

can be lost or duplicated.

Property 1.

A protocol ensures Non-Injective Mes-

sage Authenticity (NIMA) between sender

and re-

ceiver B for data D if set(R

A,B,D

) ⊆ set(S

A,B,D

It does only ensure that messages are unmodiﬁed,

but not that they are actually delivered. For this, we

deﬁne the corresponding delivery property.

Property 2.

A protocol ensures Non-Injective Mes-

sage Delivery (NIMD) between sender

and receiver

B for data D if set(R

A,B,D

) ⊇ set(S

A,B,D

Note that message delivery is difﬁcult to achieve

using an insecure asynchronous network such as In-

ternet, but industrial systems often use special (real-

time) networks with stronger channel guarantees such

as Parallel Redundancy Protocol (PRP) and High-

availability Seamless Redundancy (HSR) (IEC-62439,

2016). Taking the above properties together, we obtain

Non-Injective Message Integrity.

Property 3.

A protocol ensures Non-Injective Mes-

sage Integrity (NIMI) between sender

and receiver

B for data D if set(R

A,B,D

) = set(S

A,B,D

To ensure that messages cannot be duplicated, we

have Injective Message Authenticity and Injective Mes-

sage Delivery.

Property 4.

A protocol ensures Injective Message

Authenticity (IMA) between sender

and receiver

for data D if multiset(R

A,B,D

) ⊆ multiset(S

A,B,D

Property 5.

A protocol ensures Injective Message

Delivery (IMD) between sender

and receiver

for

data D if multiset(R

A,B,D

) ⊇ multiset(S

A,B,D

Both properties can be veriﬁed at the same time by

checking Injective Message Integrity.

Property 6.

A protocol ensures Injective Message

Integrity (IMI) between sender

and receiver

for

data D if multiset(R

A,B,D

) = multiset(S

A,B,D

Again it is easy to see that a protocol ensuring

Injective Message Integrity also ensures Injective Mes-

sage Delivery and Injective Message Authenticity, and

that vice versa a protocol ensuring Injective Message

Delivery and Injective Message Authenticity also en-

sures Injective Message Integrity.

Injective Message Integrity ensures that all mes-

sages are delivered, and not duplicated, but they can

still be reordered. This is prevented by Flow Authen-

ticity and Flow Delivery.

Property 7.

A protocol ensures Flow Authenticity

(FA) between sender

and receiver

for data

A,B,D

is a subchain of S

A,B,D

Property 8.

A protocol ensures Flow Delivery (FD)

between sender

and receiver

for data

A,B,D

is a subchain of R

A,B,D

Both properties can be veriﬁed at the same time

by checking Flow Integrity, which corresponds to the

property one would like to achieve in real systems.

Property 9.

A protocol ensures Flow Integrity (FI)

between sender

and receiver

for data

A,B,D

Again it is easy to see that a protocol ensuring

Flow Integrity also ensures Flow Delivery and Flow

Authenticity, and that vice versa a protocol ensuring

Flow Delivery and Flow Authenticity also ensures

Flow Integrity.

Note that a protocol ensuring Flow Integrity also

ensures Injective Message Integrity, and that a protocol

ensuring Injective Message Integrity also ensures Non-

Injective Message Integrity (and analogously for the

authenticity and delivery properties). This is summed

up in Figure 1.

FA)(FD

∧

IMA)(IMD

IMI

NIMA)(NIMD

NIMI

Figure 1: Relationship of our notions:

A ⇒ B

if a protocol

ensuring A also ensures B.

Moreover, if a protocol ensures either Flow Au-

thenticity and Injective Message Delivery, or Flow

Delivery and Injective Message Authenticity, this is

sufﬁcient to ensure Flow Integrity, as the following

Theorem 1 shows.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

Theorem 1.

A protocol that ensures Flow Delivery

and Injective Message Authenticity also ensures Flow

Integrity (

FD ∧ IMA ⇒ FI

). Similarly, a protocol that

ensures Flow Authenticity and Injective Message De-

livery, also ensures Flow Integrity (FA ∧ IMD ⇒ FI).

Proof.

Let

,. . . ,s

] = S

A,B,D

and

,. . . ,r

] =

A,B,D

. Suppose that a protocol ensures Flow Delivery

and Injective Message Authenticity, i.e. we have that

A,B,D

is a subchain of

A,B,D

, and

multiset(R

A,B,D

) ⊆

multiset(S

A,B,D

)

. Moreover, as any protocol ensuring

Flow Delivery also ensures Injective Message Deliv-

ery, we have

multiset(R

A,B,D

) ⊇ multiset(S

A,B,D

)

, and

thus multiset(R

A,B,D

) = multiset(S

A,B,D

This means that

n = m

, i.e. both sequences have

the same length. By the deﬁnition of subchains we

have that there exist sequences

,. . . ,z

such that

] · z

· . .. · z

n−1

· [s

] · z

= [r

.. . r

]

. As

n = m

, we

have that

,. . . ,s

] = [r

,. . . ,r

]

, which is what we

wanted to show.

The second proof is similar.

4 THE TAMARIN PROVER

We now recall the syntax and semantics of labeled

multiset rewriting rules, which constitute the input lan-

guage of the TAMARIN prover (Schmidt et al., 2012).

4.1 Introducing the TAMARIN Prover

In TAMARIN, equations are used to specify proper-

ties of functions, where an equation over the signa-

ture

Fun

is an unordered pair of terms

s,t ∈ T

Fun

(V )

written

s ' t

. An equational presentation is a pair

E = (Σ

Fun

;E)

of a signature

Fun

and a set of equa-

tions

. The corresponding equational theory

the smallest

Fun

-congruence containing all instances

of the equations in

. We often leave the signature

Fun

implicit and identify the equations

with the

equational presentation

. Similarly, we use

for

the equational theory

. We say that two terms

and

are equal modulo

iff

s =

. We use the subscript

to denote the usual operations on sets, sequences,

and multisets where equality is modulo

instead of

syntactic equality. For example, we write

∈

for set

membership modulo E.

Example 1.

To model MACs, let

Fun

be the signature

consisting of the functions

mac(·,·)

and

veri f y(·,·,·)

together with the equation

veri f y(mac(x,k),x, k) ' true.

In TAMARIN any system is modeled with multi-

set rewrite rules. These rules manipulate multisets

of facts which model the current state of the system,

with terms as arguments. Formally, given a signature

Fun

and a (disjoint) set of fact symbols

Fact

, we de-

ﬁne

Σ = Σ

Fun

∪ Σ

Fact

, and we deﬁne the set of facts

F = {F(t

,. . . ,t

)|t

∈ T

Fun

,F ∈ Σ

Fact

of arity n}

We assume that

Fact

is partitioned into linear and per-

sistent fact symbols; a fact

F(t

,. . . ,t

)

is called linear

if its function symbol

is linear, and persistent if

is persistent. Linear facts can only be consumed once,

whereas persistent facts can be consumed as often as

needed. In practice, messages and protocol state facts

are usually modeled as linear facts, whereas the in-

truder knowledge or, e.g. long term keys are stored

using persistent facts. Facts are said to be ground if

they only contain ground terms. We denote by

]

the

set of ﬁnite multisets built using facts from

, and by

]

the set of multisets of ground facts.

The system’s possible state transitions are mod-

eled by labeled multiset rewrite rules. A labeled

multiset rewrite rule is a tuple

(id, l, a,r)

, written

id : l−−[ a ]→r

, where

l, a, r ∈ F

]

and

id ∈ I

is a

unique identiﬁer. Given a rule

ri = id : l−−[ a ]→r

name(ri) = id

denotes its name,

prems(ri) = l

its

premises,

acts(ri) = a

its actions, and

concs(ri) = r

its conclusions. Finally, rules are said to be ground if

they only contain ground facts, and

ginsts(R)

denotes

the ground instances of a set

of multiset rewrite

rules,

lfacts(l)

is the multiset of all linear facts in

and

pfacts(l)

is the set of all persistent facts in

. We

use

mset(s)

to highlight that

is a multiset, and we use

set(s)

for the interpretation of

as a set, even if it is a

multiset.

The semantics of a set of multiset rewrite rules

are given by a labeled transition relation

→

⊆

]

× G

]

× G

]

, deﬁned by the transition rule:

ri = id : l−−[ a ]→r ∈

ginsts(P)lfacts(l) ⊆

]

Spfacts(l) ⊆ S

set(a)

−−−→

((S \

]

lfacts(l)) ∪

]

mset(r))

Note that the initial state of a labeled transition system

derived from multiset rewrite rules is the empty set

of facts

. Each transition transforms a multiset of

facts

into a new multiset of facts, according to the

rewrite rule used. Moreover each transition is labeled

by the actions

of the rule. These labels are used to

specify security properties as explained below. Since

we perform multiset rewriting modulo

, we use

∈

for the rule instance. As linear facts are consumed

upon rewriting, we use multiset inclusion, written

⊆

]

to check that all facts in

lfacts(l)

occur sufﬁciently of-

ten in

. For persistent facts, we only check that each

fact in

pfacts(l)

occurs in

. To obtain the successor

state, we remove the consumed linear facts and add

the generated facts. The actions associated to the tran-

sition contain the set of actions of the rule instance,

Formally Verifying Flow Properties in Industrial Systems

the identiﬁer of the rule, and the newly introduced

variables.

Example 2.

The following multiset rewrite rules de-

scribe a simple protocol that sends messages together

with a hash of the message. The ﬁrst rule describes the

agent

: he uses the key shared with

to send a fresh

message

. The second rule describes

: he re-

ceives a message together with its hash. Note that the

second rule can only be triggered if the input matches

the premise, i.e., if the hash is correctly computed.

Send_Message_A :

[Fr(m)]−−[ Sent(m) ]→[Out((m, h(m)))],

Receive_Message_B :

[In((m,h(m)))]−−[ Received(m) ]→[]

TAMARIN implements a Dolev-Yao intruder given

by the message deduction rules

below. The in-

truder can receive any message sent on the network,

send out any term he knows, create fresh values or

public values, and apply functions from the function

signature. This message deduction is considered mod-

ulo the equational theory.

MD = { Out(x)−−[]→K(x), K(x)−−[ K(x) ]→In(x),

Fr(x: fr)−−[]→K(x : fr), []−−[]→K(x : pub) }

∪ { K(x

),. . . ,K(x

)−−[]→K( f (x

,. . . ,x

))

| f ∈ Σ

Fun

with arity n }

Note that all messages on the public network transit via

the intruder, whose rules make the connection between

the Out and In facts in the protocol rules.

Moreover, in TAMARIN the

facts have a special

semantics. These facts can only be generated using

a special rule

FRESH : []−−[ Fr(x) ]→[Fr(x)]

, and each

instance of the rule generates a new fresh value, as

ensured by the following deﬁnition of the possible

executions.

Deﬁnition 2

(Executions)

Given a multiset rewriting

system R we deﬁne its set of executions as

exec

msr

(R) =

−→

.. .

−→

| ∀i, j ∈ N

,a.

i+1

) = Fr(a)

]

∧

j+1

) = Fr(a)

]

⇒ i = j

Our security properties will be expressed as prop-

erties on the traces associated to the executions. We

deﬁne the set of traces as follows.

Deﬁnition 3 (Traces). The set of traces is deﬁned as

traces

msr

(R) =

,. . . ,A

) | ∀ 0 ≤ i ≤ n.

=⇒

.. .

=⇒

∈ exec

msr

(R)

where

=⇒

is deﬁned as

−→

∗

−→

∗

for

A 6=

In TAMARIN, security properties are speciﬁed in an

expressive two-sorted ﬁrst-order logic over the actions

on the traces. In this logic, the sort

time

is used for

time points, and

time

are the temporal variables. The

other type

msg

for message is used for messages and

cryptographic terms.

Deﬁnition 4 (Trace formulas). A trace atom is either

false

⊥

, a term equality

≈ t

, a timepoint ordering

i l j

, a timepoint equality

= j

, or an action

F@i

for

a fact

F ∈ F

and a timepoint

. A trace formula is a

ﬁrst-order formula over trace atoms.

These trace formulas are used to specify the desired

security properties, and TAMARIN can then be used to

check whether all traces respect a property, or whether

there is an execution that violates a property.

Example 3.

Consider the multiset rewrite rules given

in Example 2. The following property speciﬁes that

any message received by B was previously sent by A:

∀i : time,m : msg.

Received(m)@i ⇒ (∃ j.Sent(m)@ j ∧ j l i)

For the formal deﬁnition of the semantics,

see (Schmidt et al., 2012).

4.2 Deﬁning our Security Properties

Using trace formulas we can specify all our proper-

ties in TAMARIN as follows. To make messages vis-

ible on the trace, we instrument the protocol rules

in TAMARIN with two actions,

Sent(A,B,m)

and

Received(A,B, m)

, where the ﬁrst one denotes that the

message

was sent by

, and

Received(A,B, m)

denotes that

received message

from

. Note that

here we only use the message payload, i.e.

is the

part of the protocol message that is of type

. Using

these actions, we can deﬁne Non-Injective Message

Authenticity in TAMARIN as follows.

Property 10.

A TAMARIN protocol model ensures

Non-Injective Message Authenticity (NIMA) between

sender

and receiver

for data

if the following

formula is satisﬁed on all traces:

∀i : time,A,B, m : msg.Received(A,B,m)@i

⇒ (∃ j.Sent(A, B, m)@ j ∧ j l i)

This deﬁnition captures precisely the deﬁnition

from Section 3: we require that any message

re-

ceived by

from

, i.e.

m ∈ set(R

A,B,D

)

, is included

set(S

A,B,D

)

, i.e. was sent by

. We can de-

ﬁne Non-Injective Message Delivery analogously by

interchanging the Sent and Received actions.

Property 11.

A TAMARIN protocol model ensures

Non-Injective Message Delivery (NIMD) between

SECRYPT 2017 - 14th International Conference on Security and Cryptography

sender

and receiver

for data

if the following

formula is satisﬁed on all traces:

∀i : time,A,B, m : msg.Sent(A,B, m)@i

⇒ (∃ j.Received(A, B, m)@ j ∧ i l j)

To verify Non-Injective Message Integrity we can

simply check whether both Non-Injective Message Au-

thenticity and Non-Injective Message Delivery hold.

To ensure injectivity, we have to ensure that a mes-

sage cannot be duplicated, which we express as fol-

lows.

Property 12.

A TAMARIN protocol model ensures

Injective Message Authenticity (IMA) between sender

and receiver

for data

if the following formula is

satisﬁed on all traces:

∀i :time, A,B,m : msg.Received(A,B, m)@i

⇒(∃ j.Sent(A, B, m)@ j ∧ j l i ∧ ¬(∃i2 : time,

A2,B2 : msg.Sent(A2, B2, m)@i2 ∧ ¬(i2

= i)))

This ensures that any received message was previ-

ously sent, and that there is not other time point where

the same message is received, thus capturing the in-

jectivity requirement

. The corresponding delivery

property deﬁnition is obtained easily by interchanging

the Sent and Received actions, as above.

Property 13.

A TAMARIN protocol model ensures

Injective Message Delivery (IMD) between sender

and receiver

for data

if the following formula is

satisﬁed on all traces:

∀i :time, A,B,m : msg.Sent(A, B,m)@i

⇒(∃ j.Received(A, B,m)@ j ∧ i l j

∧ ¬(∃i2 : time,A2,B2 : msg.

Received(A2,B2, m)@i2 ∧ ¬(i2

= i)))

To verify Injective Message Integrity, we simply

check both properties at the same time.

Flow Authenticity and Flow Delivery are expressed

in TAMARIN as follows: we ﬁrst verify that Injective

Message Authenticity or Injective Message Delivery

hold, respectively, and then check whether the order

of messages is preserved.

Property 14.

A TAMARIN protocol model ensures

Flow Authenticity (FA) between sender

and receiver

for data

if it ensures Injective Message Authen-

ticity and if the following formula is satisﬁed on all

traces:

∀i, j : time, A, B,m,m

: msg.

(Received(A,B, m)@i ∧ Received(A,B,m

)@ j ∧ i l j)

⇒ (∃k,l.Sent(A, B,m)@k ∧ Sent(A,B, m

)@l ∧ k l l)

We use unique fresh messages on the sender side to prevent

false attacks that would result from the same message being

sent twice and received twice.

Property 15.

A TAMARIN protocol model ensures

Flow Delivery (FD) between sender

and receiver

for data

if it ensures Injective Message Delivery and

if the following formula is satisﬁed on all traces:

∀i, j : time, A, B,m,m

: msg.

(Sent(A, B, m)@i ∧ Sent(A,B, m

)@ j ∧ i l j)

⇒ (∃k,l.Received(A,B,m)@k

∧ Received(A,B, m

)@l ∧ k l l)

Again, to verify Flow Integrity, we simply check

both properties at the same time.

4.3 Resilient Channels, Counters and

Timestamps

As noted above, delivery properties typically require a

resilient channel as an unrestricted Dolev-Yao intruder

can simply delete all messages and thus prevent any

message from arriving. We can model a resilient chan-

nel in TAMARIN by adding a restriction that enforces

that all messages are eventually delivered. A restric-

tion is a trace formula that TAMARIN will assume true,

i.e., it will discard all traces violating the restriction

when trying to prove a property.

To model a resilient channel, we add a new action

Ch_Sent(m)

to all rules that send out messages on the

resilient channel, and an action

Ch_Received(m)

to all

rules that receive messages from the resilient channel.

Note that here

is not only the payload of type

but the entire protocol message, and that we do not

include senders or recipients. Using these actions, we

can express the fact that the channel is resilient using

the following formula:

∀i :time, m : msg.Ch_Sent(m)@i

⇒ (∃ j.Ch_Received(m)@ j ∧ i l j)

Note that this restriction on the intruder’s capabilities

does not prevent him from delaying messages for a cer-

tain time, reordering or duplicating them, or injecting

new messages. This means that even when assuming

a resilient channel our security properties do not hold

vacuously.

We also use restrictions to model sequence num-

bers and timestamps. An intuitive way of modeling

sequence number in TAMARIN would be to use state

facts to implement a counter using a constant (e.g.

zero

) and a function (e.g.

inc(·)

). Consider a proto-

col that simply sends out a message together with its

counter:

Counter_Init : []−−[]→[Counter(zero)],

Send_Message : [Counter(n),Fr(m)]−−[]→

[Counter(inc(n)),Out((m,n))]

Formally Verifying Flow Properties in Industrial Systems

Such a model usually results in non-termination. When

TAMARIN tries to prove a property, it tries to ﬁnd a

counterexample using a backwards-search approach.

More precisely, it starts from the negation of the for-

mula, and tries to construct a valid execution by re-

solving the premises of all rule instances mentioned in

the formula until it either has found a counterexample

or a contradiction.

When analyzing the above counter model, resolv-

ing the ﬁrst premise of the

Send_Message

rule results

in two cases: either the premise is the conclusion of a

Counter_Init

rule, or it results from a

Send_Message

rule itself. In that case we need to resolve the same

premise again, and enter a loop.

Our solution to avoid this problem is to not model

the counter explicitly, but to let the intruder choose the

sequence number, while limiting his choice using a

restriction. Consider the rule

Send_Message :

[In(n),Fr(m)]−−[ Seq_Sent(A, B, n) ]→[Out((m,n))]

and the following restriction

∀i, j : time, A, B,seq

,seq

: msg.

(Seq_Sent(A, B, seq

)@i ∧ Seq_Sent(A,B, seq

)@ j

∧ i l j) ⇒ (∃di f .seq

≈ seq

+ di f )

where “

” is an associative and commutative inﬁx

operator provided by TAMARIN. Note that “

” does

not have any other associated equations and thus does

not exactly correspond to an addition of numbers. In

particular we do not have a neutral element

, so that

seq

+ 0 6= seq

. The restriction ensures that the term

representing the sequence number in any two subse-

quent messages increases by including a new term dif,

but without ﬁxing dif precisely. Although this abstrac-

tion allows jumps (for example increments by 2 or

more) in the sequence number which would not occur

in reality, it ﬁxes an order on the sequence numbers

which is sufﬁcient to prove the properties we are in-

terested in, as we will see in the case studies. Finally

timestamps can be modeled in the same way, which

means that the intruder controls the timing, but cannot

go back in time.

5 APPLICATIONS TO SCADA

PROTOCOLS

We verify the security of multiple variants of two in-

dustrial communication protocols (namely MODBUS

and OPC-UA) to check if they guarantee the proper-

ties we deﬁned in Section 3. The TAMARIN code is

available online

, all veriﬁcations where completed

http://indusprotoverif.forge.imag.fr/DPPLR17.tar.gz

on a standard laptop within a few minutes. As men-

tioned earlier, all protocols presented in this Section

are transport protocols which carry a request from a

client to a server (the responses from the server to the

client can be considered as another instance of the

same protocol) over a potentially asynchronous and

insecure network. We consider an unbounded number

of sessions of the protocol, where each session is an

arbitrary long sequence of messages.

5.1 MODBUS

Description.

MODBUS (MODBUS, 2004) is an in-

dustrial communication protocol designed by Modicon

(now Schneider Electric) in 1979. It has become one

of the most popular protocols in the domain and can

be used either on serial bus or on TCP communication.

We focus on the TCP version of the protocol, which

is nowadays more popular than the serial version. In

all MODBUS protocols, only the client is able to send

requests to which the server answers (meaning that the

server does never send a message on its own). In the

TCP version, the message includes a sequence number

in addition to the TCP sequence number. This number

is called a transaction identiﬁer and only increased

by one at each client request. Some other terms are

also part of the message, i.e. (i) a protocol identiﬁer

only used for compatibility with non-TCP versions, (ii)

the length of the message and (iii) the unit identiﬁer

which is used to dispatch the command to actuators

and sensors. Those three terms are public values that

do not impact the security of the protocol. We choose

to model them as single public header

. A generic

session of the protocol is displayed in Figure 2, where

is the transaction identiﬁer,

req

is a request from the

client and

resp

is the corresponding response from

the server.

Cli Srv

n, ph, req

n, ph, resp

n + 1, ph, req

n + 1, ph, resp

Figure 2: Two requests and responses in textbook MOD-

BUS (MODBUS, 2004).

The protocol relies on TCP to provide counter-

measures against network errors (e.g. checksums such

as CRC or LRC), and does not implement any pro-

tection against malicious adversaries. Thus anyone is

able to forge a fake message or modify an existing one,

SECRYPT 2017 - 14th International Conference on Security and Cryptography

allowing an adversary to run arbitrary commands on

servers. To avoid such attacks, two secure versions

were proposed. In (Fovino et al., 2009), the authors

proposed a version of MODBUS based on well-known

cryptographic primitives such as RSA and SHA2. Fig-

ure 3 presents the same session than in Figure 2 plus

the counter-measures proposed in (Fovino et al., 2009)

where ts

is the timestamp of the i-th message.

Cli Srv

, n, ph, req

, sign(h(ts

, n, ph, req

), skCli)

, n, ph, resp

, sign(h(ts

, n, ph, resp

), skSrv)

, n + 1, ph, req

, sign(h(ts

, n + 1, ph, req

), skCli)

, n + 1, ph, resp

, sign(h(ts

, n + 1, ph, resp

), skSrv)

Figure 3: Two requests and responses in secure MODBUS

from (Fovino et al., 2009).

In (Hayes and El-Khatib, 2013), they designed

another secure MODBUS protocol based on SCTP

(Stream Control Transmission Protocol). SCTP is a

transmission layer protocol as TCP and UDP which

provides protection against Denial-of-Service attacks.

However, like TCP it provides counter-measures

against network errors but none against malicious in-

truders. To avoid an adversary forging fake messages

or modifying existing ones, Hayes et. al. added mes-

sage authentication codes (MACs). Moreover, to avoid

replay attacks a nonce (called veriﬁcation tag) pro-

vided by SCTP is included in the MACs of the mes-

sages. Figure 4 details the session in Figure 2 plus the

counter-measures proposed in (Hayes and El-Khatib,

2013) with

the veriﬁcation tag of the SCTP session.

Cli Srv

vt, n, ph, req

, mac((vt, n, ph, req

), K)

vt, n, ph, resp

, mac((vt, n, ph, resp

), K)

vt, n + 1, ph, req

, mac((vt, n + 1, ph, req

), K)

vt, n + 1, ph, resp

, mac((vt, n + 1, ph, resp

), K)

Figure 4: Two requests and responses in secure MODBUS

from (Hayes and El-Khatib, 2013).

Security Analysis.

We modeled the three versions of

MODBUS described above and analyzed them with

TAMARIN to check if they satisfy the properties we

deﬁned in Section 3. We performed a ﬁrst analysis

assuming an insecure network, and the results are pre-

sented in Table 1.

TAMARIN ﬁnds attacks for all properties against

the standard version. This is not surprising since this

version of the protocol was not intended to provide

any security. However, the version with digital public

key signatures from (Fovino et al., 2009) is subject to

attacks since the identity of the receiver of the message

is not speciﬁed in the signature. Thus an intruder is

able to reroute a message to different recipient which

accepts the message, violating all of our properties.

This attack could be prevented by adding the receiver

inside the signature, or using a different public and

private key pair for each connection, which however

would be equivalent to using a symmetric authentica-

tion technique such as MACs, which is done in version

with MACs from (Hayes and El-Khatib, 2013). In this

version the attack is prevented since the symmetric

authentication keys are restricted to a speciﬁc session

between a speciﬁc client and a speciﬁc server. Thus if

an intruder changed the destination of a message, the

new recipient would not be able to verify the MAC.

This version of the protocol ensures all authenticity

properties, however it still fails on all delivery prop-

erties as the intruder can simply delete all message.

When assuming a resilient channel, it also ensures all

delivery properties (see Table 2). Note that even when

assuming a resilient channel the ﬁrst two variants do

still not ensure any property as messages are still not

guaranteed to be delivered at the right recipient, as in

the above attack.

5.2 OPC-UA

Description.

OPC-UA is one of the most recent in-

dustrial communication protocols, being released in

2006 (OPC Uniﬁed Architecture, 2012). It is devel-

oped by the OPC Foundation

, and is often referred to

as the next industrial communication standard. It is a

multi-level protocol, including transport and session

layers. The security layer implements key agreement

through a handshake. Then the client is invited to pro-

vide an authentication method such as a password or a

certiﬁcate using the generated key. The transport layer

consists in sending messages from the client to the

server using the security keys negotiated. A generic

session of the protocol is displayed in Figure 5 where:

• mh is a message header containing public values.

• sh

is a security header consisting of a fresh nonce

called security token.

• n

is a sequence number incremented for each re-

quest and response.

• rID

is the ID of the request to correctly associate

responses.

• req

(resp.

resp

) is the content of the request (resp.

response).

• pad is a padding if needed.

• mac(...) is a signature of everything above.

A consortium of the main stakeholders of the domain.

Formally Verifying Flow Properties in Industrial Systems

Table 1: Results for MODBUS assuming an insecure network.

Protocol NIMA IMA FA NIMD IMD FD

Standard MODBUS (MODBUS, 2004) UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE

MODBUS Sign (Fovino et al., 2009) UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE

MODBUS MAC (Hayes and El-Khatib, 2013) SAFE SAFE SAFE UNSAFE UNSAFE UNSAFE

Table 2: Results for MODBUS assuming an resilient channel.

Protocol NIMA IMA FA NIMD IMD FD

Standard MODBUS (MODBUS, 2004) UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE

MODBUS Sign (Fovino et al., 2009) UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE

MODBUS MAC (Hayes and El-Khatib, 2013) SAFE SAFE SAFE SAFE SAFE SAFE

Cli Srv

mh, sh, {n, rID

, req

, pad, mac((mh, sh, n, rID

, req

, pad), KSig

)}

mh, sh, {n + 1, rID

, resp

, pad, mac((mh, sh, n + 1, rID

, resp

, pad), KSig

)}

mh, sh, {n + 2, rID

, req

, pad, mac((mh, sh, n + 2, rID

, req

, pad), KSig

)}

mh, sh, {n + 3, rID

, resp

, pad, mac((mh, sh, n + 3, rID

, resp

, pad), KSig

)}

Figure 5: Two requests and responses in OPC-UA.

Only the sequence number, message body and sig-

natures sent encrypted.

Finally, three security modes exist in OPC-UA:

•

SignAndEncrypt (Figure 5): messages are signed

mac(m,K

Sig

)

and encrypted

{m}

, where

mac(·,·)

is a message authentication code func-

tion,

the symmetric encryption key shared

and

Sig

the symmetric signature key

shared by X and Y .

•

Sign: it is the same as SignAndEncrypt but

messages are only signed using

mac(m,K

Sig

)

and not encrypted. Thus message 1 (respec-

tively 2, 3, and 4) of Figure 5 becomes:

mh,sh, n, rID

,req

, pad,mac((mh,sh,n, rID

req

, pad),KSig

)

•

None: messages are neither signed nor encrypted

(mainly used for compatibility). Thus message 1

(respectively 2, 3, and 4) of Figure 5 becomes:

mh,sh, n, rID

,req

, pad

Security Analysis.

We model the transport layer of

OPC-UA presented in Figure 5 for the three security

modes (None, Sign and SignAndEncrypt). Results

for the case of an insecure network are presented in

Table 3.

TAMARIN ﬁnds attacks on the version with security

mode None. This is not surprising since this version

was not intended to not provide any security. However

both the Sign and SignAndEncrypt versions are safe

for all authenticity properties. This means that having

only the MACs added in the Sign version is enough to

guarantee Flow Authenticity. To also have the corre-

sponding delivery properties, we again need to assume

a resilient channel (see Table 4).

Out of curiosity, we also checked a variant of the

protocol with only symmetric encryption and no MAC

(thus not an ofﬁcial version). It appears that we ob-

tain the same results as for signatures. This is due to

the fact that the symmetric keys are only shared by

two participants and any message with its destination

changed would not be readable by its new recipient.

OPC-UA in case of bounded sequence numbers.

Until now we assumed sequence numbers to be un-

bounded integers from

. However, in reality machine

integers are obviously bounded and this can have an

impact on properties such as Flow Integrity. To evalu-

ate this impact, we tested a modeling of OPC-UA Sig-

nAndEncrypt (described in Figure 5) with explicitly

bounded sequence numbers (in our example we bound

it to four). This means that if a client sends four mes-

sages, then the fourth message has the same sequence

number as the ﬁrst one.

We checked the properties described in Section 3

on this version with TAMARIN and obtained the results

presented in Table 5: it turns out that Flow Integrity is

no longer veriﬁed. The attack works as follows: the

client sends out four messages, thus the fourth message

has the same sequence number as the ﬁrst one. The

intruder delays the ﬁrst three messages so that the

ﬁrst message received by the server is the forth with

sequence number zero. He then transmits the second

message which has a sequence number of one, and is

thus accepted by the server although it was actually

sent earlier than the message he accepted previously.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

Table 3: Results for OPC-UA (OPC Uniﬁed Architecture, 2012), assuming an insecure network.

Protocol NIMA IMA FA NIMD IMD FD

OPC-UA None UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE

OPC-UA Sign SAFE SAFE SAFE UNSAFE UNSAFE UNSAFE

OPC-UA SignAndEncrypt SAFE SAFE SAFE UNSAFE UNSAFE UNSAFE

Table 4: Results for OPC-UA (OPC Uniﬁed Architecture, 2012), assuming a resilient channel.

Protocol NIMA IMA FA NIMD IMD FD

OPC-UA None UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE UNSAFE

OPC-UA Sign SAFE SAFE SAFE SAFE SAFE SAFE

OPC-UA SignAndEncrypt SAFE SAFE SAFE SAFE SAFE SAFE

Table 5: Results for OPC-UA with bounded counters.

Protocol NIMA IMA FA NIMD IMD FD

OPC-UA SignAndEncrypt

with bounded numbers

Insecure Channel

SAFE SAFE UNSAFE UNSAFE UNSAFE UNSAFE

OPC-UA SignAndEncrypt

with bounded numbers

Secure Channel

SAFE SAFE SAFE SAFE SAFE SAFE

Interestingly the described attack disappears if we

assume a resilient channel. The server will accept

each sequence number only once

, and if we have two

messages with the same sequence number this leads to

a contradiction since both of them have to be received.

This however implies that each sequence number can

be used only once also on the client side, thus there

can be only a ﬁnite number of messages, bounded by

the range of the sequence numbers.

This analysis illustrates the need for a big range of

sequence numbers. If more messages than the range

of sequence numbers allows need to be exchanged,

one has to reinitialize the session (i.e., exchange new

keys) before running out of sequence numbers. This

is the solution adopted by OPC-UA: in (OPC Uni-

ﬁed Architecture, 2012, p. 36) it is stated that “A

SequenceNumber may not be reused for any TokenId.

The SecurityToken lifetime should be short enough

to ensure that this never happens [...]”. Our analysis

underlines the importance of this requirement.

6 CONCLUSION

We provided a formal deﬁnition of Flow Integrity and

other related properties in industrial systems. Flow

Integrity ensures that all messages are received with-

out alteration, and in the same order as they were sent.

Note that allowing a sequence number to be reused leads

to attacks on Injective Message Authenticity as the same

message can be accepted multiple times.

We checked Flow Integrity on multiple variants of

two real industrial protocols: MODBUS and OPC-UA.

Our analysis conﬁrms that most of the secure modes of

these protocol ensure Flow Integrity given a resilient

network. However, we also identiﬁed a weakness in a

supposedly secure version of MODBUS, due to an in-

sufﬁcient use of cryptography. Moreover, our analysis

of bounded sequence numbers highlighted the impor-

tance of the renewal of session keys to avoid the reuse

of sequence numbers. Unsurprisingly, the insecure

modes of these protocols did not ensure any of our se-

curity properties. Moreover it turns out that to ensure

delivery one has to assume a resilient channel, as the

intruder can otherwise always block messages. At the

same time, our results show that a resilient channel

alone is not sufﬁcient to ensure Flow Integrity: one

still needs to use cryptography to prevent the intruder

from rerouting or injecting messages.

In the future, we aim at testing this property on

real implementations to see if we can reproduce the

theoretical results. We would also like to study other in-

dustrial protocols such as DNP3 or IEC 61850. Finally

we are interested in formalizing properties similar to

Flow Integrity for protocols with encapsulation. Such

protocols permit for example to transfer MODBUS

packets through an OPC-UA channel. They are a real

challenge for formal veriﬁcation as there is few work

on protocol composition, and it has turned out that

verifying the composition is more complicated than

verify the protocols independently.

Formally Verifying Flow Properties in Industrial Systems

REFERENCES

ANSSI (2012). Managing cybersecurity for ICS.

Armando, A., Basin, D., Boichut, Y., Chevalier, Y., Com-

pagna, L., Cuellar, J., Drielsma, P. H., Heám, P.-C.,

Kouchnarenko, O., Mantovani, J., Mödersheim, S., von

Oheimb, D., R., M., Santiago, J., Turuani, M., Viganò,

L., and Vigneron, L. (2005). The AVISPA tool for the

automated validation of internet security protocols and

applications. In CAV’05.

Backes, M., Dreier, J., Kremer, S., and Künnemann, R.

(2017). A novel approach for reasoning about live-

ness in cryptographic protocols and its application to

fair exchange. In EuroS&P’17. To appear.

Basin, D., Mödersheim, S., and Viganò, L. (2003). An on-

the-ﬂy model-checker for security protocol analysis.

In ESORICS’03.

Blanchet, B. (2001). An efﬁcient cryptographic protocol

veriﬁer based on Prolog rules. In CSFW’01.

Bratus, S., Crain, A. J., Hallberg, S. M., Hirsch, D. P., Patter-

son, M. L., Koo, M., and Smith, S. W. (2016). Imple-

menting a vertically hardened dnp3 control stack for

power applications. In ICSS’16, pages 45–53.

Clark, D. D. and Wilson, D. R. (1987). A comparison of

commercial and military computer security policies. In

Security and Privacy, 1987 IEEE Symposium on, pages

184–184. IEEE.

Clarke, G. R., Reynders, D., and Wright, E. (2004). Practical

modern SCADA protocols: DNP3, 60870.5 and related

systems. Newnes.

Cremers, C. (2008). The Scyther Tool: Veriﬁcation, falsiﬁ-

cation, and analysis of security protocols. In CAV’08.

Cremers, C., Horvat, M., Scott, S., and van der Merwe, T.

(2016). Automated analysis and veriﬁcation of TLS

1.3: 0-rtt, resumption and delayed authentication. In

SP’16.

Dolev, D. and Yao, A. C. (1981). On the security of public

key protocols. Information Theory, IEEE Transactions

on, 29(2):198–208.

Dreier, J., Lafourcade, P., and Lakhnech, Y. (2013). Formal

veriﬁcation of e-auction protocols. In POST’13.

Dutertre, B. (2007). Formal modeling and analysis of the

MODBUS protocol. In Critical Infrastructure Protec-

tion, pages 189–204. Springer.

Dzung, D., Naedele, M., von Hoff, T., and Crevatin, M.

(2005). Security for industrial communication systems.

Proceedings of the IEEE, 93(6):1152–1177.

Fovino, I., Carcano, A., Masera, M., and Trombetta, A.

(2009). Design and implementation of a secure MOD-

BUS protocol. In IFIP AICT’09.

Hayes, G. and El-Khatib, K. (2013). Securing MODBUS

transactions using hash-based message authentication

codes and stream transmission control protocol. In

ICCIT’13.

Heintze, N. and Riecke, J. G. (1998). The slam calculus:

programming with secrecy and integrity. In POPL’98.

IEC-62439 (2016). Industrial communication networks -

High availability automation networks - Part 3: Paral-

lel Redundancy Protocol (PRP) and High-availability

Seamless Redundancy (HSR). International Elec-

trotechnical Commission.

Kremer, S. and Ryan, M. D. (2005). Analysis of an electronic

voting protocol in the applied pi-calculus. In ESOP’05.

Lafourcade, P. and Puys, M. (2015). Performance evalu-

ations of cryptographic protocols. veriﬁcation tools

dealing with algebraic properties. In FPS 2015.

Langner, R. (2011). Stuxnet: Dissecting a cyberwarfare

weapon. Security & Privacy, IEEE, 9(3):49–51.

Lowe, G. (1997). A hierarchy of authentication speciﬁca-

tions. In CSFW ’97.

Meier, S., Schmidt, B., Cremers, C., and Basin, D. (2013).

The TAMARIN prover for the symbolic analysis of

security protocols. In CAV’13.

MODBUS (2004). MODBUS IDA, MODBUS messaging

on TCP/IP implementation guide v1.0a.

OPC Uniﬁed Architecture (2012). Part 6: Mappings.

Patel, S. C. and Yu, Y. (2007). Analysis of SCADA security

models. International Management Review, 3(2):68.

Patterson, M. and Hirsch, D. (2014). Hammer parser genera-

tor. https://github.com/UpstandingHackers/hammer.

Puys, M., Potet, M., and Lafourcade, P. (2016). Formal

analysis of security properties on the OPC-UA SCADA

protocol. In SAFECOMP’16.

Saul, E. and Hutchison, A. (1999). SPEAR II – the security

protocol engineering and analysis resource.

Schmidt, B., Meier, S., Cremers, C., and Basin, D. (2012).

Automated analysis of difﬁe-hellman protocols and

advanced security properties. In CSF’12.

Stouffer, K., Falco, J., and Karen, S. (2011). Guide to

industrial control systems (ICS) security. NIST special

publication, 800(82):16–16.

Umezawa, Y. and Shimizu, T. (2005). A formal veriﬁcation

methodology for checking data integrity. In DATE’05.

Wanying, Q., Weimin, W., Surong, Z., and Yan, Z. (2015).

The study of security issues for the industrial control

systems communication protocols. JIMET’15.

SECRYPT 2017 - 14th International Conference on Security and Cryptography