1474 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 12, NO.
4, AUGUST 2016
Securing DNP3 Broadcast Communications
in SCADA Systems
Raphael Amoah, Member, IEEE, Seyit Camtepe, Member, IEEE, and Ernest Foo, Member, IEEE
Abstract—The Distributed Network Protocol version 3
(DNP3) provides Secure Authentication (DNP3-SA) as the
mechanism to authenticate unicast messages from a mas-
ter station to its outstations in supervisory control and data
acquisition systems. In large-scale systems, it may be nec-
essary to broadcast a critical request from a master sta-
tion to multiple outstations at once. The DNP3 protocol
standard describes the use of broadcast communication;
however, it does not specify its security. This paper is the
first to present DNP3 Secure Authentication for Broadcast
(DNP3-SAB), a new lightweight security scheme for broad-
cast mode communication. This scheme is based on hash
chain and only makes use of the existing cryptographic
primitives specified in DNP3-SA. The scheme integrates it-
self into the DNP3-SA key update process. The proposed
scheme is modeled, validated, and verified using colored
Petri Nets against the most common protocol attacks such
as modification, injection, and replay. Performance analy-
sis on our scheme and the existing DNP3-SA modes (NACR
and AGM) shows that DNP3-SAB reduces the communica-
tion overhead significantly at the cost of an increase with
a constant term in processing and storage overhead. This
benefit is maintained even when DNP3-SAB is under attack.
Index Terms—Colored Petri Nets (CPN), Distributed
Network Protocol version 3 (DNP3), Distributed Network
Protocol version 3 Secure Authentication (DNP3-SA), Dis-
tributed Network Protocol version 3 Secure Authentication
for Broadcast (DNP3-SAB), formal methods, supervisory
control and data acquisition (SCADA).
I. INTRODUCTION
UPERVISORY control and data acquisition (SCADA) sys-
S tems are predominant among the electricity grids, and the
emergence of smart grids systems is revolutionizing the energy
industry [13], [22]. Reports [15] and research [23] on SCADA
security have shown an increasing number of cyber incidents
and attacks targeting critical infrastructure that use SCADA
systems. These incidents and attacks are expected to increase
in number and severity because legacy SCADA systems and
protocols were not designed to work in insecure environments
such as the Internet.
A SCADA network is composed of various components that
range from hardware (IEDs, PLC, RTU) to standard protocols
Manuscript received August 08, 2015; revised April 28, 2016; accepted
June 25, 2016. Date of publication July 07, 2016; date of current version
August 04, 2016. Paper no. TII-16-0082. (Corresponding author: R.
Amoah.)
The authors are with the School of Electrical Engineering and
Computer Science, Queensland University of Technology, Brisbane,
QLD 4001, Australia (e-mail: r.amoah@qut.edu.au; seyit.camtepe@qut.
edu.au; e.foo@qut.edu.au).
Color versions of one or more of the figures in this paper are available
online at http://ieeexplore.ieee.org
Digital Object Identifier 10.1109/TII.2016.2587883
1551-3203 © 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications standards/publications/rights/index.html for more information.
such as Profinet [27] and Modbus [24]. The Distributed Network
Protocol version 3 (DNP3) [16] is one of the standard engineer-
ing protocols for SCADA systems. It is designed to mainly
facilitate interactions between outstations and their master sta-
tions in an interconnected SCADA network. The DNP3 proto-
col supports multidrop and the data concentrator architectures,
through which large numbers of outstations and master stations
from multiple sites can concurrently interact. These types of
large-scale DNP3 deployments are mainly used for power grid
automation. The DNP3 protocol provides a security mechanism
called secure authentication (DNP3-SA) [11]. This is primarily
a unilateral keyed-hash message authentication code (HMAC)
mechanism used to secure DNP3 messages. DNP3 is one of the
first standardized SCADA protocols that attempt to provide a
security mechanism.
In [3] and [4], Amoah, Suriadi, Camtepe, and Foo presented
formal analysis of DNP3-SA using CPN. The authors con-
structed models to analyze each of the DNP3-SA operational
modes. Each security analysis of the models was primarily
limited to unicast communication: one master station and one
outstation. Unicast communication is one of the two communi-
cation modes supported by the DNP3 protocol [9, p. 70].
This paper focuses on DNP3 broadcast mode, which is the
second of the communication modes supported by the DNP3
protocol. DNP3 broadcast communication allows a master sta-
tion to simultaneously communicate with multiple outstations
with a single command. One of the advantages of this mode
is that it reduces delay and overhead in large-scale systems.
Broadcast is an important feature for cases of emergencies. For
example, an emergency shut-down of stations may be required
to be broadcast due to an electrical incident. The DNP3 broad-
cast mode does not have any security mechanism described in
the protocol specification. This gap in the protocol can lead
to devastating problems. For example, an attacker who has ac-
cess to the network may modify commands or execute unau-
thorized commands simultaneously on multiple outstations to
interrupt services.
Hence, the contribution of this paper is twofold. First, we
present a new security scheme for DNP3 broadcast mode called
Secure Authentication for Broadcast (SAB). Our scheme se-
cures DNP3 broadcast through the use of a one-way hash func-
tion (hash chain) that can only be generated and distributed by
the master station and not by any of the outstations. The out-
stations verify the parameters provided by the master station by
using initial predistributed credentials. To our knowledge, this
is the first proposal for DNP3 broadcast authentication. SAB
extends the DNP3-SA protocol by reusing its existing crypto-
graphic primitives with the hash chain such that it does not
require a major upgrade in existing platforms.
AMOAH et al.: SECURING DNP3 BROADCAST COMMUNICATIONS IN SCADA SYSTEMS
The second contribution of this paper uses colored Petri Nets
(CPN) to create an executable DNP3-SAB model and formally
analyze the security behavior of our scheme. CPNs [20] are
a widely used formalism for designs, specifications, simula-
tions, and verifications. Its application in various domains such
as security protocols [2], [28] have proven to be trustworthy
and reliable. This paper uses CPN because it has the ability to
conveniently express characteristics such as concurrency, data
distribution, asynchronous, and nondeterministic features that
are inherent in various communication and security protocols.
As the DNP3 broadcast mode involves a master station inter-
acting with multiple outstations, the use of CPN’s hierarchical
structure and parameterization technique become an important
requirement. This is because the hierarchical structure supports
a modular approach for modeling, where the behavior of large
systems can be captured at different levels of abstraction. The
parameterization technique enables a number of attacks to be
captured for analysis as part of the SAB model without the need
to create a new model. By using this CPN tool, we show that
our proposed scheme (the SAB CPN model) provides DNP3
broadcast authentication. We also show that our scheme re-
duces communication overhead at the cost of a minor increase
in processing and storage overhead.
This paper is organized as follows. Section II presents the
related work. Section III presents the overview of the DNP3-SA
protocol. Section IV presents the proposed DNP3-SAB scheme.
The CPN modeling of DNP3-SAB and its approach are pre-
sented in Section V. The CPN model description is presented
in Section VI. The formal analysis of DNP3-SAB CPN model
using state-space tool is presented and discussed in Section VII.
The performance analysis is presented in Section VIII. Finally,
Section IX presents the discussions and conclusion of this paper.
II. RELATED WORK
Many of the security flaws found in SCADA are associated
with the communication protocols used in control systems. This
is because SCADA protocols were not designed with a security
mindset. For instance, in 2004, Byres, Franz, and Miller [5]
presented the use of attack trees in assessing flaws in the Mod-
bus protocol. The authors showed how to identify and com-
promise a Modbus device to execute arbitrary requests. Later,
in 2008, Huitsing, Chandia, Papa, and Shenoi [14] presented
an attack taxonomy on the Modbus protocol, where some of
the attacks could be used to exploit Modbus’s assets (serial
and TCP) in various ways. In the subsequent year (2009), East,
Butts, Papa, and Shenoi [10] presented a taxonomy of attacks
on the DNP3 protocol before DNP3-SA was adapted from IEC
62351 [17]. Moreover, in the same year (2009), Akerberg and
Bjorkman [1] explored flaws in the Profinet protocol. Similarly,
in 2011, Cheminod, Pironti, and Sisto [6] presented a formal
vulnerability analysis of the Fieldbus access protocol, where
they presented flaws of the protocol that might be susceptible to
potential replay attacks. In 2014 and 2015, respectively, Amoah,
Suriadi, Camtepe, and Foo [3], [4] presented formal analyses of
the DNP3-SA protocol using the CPNTools [18], where the
authors also presented new flaws in the DNP3-SA protocol.
1475
Many of the standardized SCADA protocols support differ-
ent types of communication modes; however, traditional secu-
rity solutions and SCADA security proposals are mostly limited
to unicast. This paper focuses on security of DNP3 broadcast
communication. Broadcast communication and its security have
gained wide attention in the sensor network domain. Some of
the solutions from sensor networks have been adapted to secure
various communication modes in SCADA systems. Relevant to
the topic of this paper, Choi, Kim, Won, and Kim proposed an
advanced key-management architecture for unicast and broad-
cast communications in SCADA systems [7]. The proposed
scheme is extended to an efficient secure group communication
scheme in SCADA systems [8]. Later, in [21], it has been shown
that solutions by Choi, Kim, Won, and Kim are only feasible
with the aid of trusted entities that facilitates key establishment
between SCADA entities. Though these schemes prove promis-
ing, they are constrained with availability issues. Each trusted
entity forms a single point of failure, meaning that failure of
even one trusted entity may threaten continuity of the whole
security process.
These schemes cannot be directly applied to DNP3 and
other SCADA protocols. This is due to their specific archi-
tecture and application limitations. Moreover, existing devices
with DNP3 capabilities have limited support for cryptographic
methods (i.e., SHA-1-HMAC, SHA-256-HMAC, AES-GMAC,
and AES-128 key wrap) due to their resource limitations. This
requires the proposed SAB solution to be compliant to these
cryptographic methods only.
Identifying the gap of missing authentication for DNP3 broad-
cast communication, this paper employs the hash-chain concept
from the TESLA protocol [25] (Timed Efficient Stream Loss-
tolerant Authentication) to secure DNP3 broadcast messages in
SCADA systems. TESLA is a broadcast authentication protocol
that uses hash chains and time-delayed key disclosure. TESLA
generates a key chain by using the relation of H(Ski ) = Ski−1 .
Sender uses Ski to authenticate a broadcast message Mti sent
at time interval ti . The broadcast message also includes the
key used in the previous time interval (i.e., Mti ||Ski−1 ). That
means, the key Ski will be disclosed along with a message in
the coming time intervals, e.g., time interval ti+1 , and the mes-
sage Mti must be stored until then. Disclosed key Ski can then
be used to authenticate the stored message Mti . Moreover, the
disclosed key Ski can be checked for its validity using its re-
lation with the keys disclosed earlier (e.g., H(Ski ) = Ski−1 or
H(H(Ski )) = Ski−2 ). TESLA is considered secure because it
allows all receivers of a given broadcast or multicast message
to verify its integrity and authenticity. Moreover, it is consid-
ered efficient because of its low communication and computa-
tional overheads. It scales well on a large number of receivers.
However, these benefits of TESLA come at the cost of storage
overhead because received messages must be stored until the
relevant keys are disclosed and validated.
TESLA and its derivatives [26] cannot be directly applied
to the DNP3 protocol due to their domain differences and the
nature of the DNP3 protocol. That is, TESLA and its derivatives
depend on time synchronization and the revelation of keys. Ad-
ditionally, TESLA authenticates its initial packet with a digi-
tal signature, which can be seen as costly for SCADA systems
1476 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 12, NO. 4, AUGUST 2016
Fig. 1. DNP3-SA NACR operation.
because SCADA devices are constrained with processing power.
Though time is a crucial factor in SCADA systems, our approach
to secure SCADA systems using the DNP3 protocol does not de-
pend on strict time synchronization as TESLA does. Moreover,
DNP3 provides an authentication scheme for unicast commu-
nication (DNP3-SA) that makes use of certain cryptographic
primitives and has a user and key management scheme that up-
dates keys regularly after a certain period of time (say minutes up
to weeks depending on the rate of communication) [16]. Hence,
this paper presents a broadcast authentication scheme based on
hash chains and message authentication codes (MACs) which
integrates with the existing user and key management scheme
of DNP3-SA without needing any major upgrade. Addition-
ally, this paper presents a CPN model to validate and verify the
security behavior of SAB with adversarial settings.
III. OVERVIEW OF THE DNP3-SA PROTOCOL
DNP3 is a layered and nonproprietary protocol, which is de-
signed to facilitate communication between master stations and
outstations via serial-line or TCP/IP protocols through encapsu-
lation. DNP3-SA is the embedded security mechanism in the ap-
plication layer of the DNP3 protocol. Primarily, DNP3-SA uses
an HMAC mechanism with a secret key, k (i.e., 128 bits) to au-
thenticate critical messages transmitted between interconnected
stations. A critical DNP3 message can either be a request from
a master station or an unsolicited response from an outstation
that contains a mandatory code. A mandatory code is defined
as any code that can control stations or set crucial parameters
such as power grid voltages and frequencies. This implies that
any station that sends a message which includes any manda-
tory code will be challenged by the receiving device to prove
its identity. Authentication in DNP3-SA is unilateral, but the
mechanism operates in two different modes: two-pass authen-
tication (NACR) and one-pass authentication (AGM) through
the HMAC. However, the AGM operation is also dependent on
NACR. This means that AGM can only be in-use if there has
been one or more occurrences of NACR operations. This behav-
ior enables the AGM to make use of “the most recent challenge
message” from the NACR operation.
An in-depth view of the protocol is provided later in
Section IV (i.e., when providing the SAB scheme). But to facil-
itate the understanding of the protocol, the operation of NACR
and AGM are presented in Figs. 1 and 2, respectively. It is
important to note that in these figures, it is assumed that ses-
sion key, Skm o , for each user have been securely established
between the master station and the outstation (this will further
be explained in Section IV). In Fig. 1, it is depicted that the
Fig. 2. DNP3-SA AGM operation.
master station sends a request to an outstation. At the receipt of
the message, the outstation sends a challenge message, which
contains an algorithm (H), nonce (P ), and a challenge sequence
number (KSn) to the master. The master uses the H algorithm
from the challenge received and the shared-key (Skm o ) on the
entire challenge data together with the request to create a MAC
tag. The MAC tag is then sent to the outstation. On receiving
the MAC tag, the outstation calculates its MAC tag by using the
same computational approach and elements used by the master
station. A match in the tags indicates an authentication success
and leads to execution of the request. Otherwise, the outsta-
tion discards the request and sends an error message to the
master station.
In Fig. 2, a number of challenge–response messages are elim-
inated. It is assumed that the master station has the “most recent
challenge message” from the most recent NACR operation. Tak-
ing the most recent challenge message into account, the master
is always required to increase KSn from the challenge by 1 for
all AGM operations before a legitimate AGM message can be
composed. Fig. 2 depicts the master station sending an AGM
message to the outstation. The AGM message consists of a re-
quest and a MAC tag. The MAC tag is computed by using
the algorithm (H), the session key (Skm o ), the “most recent
challenge message,” and the request. On receipt of the AGM
message, the outstation temporarily stores the MAC tag, ex-
tracts relevant data, computes its own tag, and verifies if the
tags match. A successful verification will lead to processing
the request and replying with a response message. A failed
verification will lead to an error message.
IV. SECURE AUTHENTICATION FOR BROADCAST
The DNP3-SA protocol works well under unicast commu-
nication, but it cannot be applied to broadcast communication.
This is because as DNP3-SA uses the challenge–response ap-
proach, the master station will need to store, remember, and
exchange a number of challenges and response messages with
each outstation. This is not practical because there will be de-
lays and an increase in communication, processing, and storage
overheads. However, in the absence of an appropriate broadcast
authentication mechanism, it is possible for an attacker to broad-
cast unauthorized commands to be performed by all outstations
at once. This leads us to design a new security scheme, SAB, to
secure broadcast mode communication. A detailed description
of SAB is presented in Fig. 3.
A. Overview of SAB
The concept of SAB is derived from the TESLA protocol
presented by Perrig, Canetti, Tygar, and Song [25]. SAB is a
AMOAH et al.: SECURING DNP3 BROADCAST COMMUNICATIONS IN SCADA SYSTEMS
Fig. 3. New security scheme for broadcast mode communication.
minimalist broadcast authentication protocol designed only to
use existing cryptographic primitives of DNP3-SA (i.e., SHA-
1-HMAC, SHA-256-HMAC, AES-GMAC, and AES-128 key
wrap) so that existing DNP3 devices can be made compati-
ble with minimal software upgrades. Intuitively, SAB operates
through a hash chain, which is a linked hash values known to
master station only. Using the predistributed credentials, the
outstations can only verify the current hash value released with
the current broadcast message, but they cannot produce the hash
value before it is released. Limiting this feature to only the mas-
ter station implies that broadcast messages are generated by the
master station and they are correct. This, therefore, effectively
secures DNP3 broadcast communication against modification,
spoofing, replay, and injection attacks. This approach is better
than some existing schemes because our scheme solves the key
management problem associated with the HMAC mechanism.
Thus, instead of the HMAC mechanism using different keys for
each broadcast message, our scheme uses a hash chain with a
1477
single symmetric key. Moreover, our scheme is not constrained
by time like other schemes based on TESLA and most of its
derivatives. Moreover, SAB does not require infrastructure like
a public key infrastructure (PKI), where processor intensive
algorithms like RSA are used. A comparison of performance
and functionality of SAB using other alternative methods is
presented in Section VIII.
B. Operation Details of SAB
Fig. 3 presents the detailed behavior of SAB. To under-
stand the table, the following notations are worth noting. Mas-
ter Station and Outstations represent the communicating enti-

