# Caching-based Multicast Message Authentication in Time-critical Industrial
Control Systems ††thanks: This research is supported by the National Research
Foundation, Prime Minister’s Office, Singapore under its Campus for Research
Excellence and Technological Enterprise (CREATE) programme.

Utku Tefek  Advanced Digital Sciences Center
Singapore
<EMAIL_ADDRESS>Ertem Esiner  Advanced Digital Sciences Center
Singapore
<EMAIL_ADDRESS>Daisuke Mashima  Advanced Digital Sciences Center
Singapore
<EMAIL_ADDRESS>Binbin Chen  Singapore University of Technology
and Design
Singapore
<EMAIL_ADDRESS>Yih-Chun Hu  University of Illinois at Urbana-
Champaign
Illinois, USA
<EMAIL_ADDRESS>
###### Abstract

Attacks against industrial control systems (ICSs) often exploit the
insufficiency of authentication mechanisms. Verifying whether the received
messages are intact and issued by legitimate sources can prevent malicious
data/command injection by illegitimate or compromised devices. However, the
key challenge is to introduce message authentication for various ICS
communication models, including multicast or broadcast, with a messaging rate
that can be as high as thousands of messages per second, within very stringent
latency constraints. For example, certain commands for protection in smart
grids must be delivered within 2 milliseconds, ruling out public-key
cryptography. This paper proposes two lightweight message authentication
schemes, named CMA and its multicast variant CMMA, that perform precomputation
and caching to authenticate future messages. With minimal precomputation and
communication overhead, C(M)MA eliminates all cryptographic operations for the
source after the message is given, and all expensive cryptographic operations
for the destinations after the message is received. C(M)MA considers the
urgency profile (or likelihood) of a set of future messages for even faster
verification of the most time-critical (or likely) messages. We demonstrate
the feasibility of C(M)MA in an ICS setting based on a substation automation
system in smart grids.

###### Index Terms:

industrial control system, IEC 61850, message authentication, multicast

##  I Introduction

In industrial control systems (ICSs), enabling the devices to verify that the
packets originated from their claimed source and have not been modified while
in transit is critical for reliable and trustworthy operation. On the other
hand, many ICSs require low-latency, and often high-volume messaging, which
pose a significant challenge when integrating security mechanisms into the
network. According to the IEEE Power and Energy Society guidelines, periodic
status updates and automated control for protection in a field substation of a
smart grid, e.g., circuit breaker control upon over-current, requires response
time to be 1-2 ms, including all the network-related and processing delays,
and involves up to 4,000 messages per second [1, 2]. Due to this tight
requirement, IEC 61850 — an increasingly adopted standard for substation
automation [3, 4] — utilizes link-layer multicast for sharing emergency event
information with as many as hundreds of devices.

In point-to-point communication settings, the straightforward method of
appending a message authentication code (MAC) to each packet using a shared
secret key allows the destination to perform this verification. While
computationally inexpensive, such symmetric cryptography approaches with a
group key are not secure for broadcast and multicast communication settings,
because any destination in possession of the shared secret key can impersonate
the source and inject forged packets. To prevent this attack, pairwise
symmetric keys are necessary. With pairwise symmetric keys, however, the
source would need to generate a separate MAC for each destination, increasing
the computational load linearly with the number of destinations. Other
downsides are the complicated key distribution and storage overhead. Hence,
one should look for asymmetry between the source and destinations.

Digital signatures are widely used for multicast/broadcast communication, as
signing a packet with a private key enables its verification by any entity
that possesses the corresponding public key. Indeed, digital signatures are
secure for multicast message authentication, and they offer additional
properties such as non-repudiation. IEC 62351-6 standard recommends using RSA
signatures for IEC 61850 GOOSE message authentication [5]. However, one common
drawback of the digital signatures is expensive computations, such as modular
exponentiation (RSA [6]), elliptic curve scalar multiplication (ECDSA [7]),
and cryptographic pairing, which introduce high overhead for signing and
verification, especially on resource-constrained devices (e.g., legacy ICS
devices). There are other methods for generating asymmetry between the source
and destinations while retaining the computational efficiency of symmetric
cryptography. Hash-chains [8] and the notion of delayed key disclosure [9, 10,
11, 12, 13, 14] have been used to authenticate routing updates in routing
protocols. These methods generate time asymmetry between the source and
destinations, hence achieving public verifiability without having to resort to
expensive asymmetric cryptography. However, one major drawback of delayed key
disclosure is that the destinations cannot verify a message until the
corresponding key is disclosed. Clearly, a disclosure delay in the order of a
few messaging cycles is not acceptable for time-critical ICSs.

Besides the constraints, ICS messages have certain domain-related features,
such as structured and predictable message content. ICS messages are
semantically fragmented into predefined fields, each with a relatively small
set of possible values. Some message fields contain predetermined values such
as IDs, sequence numbers, and expiry period known to the source long before
the message is sent. Other fields may contain measurements that constantly
fluctuate around specific values or several binary flags indicating urgent
commands/alerts. The measurement values can be largely predictable due to
their almost constant base value, while the urgent binary values only yield a
limited number of possible outcomes. The limited entropy of ICS messages can
be exploited to accelerate message authentication as elaborated in Section
II-B.

In this paper, we first evaluate several baseline caching approaches that
precompute and store cryptographic evidence — a piece of information to verify
the source and integrity of the message — for potential future messages. These
relatively primitive designs incur significant precomputation and
communication overhead in order to minimize the computations after the message
is given (post-message). Then, we introduce Caching-based Message
Authentication (CMA) and the multicast variant Caching-based Multicast Message
Authentication (CMMA). Given a set of potential future messages, both schemes
precompute and cache cryptographic evidence for a set of possible messages,
hence building a cache for message authentication. The proposed schemes employ
authenticated data structures to mitigate the overhead suffered by the
baseline designs. In particular, we use Huffman Hash Tree (HHT) to ensure
faster verification of urgent or likely messages over relatively time-tolerant
or less-likely messages. C(M)MA relies on symmetric keys hence does not suffer
from the drawbacks of asymmetric cryptography. CMA is based on MACs, and is
suitable when the communication is unicast or the number of destinations is
small. CMMA employs an adaptation of delayed key disclosure. Thus its overhead
does not depend on the number of destinations, making it suitable for
multicast/broadcast communication, however it requires loose time
synchronization. Despite the delayed disclosure of keys, CMMA does not suffer
from the disclosure delay of such schemes, as discussed in Section IV-B. To
our knowledge, we are the first to demonstrate the feasibility and
practicality of multicast message authentication using a precomputation cache
for low-latency, high-rate ICS communication on resource-constrained devices.

##  II Approach

###  II-A Design Goals and Threat Model

