Securing GOOSE: The Return of One-Time Pads
Kwasi Boakye-Boateng, Arash Habibi Lashkari
Canadian Institute for Cybersecurity (CIC), Faculty of Computer Science
University of New Brunswick (UNB), Fredericton, NB, Canada
kwasi.boakye-boateng@unb.ca, a.habibi.l@unb.ca
Abstract—IEC 61850 is an international standard that is widely
used in substation automation systems (SAS) in smart grids.
During its development, security was not considered thus leaving
SAS vulnerable to attacks from adversaries. IEC 62351 was
developed to provide security recommendations for SAS against
(distributed) denial-of-service, replay, alteration, spoofing and
detection of devices attacks. However, real-time communications,
which require protocols such as Generic Object-Oriented Sub-
station Event (GOOSE) to function efficiently, cannot implement
these recommendations due to latency constraints. There has
been researching that sought to improve the security of GOOSE
messages, however, some cannot be practically implemented due
to hardware requirements while others are theoretical, even
though latency requirements were met. This research investi-
gates the possibility of encrypting GOOSE messages with One-
Time Pads (OTP), leveraging the fact that encryption/decryption
processes require the random generation of OTPs and modulo
addition (XOR), which could be a realistic approach to secure
GOOSE while maintaining latency requirements. Results show
that GOOSE messages can be encrypted with some future work
required.
Index Terms—substation security, substation automation sys-
tems, smart grid security, One-Time Pads, Secure GOOSE, IEC
61850, IEC 62351.
I. I NTRODUCTION
A smart grid is a power grid that has been enhanced,
using Information and Communications Technology (ICT),
for advanced remote control and automation; to generate,
transmit and distribute electricity, with substations being a
critical component. Substation automation systems (SAS) are
essential in economically maintaining the energy balance
between generation and demand in the operation of electrical
power [1]. The most important functions of SAS are control,
monitoring, alarming, measurement, setting and monitoring
of protective relays, control and monitoring of the auxiliary
power system, and voltage regulation. One of the most critical
requirements for real-time operations within a substation is
efficient communication within the SAS. To this end, the
International Electrotechnical Commission (IEC) developed
the IEC 61850 [2] standard to ensure vendor interoperability
among devices; and abstracting data and services that can
allow underlying protocols to be mapped to them. Theoret-
ically, a protocol can be developed specifically for substations
based on the standard, in spite of its complexity. IEC 61850
is integral in the communication and information exchange
implemented within an electrical substation environment. One
of the communication protocols included in IEC 61850 is
the Generic Objected-Oriented Substation Event (GOOSE
978-1-7281-1576-4/19/$31.00
2019
c IEEE
[3]) protocol,which is required for real-time operations of a
substation, with a performance constraint requirement of not
more 4 milliseconds (ms).
A. IEC 61850-Based Substation Architecture
A typical electric substation comprises primary and sec-
ondary equipment [4]. The primary equipment is made up
of high voltage devices while the secondary equipment is
made up of medium to low-voltage devices. The secondary
equipment is responsible for the control and protection of the
primary equipment. An SAS is based on a lot of dedicated
software stored in pieces of hardware that belong to a set of
substation secondary components. An SAS is composed of
three groups of devices namely the process devices group,
interface devices group and application devices group. The
process devices group includes analog-to-digital converters
(known as Merging Units) and actuator devices to make the
transition between SAS and high voltage equipment. The
interface devices group covers a set of Intelligent Electronic
Devices (IEDs) that receive and process signals coming from
high voltage equipment. IEDs can also control some devices
in the process group. The application devices group includes
all computers and other components required to run control
functionalities and to communicate with internal and external
subsystems. IEC 61850 as a communication standard, ensures,
among other things, vendor interoperability among devices
within the substation environment and has been integral in
the communication and information exchange implemented
within an electrical substation environment. SAS has a hier-
archical structure and IEC 61850 defines three typical levels
for communication and application functions (Fig. 1). These
are process, bay and station levels [5]. The process level
includes primary equipment and process devices group in
the substation. The process level communicates with the bay
level via the process bus. The bay level includes the interface
devices group and communicates with the station level via
the station bus. The station level includes Supervisory Control
and Data Acquisition (SCADA), Human Machine Interface
(HMI) and other station computers and devices found in the
application devices group.
B. IEC 61850 OSI Architecture, GOOSE Protocol and Secu-
rity Issues
Due to its Ethernet-based communication (IEEE 802.3),
an IEC 61850-based substation is more advantageous than
the traditional substation, in ensuring reliable and efficient