ties. Skm o and Skm o , respectively, represent the old and new
session keys of a particular user, which are used to provide
entity authentication for the data transmitted in the control di-
rection (i.e., from master to outstations). Both session keys
are derived from the long-term secret key, U pK. U pK is
1478
traditionally manually distributed to all the entities in the con-
trol system. R is a random bit-string with sufficient length, such
as 128 bits, to prevent trivial preimage attacks. H represents
the hash function and is used to compute the hash-chain tags:
S1 = H(R), S2 = H(S1 ), . . . , Sn = H(Sn − 1), which repre-
sent hash-chain tags that are produced from a single random
value (R). Sn represents the last hash tag of the hash chain,

while n represents the index of Sn . KS and KS represent
challenge messages that contain old and new challenge data,
respectively. Each challenge contains a key change sequence
number KSn, MAC algorithm H, and a Nonce P . E and D
represent symmetric key encryption and decryption schemes,
respectively, agreed between all the entities. C (ciphertext) rep-

resents encrypted (Skm o , Sn , n). M ACS k m o and M ACS k m
represent agreed MAC schemes with keys. tag and tagA repre-
sent MAC tags generated by the master station, while tag  and
tagA represent MAC tags generated by outstations. KSR repre-
sents a request (F C)R eq that contains a user’s key change data.
KC represents the concatenated ciphertext C and the MAC tag
tag. KSC represents a response that contains the status of the
user’s key update (F C)R esp and a new challenge message KS  .
BM represents a broadcast message that contains a request
(F C, OH)R eq , a hash tag Si , the index of the hash tag i, and
the MAC tag tagA . ErrorResp represents an error response.
UI D represents a user identification number associated with
the communicating entities. Sstored , Nstored , Sreceived , and
Nreceived store value from Sn , n, Si , and i (where 1 ≤ i < n),
respectively. Scalc is the variable used to calculate the next hash
tag of the hash chain. In this scenario, it is assumed that the
necessary algorithms and session key, Skm o are preestablished
between M and O, but the session key is outdated. Therefore,
M wishes to update the old session key to a new key. But before
M updates the key, it is required that M precreates a hash chain
for future broadcast communication. In creating the chain, M
is required to choose an arbitrary number R (let us say 128
bits) and creates a series of hash tag values using hash chains
as illustrated in step 1 of Fig. 3. After creating the chain, M
can now send a key status request, KSR, to all O to update the
session key of a particular user (step 2). At the receipt of KSR,
all O reply with key status message, KS, which contains the
challenge data (H, P , and KSn, from step 3). At the receipt
of KS, M uses the preshared key, U pK, to encrypt the new