In ICSs in general, ensuring message integrity and authenticity is critical
for defending against threats. For instance, verifying that the
commands/messages have been initiated only by trusted devices and have not
been altered by an unauthorized party can thwart malicious command injection
and false data injection attacks. In the power grid system, as is the case
with many other ICSs, timely communication among the devices is imperative. In
the modernized power grid systems, IEC 61850 GOOSE (Generic Object Oriented
Substation Event), a link-layer multicast, publisher-subscriber communication
protocol, is used among a predefined group of devices, e.g., intelligent
electronic devices (IEDs) and programmable logic controllers (PLCs), for
regular status updates and urgent control communication. The status updates
are announced both regularly and in an on-demand manner whenever the status or
measurement of the power grid device is updated, and messages for propagating
events such as over current and automated protection control (e.g., opening
circuit breakers) require very short latency (1-2 ms) [1, 15]. Besides the
end-to-end latency, throughput requirement also poses a challenge. For
instance, IEC 61850 SV (Sampled Value) protocol has almost the identical
message structure and communication model, but it is sent with a constant and
much higher rate (e.g., 4,000 messages/sec) [3, 4].

We consider typical remote attackers for false data injection attacks [16],
where attackers have a footprint in the system (e.g., via compromised VPN [17]
and malware [18]). Such remote attackers could inject arbitrary packets and
observe network traffic. However, they are unable to manipulate the
configuration of devices (e.g., installation of malicious software/firmware)
since the configuration of ICS devices is typically done through local, serial
connections. Against this threat model, we aim to design a message
authentication mechanism that incurs minimal overhead even for multicast
traffic and is also verifier-efficient. Such a defense mechanism is to be
deployed on ICS devices or Bump-in-the-wire (BITW) devices in front of them.
Note that BITW devices are not addressable and thus not accessible to remote
attackers in our scope.

###  II-B Entropy of ICS Messages

At the high level, our approach to reducing the latency in authenticating ICS
messages involves precomputation and caching of the cryptographic evidence for
potential future messages. Such a strategy could be feasible when the timing
and content of ICS messages are, to some extent, predictable. While we target
ICSs in general, in this section, we discuss the entropy of ICS messages by
using IEC 61850 GOOSE as a concrete example.

Figure 1: The contents of the GOOSE Protocol Data Unit.

As shown in Fig. 1, a GOOSE Protocol Data Unit (PDU) consists of a GOOSE
control block reference (gocbRef), a two-byte long timeAllowedtoLive field
specifying the lifetime of the message, an identifier of the dataset included
(datSet), a GOOSE ID (goID), an 8-byte long timestamp (t), a status number
(stNum), a sequence number (sqNum) which is incremented by one or rolled over
to zero upon each packet transmission, a test bit test, configuration revision
(confRev) and needs commissioning (ndsCom) flags, and the number of user-
defined data entries (numDatSetEntries) [19, 20]. The last portion of the
GOOSE packet is the allData field, which stores device/alarm status and
measurements.

The prediction of GOOSE PDU fields is trivial except for the timestamp t and
user-defined allData field. For example, either the status or sequence number
is incremented by one in each packet, gocbRef and datSet fields are known from
the IED’s configuration file (called IEC 61850 SCL file), and confRev, ndsCom,
test, timeAllowedtoLive values are static for a given system and source-
destination(s) setting. t is (not the timestamp of the message itself, but)
the timestamp of the last status change, and thus remains the same until the
next change. An approximate timestamp value would be sufficient for messages
to be accepted at their destination given that timeAllowedtoLive is typically
greater than 100 ms, much larger than the targeted latency of 1-2 ms. The data
conveyed in allData field consists of several binary values or a few multi-
byte values to convey current, voltage, frequency readings depending on the
type of dataset in the GOOSE message. Based on our observation from the SCL
files of Electric Power and Intelligent Control (EPIC) testbed in the
Singapore University of Technology and Design, there are three types of
messages: Control, Protection, and Measurement. Control data includes two
boolean values indicating circuit breaker status and a quality value
(generally “0000”) associated with each. Similarly, the Protection data
contains a boolean field indicating a fault occurrence, the same quality
value. The prediction of these binary values is viable given the limited space
for possible outcomes.

Measurement data involves 10-12 measurements, each consisting of several bytes
representing voltage, current, or frequency. Such measurements fluctuate
within a certain range (e.g., around 49.9-50.1 Hz) and do not change markedly
over time. Using a prediction method (e.g., [21], [22]) can narrow down the
space further. Thus, the set of possible measurements can be reduced to a much
smaller set of Measurement packets to be prioritized. While predicting a large
number of measurements is often non-trivial, Measurement packets are not as
time-critical as Protection and Control packets. Thus, our scheme can still be
opportunistically applied to Measurement packets with lower priority, as shown
in Section IV.

##  III Baseline Caching-based Approaches

To meet the stringent latency constraints (illustrated as ‘Delay threshold’ in
Fig. 2), a straightforward solution is to use lightweight cryptographic MAC
without any need for message prediction. Such methods based on symmetric
cryptography enable very fast message authentication in unicast settings,
however, in the case of multicast or broadcast, the source needs to calculate
cryptographic evidence separately for each recipient (using pairwise shared
secret keys), which increases the computation time at the publisher linearly
with the number of recipients. Such no precomputation setting is illustrated
in Fig. 2(a), and its performance is given in Table I.

Figure 2: Processing loads and packet delays under different designs. The scaling does not represent true values. TABLE I: Complexity analysis. N: number of subscribers, k: number of unpredictable binary fields, ku: number of unpredictable binary fields in an urgent message ($k_{u}<k$), R1: message arrival rate, R2: $1/$timeAllowedtoLive, $D$: depth of the true message. Design |  # of secure hashing in post-message |  # of secure hashing at the publisher |  # of secure hashing at the subscriber |  communication overhead
---|---|---|---|---
No precomput. |  2N |  2N $\times$ R1 |  2R1 |  N $\times$ R1
Predict-one |  $\sim$0 |  2N $\times$ R2 |  2R1 |  N $\times$ R1
Precompute-all |  0 |  2N $\times$ 2k $\times$ R2 |  2R1 |  N $\times$ R1
State change |  $\sim$2N |  2N $\times$ (R${}_{1}+$2${}^{k_{u}}\times$R2) |  2R1 |  N $\times$ R1
CMA w/ MHT |  0 |  (2N$+2^{k+1}$ $-1$) $\times$ R2 |  ($k+$3) $\times$ R1 |  N $\times$ $(k+2)$ $\times$ R1
CMA w/ HHT |  0 |  (2N$+2^{k+1}$ $-1$) $\times$ R2 |  ($D+$3) $\times$ R1 |  N $\times$ $(D+2)$ $\times$ R1
CMMA w/ MHT |  0 |  (3$+2^{k+1}$) $\times$ R2 |  ($k+$5) $\times$ R1 |  ($k+$3) $\times$ R1
CMMA w/ HHT |  0 |  (3$+2^{k+1}$) $\times$ R2 |  ($D+$5) $\times$ R1 |  ($D+$3) $\times$ R1