Fig. 1. IEC 61850-based Substation Architecture [5]
communication through the use of its protocols. Fig. 2 shows
the Open Systems Interconnection(OSI) Architecture of IEC
61850. The client-server-based Manufacturing Message Spec-
ification (MMS) protocol [6] is used for the management and
monitoring of substation devices. Time Sync (currently Preci-
sion Time Protocol-implemented [7]) is used to synchronize
clocks throughout the SAS. Sample Value (SV) protocol [8] is
used to transmit high-speed streams of raw information, par-
ticularly those measured by instrument transformers, encoded
in multicast Ethernet frames. The Generic Object Oriented
TABLE I
IEC 61850 M ESSAGE T YPES AND C ONSTRAINTS [9]
Message Type Delay Constraint(ms)
1A - Fast messages, trip ≤3
1B - Fast messages, others ≤20
2 - Medium speed messages ≤100
3 - Low speed Messages ≤500
4 - Raw Data Messages ≤3, ≤10
5 - File Transfer Functions ≤1000
6 - Time synchronization messages N/A
7 - Command Message With Access control N/A
Fig. 2. IEC 61850 Communication Stack [10]
Substation Event (GOOSE) is an event-driven protocol used
for protection and control of primary equipment as well as
other applications by providing a fast and reliable mechanism
that allows the exchange of data between two or more IEDs
over IEEE 802.3 networks. GOOSE embeds certain logical
and analog data such as circuit breaker status, circuit breaker
control, interlocking, general alarms, and power transformer
temperature into transmitted Ethernet packets. Referring to
the IEC 61850-defined performance constraints requirements
for different types of data in Table I and the stack in Fig. 2,
GOOSE messages are classified as Type 1, which means that
they require high-speed transmission of their data.
IEC 61850 was designed without security in mind. The
isolated nature of the substation network, at the time of
the standard’s design, did not warrant the need for security.
Due to current advancements in technology and the need for
automation and remote access, this reason is no longer valid
[11]. This has exposed the substation to attacks such as denial-
of-service, man-in-the-middle, masquerade and eavesdropping
attacks. There has also been research exposing the vulnera-
bilities and the various attacks that can be associated with it
[12]. Some of these vulnerabilities are published in websites
that record these vulnerabilities [13]. In 2007, IEC 62351 was
developed to ensure security in industrial control protocols,
including IEC 61850, with authentication of data, transfers
through digital signatures, prevention of eavesdropping and
spoofing, and intrusion detection as their main objectives [10].
However, these standards do not work on GOOSE due to
the cost of latency when these security recommendations are
implemented in GOOSE. Standard encryption algorithms do
not work because their time of execution exceeds the 4ms
constraint [14] [15]. This is due to a number of operations
that need to be applied to the messages in order to achieve
security. They are also not feasible because of the processor
constraints on the devices, known as Intelligent Electronic
Devices (IEDs), that implement GOOSE.
substation ⊕ poltmcngsj = himlf cgogw (1)
himlf cgogw ⊕ poltmcngsj = substation (2)
This research aims to investigate the possibility of ensuring se-
curity in GOOSE protocol by encrypting its messages/packets
(messages and packets are used interchangeably in this paper)
with One-Time Pads (OTP) [16]. The OTP is an encryption key
that has its characters randomly generated and has been mathe-
matically proven to be computationally secure and unbreakable
due to its uniform frequency of distribution. Encryption and
decryption with OTPs requires only a modulo addition (XOR)
operation with the plain text. It is also a requirement that
the lengths of the OTP and plaintext be the same. The
OTP is used only once hence its name. Assuming that we
have a plaintext(substation) and an OTP (poltmcngsj); the
encryption generates the cyphertext (himlf cgogw) in Equa-
tion 1 and decrypting it with the OTP reveals the plaintext in
Equation 2. The only resource intensive operation anticipated
in this process is the random generation of the OTP. It is
expected that latency should be negligible after the protocol
is implemented.
II. R ELATED W ORKS
In this section, a taxonomy of attacks related to GOOSE
and the recommendations against these attacks by IEC 62351
standard are discussed. Later, related work on protocols de-
signed to ensure encryption in GOOSE is discussed. How these
protocols measure up against these attacks are also discussed.
A. Taxonomy of Attacks Related to GOOSE
Volkova et al. [10] as well as other researchers( [17] [18])
provide an extensive review of attacks in control network
protocols (including IEC 61850) and the recommendations
provided by IEC 62351. In this paper, attacks related to
GOOSE are mentioned.
1) Detection of control devices: Author mentions two ap-
proaches used by the adversary to detect number and types
of devices within the network. These are active and passive
approaches. The active approach requires the adversary to send
packets within the network to obtain responses and based
on those responses, the type and number of devices can be
determined. In the passive approach, the adversary sets up
a device’s interface to promiscuous mode to monitor traffic
within the network. Results from the monitoring are used to
determine the number and types of devices within the network.
However, it is stated that IEC 62351 provide no comprehensive
countermeasures to stop it [10].
2) Replay, alteration and spoofing attacks: Replay attacks
involve the retransmission of captured original packets by the
adversary. These packets, obtained during a passive detection
approach, are retransmitted to obtain further information or
observe the behaviour of the network which could be useful
to the adversary. Also such packets can be captured, modified
and retransmitted by the adversary to either extract more in-
formation or provoke disurbances, or emergencies, within the
substation environment. Quite often, the altered or modified
GOOSE packets are used to compromise IEDs and cause
damage within the substation. In the replay attack, original
messages replayed by the attacker, when the 32-bit stN um
value (see Section III) is reset to zero, will be accepted by
the receiving device as legitimate messages. This strategy can
be used as form of denial-of-service attack because legitimate
messages will always be dropped because their stN um values
are always lesser than those of malicious messages.
Hoyos et al. [14] exploited GOOSE by injecting false
GOOSE packets into the network. After monitoring the repet-
itive nature of GOOSE communication, a pattern was es-
tablished. Using Scapy [19] and Python scripts, a GOOSE
packet was captured, parsed and modified into a malicious
packet. The malicious packet was injected at a time when
the retransmission interval was steady to deceive recipients
that it was a new packet. This was processed by an IED
that triggered a circuit breaker thus demonstrating that such
malicious packets can cause the substation to be in a critical
state. Wright et al. [20] also developed a model to calculate
the minimum requirements for an attacker to inject a malicious
packet into the network. These attacks on GOOSE could
have cascading problems throughout, not only in a substation,
but an entire smart grid. IEC 62351 standard recommends
implementing Message Authentication Code (MAC) [21] for
security in GOOSE and the RSA [16] encryption algorithm
is recommended by the standard to implement it. However,
the large computation overhead and low efficiency involved in
the implementation makes it difficult to match the real-time
requirements of data transmission for GOOSE.
3) DoS/DDoS Attacks: Denial-of-service (DoS) or Dis-
tributed DoS (DDoS) attacks have a sole purpose of ensuring
that a device is unable to render services to its intended
users. The adversary achieves this by flooding the device
with illegitimate messages/requests thereby making the device
unable to respond to legitimate messages. It can slow down the
performance of devices which can have a cascading effect on
substations. As mentioned previously, an attacker can realise
a DoS attack by sending malicious messages with higher
sequence numbers than the legitimate messages. as a result, all
legitimate messages will be seen as stale and dropped while
the malicious messages are accepted. IEC 62351 does not have
solutions that are sufficient in dealing with DoS attacks.
B. Existing Encryption Protocols
Mei et al. [11] discussed the implementation of a Hash-
based MAC (HMAC) [21] as a more efficient security protocol
as opposed to IEC 62351’s recommendation. However it was
not implemented and there were no theoretical proofs to
calculate its efficiency. Premnath et al. [22] applied the NTRU
[23] encryption algorithm in ensuring security of SCADA.
Randomly-generated 32-byte messages were encrypted on
Raspberry Pi and compared with RSA. NTRUEncrypt was
used to encrypt packets and NTRUSign was used to sign
the packets to ensure integrity. Even though NTRU was
better, the computational time was more than 50ms which
exceeds the GOOSE performance requirements. Wang et al.
[24] designed a security scheme based on a hybrid DES-
RSA algorithm but it requires high-computing performance
to satisfy GOOSE performance requirements. There is also
the issue of packet overhead which can also affect GOOSE
performance requirements, should a maximum-size packet be
used. Zhang et al. [25] developed a hardware-based secu-
rity scheme for GOOSE using Certificate-less Public Key
Cryptography(CL-PKC) [26] which had latencies of less than
1.5ms - well within the GOOSE performance requirements.
However, the calculations of the delay were purely theoretical
based on the performance of the A980 chip on encryption
algorithms. Also, the assumption made was that encryption is
implemented on a security chip before the packet is sent to
the master CPU for processing. This may not be feasible for
implementation for devices that do not have security chips.
Existing devices may not be replaced with new devices, that
have these security chips, by substation operators due to
capital expenditure issues thus making this security scheme
not suitable for substations. Table III provides an overview of
previous research on GOOSE encryption.
In terms of attacks in Table II, there are a few drawbacks
from these protocols suffer from. All protocols are unable to
handle DoS/DDoS and replay attacks because they did not
implement any techniques to verify the freshness of the mes-
sage. Only the CLPLK is vulnerable to the detection of devices
 TABLE II