session key, Skm o , and the last hash tag of the hash chains, Sn ,
together with associated its index, n (step 4). Furthermore, M
uses H from KS, and the existing (old) session key, Skm o , to
keyed-hash KS and KSR in order to compute the MAC tag,
tag (step 5). Then, M sends KC, which contains ciphertext,
C, and the MAC tag, tag, to all O (step 6). On receipt of the
message, all O first compute their MAC tag tag  by using the
same computational elements used by M and then checks if the
tags match (step 7). If the tags match, then all O performs the
second action by decrypting KC using U pK and storing the

contents (Skm o , Sn , and n refer to step 8). At this point, all O
can respond to M with KSC to indicate that the new session

key (Skm o ), as well as the last hash tag value of the chain and
its index are stored (step 9). Furthermore, KSC also includes
a new challenge message, KS  , that M uses to reauthenticate
itself to all O in case a new key and hash updates (new hash
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 12, NO. 4, AUGUST 2016
chain) are required (steps 1–9). It is worth noting that KS  is a
variable of the DNP3-SA protocol and it is used for challenging
the master station in the DNP3-SA protocol. KS  is not used
in SAB, but it is maintained for compatibility reasons with the
DNP3-SA protocol. Analysis of the DNP3-SA protocol can be
found elsewhere [3]. At this point, it is important to note that all
stations (M and all O) are now set to communicate with normal
DNP3 messages.
In the part labeled Continuation of New Scheme, we make
use of the AGM behavior, as explained in Section III. That is,
before any broadcast message can be sent, M must first compute
a MAC tag based. Computation of the MAC tag is based on the
request about to be sent, a hash tag from the hash chain and the
o
index value associated with the tag. It is to be noted that the index
is always linked to a particular hash value chosen. In computing
tagA , M uses the agreed MAC scheme with the recent estab-
lished key, Skm 
o , on the message (Si , i, (F C, OH)R eq , UI D ).
After tagA is obtained, M sends BM (broadcast message),
which constitutes (Si , i, (F C, OH)R eq , UI D ) and tagA to all
O. On the receipt of the message, all O first check if i associ-
ated with hash tag, Si is valid (nonnegative value), and i is less
than what is previously stored (Sstored ). There are two main
reasons why this action (i checking) is required: 1) to prevent
potential replay attacks of a previously recorded message with
a valid MAC tag; and 2) to take into consideration subsequent
rounds of authentication for legitimate broadcast messages is-
sued by the master station. For the replay attack, assuming i is
valid, then all O will continue to perform a MAC tag verification
for message authentication (line 13); otherwise, the operation is
aborted. In checking for message authentication, all O compute
tagA and verify them against tagA received from the master.
A match implies success, which further leads all O to check
for freshness (the status of hash tag received, line 14) before
the broadcast request can be processed. In checking the hash
tag, all O use i (Nreceived ) to determine the number of hash
iterations that must be performed on Si to obtain the final hash
tag result, Scalc . Scalc is then compared with the stored hash
tag, SStored . If the hash tags match, then, Scalc is stored as
the new hash tag value (SStored ), and the broadcast request
(BM [(F C, OH)R eq ]) is processed. However, if the tags do not
match, then Scalc is discarded and an error response is sent to
M . This action or behavior applies to multiple rounds of au-
thentication within SAB. Thus, since every hash tag is linked
to an index, it implies that every broadcast message will have
a unique hash tag and its associated index for every round of
authentication required. Therefore, for all rounds of authenti-
cation if the indexes are not valid, the outstations will respond
with error messages just as before in the replay attack. But, if the
indexes are valid in each round, then the outstations are required
to perform the MAC tag verification (line 13). If the MAC tags
verification do not match for each round, the outstations will
respond with error messages or abort the operation. Otherwise,
the outstations will continue to verify the status of all hash tags
for each round (line 14) before the broadcast request can be
further processed. A successful hash tag verification in each of
the rounds will lead to discarding the old hash tag and storing
the new hash and processing the broadcast request as expected.
But failures in each round will lead to an error message.
AMOAH et al.: SECURING DNP3 BROADCAST COMMUNICATIONS IN SCADA SYSTEMS
V. CPN MODELING OF THE DNP3-SAB PROTOCOL
A CPN model is a bipartite graph that comprises of two forms
of nodes, places (drawn as ellipses) and transitions (drawn as
rectangles), and directed edges that are known as arcs that con-
nect places to transitions. The places and transitions respectively
represent states and events in a given model. They are associated
with color sets (simple and compound color sets) that enable a
place to store data (token(s)). Simple color sets are made of data
types such as string, integer, and boolean values. Compound
color sets (product, record, and union) are color sets that are
constructed on simple colored sets. For example, colset Eg
= product string ∗ integer. The distribution of a to-
ken from one place to another through a transition represents
a state change. As previously, we use the CPN tool mainly be-
cause of its ability to conveniently express characteristics such as
concurrency, parallel, data distribution, asynchronous, and non-
deterministic features that are inherent in many systems. With
such abilities, different level of abstractions of the protocol can
be captured in order to validate and verify the correctness of our
scheme. In addition, essential security primitives and behav-
iors of SAB can be captured and represented as “black-boxes”
through the CPN functional programming language Standard
ML (SML) [12]. This is because SML creates the flexibility
to virtually capture different types of data or cryptographic pa-
rameters for various types of operations. The effectiveness of
CPN is also supported by the embedded state-space tool [19],
which can be used to perform validation and verification analy-
sis through a summary report that is provided after the execution
of the CPN model.
A. Our CPN Modeling Approach
To understand the CPN formalism, this section presents spe-
cific processes involved in modeling the DNP3 broadcast pro-
tocol with SAB. These processes are useful for representing
various data such as requests and responses, cryptographic
primitives, and operations as well as other behaviors such as
adversaries. The processes include three steps.
1) Protocol primitives abstraction: This approach is used
to capture various data such as requests and responses
and security primitives (cryptographic keys, MAC tags,
hashes) from the DNP3-SAB protocol. In capturing these
primitives and behaviors in CPN, we needed to first repre-
sent data as CPN color sets and then address their opera-
tions by using CPN SML functions. As previously stated,
color sets (both simple and compound) are made of data
types. Therefore, representing data (requests, responses,
and security parameters) with these color sets create the
flexibility and inclusiveness to virtually capture differ-
ent types of cryptographic parameters for various types
of operations required. For example, the CPN record
and product data types help encode relevant data needed
to represent a cryptographic parameter. Relevant to this
paper, colset Request=product of fcode ∗
oheader is an example of the CPN color set used to
represent the protocol initial request from the master
station. Here, fcode and oheader are both a string data
type. This implies that an integer request will be void
1479
Fig. 4. DNP3-SA CPN on multidrop—top-level page.
because the model is only accepting specific string val-
ues as requests. On the other hand, we use CPN’s SML
functions to simulate the operations of the primitive cap-
tured. But it is worth noting that SML functions used
are mostly symbolic rather than the real operation. For
example, the outstation’s way of generating appropriate
responses based on a particular request from the master
does not perform the actual generation of responses ex-
pected from the protocol specification. Rather, the SML
functions only mimic the behavior of the protocol by us-
ing certain restrictions. This approach helps one to reuse
functions, which also leads to obtain a clean and precise
model.
2) Hierarchical net structure: In this paper, we choose to
model a single master station that is concurrently commu-
nicating with three outstations. This configuration is set
up to facilitate the understanding of the paper and model
can be extended to support more stations. To achieve this
configuration, we use the CPN hierarchical technique
to hide the details of the net structure in order to sim-
plify complexities. This approach is suitable for creating
large models because the behaviors of entities or security
operations can be represented as substitution transitions
(rectangular shaped but with double outline). Each sub-
stitution transition may link to at least a subnet structure
page, where detail of the net structure can be found. This
makes it possible to capture different levels of abstraction
in the same CPN model. For example, we demonstrate
this approach in Figs. 4–8, where Fig. 4 presents the
main page (top-level), while Figs. 5–8 present details of
some substitution transition in our main page. This paper
presents pages (top- and third-level pages) of the model
that are relevant to the contribution of this paper.
3) Model parameterization with adversaries: Relevant to
this paper, this approach is used to avoid the tendencies of
creating different models to capture different behaviors.
Thus, using this approach enabled us to construct a CPN
model such that it is also possible to incorporate different
types of adversarial behaviors, where one or more of the
attack behaviors can be enabled or disabled depending
on the environment for analysis (i.e., validation or ver-
ification). There are many types of attack that could be
launched, but we scope this work to only consider com-
mon Internet attacks such as modification, replay, and
1480
Fig. 5. Network and attack models.
Fig. 6. Processing requests on all outstations.
Fig. 7. Behavior of SAB on the master station.
injection. The detail of the attack models is provided in
Section VII-B.
VI. MODEL DESCRIPTION
A. Model Assumptions
Before the CPN model for DNP3-SAB is presented, it is im-
portant to note that some assumptions were considered while
modeling. These assumptions are made to help avoid the pos-
sibility of generating large state-space values, and they re-
duce complexity in constructing the model. Some of these
assumptions include the following.
1) The master station communicates with three outstations.
2) All default algorithms (i.e., long-term secret key, ses-
sion keys, and MAC scheme) used in DNP3-SA among
stations have been preestablished.
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 12, NO. 4, AUGUST 2016
Fig. 8. Behavior of SAB on all outstations.
3) The underlying layers of the DNP3 protocol are reliable
to ensure that there no communication failures.
4) Not all DNP3 and DNP3-SA data variations are captured.
This is because some data variation do not contribute
to the security analysis of this paper. Examples of such
variations include binary, analog inputs, and outputs data.
B. CPN Model of DNP3-SAB
Taking the above assumptions into consideration, the DNP3-
SAB CPN model is constructed in three different levels
of details or pages. The pages were created to improve
the readability of this paper. These three pages include
the top-level, second-level, and third-level pages. The top-
level page is the main abstract view of our CPN model.
The second-level page shows brief details of the top-
level, while the third-level pages present the actual details
of the modules (substitution transitions). Because of space
constraint, top- and third-level pages that directly contribute
to this paper are presented (see Figs. 4–8).
Fig. 4 presents the top-level page of the DNP3-SAB CPN
model. The model represents one master station communicat-
ing with three outstations for the purpose of illustrating and
evaluating the contribution of this paper using sized mod-
els with sufficient details. The behavior of the master station
[see Fig. 4(left)], network [see Fig. 4(middle)], and outstations
[primary outstations A, B, C; Fig. 4(right)] are presented with
substitution transitions (i.e., double-lined square boxes). A sub-
stitution transition is a high-level module that is used to hide the
detailed operation of a net structure. For example, the network
substitution transition hides the details of the network activities
between the stations (see Fig. 5). Remaining SendA, sendRq,
TrigRep, DataB, and sendRsp places model the transmis-
sion of data via the network between the stations. The ctr-
lkey and UserID places capture users and their associated
keys. Fig. 5 presents the third-level page of the network in our
CPN model (the network substitution transition in Fig. 4). Fig. 5
presents two behaviors: network behavior and parameterized at-
tack models. The network behavior specifies the way that the
master station and the outstations exchange messages. In Fig. 5,
the network behavior is modeled with the SendA and sendRq
AMOAH et al.: SECURING DNP3 BROADCAST COMMUNICATIONS IN SCADA SYSTEMS 1481