Based on the IEC 61850 GOOSE specification, messages are sent at arbitrary
times whenever a change occurs or at regular intervals in the case of no
change. The source can cache the cryptographic evidence within each
timeAllowedtoLive period. If the source caches cryptographic evidence in
anticipation of a state change, but no state change occurs within that
timeAllowedtoLive period, the cache is not used and discarded. This results in
a higher rate of cache build-up than the actual message arrival rate. Thus,
the rate required to build cache for a message (R2 = $1/timeAllowedtoLive$)
would be greater than the actual message arrival rate (R1).

Predict-one design: This design significantly reduces the average processing
delay by caching the cryptographic evidence for only a single prospective
message (preferably, the message with the highest probability to be sent),
before the actual message is given. The second row of Table I shows the
required number of secure hash operations post-message. Fig. 2(b) illustrates
the processor loads and packet delays for a case where the first two
predictions hold true; hence the delays are minimal. However, the third
prediction is wrong, and the evidence for the “surprise” message needs to be
generated on-the-fly, and this will still incur a delay as large as the no
precomputation setting. Predict-one design would only be suitable for systems
that require low average communication delay, but can tolerate higher delay
occasionally for surprise messages.

Precompute-all design: If the source could cache the cryptographic evidence
for all the possible prospective messages, it would avoid cryptographic
operations in the post-message phase. As shown in Fig. 2(c), this design is
feasible if precomputing a MAC for each possible message and destination is
within the computing capability of the source hardware. This design ensures a
delay upper bound at the cost of increased computation load. However, the
computation load grows exponentially with the number of unpredictable binary
fields in a message.

Prepare for state change: As discussed in Section II-A, the periodic reporting
messages of GOOSE can typically tolerate some delay, while the timely delivery
of urgent control messages (triggered by an unexpected event such as a circuit
breaker failure) is critical. In this design, the source always caches the
cryptographic evidence only for such urgent messages. Although the load for
precomputing for the urgent messages still grows exponentially with the number
of binary fields in an urgent message ($\sim$N $\times$
2${}^{\textnormal{k}_{u}}$ $\times$ R2), this is still lower than the
precompute-all design, since such urgent messages report a smaller number of
unpredictable binary fields, i.e., k${}_{u}<$ k. The first two messages in
Fig. 2(d) are periodic messages containing no state change. Therefore, the
source has to generate the cryptographic evidence for the actual message after
its arrival, incurring a delay equivalent to that of the no precomputation
setting. When an urgent message arrives as in the third one, the delay is much
smaller because the cryptographic evidence has already been cached.

Although the baseline approaches can be useful in certain settings, they rely
on heavy precomputation to reduce message authentication delay. The
precomputation and communication loads increase dramatically with the number
of unpredictable binary fields and the number of destinations. Next, we
discuss the use of authenticated trees and their integration with delayed key
disclosure, which results in smaller loads and delays as illustrated in Figure
2(e)-(f).

##  IV Caching-based (Multicast) Message Authentication

Using authenticated data structures, C(M)MA reduces the precomputation load
and communication overhead. Instead of computing cryptographic evidence
separately for each message, the source constructs a binary tree on the set of
prioritized messages, and uses the tree’s root as an aggregate prioritization
outcome. This root is shared with the destination(s) in the pre-message phase.
Thus, instead of sharing each possible or prioritized future message and their
corresponding evidence separately, the source caches the binary tree, then
shares its root (and a proof to authenticate it), which serves as a public
meta-data to authenticate the true message, provided that the true message is
among the set of prioritized messages. We present the use of MACs, as well as
an adaptation of TESLA protocol [10] to authenticate the root.

Analogous to the construction of minimum redundancy codes [23], Huffman Hash
Tree (HHT) is constructed on the possible messages, in a way that the expected
depth of the leaf corresponding to the true message is minimized. To achieve
this, the depth of the leaf corresponding to a certain message is set to the
equivalent of the coding length of that message in Huffman Coding. As
illustrated in Figure 3, this setup situates the prioritized messages (e.g.,
$m_{i,1}$) closer to the root. Since Merkle Hash Tree (MHT) is a special case
of HHT where the frequencies or delay tolerance profiles of different messages
are equal, we provide our example over an HHT. In an HHT implementation, the
most likely messages, such as the expected measurements, or alternatively the
most delay stringent messages (e.g., certain alerts) can be placed closer to
the root.

Figure 3: C(M)MA model. $m_{i,1}$ is the most delay stringent (or likely)
message, followed by $m_{i,2}$.

###  IV-A CMA for Unicast ICS Communication

In the following, we describe the protocol using MACs to authenticate the
root.

Initialize($\lambda$)$\longrightarrow${$\mathcal{K}$} : In this procedure,
given the security parameter $\lambda$, the source establishes pairwise
symmetric keys $K=\\{sk_{1},\ldots,sk_{N}\\}$ with each destination. This
procedure is performed only during initialization, and repeated for every $L$
messages.

Prioritize(preferences, system data)$\longrightarrow${$M_{i}$, $P_{i}$}: The
input to the Prioritize procedure includes operator’s preference (e.g., in
terms of message type or target devices to prioritize) and historical system
data. The output consists of the set of possible messages
$M_{i}=\\{m_{i,1},\ldots,m_{i,2^{k}}\\}$, and (if available) the normalized
weight of each message $P_{i}=\\{p_{i,1},\ldots,p_{i,2^{k}}\\}$ (based on
probabilities or tolerable delays), such that $\sum_{j=1}^{2^{k}}p_{i,j}$=1,
for time interval $i\in\\{1,\ldots L\\}$. The output {$M_{i}$, $P_{i}$} is
collectively referred to as the prioritization outcome. Whenever
timeAllowedtoLive is about to expire, or a new input is available, the
procedure is repeated.

Tree construction($M_{i}$, $P_{i}$, $K$, $ts_{i}$)$\longrightarrow${treei,
rooti, $S_{i}\\}$: The inputs to this procedure are $M_{i}$, $P_{i}$ obtained
from the output of the Prioritize procedure, the symmetric keys $K$ shared
with each destination, and the timestamp $ts_{i}$ for freshness. The outputs
are the tree treei, its root value rooti, and the set of HMACs
$S_{i}=\\{s_{i,1},s_{i,2},\ldots,s_{i,N}\\}$ calculated from rooti, using the
corresponding shared key of each destination $n\in\\{1,\ldots,N\\}$. The
constructed tree binds the prioritized messages to a root value rooti. To
prevent an adversary from predicting the messages and hence calculating the
same root value, each message is concatenated with a nonce in
$\\{r_{i,1},\ldots,r_{i,{2^{k}}}\\}$ before calculating the leaf values. Then,
the root is obtained by pairwise hashing of sibling nodes starting from the
deepest nodes. Finally, the root is timestamped and shared with the
destination(s) along with its HMAC, calculated separately for each destination
using the pairwise symmetric keys established in the Initialize procedure. In
other words, $s_{i,n}=$ $HMAC(sk_{n},ts_{i},\textnormal{root}_{i})$ is shared
with destination $n$, $\forall n\in\\{1,\ldots,\textnormal{N}\\}$, where
$sk_{n}$ is the key shared between the source and destination $n$, and
$ts_{i}$ is the timestamp for the corresponding interval. The tree is only
known to the source at this point, thus serves as the private meta-data.