TAXONOMY OF GOOSE-R ELATED ATTACKS

Attack Security Requirement Vio- Effects IEC 62351 Recommendation

lated
Detection of control de- Confidentiality Number of devices and message contents are No comprehensive countermeasures pro-
vices exposed to the adversary vided
Replay, alteration and Integrity Modified messages can cause high voltage RSA signatures suggested but they affect
spoofing attacks devices to malfunction leading to cascading real-time performance of GOOSE
effects
DoS/DDoS Attacks Availability Real-time operations of IEDs will fail which No sufficient solutions provided
can possibly leading to cascading failures
within the substation

TABLE III
OVERVIEW OF P REVIOUS R ESEARCH ON GOOSE E NCRYPTION
Protocol Latency(ms) Problem
CLPKC [25] ≈ 1.409 Theoretical, hardware-based and
difficult to be replicated practi-
cally
NTRU [22] > 50 High latency, even though im-
plemented on Raspberry Pi
Hybrid DES- <2 Requires high performance com-
RSA [24] puting
attack because the contents of the messages are not hidden
and its primary concern is the integrity and non-repudiation
of messages. Against alteration and spoofing attacks, there
are no known drawbacks for all three protocols. Table IV
provides a summary of the drawbacks of the protocols.Review
of these papers proves that there is a need for a protocol that
should be easily implemented on a software or hardware level
depending on the choice of the operator or manufacturer. Such
a protocol should neither require high computing overhead nor
incur packet overhead. Above all such a protocol must satisfy
the performance constraints requirements of GOOSE.
III. GOOSE PACKET S TRUCTURE AND C OMMUNICATION
M ECHANISM
A GOOSE packet (Fig. 3), which is an Ethernet-based
packet, has the following fields: Destination, Source,
EtherT ype, P ayload, and F ieldControlSequence (F CS)
fields. The Source and Destination fields are Ethernet-
based Media Access Control(MAC) addresses and each has
a size of 6 bytes. The Destination field is a multicast MAC
address with the recommended format being 01 − 0C − CD −
01 − Y Y − Y Y , where Y Y − Y Y is within the range of
01 − 00 to 01 − F F . In a situation where the recommended
format will not be followed, the first octet must have its least
significant bit set to 1 to indicate that address is a multicast
address and the fourth octet must have always have a value
of 01 to indicate that it is a GOOSE multicast address. The
2-byte EtherT ype field specifies the type of packet and
has a value of 0x88B8 which means that the packet is a
GOOSE packet. The F CS field, which has a size of 4 bytes,
is used for error detection and control. The P ayload field
has a varying size not more than 1500 bytes and has five
fields namely the AP P ID, Length, Reserved1, Reserved2
and GooseP ayload/Application Protocol Data Unit(AP DU ).
AP P ID, Length, Reserved1 and Reserved2 each has a size
of 2 bytes. AP P ID holds the identification of a logical device,
which can be found within an IED, responsible for GOOSE
operations. Reserved1 and Reserved2 fields are reserved for
future extensions for functions for GOOSE messages and are
always set to 0. The Length field specifies the length of the
message; it is calculated as m + 8 where m is the length of
the AP DU . The APDU, which holds the actual GOOSE data,
contains the following fields: gocbRef , timeAllowedT oLive,
datSet, goID, t, stN um, sqN um, test, conf Rev, ndsCom,
numDatSetEntries and allData. gocbRef is the name
of the GOOSE Control Block which is within the IED.
timeAllowedtoLive provides the time that next GOOSE
packet is expected. dataSet refers to the name of the dataset
object, within the IED, within which values of its members
are transmitted. The members are uniquely numbered starting
from 1. goID is the GOOSE ID of the GOOSE block within
the IED. t holds the timestamp of the GOOSE packet that was
transmitted. Because GOOSE is an event driven protocol, a
unique state number, stN um, is required to record each event,
of which its data is being transmitted, in a GOOSE packet.
The value of stN um changes in increasing order. sqN um is
the number assigned to retransmitted GOOSE messages of a
particular event in increasing order. sqN um is reset to 0 when
stN um is incremented to indicate that a new event has its data
being transmitted.
When the value of test is 1 (TRUE), it means that the
values of the dataset in the message are being used for
testing purposes, a value of 0 means that they shall be used
for operational purposes. conf Rev displays the configura-
tion version of the IED. ndsCom, which stands for ”needs
commissioning”, when set to TRUE, means that the IED
requires further configuration. numDatSetEntries provides
the number of data members in the dataset in GOOSE packet.
alldata represents the actual data in the dataset encoded in
ASN.1/BER [27] format. In fact, data within the APDU is
encoded using Abstract Syntax Notation ONE/Basic Encoding
Rules (ASN.1/BER). Each field within the APDU has the
format T AG, LEN GT H and DAT A (actual value/data of
the field). T AG indicates the type of information represented
by DAT A. LEN GT H indicates the size of DAT A in bytes.
GOOSE implements the publish-subscribe mechanism which
involves sending multicast messages within the network. In
the publish-subscribe mechanism, one device (the publisher)
 TABLE IV