places and the ConnectA transition. These places and transition VII. FORMAL ANALYSIS OF DNP3-SAB CPN MODEL
allows the master to send data to the outstations. The color sets
In this section, we present the validation and verification of
(colset Packet and PacketRsp) represent all data (request, re-
the DNP3-SAB CPN model under the setup of one master to
sponse, and cryptographic parameters) exchanged between all
three outstations by using CPNs state-space tool. This setup
the stations. The labeled part “Receiving Responses” of Fig. 5
provides a model with a proper size for illustration and with
forms part of the network behavior, where all outstations re-
sufficient details for security analysis. However, a generic per-
spond to requests, if required. The parameterized attack models
formance and overhead analysis showing how the proposed so-
mark the adversarial behaviors on the network. These behaviors
lution scales with increasing number of outstations is presented
include attacks replay, injection, and modification. These attack
in Section VIII.
behaviors are set to false (turned OFF) and will be discussed
The state-space tool provides relevant information on how
later in Section VII-B.
the model proceeded from one state to another in consistent
Fig. 6 presents the third-level page of all the outstations pro-
manner. This vital information is presented in a summary report
cessing requests. It is assumed that all outstations will be pro-
with a number of behavioral properties. Some of these proper-
cessing the same request. We model the broadcast behavior of all
ties include the nodes and arcs of the state space, the strongly
outstations with the T_write transition from the Sub Processes
connected components (SCC), live transitions, home markings,
substitution transition, the SenSor and Enabler transitions, and
dead markings, and dead transitions. The state-space nodes and
the Actuator1 and Binary places. These places and transi-
arcs are properties used to determine the number of nodes and
tions are used to capture the executions of all broadcast opera-
arcs involved in the entire model. Likewise, SCC is a prop-
tions. For example, the SenSor transition must execute the token
erty used to determine the reachability of nodes and iterations
value “Rlsed Pressure” three times when the appropriate
involved in the model. This paper is more interested in dead
broadcast request for this operation is received.
markings and dead transitions. A marking or state is declared
Fig. 7 depicts the behavior of SAB on the master station. The
dead when there exist no binding elements to make the state ac-
HashChain place presents all the generated hash tag values
tive. In our model, a dead marking signifies a termination point.
and their respective indexes (the left-down bubble in Fig. 7) us-
Similarly, a transition is declared dead when the transition has
ing one of the DNP3-SA hash function specified in its standard.
no path from reachable states to enable it. A dead transition
This behavior represents step 1 in Fig. 3. The MAC place models
in our model may imply that an expected or unexpected action
the MAC token (values) obtained from the BSecure transition
may have occurred. It is to be noted that dead transitions in our
(refer to the inputs of BSecure, representing step 10 in Fig. 3).
model are subject to change. Depending on the behavior to be
The BdRequest, HValue, and Index places model the ac-
validated or verified, the number of dead transitions might vary
tual broadcast request about to be sent, the hash tag from the
because certain parameterized behaviors might be set to true or
hash chain, and the index of the hash tag, respectively. These
false. For example, if all attack models are set to false (turned
tokens are grouped as a single broadcast message through the
OFF), while validating the model may generate a large number
BPackA transition and transmitted to the network through the
of dead transitions.
SendRQ place. This captures the behavior (step 11) illustrated
in Fig. 3.
Fig. 8 presents the behavior of SAB on the outstations. The A. Validation of the DNP3-SAB CPN Model
Stored Values substitution transition models the storage area for
The aim of this section is to validate the DNP3-SAB CPN
valid hash tags and their indexes. This includes the last hash tag
model without any attack model turned ON (i.e., true). The
from the hash chain, which is assumed to be securely established
purpose of this action to determine whether the model re-
before the communication began between the stations (to the
flects the DNP3 broadcast behavior expected from the protocol
center of Fig. 8). The BrdCast Requests transition models the
specification. In this analysis, it is expected to obtain a sin-
receipt of every broadcast message from the network through
gle dead marking as the result of a single initial request from
the sendRq place (lower left of the Fig. 8). The Check Index
the master station to all outstations. This single dead marking
Value transition models the behavior for checking whether the
will indicate that every request issued by the master station is
incoming index values of the hash tag are valid. This transition
received and processed simultaneously by all the outstations.
is there for subsequent rounds of authentication and to avoid
Additionally, it is also expected to obtain 37 dead transitions.
replayed messages. If the received index of the hash tag is valid,
These transitions will consist of parameterized attack models
then a token is placed on the Trigger place to verify the
that have been set to false, inactive DNP3-SAB operations (be-
authenticity of the broadcast message. Otherwise, a token is
cause we are validating), and security transitions such as Errf-
placed on the AuthStatus place to signify an error (to the
back and Gen AuthError that could not execute, as there are no
center-right of Fig. 8). This behavior reflects the verification
attacks enabled.
process (step 12) in Fig. 3. Moreover, the ECV substitution
Table I presents the full state-space report of the DNP3-
transition models the behavior, where the received hash tag
SAB CPN Model. The table has two parts: initial DNP3-SAB
from the master station is extracted and hashed a number of
CPN model and attack models on DNP3-SAB CPN model. The
times to obtain a particular hash value. This behavior represents
initial DNP3-SAB CPN model presents the validation of the
step 14 in Fig. 3. The verification of MAC tags for message
SAB model, while the latter is the verification of DNP3-SAB
authentication and hash tags for freshness is achieved through
against the most common attack models (this is presented in the
the Tagcheck transition, representing steps 13 and 14 in Fig. 3.
subsequent section).
1482
TABLE I
STATE-SPACE ANALYSIS OF SAB ON MULTIDROP
State-Space Report for CPN SAB Model
Initial SAB CPN Model Attack Models on SAB
Injection Modification Replay
State-Space Nodes 13 829 23 831 821 44 789
State-Space Arcs 50 117 50 120 1045 89 056
SCC Graph Nodes 13 829 23 831 821 44 789
SCC Graph Arcs 50 117 50 120 1045 89 056
Dead Markings 1 3 1 3
Dead Transitions 37 25 53 22
In Table I, initial DNP3-SAB CPN model the report presents
identical values obtained for nodes and arcs of the state space
and that of the SCC. Achieving these matching values for both
properties implies that our model has no loops, and moreover,
the model has a finite sequence of occurrence. Furthermore, the
report presents a single dead marking with 37 dead transitions.
These values (single dead marking and 37 dead transitions) are
consistent with our expectation in Section VII. This is because
a close inspection of the model revealed that the single dead
marking represents the state where a broadcast request from
the master station has been successfully authenticated and pro-
cessed by all outstations. As a result, it led to the execution
of the Sensor transition, which further led to overwrite the de-
fault token value of “0” to “3” on the Actuator1 place on
all outstations (refer to the bottom of Fig. 6). Additionally, the
inspection also revealed that all 37 dead transitions were consis-
tent with our expectations. This is due to the absence of attack
models and certain security operations such as Errfback and
Gen AuthError transitions, which model authentication failure
operations that could not be executed as there are no attacks
enabled. In summary, these behaviors are expected as SAB is
enabled and no attack models have been enabled.
B. Verification of the DNP3-SAB CPN Model
This section presents the evaluation of DNP3-SAB CPN
model with adversaries enabled (i.e., attacks set to true) to de-
termine whether the authentication property of DNP3-SAB is
provided. But before we discuss the evaluation of DNP3-SAB,
this section will provide the details of the attack models used for
verifying the model. As previously emphasized in Section V-A,
the adversarial behaviors considered for this analysis include re-
play, injection, and modification attacks. The overall objective
of these attacks is to broadcast a request and get it processed on
the three outstations.
Fig. 9 presents the attack model considered for this analysis.
The attacks are modeled with places, transitions, and parame-
ters as before (see dotted area of Fig. 9). These attack behaviors
were set to false during the validation of the model. But to ver-
ify the model, we have enabled these attacks such that we can
revalidate the security of the model. In Fig. 9, the replay attack
is modeled through the Capture Reqs and TrigRep places and
the Replay transition. At this point, the attack is able to store
and replay previous messages from the master station. The in-
jection attack is modeled through the InjectR place and the
IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 12, NO. 4, AUGUST 2016
Fig. 9. Attack models in the network module.
ExcM1 transition. This allows the attacker to forge and inject an
existing request data with random strings via the network to the
outstations (see the box on top of InjectR; Fig. 9). The modifica-
tion attack is modeled through the function MoDAttack1. The
function is defined as a parameter on the arc inscription binding
the ConnectA transition and the sendRq place. This implies
that the attack can actively modify data (request contents and
network addresses) while in transmission through the network.
In Table I, the attack models on SAB show three dead mark-
ings for the injection and replay attack models, and a single dead
marking for the modification attack. Obtaining these markings
with their respective dead transitions led us to simulate the model
to investigate the behavior obtained for each attack model. The
investigation of the modification attack revealed that the single
dead marking obtained represents the execution of the Gen Au-
thError and Errfback transitions in all outstations, indicating an
authentication failure for the initial model state. This behavior is
expected because the attacker is actively modifying the content
of the packet since the message in the protocol is in “cleartext.”
As a result, the initial request from the master station does not
get executed because the integrity of the initial message has
been compromised. This led to 53 dead transitions because the
initial request was not executed on any of the outstations. In-
vestigating the injection attack model revealed that one of the
obtained dead markings represented the successful execution of
the SenSor transition on all the outstations (see Fig. 6), leading
to obtaining the token value “3” on each of the outstations. This
implies that authentication for the initial broadcast message from
the master station was successful. This is expected. However,
the remaining dead markings (2) of the injection attack repre-
sent the case of failure to terminate the protocol. This failure to
terminate the protocol led to the execution of the Errfback and
Gen AuthError transitions. A further investigation showed that
this failure occurred because the parameters provided by the at-
tacker could not be verified by SAB as required. As a result, the
execution of Errfback and Gen AuthError transitions indicate an
authentication failure. Moreover, the analysis also showed that
the 25 dead transitions obtained from the model were as a result
of the failure, as certain transitions could not be executed due
to the lack of data. The model reveals that it is computationally
hard for the attacker to forge and provide the expected data. This
is because the attacker has no prior knowledge of the hash-chain
parameters preestablished between the stations. For this reason,
this failure will give an insight to an administrator through its
log files.
AMOAH et al.: SECURING DNP3 BROADCAST COMMUNICATIONS IN SCADA SYSTEMS
Similarly, with the replay attack one out of the three dead
markings indicated the successful execution of the SenSor tran-
sition on all the outstations. This also implies that the initial state
of the model (request from the master station) was successfully
authenticated before processing. However, both remaining dead
transitions represented authentication failures, which lead to the
execution of Errfback and Gen AuthError transitions. In the re-
play attack, Errfback and Gen AuthError transitions occurred
because the replayed messages lacked freshness, new hash tags
and MAC tags. As a result, 22 dead transitions occurred. In
summary, these behaviors indicate that all parameterized at-
tacker behaviors in this model have been detected and stopped.
As a result, no unauthorized commands were possible to execute
on the outstations without a proper authentication performed.
VIII. PERFORMANCE ANALYSIS AND COMPARISON
This section provides a comparison of storage, communi-
cation, and computation overheads of SAB against its unicast
counterparts: DNP3-SA NACR and AGM. The comparisons are
based on the total headcount of messages within the protocol but
not in terms of bytes sizes. This is because most of the messages
have similar byte sizes. Moreover, the performance of these au-
thenticated unicast and broadcast communication schemes are
compared under adversarial conditions. The purpose of this pre-
sentation is to show that SAB is usable because our lightweight
security solution improve performance and reduce overheads.
The following notations are used in Table II. Here, N repre-
sents the number of outstations a master station is communicat-
ing with. Here, n denotes the approximate number of commands
to be exchanged between the master station and its N outstations
per user and during a time interval between two key updates.
Additionally, n also represents the number of hash tags in a
hash chain generated as part of SAB. SAB uses one hash tag
per request as illustrated in Fig. 3. H denotes the hash function
used to compute the hash chains. E and D denote encryption
and decryption, respectively. DAS , DAN , and DAA denote
the Drop attack on SAB, NACR, and AGM, respectively. In the
drop attack, an adversary drops a request from the master station
with the probability Pa . M IRS , M IRN , and M IRA denote
the modification, injection and replay attacks on SAB, NACR,
and AGM, respectively. The probability that these attacks will
target a request from the master station is represented as Pa .
For the sake of comparability, we have represented all crypto-
graphic transformations used in DNP3-SA and DNP3-SAB as
C (i.e., C = {H, E, D, M AC}). Similarly, the stored param-
eters used in DNP3-SA and DNP3-SAB are represented as K
(i.e., K = {Sn , n, U pK, Skm o , P , KSn}).
To understand the overheads analyses presented in Table II,
three things must be noted.
1) There are N outstations communicating with a single
master station.
2) There exists a key update process that occurs before the
NACR or AGM operates. The key update process has
four headcounts of messages per round and per user
(refer to Fig. 3).
3) NACR is a prior requirement to AGM operation.
1483
This implies that the number of communicated messages in
NACR will also be considered in AGM operation. Table II shows
that the total messages involved in SAB communication is 4N
+ n. This value (4N + n) is obtained because there are four
messages exchanged during the key update process to N out-
stations and a single (n) broadcast requests are sent (refer to the
exchanged messages in Fig. 3). This value corresponds to O(N
+ n). In processing SAB, the master needs to generate a hash
chain and a MAC tag. This is represented in the table as 2n +
2 ≈ O(n) (including the key update setup). Similarly, process-
ing SAB on each outstation requires 4N n (including the keys
update). This is because that each of the N outstations com-
putes a hash and MAC tag. The value on the outstations (2N n)
corresponds to O(N n), while that of the master corresponds to
O(n). For SAB storage overhead, the table shows 2n + 2 for
the master and 8N for the outstations. The value 2n + 2 on the
master represents a hash value (Si) with its index (i) and the
storage of two keys (i.e., UpK and SKm o ). Similarly, 8N on
the outstations imply that each of the N outstations stores eight
parameters consisting of two keys (UpK and SKm o ), chalg, Sn ,
i, Scalc , Sstored , and Nstored . Here, 8N corresponds to O(N ) and
(2n + 2) corresponds to O(n).
In Table II, the overheads of NACR and AGM are also pre-
sented. The overheads of NACR are almost the same as that of
the AGM, except that overhead of the AGM includes the NACR
behavior as prior requirement. However, both modes take into
account N outstations. This is done to compare SAB to NACR
and AGM. From Table II, comparing the overheads of SAB to
the existing NACR and AGM overheads, the table shows that
SAB has less communication overhead over its counterparts:
NACR and AGM. This is because in SAB operation, the mas-
ter sends a single request to N outstations at once, rather than
sending a request to each of the N outstations (as this is the
case for NACR and AGM). However, the table shows a slight
(minor) increase in storage and processing overheads on the N
outstations during SAB. This slight increase is asymptotically
insignificant because SAB is designed to run on large systems
rather than a small-scale systems. In case NACR and AGM
are to be used on large-scale systems, the processing and stor-
age overheads will dramatically increase. This is because both
modes will have to individually exchange n of messages to N
outstations. The advantage of SAB communication overhead
becomes clearer when attacks such as drop, modification, injec-
tion, and replay attacks are considered (refer to Table II). Thus,
in the attack models (DAS and M IRS ), SAB requires much
less retransmission (nPa ) for each request attacked with prob-
ability Pa than its counterparts. In addition, SAB causes less
processing overhead on the master station compared to NACR
and AGM. The extra processing caused on the master station
due to an attacked request is much less for SAB than for NACR
and AGM.
Based on this analysis, we conclude and make it clear that
there is always a tradeoff of performance when providing secu-
rity. Table II has shown that there exist the benefits in the entire
communication overhead of SAB as well as processing overhead
on the master stations. But these benefits come at the cost of an
extra storage used on the master stations to store hash chains and
their indexes. Additionally, calculations on the outstations also
1484 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 12, NO. 4, AUGUST 2016