Prove($m_{i,t}$, treei)$\longrightarrow${proofi}: The inputs are the true
message $m_{i,t}$, and the $tree_{i}$ constructed in the previous procedure,
and the output proofi is a collection of values from the tree between
$m_{i,t}$ and the root. After the true message (say $m_{i,t}$) is known to the
source, it sends $m_{i,t}$ and the other corresponding values of the HHT as
proofi to allow the destination(s) to calculate the root value. For example,
if $m_{i,t}=m_{i,2}$ in Fig. 3, the proof contains
$\\{r_{i,2},H_{i,1},H_{i,3},H(H_{i,4}\|H_{i,.})\\}$. No hash operations are
performed in this procedure.

Next, we introduce the steps at the destination device(s).

Pre-Verify($sk_{n}$, $s_{i,n}$, rooti)$\longrightarrow${accept, reject}: For
destination $n$, the inputs are the shared key $sk_{n}$, the root rooti and
its HMAC $s_{i,n}$ sent by the source following its Tree Construction
procedure. When the destination $n$ receives the root value rooti and its
claimed HMAC $s_{i,n}$, it verifies rooti using the shared key $sk_{n}$
established in the Initialize procedure. If accepted, rooti is stored for a
timeAllowedtoLive period. Note that this pre-verification is done before the
actual message is given to the destination device.

Verify($m^{\prime}_{i,t}$, proofi, rooti)$\longrightarrow${accept, reject}:
The inputs are the message $m^{\prime}_{i,t}$ to be verified, its proof
proofi, sent by the source following its $Prove$ procedure and the stored root
value rooti corresponding to the ith interval. Once the message
$m^{\prime}_{i,t}$ and its proof (corresponding values of the HHT) are
received, the destination calculates the root by traversing the tree to
retrieve hashes of siblings of nodes on a path between the leaf holding
$m^{\prime}_{i,t}$ and a root of the hash tree. Finally, the destination
compares the calculated root with the previously stored roots which had been
received within the last timeAllowedtoLive duration. If a match is found,
$m^{\prime}_{i,t}$ is authenticated.

###  IV-B CMMA for Broadcast/Multicast ICS Communication

Using binary trees to combine the prioritization outcome into a single root
value reduces the communication overhead and the computation overhead of the
source. However, the factor of $N$ still appears in the corresponding
complexity expressions in Table I, because the cryptographic evidence to prove
the root integrity is generated separately for each destination. In a
multicast setting, to avoid computing MACs separately for each destination, we
need to introduce a source of asymmetry between the source and destinations.
The asymmetry ensures that the destinations can only verify the prioritization
outcomes, but not generate valid evidence for them. We use an adaptation of
TESLA protocol [10] to introduce time asymmetry while relying on the
reasonable assumption that the destinations are loosely time synchronized with
the source in a smart grid.

The plain TESLA protocol: We first discuss how the plain TESLA protocol
operates. The source generates a hash chain by iteratively applying a one-way
function $H$ — constructed using a pseudorandom function family — starting
from a random number $C_{L}$. That is, $C_{i-1}=H(C_{i})$, $\forall
i\in{1,\ldots,L}$ hence producing the sequence, $C_{0},C_{1},\ldots,C_{L}$ in
the reverse order of generation. Since $H$ is one-way, no user other than the
source knows $C_{i}$ given $C_{i-1}$. However, any user possessing $C_{0}$ can
readily verify if a given $value$ belongs to the hash chain (and hence
generated by the source) by checking if $H^{i}(value)=C_{0}$ for some $i$.

After generating the hash chain, the source distributes $C_{0}$ to every
destination securely, e.g., using digital signatures, or using the commitment
of the previous hash chain ($C_{L}$) if any. To authenticate each message, the
source computes and attaches the MAC using the key chain in the reverse of
generation: $C_{1},C_{2},\ldots,C_{L}$. I.e., for the $j$’th message, $C_{j}$
is used.111In TESLA protocol another one way function $H^{\prime}$ — derived
in the same way as $H$ — is applied on $C_{i}$’s to derive the actual keys
used in MAC computation. This is because using the same key both to derive the
hash chain and to compute MACs may lead to cryptographic weaknesses. Also
along with the $j$’th message, the source reveals the key $C_{i}$, which was
used to compute the MAC of the earlier $i$’th message, so that the
destination(s) can verify the authenticity of message $i$ by checking
$H^{i}(C_{i})=C_{0}$, or simply $H(C_{i})=C_{i-1}$ if the destination
possesses $C_{i-1}$. $d=j-i$ number of messaging intervals is the disclosure
delay of TESLA, and ensures source-destination(s) asymmetry without having to
resort to expensive public key cryptography.

In TESLA, one MAC per message is sufficient to provide broadcast/multicast
authentication, provided that the destinations have loose time synchronization
with the source. However, the major drawback of TESLA (or delayed key
disclosure schemes in general) is, the delay in verification of each message,
introduced by the disclosure delay. Clearly, disclosure delay in the order of
a few messaging intervals (i.e., larger than the sum of maximum network delay
and synchronization error) is not tolerable in the time-critical setting we
are targeting.

CMMA: CMMA relies on authenticating the prioritization outcomes with TESLA,
rather than the true message itself, as shown in Fig. 4. Therefore, it does
not suffer from the disclosure delay of TESLA, despite using it to introduce
source-destination asymmetry. Next, we describe the procedures.

Figure 4: The disclosure schedule of CMMA.

Initialize($C_{L}^{\prime}$)$\longrightarrow${$C_{0},\ldots,C_{L}$, proof for
$C_{0}$}: This procedure outputs a key chain of $L+1$ values, and the proof
for the first value by using the commitment of the previous hash chain,
$C_{L}^{\prime}$. The source selects a random number $C_{L}$, and commits it
to generate a hash-chain of length $L+1$, by repeatedly applying a one-way
function $H$, such that $C_{i-1}=H(C_{i})$, $\forall i\in{1,\ldots,L}$. We
call $\\{C_{i}\\}$’s as the TESLA keys and they are used in the reverse order
of generation, i.e., from $C_{1}$ to $C_{L}$, to authenticate the root values
for the messages in the next $L$ time intervals. Finally, the source generates
a proof for the first TESLA key $C_{0}$ and the key disclosure schedule using
the commitment of the previous hash chain ($C_{L}^{\prime}$) if any, otherwise
digitally signs $C_{0}$ and the key disclosure schedule before sending them to
the destination(s).

As stated above, in TESLA another hash function $H^{\prime}$ is applied on
$C_{i}$’s to derive the actual keys used in MAC computation. Thus, we follow
the same rule and use another set of keys derived from the TESLA keys,
$C_{i}^{\prime}=H^{\prime}(C_{i})$, $\forall i\in{0,\ldots,L}$, to compute the
MAC for messages in the next $L$ time intervals.

Prioritize(preferences, system data)$\longrightarrow${$M_{i}$, $P_{i}$}: This
procedure is the same as the Prioritize procedure of CMA above.