D RAWBACKS OF P REVIOUS R ESEARCH ON GOOSE E NCRYPTION IN R ELATION TO GOOSE-R ELATED ATTACKS

Type of Attack
Protocol Detection of devices Replay Alteration and spoofing DoS/DDoS
CLPLK Attacker can monitor Replayed packets will be No known drawbacks due to Flooding of devices with unmodi-
messages. accepted by devices be- authentication and signature fied replay packets will be accepted
cause there is no check for fields. by devices.
freshness.
NTRU No known drawbacks. Replayed packets will be No known drawbacks due to Flooding of devices with unmodi-
Attacker is unable to accepted by devices be- authentication and signature fied replay packets will be accepted
monitor encrypted pack- cause there is no check for fields. by devices.
ets. freshness.
Hybrid RSA and DES No known drawbacks. Replayed packets will be No known drawbacks due to Flooding of devices with unmodi-
Attacker is unable to accepted by devices be- authentication and signature fied replay packets will be accepted
monitor encrypted pack- cause there is no check for fields. by devices.
ets. freshness.

TABLE V
L IST OF N OTATIONS

PGoose GOOSE packet to be transmitted/received

K key or OTP to encrypt PGoose
AP P ID 2-byte Application ID field of PGoose
KAP P ID 2-byte subset of K used to encrypt AP P ID
destM ac 6-byte destination MAC address field of PGoose
KdestM ac 6-byte subset of K used to encrypt destM AC
Fig. 3. GOOSE Packet Structure [28] srcM ac 6-byte source MAC address field of PGoose
KsrcM ac 6-byte subset of K used to encrypt srcM AC
gooseF CS 4-byte frame check sequence field of PGoose
KgooseF CS 4-byte subset of K used to encrypt gooseF CS
creates a message that is delivered to a group of destination gooseP DU protocol data unit of PGoose
devices (the subscribers) simultaneously in a single transmis- lgooseP DU gooseP DU length in bytes
i a counter starting from zero used a for loop
sion from the source. To satisfy real-time requirements of gooseP DU [i] ith byte of gooseP DU
GOOSE, communication is unconfirmed; thus a message is KgooseP DU Byte 1-byte subset of K used to encrypt
sent in a repetitive manner at a specific time interval, as long gooseP DU [i]
⊕ XOR operation
as there has been no change in events. This repetition strategy ← assignment operator
is implemented as strategy against packet loss because no multiM ac 6-byte MAC address of device
acknowledgement is sent from the subscribers to the publisher. srcM acList list of source MAC addresses in a device