TABLE II
PERFORMANCE ANALYSIS AND COMPARISON

Communication (# messages) Processing (# Crypto Operations C ) Storage (# Parameters K )

Master N Outstations Master N Outstations

SAB 4N + n ≈ O(N + n ) 2n + 2 ≈ O(n ) 4N n ≈ O(N n ) 2n + 2 ≈ O(n ) 8N ≈ O(N )

NACR 4N (n + 1) ≈ O(N n ) N n ≈ O(N n ) N n ≈ O(N n ) 4 (Constant) 4N ≈ O(N )
AGM 8N + 2N n ≈ O(N n ) N (n + 1) ≈ O(N n ) N n ≈ O(N n ) 4 (Constant) 4N ≈ O(N )
DAS n P a ≈ O(n ) n P a ≈ O(n ) N n P a ≈ O(N n ) - -
DAN N n P a ≈ O(N n ) N n P a ≈ O(N n ) N n P a ≈ O(N n ) - -
DAA N n P a ≈ O(N n ) N n P a ≈ O(N n ) N n P a ≈ O(N n ) - -
M I RS n P a ≈ O(n ) n P a ≈ O(n ) n P a ≈ O(n ) - -
M I RN 2N n P a ≈ O(N n ) N n P a ≈ O(N n ) N n P a ≈ O(N n ) - -
M I RA 2N n P a ≈ O(N n ) N n P a ≈ O(N n ) N n P a ≈ O(N n ) - -

TABLE III
PERFORMANCE AND FUNCTIONALITY OF SAB USING ALTERNATIVE METHODS

Functionality Performance

Schemes Mechanism Infrastructure Security Properties Communication Computation Storage

-Authentication
-Integrity 1 Key update n *HMAC n *MAC 1 Symmetric Key
Proposed SAB Hash chain None -Resistant to dishonest per n message 1*AES 1 Hash value per outstation
outstations*
-Authentication
SABSym Message-based None -Integrity n Key update n *HMAC n *MAC 1 Symmetric Key
key establishment -Require honest per n message n *AES 1 nonce value per outstation
outstations
-Authentication
SABAsym Digital signature PKI -Integrity Public key distribution n *PKI 1 Public Key
-Non-reputation 1 nonce value per outstation

cause a slight increase in processing overheads by a constant
term. This slight difference disappears in the attack scenarios.
SAB, NACR, and AGM cause the same processing overhead
on outstations when a request message is attacked (i.e., drop,
modification, injection, and replay) with a probability Pa . Fur-
thermore, as SAB utilizes only the existing security primitives
from NACR and AGM (refer to steps 2–6 of Fig. 3), it implies
that there are no additional cryptographic updates required for
devices supporting DNP3-SAB. Existing devices that support
DNP3-SA will have sufficient resources to support DNP3-SAB
as well. Also, the time a master station takes to send a request
to N outstations securely using DNP3-SA is more than the time
required for DNP3-SAB. This is because, using DNP3-SA, the
master station has to contact N outstations individually in se-
quence, causing some outstations to receive the request later
than others.
In Table III, the performance and functionality of SAB using
two alternative methods: symmetric (SABSym ) and asymmetric
key (SABAsym ) cryptography are presented. The table shows that
while the proposed SAB in this paper uses hash-chain values to
authenticate each broadcast message, the SABSym with symmet-
ric key requires a broadcast key established for each broadcast
message. SABAsym can use a single public key to authenticate all
broadcast messages, but it requires an infrastructure to distribute
public keys. All three schemes provide authentication and in-
tegrity. But the SABSym requires all outstations to be honest. This
is because a compromised outstation with the knowledge of the
symmetric key can masquerade the master station. SABAsym can
additionally be used for nonrepudiation. In terms of communi-
cation, SABAsym distributes one public key for authenticating
all broadcast messages and SAB requires a symmetric key and
a hash-chain value distribution once for n broadcast messages.
SABSym distributes a symmetric key for each broadcast mes-
sage. The advantage of SABAsym comes with high computation
requirements, which are not available for most master and out-
stations in service today. SABSym requires more computation
than SAB due to key establishment requirements. All schemes
require one key and random value per message to be stored.
Excluding SABAsym due to its high computation and infrastruc-
ture requirements, SAB shows clear advantage over SABSym in
security and computation and communication overhead.
IX. DISCUSSION AND CONCLUSION
The HMAC mechanism of the DNP3-SA protocol alone is
not sufficient to secure the DNP3 broadcast mode. This is be-
cause the HMAC mechanism will require a different key to
compute a unique MAC tag for each broadcast message. The
proposed SAB uses a hash chain to solve the problem of key
management. Hash values used for messages are linked together
as a hash chain. The usage of a single key together with the
hash chain removes need for a key per message. Additionally,
AMOAH et al.: SECURING DNP3 BROADCAST COMMUNICATIONS IN SCADA SYSTEMS
because the hash chains are also associated with indexes, it pre-
vents potential replay attacks from occurring. Using only the
index without hash values would not be sufficient because any
compromised outstation that already has knowledge of the sym-
metric key and the index can masquerade as the master station
and send broadcast messages to its counterparts. The analy-
sis of the SAB CPN model in this paper has shown that the
DNP3 broadcasts can be secured against attack vectors such
as modification, injection, spoofing, and replay, attacks listed
by the DNP3 consortium in the protocol specification. More-
over, SAB’s performance and comparison with alternative meth-
ods have shown SAB’s advantage in security, computation, and
communication overhead.
In the future, we will extend our model to address com-
munication on a data concentrator. A data concentrator is an
architecture where one a master station interacts with multiple
submaster stations and outstations with different communica-
tion modes. The motive of this work will be to analyze various
security properties on such a complex architecture.
REFERENCES
[1] J. Akerberg and M. Bjorkman, “Exploring security in PROFINET IO,”
in Proc. 33rd Annu. IEEE Int. Comput. Softw. Appl. Conf., 2009, vol. 1,
pp. 406–412.
[2] I. Al-Azzoni, D. G. Down, and R. Khedri, “Modeling and verification
of cryptographic protocols using coloured Petri Nets and design/CPN,”
Nordic J. Comput., vol. 12, no. 3, p. 201, 2005.
[3] R. Amoah, S. Camtepe, and E. Foo, “Formal modelling and analy-
sis of DNP3 secure authentication,” J. Netw. Comput. Appl., vol. 59,
pp. 345–360, 2016.
[4] R. Amoah, S. Suriadi, S. Camtepe, and E. Foo, “Security analysis of the
non-aggressive challenge response of the DNP3 protocol using a CPN
model,” in Proc. IEEE Int. Conf. Commun., Jun. 2014, pp. 827–833.
[5] E. J. Byres, M. Franz, and D. Miller, “The use of attack trees in assessing
vulnerabilities in SCADA systems,” presented at the Int. Infrastructure
Survivability Workshop, Lisbon, Portugal, 2004.
[6] M. Cheminod, A. Pironti, and R. Sisto, “Formal vulnerability analysis of
a security system for remote fieldbus access,” IEEE Trans. Ind. Informat.,
vol. 7, no. 1, pp. 30–40, Feb. 2011.
[7] D. Choi, H. Kim, D. Won, and S. Kim, “Advanced key-management
architecture for secure SCADA communications,” IEEE Trans. Power
Del., vol. 24, no. 3, pp. 1154–1163, Jul. 2009.
[8] D. Choi, S. Lee, D. Won, and S. Kim, “Efficient secure group communica-
tions for SCADA,” IEEE Trans. Power Del., vol. 25, no. 2, pp. 714–722,
Apr. 2010.
[9] G. Clarke and D. Reynders, Practical Modern SCADA Protocols: DNP3,
60870.5 and Related Systems. Burlington, MA, USA: Newnes, 2004.
[10] S. East, J. Butts, M. Papa, and S. Shenoi, “A Taxonomy of Attacks on the
DNP3 Protocol,” Crit. Infrastructure Protection III, vol. 311, pp. 67–81,
2009.
[11] G. Gilchrist, “Secure authentication for DNP3,” in Proc. IEEE Power En-
ergy Soc. Gen. Meet.-Convers. Del. Elect. Energy 21st Century, Pittsburgh,
PA, USA, 2008, pp. 1–3.
[12] S. Gilmore, Programming in Standard ML’97: A Tutorial Introduction.
Edinburgh, U.K.: Univ. Edinburgh, 1997.
[13] V. C. Gungor “Smart grid technologies: Communication technologies
and standards,” IEEE Trans. Ind. Informat., vol. 7, no. 4, pp. 529–539,
Nov. 2011.
[14] P. Huitsing, R. Chandia, M. Papa, and S. Shenoi, “Attack Taxonomies
for the Modbus protocols,” Int. J. Crit. Infrastructure Protection, vol. 1,
pp. 37–44, 2008.
[15] ICS-CERT, Monthly Monitor (ICS-MM201502), ICS-CERT Moni-
tor, 2015. [Online]. Available: https://ics-cert.us-cert.gov/monitors/ICS-
MM201502. Accessed on: 10/03/2015.
[16] IEEE Standard for Electric Power Systems Communications-Distributed
Network Protocol (DNP3), IEEE Std 1815–2012, 2012, pp. 1–866.
[17] IEC 62351Power Systems Management and Associated Information
Exchange—Data and Communications Security—Part 1: Communication
1485
Network and System Security—Introduction to Security Issues, IEC TS
62 351–1, 2007.
[18] K. Jensen, L. Kristensen, and L. Wells, “Coloured Petri Nets and CPN
tools for modelling and validation of concurrent systems,” Int. J. Softw.
Tools Technol. Transfer, vol. 9, no. 3, pp. 213–254, 2007.
[19] K. Jensen, S. Christensen, and L. M. Kristensen, CPN Tools State Space
Manual, Dept. Comput. Sci., Univ. Aarhus, Aarhus, Denmark, 2006.
[20] K. Jensen and L. Kristensen, Coloured Petri Nets. Berlin, Germany:
Springer-Verlag, 2006.
[21] W. Kim, “On cyberwarfare,” Int. J. Web Grid Serv., vol. 8, no. 4,
pp. 321–334, 2012.
[22] X. Lu, W. Wang, and J. Ma, “An empirical study of communication infras-
tructures towards the smart grid: Design, implementation, and evaluation,”
IEEE Trans. Smart Grid, vol. 4, no. 1, pp. 170–183, Mar. 2013.
[23] B. Miller and D. Rowe, “A survey SCADA of and critical infrastructure
incidents,” in Proc. 1st Annu. Conf. Res. Inf. Technol., 2012, pp. 51–56.
[24] Modbus Application Protocol Specification v1. 1a, I. Modbus, Grafton,
MA, USA, 2004.
[25] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, “The TESLA broadcast
authentication protocol,” RSA Crypto Bytes, vol. 5, no. 2, pp. 2–13, 2002.
[26] A. Perrig, R. Szewczyk, J. D. Tygar, V. Wen, and D. E. Culler, “Spins:
Security protocols for sensor networks,” Wireless Netw., vol. 8, no. 5,
pp. 521–534, 2002.
[27] PROFInet Architecture Description and Specification, PROFIBUS
International Std., version 2.01, Aug. 2003. [Online]. Available:
http://www.PROFIBUS.com
[28] S. Suriadi, C. Ouyang, and E. Foo, “Privacy compliance verification in
cryptographic protocols,” Trans. Petri Nets Other Models Concurrency
VI: Lecture Notes Comput. Sci., vol. 7400, pp. 251–276, 2012.
Raphael Amoah (M’14) received the Ph.D. de-
gree from the Queensland University of Technol-
ogy (QUT), Brisbane, Australia, in 2016.
He has been a Sessional Academic with
the QUT since 2012. His current research
interests include cyber-physical systems, for-
mal methods, formal verification of communica-
tion protocols used in supervisory control and
data acquisition, and industrial controls systems
security such as smart grid.
Seyit Camtepe (S’04–M’07) received the Ph.D.
degree in computer science from Rensse-
laer Polytechnic Institute, New York, NY, USA,
in 2007.
From 2007 to 2013, he was with Technische
Universitaet Berlin, Berlin, Germany, as a Se-
nior Researcher and Research Group Leader
in Security. Since 2013, he has been with the
Queensland University of Technology, Brisbane,
Australia, as a Lecturer. His research interests
include mobile and wireless communication,
pervasive security, and applied and malicious cryptography.
Ernest Foo (M’99) received the Ph.D. degree
from the Queensland University of Technology
(QUT), Brisbane, Australia, in 2000.
From 2007, he has been a Senior Lecturer
and Researcher at the Information Security Dis-
cipline, School of Electrical Engineering and
Computer Science, QUT. His research interests
can be broadly grouped into the field of secure
network protocols with an active interest in the
security of industrial controls systems such as
supervisory control and data acquisition and the
smart grid.