Tree Construction($M_{i}$, $P_{i}$, $C_{i}$, $ts_{i}$)$\longrightarrow${treei,
rooti, $s_{i}$}: The inputs to this procedure are $M_{i}$, $P_{i}$ obtained
from the output of the Prioritize procedure, the TESLA key $C_{i}$ for time
interval $i$, and the timestamp $ts_{i}$. The outputs are the tree treei, its
root value rooti, and the MAC $s_{i}$ for $root_{i}$, computed using $C_{i}$.
In this procedure, the source constructs an HHT on the set of prioritized
messages. Since an adversary can also predict such messages, each leaf node
should be nonced with a random value in $\\{r_{i,1},\ldots,r_{i,{2^{k}}}\\}$.
The source then computes a MAC for the tree’s root, rooti, using the hash of
the corresponding TESLA key $C_{i}$, such that
$s_{i}=HMAC(H^{\prime}(C_{i}),ts_{i},\textnormal{root}_{i})$. $s_{i}$ is
shared with the destination(s) and serves as the public meta-data. The tree is
only known to the source, thus serves as the private meta-data. Note that only
a single public meta-data value $s_{i}$ is computed for all destinations.

Prove($m_{i,t}$, treei)$\longrightarrow${proof}: The inputs are the true
message $m_{i,t}\in M_{i}$, and the $tree_{i}$ constructed in the previous
procedure, and the output proofi is a collection of values from the tree.
After the true message $m_{i,t}$ is known to the source (say $d$ time
intervals later), it sends $m_{i,t}$ and the corresponding values of treei
that will allow the destination(s) to calculate rooti. The source also
discloses the TESLA key $C_{i}$ together with the message to allow the
destination(s) to verify rooti. Note that the TESLA key $C_{i}$ used to verify
the rooti is disclosed in time interval $d+i$ to create time asymmetry between
the source and destination(s), but this disclosure delay is not reflected in
the authentication of $m_{i,t}$, as long as the prioritization outcome
precedes the true message by more than the minimum disclosure delay allowable
by the system.222The disclosure delay depends on the level of time
synchronization, and the network delay between the source and destination(s).
Typically, the disclosure delay should be the sum of the network delay and
synchronization error [11].

Pre-Verify: This step is null in CMMA.

Verify($C_{i},C_{i-1},s_{i},m_{i,t}$, proofi)$\longrightarrow${accept,
reject}: The inputs are TESLA keys $C_{i},C_{i-1}$, the MAC $s_{i}$ of
$root_{i}$, the true message $m_{i,t}$ and the proof proofi for the true
message. In this procedure, first, the destination verifies the TESLA key
$C_{i}$ using a previously disclosed key, e.g., $H(C_{i})=C_{i-1}$. If
$C_{i-1}$ was not received due to packet loss etc., the destination can still
verify $C_{i}$ by repeatedly applying $H$ on $C_{i}$ to obtain the last
received TESLA key, i.e., $H^{j}(C_{i})=C_{i-j}$. If verified, $C_{i}$ is used
to verify the true message, and also stored to verify the future values of the
hash chain to be received. Then, using the proofi, the destination traverses
the tree to retrieve hashes of siblings of nodes on a path starting from the
leaf holding $m_{i,t}$, hence calculates the root value. Finally it verifies
if $s_{i}=HMAC(H^{\prime}(C_{i}),ts_{i},\textnormal{root}_{i})$. If verified,
the true message is authenticated.

###  IV-C Performance and Security Analysis

We discuss the complexity of CMA and CMMA over Table I. In both schemes the
source does not perform any computations other than memory reads and packet
assembly in the post-message phase. It simply collects the corresponding
values from the tree and piggybacks them to the message. For the pre-message
phase, given $k$ possible binary fields and hence $2^{k}$ possible messages in
a prioritization outcome, the binary tree can be constructed with $2^{k+1}-1$
hash operations (i.e., $2^{k}$ to generate the leaves, plus $2^{k}-1$ to
construct the rest of tree). Given prioritization outcomes at a rate of R2,
the required computing rate at the source to generate the binary tree would be
$({2^{k+1}-1})$R2 number of secure hash operations per unit time. The tree
generation complexity is common for both CMA and CMMA. Added to this is the
generation of MACs, which requires $2\textnormal{N}$R2 secure hashing
operations (two per destination, per tree) for CMA and $4$R2 secure hashing
operations (two for the MAC of root, one for deriving the TESLA key and one
for the key of MAC from the TESLA key) for CMMA per unit time. So the total
computing load at the source would be $({2\textnormal{N}+2^{k+1}-1})$R2 for
CMA and ($3+2^{k+1}$) $\times$ R2 for CMMA.

In CMA the destination verifies the root before (Pre-Verify), and the proof
after (Verify) the message is received. The root verification in the Pre-
Verify procedure uses MACs, and demands a computing rate of $2$R1 secure
hashing both for MHT and HHT variants. For a MHT, proof verification in the
Verify procedure costs $(k+1)$R1 secure hashing operations. The verification
complexity of the HHT proof depends on where the received message is located
on the tree. The required computing load is $2$R1 for the message at depth
$1$, and $(D+1)$R1 in general, where $D$ is the depth of the actual message in
the HHT, and $D\leq 2^{k}-1$. So, the total computing load at the destination
is between $4$R1 and $(2+2^{k})$R1 for HHT and $(k+3)$R1 for MHT variants. In
CMMA in addition to the computations above, the corresponding TESLA key is
verified using the previously disclosed TESLA key, and the key of the MAC is
generated from it, each costing a secure hashing. Therefore the computing load
is $2$R1 more than the CMA variant.

The proof size is $(k+1)$ hash values for MHT, and $(D+1)$ for HHT, which
yields 2 for the most likely (or delay stringent) message in CMA. Adding the
MAC to the proof contributes one more hash value to the communication
overhead. In CMA the proof is communicated separately to $N$ destinations,
hence bringing the total communication overhead to $N(k+2)$ and $N(D+2)$ for
MHT and HHT variants. In CMMA the same proof and MAC, as well as the
corresponding TESLA key, are shared with all destinations, totaling $N(k+3)$
and $N(D+3)$ hash values for its MHT and HHT variants.

In C(M)MA a nonce is released when the message corresponding to that nonce is
sent. Therefore, a nonce should be refreshed once that happens. If a
probabilistic polynomial time adversary can find any set of values that give
the same root value without knowing the nonces, we can either break the
preimage resistance or the collision resistance of the hash function employed.
For 128-bit security, one should use 256-bit nonces and a secure hash
function, such as SHA-256.

###  IV-D Security Proof Sketch

In line with the threat model in Section II-A, we consider an adversary that
forges a signature for any message of his choice, where the message does not
necessarily have any particular format or meaning, but has never been signed
by the legitimate source. Hence, we consider the existential forgery game
under adaptive chosen-message attack.