IV. P ROPOSED OTP P ROTOCOL

In order to implement the OTP protocol in GOOSE pro-
tocol, an understanding of GOOSE communication and its
packet structure (see Section I-B and III) was required before
encryption and decryption algorithms were designed. Also,
reviewing existing literature(see Section II) was important
to learn whether some of the techniques implemented could
be beneficial in the design of the algorithm. In a high-level
description of the OTP protocol, the publisher fetches or
generates the OTP, encrypts the GOOSE packet with the OTP
by performing an XOR operation on it and then transmits
it after encryption. The subscriber, upon receiving the packet,
fetches or generates the OTP and decrypts the encrypted packet
by performing an XOR operation on it with the OTP. The
subscriber verifies the source and destination address, which
is already an existing procedure in GOOSE, and accepts the
packet if the source address is known and the destination
address matches the multicast address it is subscribed to. If
there is no match, the packet is dropped. Because the OTP
is used only once, a replay attack would not work because
the destination and source addresses will be decrypted with a
different key which will cause the packet to be dropped due to
unknown addresses that are generated as a result. The F CS
field is decrypted as well, thus a decryption of a replay or
malicious packet will reveal a value which will generate an
error when an integrity check is made. Due to the uniform
frequency of distribution of OTPs, it has been mathematically
proven that statistical or brute force attacks do not work
against OTPs. This makes the packet secure against attacks
on confidentiality, integrity and authentication. Using the list
of notations in Table V, Algorithms 1 and 2 are explained.
Algorithm 1 details the proposed publisher’s encryption al-
gorithm for the GOOSE packet. An OTP, K, is generated to
encrypt certain fields of the GOOSE packet, PGoose . K and
the total size of the selected fields of PGoose must have the
same length. K is divided into different keys to be used to
encrypt the various fields of the packet. The size of these
keys must match the size of the corresponding packet fields
that must be encrypted. As mentioned earlier, the encryption
process is a simple XOR operation. For example, as shown in
Algorithm 1, srcM ac, which represents the Source field, is
XORed with KsrcM ac to encrypt that field. The AP DU field,
which is represented by gooseP DU , is encrypted on a byte-
Algorithm 1 Encryption Algorithm challenging due to the scarcity of test environments especially
Generate KsrcM ac when it is not advisable to test them in real-life environments
srcM ac ← srcM ac ⊕ KsrcM ac [15]. Most of the available simulation tools are voltage,
Generate KdestM ac current or power-based. Others that would be suitable for
destM ac ← destM ac ⊕ KdestM ac the research require licenses which can be costly as is
Generate KAP P ID acquiring devices to test in a made-up test environment.
AP P ID ← AP P ID ⊕ KAP P ID In this research, tools used by Hoyos et al. [14] to exploit
for i = 0&&i < lgooseP DU do GOOSE packets and Scapy were used in the implementation
Generate KgooseP DU Byte of the proposed algorithm. The tools are free, open-source
gooseP DU [i] ← gooseP DU [i] ⊕ KgooseP DU Byte and Python-based. Implementation of the proposed protocol
end for was done on a Debian-based Linux platform. The laptop
Generate KgooseF CS running the platform has 8GB RAM and a 2.3GHz quad-core
gooseF CS ← gooseF CS ⊕ KgooseF CS Intel 7th -Generation i3 processor. Due to lack of access to
Transmit PGoose a substation environment or a convenient simulation tool, a
file (network dump) containing GOOSE packet data that was
found in a GitHub repository of Hoyos et al. [14] was used
by-byte basis due to the varying nature of its size. EtherT ype, to test the proposed algorithm and the outcome was observed.
Length, Reserved1 and Reserved2 fields were not encrypted A GOOSE packet is retrieved from the file, encrypted and
because they do not carry any information worth securing. the encrypted packet is written to another file. The fields
Encrypting these fields would facilitate the exposure of some are manually calculated to ensure that they were correctly
portions of K by the adversary through the use of default encrypted. A Python script was created for this sole purpose.
values of the reserved fields and manually calculating the The packet data in the dump file are seen as byte strings
actual length of the packet. Algorithm 2 details the proposed in Python; thus it was required that the data be converted to
subscriber’s decryption algorithm for the GOOSE packet. The byte integers before XOR operations were performed on each
only difference between Algorithm 1 and Algorithm 2 is the of the required fields of the packet. The OTP is generated
verification of addresses by the subscriber. The subscriber ver- using a pseudo-random number generator (PRNG) from the
ifies whether the Destination field in the packet, represented Python library. The PRNG was implemented to generate one-
by destM ac, matches the multicast address, multiM ac, that it byte values which were stored in an array with the same size
is subscribed to. It also verifies whether srcM ac is part of the as the total size of the packet fields that had to be encrypted.
table of source addresses, srcM acList, that it is subscribed Based on the known byte positions of each field, the packet
to. was iteratively XORed with each member of the array. The
encrypted packet is written to another file.
Algorithm 2 Decryption Algorithm The fact that no verification could be performed after
Generate KsrcM ac decryption by a subscriber implied that both the encryption
srcM ac ← srcM ac ⊕ KsrcM ac and protection processes shared the same number of steps.
Generate KdestM ac This made it easier to measure latency when the PRNG was
destM ac ← destM ac ⊕ KdestM ac used and when the PRNG was not used. The array used for
Generate KAP P ID encryption was the same used for decryption. This means that
AP P ID ← AP P ID ⊕ KAP P ID the calculation of latency in encryption with PRNG will be the
for i = 0 && i < lgooseP DU do same for decryption using PRNG and vice-versa. Using the
Generate KgooseP DU Byte same array generated from the PRNG for decryption implies
gooseP DU [i] ← gooseP DU [i] ⊕ KgooseP DU Byte that the calculation for latency in decryption without PRNG
end for will be the same for encryption and vice-versa. This method
Generate KgooseF CS of computation was deemed necessary because numbers gen-
gooseF CS ← gooseF CS ⊕ KgooseF CS erated by the PRNG were non-deterministic and that affected
if (destM ac 6= multiM ac) && (srcM ac ∈/ srcM acList) the decryption of the packet when a new array of numbers was
then generated. The decrypted packet is written to the same file as
Drop PGoose the encrypted packet for comparison. Table VI provides the
else results of the OTP protocol compared with previous research
Accept PGoose from Table III. The latency calculated when the PRNG is
end if used in encryption/decryption is approximately 3.1ms and
without PRNG is approximately 2.9ms implying a delta of
approximately 0.2ms. The results were not surprising given
V. I MPLEMENTATION AND E VALUATION the fact that Python is an interpreted language to execute an
Implementation of proposed security-based research algorithm which should have been implemented in a driver
methodologies and algorithms for substations is very of a network card. A faster processor could have been used
 TABLE VI