There are two steps to consider in the proof of security; one for the secure
transmission of the root (binding the aggregate prioritization outcome) and
one for the authentication of the true messages. The first is as secure as the
employed MAC (for CMA) or TESLA (for CMMA). For the second, we show that our
scheme is secure if the hash function employed for the authenticated data
structure is collision and preimage resistant.

If a probabilistic polynomial time (PPT) adversary $\mathcal{A}$ wins security
game of our scheme with non-negligible probability, we use it to construct
other PPT algorithms $\mathcal{B}$ or $\mathcal{B}^{\prime}$ who break with
non-negligible probability, the collision resistance or the preimage
resistance of the hash function, respectively. $\mathcal{B}$ acts as the
adversary in the security game with the hash function challenger
$\mathcal{HC}$. In parallel, $\mathcal{B}$ plays the role of the challenger in
our game with $\mathcal{A}$. Consider the following existential forgery game
under adaptive chosen-message attack:

Setup: $\mathcal{HC}$ picks a secure hash function (hash) from a hash function
family — we use SHA-256 in our implementation — and passes the parameters to
$\mathcal{B}$. $\mathcal{B}$ generates a set of nonce values of size
equivalent to the maximum possible size of the prioritized message set.

Query: $\mathcal{A}$ generates a set of values (messages and relative
probabilities) and passes it to $\mathcal{B}$ to be used as the prioritization
outcome. $\mathcal{B}$ builds a tree333Each tree is of size equivalent to the
maximum number of prioritized messages, which is bounded by a constant. on the
prioritization outcome. In particular, $\mathcal{B}$ calculates the hash
values using hash for every node of the tree and passes the root hash value
($root_{i}$ for the $i$th query) to $\mathcal{A}$. $\mathcal{B}$’s load is
constant in this step, given that each prioritization outcome is of constant
size $c$ and creating the tree is linear in $c$ (specifically, $2c$).
$\mathcal{A}$ then picks a message $m_{i}$ among the set of generated messages
for the $i$th query, and passes it to $\mathcal{B}$. $\mathcal{B}$ performs
the Prove procedure using $m_{i}$ as the true message, hence collects the
nonce value from the corresponding leaf and the neighboring values on the path
from the leaf to the root (collectively called $proof_{i}$ for query $i$),
then passes them to $\mathcal{A}$. $\mathcal{A}$ can repeat this query for
polynomially many ($p$) times. After query $i$, $\mathcal{B}$ refreshes the
consumed nonce, which is revealed to generate $proof_{i}$.

Challenge: $\mathcal{A}$ prepares and sends another message $m^{\prime}$ where
$m^{\prime}$ $\neq$ $m_{i}$, $\forall i\in\\{1,\ldots,p\\}$ and a set of
values (proof′) that are required to calculate the hash value of the root
$root_{i}$, in any query $i\in\\{1,\ldots,p\\}$ that $\mathcal{A}$ picks.

If $\mathcal{B}$ verifies the proof′ and $m^{\prime}$ with $root_{i}$ for any
$i\in\\{1,\ldots,p\\}$, using the Verify procedure, then $\mathcal{A}$ wins.
For this, $\mathcal{A}$ needs to find a nonce value that has not been revealed
to it or needs to come up with a new set of values, which, when chained
together with the given hash function hash, yield any $root_{i}$. For the
former, the probability that $\mathcal{A}$ finds a nonce that has not been
revealed to it is negligible, since otherwise, we can define a
$\mathcal{B}^{\prime}$ that breaks the preimage resistance of hash. For the
latter, $\mathcal{B}$ uses the new set of values to break the security of the
given hash function (by finding a collision in hash) using the collision on
the chain from the leaf node corresponding to $m^{\prime}$ to the root.

##  V Implementation and Evaluation

We used BeagleBoard-X15 (BBX15 for short) with a single active core for
measuring the computation times in the schemes discussed in this paper. The
reason for choosing BBX15 is its relatively low-cost, and its port selection
that accommodates a Bump-in-the-wire (BITW) deployment, a desirable feature
for legacy compliance. Detailed specifications of BBX15 can be found in [24].
The HHT generated in the Tree construction steps of C(M)MA is stored in the
RAM. All data points presented are the average of 500 runs. The security
parameters for each implemented scheme are chosen to meet 128-bit security, in
particular, SHA-256 as the digest function, 256-bit nonces, and curve P-256 in
ECDSA.

We have measured the average time taken for subtasks of the baseline designs,
CMA and CMMA, as well as the widely used ECDSA. For ECDSA plots, we assumed
the same authenticated tree based approach to bind prioritization outcomes
into a single root value, but used ECDSA to authenticate the root. In other
words, the source signs the tree’s root with ECDSA, instead of generating a
MAC for the root in the Tree construction procedure as in C(M)MA.
Consequently, the Pre-Verify step of “tree with ECDSA” involves the
verification of ECDSA signature. Since the post-message signing consists only
of memory reads and packet assembly (see the Prove procedures of CMA and CMMA
in Sections IV-A and IV-B), it is performed virtually instantly, and hence not
evaluated.

###  V-A Precomputation Time

The precomputation time does not contribute to the delay overhead as long as
it is shorter than a messaging interval, yet it determines the maximum
messaging throughput. Fig. 5 compares CMA and CMMA with “tree with ECDSA” and
the baseline approach of precompute all, over the number of destinations,
assuming 32 prioritized messages. As can be seen, the precomputation time
increases with the number of destinations for precompute-all, and CMA schemes.
This is because the source needs to precompute a separate proof for each
destination, using the corresponding pairwise symmetric keys. Nevertheless,
the amount of increase in CMA is much smaller thanks to the use of
authenticated trees rather than generating a separate proof for each
prioritization outcome. The precomputation times in CMMA and ECDSA do not
depend on the number of destinations due to the time asymmetry for the former,
and key asymmetry for the latter. CMMA outperforms ECDSA thanks to the use of
symmetric keys.

Figure 5: Precomputation time over the number of subscribers.

In Fig. 6, precomputation time is plotted over the number of
predicted/prioritized messages. All schemes suffer increased precomputation
time due to multiple MAC computations in precompute-all and due to larger tree
size in tree-based schemes (i.e., CMA, CMMA, and tree with ECDSA). At 32
messages, the precomputation times for CMMA and CMA are 210-250 $\mu$s. If the
true message is always in the set of prioritized messages, C(M)MA, therefore
potentially supports the throughput of 4000 messages per second in IEC 61850
SV. CMMA’s precomputation time is the shortest, outperforming tree’d ECDSA
with approximately 23 $\mu$s margin regardless of the number of subscribers or
messages in Figures 5 and 6. Although the 23 $\mu$s difference is not very
large, the main drawback of ECDSA is its verification time, as discussed next.

Figure 6: Precomputation time over the number of messages.

###  V-B Verification Time

Since the Prove procedure is virtually instant in CMA and CMMA the post-
message verification time is the largest contributor to the authentication
delay.

In Fig. 7 we show the verification time of CMMA and CMA with the HMAC as a
benchmark, since MACs (in straw man and precompute-all design) have the
smallest verification time (4 $\mu$s). HHT based CMMA and CMA constructions
have lower average verification times than those with MHT because the average
depth of the actual message is minimized in HHT (assuming message likelihood
based HHT). The best case for HHT based construction would be when the most
likely message is the true message.

Figure 7: Verification time over the number of messages. ECDSA is 2500 $\mu$s,
therefore off the scale. Distribution 3 is assumed.

In the plain TESLA protocol, the disclosure delay is added to the verification
time, therefore, it would incur significantly larger verification delay than
C(M)MA. As a rough comparison, even under ideal circumstances, e.g., perfect
source-destination synchronization, zero network delay, the highest rate of
4000 messages/second in IEC 61850 SV [25], and a minimal disclosure delay of
one interval, TESLA would incur 250 $\mu$s compared to several $\mu$s of
C(M)MA.

In Fig. 8, we illustrate how the probability distribution of future messages
affects the verification time of C(M)MA with HHT. We only show CMMA on this
figure for brevity (CMA would be 6-8 $\mu$s faster). Given that there are
$2^{k}$ possible messages, the four probability distributions we consider are:

Figure 8: Verification time under different probability distributions for
prioritized messages.

  1. Distribution 1:

We draw samples of $2^{k}$ i.i.d exponential random variables and normalize
their sum to $1$

  2. Distribution 2:

$\Pr(m_{i})=2^{-i}$, for $i\leq 2^{k}-1$, $\Pr(m_{2^{k}})=2^{-2^{k}+1}$

  3. Distribution 3:

$\Pr(m_{1})=0.5$, $\Pr(m_{i})=0.5/(2^{k}-1)$ for $i\geq 2$

  4. Distribution 4:

$\Pr(m_{1})=0.9$, $\Pr(m_{i})=0.1/(2^{k}-1)$ for $i\geq 2$

As can be seen from Fig. 8, CMMA with HHT performs significantly better than
CMMA with MHT, when certain messages have a markedly higher probability than
others (distributions 2 and 4). In particular, distribution 4 yields the best
results, because message 1, with a much lower depth in the HHT, is the message
to be authenticated in 9 out of every 10 messaging intervals. This is also in
line with IEC 61850 GOOSE/SV messaging, where the probability of sending a ‘no
state change’ message is much larger than any other.

##  VI Related Work

While digital signatures are widely used for multicast/broadcast
authentication, they are not suitable for resource-constrained devices or
delay stringent applications. Numerous schemes have been proposed, e.g., [26,
27, 28, 29], to offload some computations of digital signatures to a phase
before the message is given. The first phases of El-Gamal [30], DSS [31], and
precomputation enabled ECDSA [7] do not require the true message similar to
our Tree Construction procedure. Online/offline signatures, either based on
one-time signature schemes [32] or based on chameleon commitments [33, 26, 34]
can transform any digital signature scheme to a one with such offloading
feature. The idea is to perform expensive cryptographic operations in the
offline phase and generate a meta-data, so that in the online phase the source
can sign a message only using inexpensive computations. Although the online
signing in online/offline converted signature schemes can be fast, these
schemes still fall short in meeting stringent latency requirements due to
their offline phase or require a large volume of metadata to be stored by the
source. Among these, Lis [34] is specifically designed for cyberphysical
systems. However, it is optimized for the publisher, and thus, the
verification cost is still high. Several other schemes that amortize a
signature over several packets, e.g., [35, 36, 37], are also not satisfactory
in avoiding large computation and communication overhead, not robust against
packet losses, or lack immediate verification. The signature scheme in [38]
exploits the structure of ICS messages to enable precomputation for a
verifier-efficient scheme such as RSA, but is limited only to certain commands
in ICSs.

Another promising domain for lightweight message authentication is one-time
signatures (OTS), such as those by Lamport [39] and Rabin [40]. While these
earlier OTS require large keys and signatures, Winternitz OTS (WOTS) Scheme
[41] reduced the signature size by trading off setup and verification time. In
the same work, Merkle proposed the conversion of WOTS into a many-time
signature, by constructing a Merkle Hash Tree (MHT) on multiple WOTS public
keys to bind them into a single root value, which serves as the public key for
multiple WOTS instances. Using MHT in OTS/WOTS enables fast signing of
multiple messages with a single public key. More efficient variants of OTS
such as BiBa [42] and HORS [27] have also been proposed. Nevertheless, the
public key size in OTS and their BiBa/HORS variants is relatively large, and
each public/private key pair can be used only once, rendering them impractical
for bandwidth or storage constrained networks/devices.

##  VII Conclusions

We proposed CMA and its multicast variant CMMA as caching-based message
authentication schemes that exploit the limited entropy of ICS messages to
virtually eliminate the processing delay after the message is given. C(M)MA is
suitable for ICS protocols such as IEC 61850 where the time-critical messages
consist mostly of predetermined or predictable data. It relies on symmetric
cryptography, therefore computationally efficient, and does not suffer from
the disclosure delay of delayed key disclosure schemes, despite leveraging
their time asymmetry. We have shown that C(M)MA is a lightweight alternative
for digital signatures for low-entropy messages. Alternatively, C(M)MA can be
opportunistically used in conjunction with digital signatures to lower the
expected overhead of message authentication in ICSs.