C OMPARISON OF GOOSE E NCRYPTION P ROTOCOLS
Protocol Latency(ms)
CLPKC ≈ 1.409
NTRU > 15
Hybrid RSA and DES <2
OTP (with PRNG) ≈ 3.1
OTP (without PRNG) ≈ 2.9
Fig. 4. Normal GOOSE Packet Displayed in Wireshark
to execute the script to scale down the results into the region
of microseconds; however it would not be the true reflection
of the efficiency of the protocol. The protocol, however, can
be predicted to execute faster because it can work best in the
kernel of a device, for example within a network driver, which
could be possibly C/C++ based. Also, the numerous memory
operations, especially copying, manipulating and reassigning
of data in memory locations, when using Python, meant that
the latency will be high. There would have been a tremendous
improvement in the algorithm within a network driver due to
utilisation of C/C++ pointers which require memory referenc-
ing to access packet data in a memory buffer. Also, data being
processed by drivers would not be strings but actual bytes that
can be manipulated without any major conversion. Figures 4
and 5 show the normal and encrypted packets displayed in
Wireshark respectively. It can be observed that the encryption
provided different values for the fields mentioned. Also, the
GOOSE APDU field could not be parsed well by Wireshark
which means the adversary would require more effort to make
the packet unobservable. It terms of attacks (see Table II),
there were no drawbacks that the OTP protocol suffered from.
The OTP protocol is resilient against detection of devices
Fig. 5. Encrypted GOOSE Packet Displayed in Wireshark
because the packets were encrypted; thus the attacker is unable
to verify the true address in the packets. DoS/DDoS, replay,
alteration and spoofing attacks do not work against the OTP
protocol because every packet gets decrypted with a different
key thus all packets get dropped if addresses do not match
and also integrity check fails when calculated using the F CS
field. Table VII provides a comparison of drawbacks between
previous research and the OTP protocol. This shows that using
OTP to encrypt and decrypt GOOSE packets is feasible even
though future work is required to improve the protocol.
VI. C ONCLUSION AND F UTURE W ORK
In this paper, it has been proven that encryption and de-
cryption of packets, using One-Time Pads, to secure GOOSE
protocol is possible. Even though the results are a far cry
from those of other research, it must be noted that the
lack of a suitable testing environment is the main cause of
these results. Collaboration between industry and academia
to create a real-time emulator/simulator or an open-source
reconfigurable IED can make testing of proposed research
feasible, for not only this research but for previous and future
work. It can also be noted that the Destination field need
not be encrypted because that address is not the actual address
of any subscriber. Its exposure to the adversary is not a risk
to the network. Encrypting it will increase the computation
overhead of subscribers because every packet would have to
be decrypted to check whether it is meant for them.
Issues also to be considered in future work would be
efficient generation of OTPs, refreshment/update scheme and
prevention of key exhaustion. Two alternatives for key gener-
ation would be looked at - generation within the device and
generation by the elements in the station level. Generation
of OTPs with the device implies that a PRNG that is deter-
ministic among devices and yet appears truly random to the
adversary must be developed. This option means that the key
update/refreshment scheme would only focus on updating the
seed of the PRNG. The generation of OTPs by elements in the
station level implies that OTPs can be stored on the devices
before they are powered up or be transmitted to the devices via
the MMS protocol or any other non real-time protocol. This
means that the key update/refreshment scheme would require
using the MMS protocol or any other-non real-time protocol
to transmit a fresh set of OTPs to the device. Such protocols
can be easily protected by TLS protocol or any public-key
protocol since real-time communication is not required. Period
of refreshment is what must be determined to make the OTP
protocol efficient. This option for the generation of OTPs can
be an ideal option for the protocol.
R EFERENCES
[1] E. Padilla, Substation Automation Systems: Design and Implementation,
2015.
[2] D. Baigent, M. Adamiak, R. Mackiewicz, and G. M. G. M. SISCO,
“Iec 61850 communication networks and systems in substations: An
overview for users,” SISCO Systems, 2004.
[3] S. S. Hussain, M. A. Aftab, and I. Ali, “Iec 61850 modeling of
dstatcom and xmpp communication for reactive power management in
microgrids,” IEEE Systems Journal, no. 99, pp. 1–11, 2018.
 TABLE VII
C OMPARISON OF D RAWBACKS OF P REVIOUS R ESEARCH AND OTP
Protocol Detection of devices Replay
CLPLK Attacker can monitor Replayed packets will be
messages. accepted by devices be-
cause there is no check for
freshness.
NTRU No known drawbacks. Replayed packets will be
Attacker is unable to accepted by devices be-
monitor encrypted pack- cause there is no check for
ets. freshness.
Hybrid RSA and DES No known drawbacks. Replayed packets will be
Attacker is unable to accepted by devices be-
monitor encrypted pack- cause there is no check for
ets. freshness.
OTP No known drawbacks. No known drawbacks.
Attacker is unable to Packets will be dropped
monitor encrypted pack- because of mismatched
ets. keys.
[4] M. Kezunovic, M. Ghavami, C. Guo, Y. Guan, G. Karady, and L. Dam,
“The 21 st Century Substation Design Final Project Report Project
Team,” Tech. Rep., 2010. [Online]. Available: http://www.pserc.org.
[5] S. Nick, G. Nourbakhsh, A. Ghosh, and N. Ghasemi, “CIGRÉ Australia
APB5 SEAPAC 2015 A technique for analysing GOOSE packets when
testing relays in an IEC 61850-8-1 environment,” Tech. Rep. [Online].
Available: https://eprints.qut.edu.au/84005/1/32 AU Nick doc.pdf
[6] “Ieee recommended practice for implementing an iec 61850-based
substation communications, protection, monitoring, and control system,”
IEEE Std 2030.100-2017, pp. 1–67, June 2017.
[7] K. Correll, N. Barendt, and M. Branicky, “Design considerations for
software only implementations of the ieee 1588 precision time protocol,”
in Conference on IEEE, vol. 1588, 2005, pp. 11–15.
[8] F. Cleveland, “Iec tc57 security standards for the power system’s
information infrastructure–beyond simple encryption,” in Transmission
and Distribution Conference and Exhibition, vol. 2006, 2005, pp. 1079–
1087.
[9] M. Hosny Tawfeek Essa and P. Crossley, “GOOSE performance
assessment on an IEC 61850 redundant network,” The Journal of Engi-
neering, vol. 2018, no. 15, pp. 841–845, oct 2018. [Online]. Available:
https://digital-library.theiet.org/content/journals/10.1049/joe.2018.0208
[10] A. Volkova, M. Niedermeier, R. Basmadjian, and H. de Meer,
“Security Challenges in Control Network Protocols: A Survey,” IEEE
Communications Surveys & Tutorials, vol. 21, no. 1, pp. 619–639, 2019.
[Online]. Available: https://ieeexplore.ieee.org/document/8472799/
[11] D. Mei, B. Zhou, J. Zheng, H. Luo, and Y. Yao, “Realization of
Communication Security in Substation,” in 2018 5th International
Conference on Information Science and Control Engineering
(ICISCE). IEEE, jul 2018, pp. 910–916. [Online]. Available:
https://ieeexplore.ieee.org/document/8612688/
[12] J. Noce, Y. Lopes, N. C. Fernandes, C. V. N. Albuquerque, and D. C.
Muchaluat-Saade, “Identifying vulnerabilities in smart gric communica-
tion networks of electrical substations using geese 2.0,” in 2017 IEEE
26th International Symposium on Industrial Electronics (ISIE), June
2017, pp. 111–116.
[13] S. Samtani, S. Yu, H. Zhu, M. Patton, J. Matherly, and H. Chen,
“Identifying SCADA Systems and Their Vulnerabilities on the
Internet of Things: A Text-Mining Approach,” IEEE Intelligent
Systems, vol. 33, no. 2, pp. 63–73, mar 2018. [Online]. Available:
https://ieeexplore.ieee.org/document/8255786/
[14] J. Hoyos, M. Dehus, and T. X. Brown, “Exploiting the GOOSE
protocol: A practical attack on cyber-infrastructure,” in 2012 IEEE
Globecom Workshops. IEEE, dec 2012, pp. 1508–1513. [Online].
Available: http://ieeexplore.ieee.org/document/6477809/
[15] A. Hadbah, A. Kalam, and A. Zayegh, “Powerful IEDs, ethernet
networks and their effects on IEC 61850-based electric power
utilities security,” in 2017 Australasian Universities Power Engineering
Conference (AUPEC). IEEE, nov 2017, pp. 1–5. [Online]. Available:
http://ieeexplore.ieee.org/document/8282415/
Type of Attack
Alteration and spoofing DoS/DDoS
No known drawbacks due to Flooding of devices with unmodi-
authentication and signature fied replay packets will be accepted
fields. by devices.
No known drawbacks due to Flooding of devices with unmodi-
authentication and signature fied replay packets will be accepted
fields. by devices.
No known drawbacks due to Flooding of devices with unmodi-
authentication and signature fied replay packets will be accepted
fields. by devices.
No known drawbacks. Tam- No known drawbacks. Packets will
pering will be detected from be dropped because of mismatched
the FCS field after decryption. keys and integrity errors detected
from the FCS field.
[16] B. Schneier, Applied Cryptography: Protocols, Algorithms, and Source
Code in {C}. New York: Wiley, 1996.
[17] Y. Xu, Y. Yang, T. Li, J. Ju, and Q. Wang, “Review on cyber vulnerabil-
ities of communication protocols in industrial control systems,” in 2017
IEEE Conference on Energy Internet and Energy System Integration
(EI2). IEEE, 2017, pp. 1–6.
[18] M. T. A. Rashid, S. Yussof, Y. Yusoff, and R. Ismail, “A review of
security attacks on iec61850 substation automation system network,”
in Proceedings of the 6th International Conference on Information
Technology and Multimedia. IEEE, 2014, pp. 5–10.
[19] P. Biondi, “Scapy,” 2011. [Online]. Available: https://scapy.net/
[20] J. G. Wright and S. D. Wolthusen, “Stealthy injection attacks against
iec61850’s goose messaging service,” in 2018 IEEE PES Innovative
Smart Grid Technologies Conference Europe (ISGT-Europe). IEEE,
2018, pp. 1–6.
[21] H. Krawczyk, M. Bellare, and R. Canetti, “Hmac: Keyed-hashing for
message authentication,” Tech. Rep., 1997.
[22] A. P. Premnath, J.-Y. Jo, and Y. Kim, “Application of
NTRU Cryptographic Algorithm for SCADA Security,” in 2014
11th International Conference on Information Technology: New
Generations. IEEE, apr 2014, pp. 341–346. [Online]. Available:
http://ieeexplore.ieee.org/document/6822221/
[23] J. Hoffstein, J. Pipher, and J. H. Silverman, “Ntru: A ring-based
public key cryptosystem,” in International Algorithmic Number Theory
Symposium. Springer, 1998, pp. 267–288.
[24] W. Fangfang, W. Huazhong, C. Dongqing, and P. Yong,
“Substation Communication Security Research Based on Hybrid
Encryption of DES and RSA,” in 2013 Ninth International
Conference on Intelligent Information Hiding and Multimedia Signal
Processing. IEEE, oct 2013, pp. 437–441. [Online]. Available:
http://ieeexplore.ieee.org/document/6846671/
[25] J. ZHANG, L. Jun’e, C. Xiong, N. Ming, W. Ting, and L. Jianbo, “A
security scheme for intelligent substation communications considering
real-time performance,” Journal of Modern Power Systems and Clean
Energy, pp. 1–14, 2019.
[26] S. S. Al-Riyami and K. G. Paterson, “Certificateless public key cryp-
tography,” in International conference on the theory and application of
cryptology and information security. Springer, 2003, pp. 452–473.
[27] B. S. Kaliski Jr and C. Redwood City, “A layman’s guide to a subset
of asn. 1, ber, and der,” 1993.
[28] C. Kriger, S. Behardien, and J.-C. Retonda-Modiya, “A detailed analysis
of the goose message structure in an iec 61850 standard-based substation
automation system,” International Journal of Computers Communica-
tions & Control, vol. 8, no. 5, pp. 708–721, 2013.