## References

  * [1] IEEE Power and Energy Society, “IEEE Standard Communication Delivery Time Performance Requirements for Electric Power Substation Automation,” 2004.
  * [2] E. Esiner, D. Mashima, B. Chen, Z. Kalbarczyk, and D. Nicol, “F-pro: a fast and flexible provenance-aware message authentication scheme for smart grid,” in _Proceedings of IEEE SmartGridComm 2019_. IEEE, 2019.
  * [3] “Communication networks and systems in substations,” [Online]. Available: https://webstore.iec.ch/, (Date last accessed on Jul. 21, 2021).
  * [4] R. E. Mackiewicz, “Overview of IEC 61850 and benefits,” in _2006 IEEE Power Engineering Society General Meeting_. IEEE, 2006, pp. 8–pp.
  * [5] Cleveland, “IEC tc57 security standards for the power system’s information infrastructure - beyond simple encryption,” in _2005/2006 IEEE/PES Transmission and Distribution Conference and Exhibition_ , May 2006, pp. 1079–1087.
  * [6] R. L. Rivest, A. Shamir, and L. Adleman, “A method for obtaining digital signatures and public-key cryptosystems,” _Commun. ACM_ , vol. 21, no. 2, p. 120–126, Feb. 1978.
  * [7] D. Johnson, A. Menezes, and S. Vanstone, “The elliptic curve digital signature algorithm (ECDSA),” _International journal of information security_ , vol. 1, no. 1, pp. 36–63, 2001.
  * [8] R. Hauser, T. Przygienda, and G. Tsudik, “Reducing the cost of security in link-state routing,” in _Proceedings of SNDSS’97: Symposium on Network and Distributed System Security_. IEEE, 1997, pp. 93–99.
  * [9] S. Cheung, “An efficient message authentication scheme for link state routing,” in _Proceedings 13th Annual Computer Security Applications Conference_. IEEE, 1997, pp. 90–98.
  * [10] A. Perrig, R. Canetti, J. D. Tygar, and D. Song, “The TESLA broadcast authentication protocol,” _Rsa Cryptobytes_ , vol. 5, no. 2, pp. 2–13, 2002\.
  * [11] ——, “Efficient authentication and signing of multicast streams over lossy channels,” in _Proceeding 2000 IEEE Symposium on Security and Privacy. S &P 2000_. IEEE, 2000, pp. 56–73.
  * [12] D. Liu and P. Ning, “Multilevel $\mu$TESLA: Broadcast authentication for distributed sensor networks,” _ACM Transactions on Embedded Computing Systems (TECS)_ , vol. 3, no. 4, pp. 800–836, 2004.
  * [13] D. Liu, P. Ning, S. Zhu, and S. Jajodia, “Practical broadcast authentication in sensor networks,” in _The Second Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services_. IEEE, 2005, pp. 118–129.
  * [14] Y. Huang, W. He, K. Nahrstedt, and W. C. Lee, “Dos-resistant broadcast authentication protocol with low end-to-end delay,” in _IEEE INFOCOM Workshops 2008_ , 2008, pp. 1–6.
  * [15] J. Li, Q. Huang, F.-k. Hu, and S. Jing, “Performance testing on goose and msv transmission in one network,” _Energy Procedia_ , vol. 12, pp. 185–191, 2011\.
  * [16] M. M. Roomi, P. P. Biswas, D. Mashima, Y. Fan, and E.-C. Chang, “False data injection cyber range of modernized substation system,” in _Proceedings of IEEE SmartGridComm_. IEEE, 2020.
  * [17] R. Lee, M. Assante, and T. Conway, “Analysis of the cyber attack on the ukrainian power grid,” 2016.
  * [18] “Crashoverride malware,” [Online]. Available: https://www.us-cert.gov/ncas/alerts/TA17-163A, 2017, (Date last accessed on Aug. 18, 2017).
  * [19] C. Kriger, S. Behardien, and J. Retonda, “A detailed analysis of the goose message structure in an IEC 61850 standard-based substation automation system,” _International Journal of Computers, Communications and Control (IJCCC)_ , vol. 8, pp. 708–721, 2013.
  * [20] P. P. Biswas, H. C. Tan, Q. Zhu, Y. Li, D. Mashima, and B. Chen, “A synthesized dataset for cybersecurity study of IEC 61850 based substation,” in _Proceedings of IEEE SmartGridComm_. IEEE, 2019.
  * [21] L. Da Silva and D. Coury, “Network traffic prediction for detecting ddos attacks in IEC 61850 communication networks,” _Computers and Electrical Engineering_ , vol. 87, p. 106793, 2020.
  * [22] L. E. Da Silva and D. V. Coury, “A new methodology for real-time detection of attacks in IEC 61850-based systems,” _Electric Power Systems Research_ , vol. 143, pp. 825–833, 2017.
  * [23] D. A. Huffman, “A method for the construction of minimum-redundancy codes,” _Proceedings of the IRE_ , vol. 40, no. 9, pp. 1098–1101, 1952.
  * [24] “BeagleBoard-X15,” [Online]. Available: https://beagleboard.org/x15”, 2018, (Date last accessed on May 17, 2018).
  * [25] P. Schaub and A. Kenwrick, “An IEC 61850 process bus solution for powerlink’s ipass substation refurbishment project,” _PAC World Magazine_ , vol. 9, no. 2009, pp. 38–44, 2009.
  * [26] A. Shamir and Y. Tauman, “Improved online/offline signature schemes,” in _Annual International Cryptology Conference_. Springer, 2001, pp. 355–367.
  * [27] L. Reyzin and N. Reyzin, “Better than BiBa: Short one-time signatures with fast signing and verifying,” in _Australasian Conference on Information Security and Privacy_. Springer, 2002, pp. 144–153.
  * [28] A. Aysu and P. Schaumont, “Precomputation methods for hash-based signatures on energy-harvesting platforms,” _IEEE Transactions on Computers_ , vol. 65, no. 9, pp. 2925–2931, 2016.
  * [29] G. Ateniese, G. Bianchi, A. Capossele, and C. Petrioli, “Low-cost standard signatures in wireless sensor networks: a case for reviving pre-computation techniques?” in _Proceedings of NDSS 2013_ , 2013.
  * [30] T. ElGamal, “A public key cryptosystem and a signature scheme based on discrete logarithms,” _IEEE transactions on information theory_ , vol. 31, no. 4, pp. 469–472, 1985.
  * [31] P. Gallagher, “Digital signature standard (DSS),” _Federal Information Processing Standards Publications, volume FIPS_ , pp. 186–3, 2013.
  * [32] S. Even, O. Goldreich, and S. Micali, “On-line/off-line digital signatures,” in _Conference on the Theory and Application of Cryptology_. Springer, 1989, pp. 263–275.
  * [33] H. M. Krawczyk and T. D. Rabin, “Chameleon hashing and signatures,” Aug.22 2000, US Patent 6,108,783.
  * [34] Z. Yang, C. Jin, Y. Tian, J. Lai, and J. Zhou, “LiS: Lightweight signature schemes for continuous message authentication in cyber-physical systems,” in _Proceedings of the 15th ACM Asia Conference on Computer and Communications Security_ , 2020, pp. 719–731.
  * [35] Jung Min Park, E. K. P. Chong, and H. J. Siegel, “Efficient multicast packet authentication using signature amortization,” in _Proceedings 2002 IEEE Symposium on Security and Privacy_ , 2002, pp. 227–240.
  * [36] Y. Liu, J. Li, and M. Guizani, “Pkc based broadcast authentication using signature amortization for wsns,” _IEEE Transactions on Wireless Communications_ , vol. 11, no. 6, pp. 2106–2115, 2012.
  * [37] C. Tartary, H. Wang, and S. Ling, “Authentication of digital streams,” _IEEE Transactions on Information Theory_ , vol. 57, no. 9, pp. 6285–6303, 2011.
  * [38] A. A. Yavuz, “An efficient real-time broadcast authentication scheme for command and control messages,” _IEEE Transactions on Information Forensics and Security_ , vol. 9, no. 10, pp. 1733–1742, 2014.
  * [39] L. Lamport, “Constructing digital signatures from a one-way function,” Technical Report CSL-98, SRI International Palo Alto, Tech. Rep., 1979.
  * [40] M. O. Rabin, “Digitalized signatures and public-key functions as intractable as factorization,” Massachusetts Inst of Tech Cambridge Lab for Computer Science, Tech. Rep., 1979.
  * [41] R. C. Merkle, “A certified digital signature,” in _Conference on the Theory and Application of Cryptology_. Springer, 1989, pp. 218–238.
  * [42] A. Perrig, “The BiBa one-time signature and broadcast authentication protocol,” in _Proceedings of the 8th ACM conference on Computer and Communications Security_. ACM, 2001, pp. 28–37.