Message Authentication and Provenance Verification for Industrial Control Systems

2.1 Overview of Industrial Control Systems

In this section, we begin with a general description of ICSs and discuss security challenges. We then provide the details of a smart grid system, as a representative ICS.

Based on the Purdue Model [7], recent ICSs, in general, are organized as shown in Figure 1. Level 3 and below are the operation technology (OT) systems. Level 0 includes a number of sensors and actuators physically connected to the plant equipment, and intelligent devices at Level 1 with computation and communication capabilities collect data from sensors and operate on actuators. Intelligent devices communicate with the local human-machine interface (HMI) on each outstation and/or systems in the control center (Level 3) using ICS protocols. The specific protocols utilized differ depending on the types of systems and plants. In the recent OT systems, typically VPN interfaces are set up for the sake of remote access by employees as well as system/device vendors for remote maintenance.

Fig. 1.

View Figure

2.2 Cybersecurity Threats and Attack Model against Industrial Control Systems

In this section, we discuss cyber attacks that could risk the operation of ICSs by referring to the system model discussed in the previous section and high-profile attack incidents.

Malicious Command Injection: Attackers can mount man-in-the-middle (MITM) attacks on the wide-area network (WAN), which connects a control center (Level 3) to outstations in the field (Level 2), or within the control center local area network (LAN) [8, 9], to replay, forge, or tamper with ICS messages.

Malicious Firmware or Configuration: This can be seen as a special case of malicious command injection. An engineering workstation at Level 3 would be sending updated firmware, ICS device configuration, and automated control logic to intelligent devices at Level 1. Once these are tampered with or any unauthorized update of these is made, it would cause significant damage to the physical plant as well as the stability of the plant operation.

False Data Injection: Similarly to false command injection, attackers could inject fake data into the supervisory control and data acquisition (SCADA) monitoring communication (from Level 1 to Level 2 and 3 as well as within Level 1) to confuse and reduce the situational awareness of the control center system [10] or into programmable logic controllers (PLCs) whose logic depends on power grid measurements. False data can also be injected via compromised field devices, e.g., by using a malware [11].

Compromised or Rogue Field Device: Attackers or malware may first target devices at Level 1 that are often less protected owing to the lack of strong cybersecurity protections. As demonstrated by CrashOverride [12], advanced malware could be used for publishing malicious control commands, executing features beyond its scope, and mounting MITM attacks.

Remote Attack via VPN: Attackers may remotely access the system via the VPN interface at Level 3 or Level 2. For instance, by exploiting vulnerabilities like Shellshock [2], an attacker can virtually become a part of the control center or outstation local area network and execute arbitrary shell commands on the VPN server to inject malicious commands through it. A malicious insider with knowledge of the VPN credential can mount an attack in a similar way.

Attacks via User Interface: Insider attacks against the SCADA master or HMI are also a serious concern [11]. As seen in the Ukraine incident [13], the SCADA master system can be remotely manipulated by an external attacker. Compromised field service (maintenance) devices or abuse of such devices would also cause similar outcomes [11].

2.3 Substation Automation and Remote Control in Smart Grid

The smart grid, an electrical power grid system empowered by information and communication technologies, is one of the most critical infrastructures for our lives as well as one of the most latency stringent examples of industrial control systems. In this section, we elaborate on the detail of it to provide a context for the rest of this article.

A typical smart grid system includes a control center and multiple (possibly thousands of) substations in the field. Figure 2 shows one substation connected to a control center via a WAN. The WAN can be a wired, private network or a private channel over a public network (e.g., the Internet) or through a wireless (e.g., cellular) network. Modern substations use standardized technologies like IEC 60870-5-104 or DNP3.0 for tele-control and IEC 61850 for substation automation [14].

Fig. 2.

View Figure

Within the substation, as discussed in the reference model published by IEC TC57 [14], IEDs serve as the communication endpoints on the cyber side. They are responsible for operating on physical power system devices, e.g., circuit breakers and transformers. Real-time communication among IEDs is crucial for the automated protection of components. For example, a device or system fault event detected by one IED needs to trigger other IEDs to take immediate actions [15]. PLCs are also common devices in charge of automated control based on various power grid measurements. In addition, according to the reference model in [14], typically there is a substation gateway at the entrance of a substation [14]. The substation gateway often performs protocol translation (an example of message transformation en route), e.g., between IEC 60870-5-104 and IEC 61850 [14]. Remote control and monitoring of substations may involve remote terminal units (RTUs), which receive commands from the control center and then interact with IEDs accordingly. The HMI for local control and monitoring by human operators is often found in large substations, and the HMI may be connected to RTUs for exercising control and monitoring. Lastly, in order to enable remote maintenance by grid operators or device vendors, VPN devices connected to the public network are increasingly deployed. The VPN may also be used as a backup SCADA.

Table 1 summarizes the typical communication patterns observed in the smart grid system. As shown in the table, some communication settings involve only a source and a destination. In IEC 61850-compliant substations, Status Update in Substation, Automated Control in Substation, and Protection to Switchgear are done using Generic Object Oriented Substation Events (GOOSE), which is a publisher-subscriber-type multicast communication protocol.

In other communication settings, multiple intermediaries (hops) are involved. For instance, in SCADA Control/Monitoring, commands from a control center to a field device in a low-voltage substation may be mediated by devices in a high-voltage substation. Note that, for such communication, when protocol translation is involved, the substation gateway may work as a source of the translated messages. Besides, commands from a control center are often sent to a gateway device or RTU of a substation. The substation gateway may perform translation of the protocol (e.g., from IEC 60870-5-104 to IEC 61850). Likewise, an RTU may have the autonomy to modify command semantics (e.g., a single incoming control command from the control center may be subdivided into multiple commands and sent to multiple IEDs and/or PLCs). In such a case, the substation gateway or RTU may also work as a source of communication. Another complicated communication model is the Reporting by Field Devices, where measurements from PLCs or IEDs are first sent to the substation gateway or RTU, which may perform protocol translation and/or message aggregation before forwarding them. In this case, again, the substation gateway behaves as a secondary source.

The Remote Maintenance use case corresponds to a situation where a grid operator or device vendor performs firmware or configuration updates remotely. In such a situation the VPN interface may be involved in the communication path. The same may apply to the SCADA Control/Monitoring case when the SCADA master connects to substations via VPN. Operation on Substation HMI may be direct or involve single or multiple hops such as an RTU, which either operates on physical power system devices or interacts with IEDs according to the operation performed on the HMI.

The last column of Table 1 shows the message delivery latency requirements found in the public guidelines [16, 17]. Two use cases corresponding to maintenance are not sensitive to latency and therefore are left blank. As seen in the table, the latency requirements vary depending on use cases, and communication within substations has very stringent delivery latency requirements. In particular, Protection to Switchgear requires very short latency (below 2 ms [16]). An example is the control of circuit breakers for system protection, as any delay of such communication would result in damage to transmission lines and, in the worst situation, a power blackout. The latency requirement with entities outside a substation is less stringent (i.e., around 100 ms or more). However, operations related to distribution automation still require a sub-100-millisecond delay, even over a WAN [17].

2.4 Design Goals

To counter injection by malicious parties, it is crucial to verify the source and integrity of messages. Protection of this type can be typically achieved by message authentication, using message authentication codes or digital signatures. Against injection by compromised field devices, the verification of the message source (and integrity) is insufficient because the message source is already a legitimate device or possesses the credentials of a legitimate device in the system.

To counter injection via compromised or rogue field devices, verification of the message delivery path is imperative. If an attacker steals an authorized source’s credentials and inserts a message using an alternative entry point or path (e.g., from the malware on a field device), the path verification enables the destination to check whether the message has been witnessed by the expected set of nodes. For example, downstream nodes can regard the messages as trusted if a message has gone through a well-protected high-voltage substation system. As discussed in Section 2.3, the substation gateway performs protocol translation. In such a case, verifying the identity of the protocol translator allows the destination to check if the conversion is performed by a legitimate protocol translator, i.e., the substation gateway.

Based on these observations, we introduce the concept of provenance for addressing security concerns. Specifically, we focus on checking the authenticity of the message source and verifying the end-to-end message delivery path (i.e., which nodes are involved and in what order) as well as message transformation en route.

Systematically verifiable provenance information based on cryptographic proofs can be utilized for a variety of policy checks and decision-making regarding the legitimacy of a message.

In summary, our design goals are:

(1) providing ICSs with verifiable provenance information for message authentication, including the source of messages, message delivery path, and message transformation; (2) developing a low-latency cryptographic mechanism for generating and verifying provenance information within the stringent latency requirements for conveying verifiable provenance information; (3) developing a flexible solution for supporting various ICS settings and communication models (e.g., those listed in Table 1 in the smart grid context); and (4) enabling seamless multi-factor authentication for field service devices to issue commands to the protected systems and introduce command scope for authentication. Therefore, the generated codes cannot be used to execute features beyond their original scope as in CrashOverride.

3.1 Model and Algorithms

In our message provenance verification model, there is a message source, a message destination, and intermediaries on the message delivery path. The source wants to prove its identity and the integrity of its messages to the destination. The intermediaries witness the message and may or may not extend it. The intermediaries that witness or extend want to prove to the destination that they have witnessed or extended the message. The destination wants to verify the provenance of the message. We provide below the definitions of the Initiate algorithm for the source, Witness and Extend algorithms for intermediaries, and Verify algorithm for the destination.

• Setup: The Setup is reserved for key generation and distribution.

• Initiate: The Initiate algorithm is run at the source to generate evidence to prove source identity and message integrity to the destination. The output evidence can be used as an input for the Witness and Extend algorithms.

• Extend: An intermediary runs the Extend algorithm with the received message(s), their evidence, and a new (or transformed) message as inputs to prove that the message passed through the intermediary and that the new message is added by this intermediary.

• Witness: An intermediary runs the Witness algorithm to perform Extend without adding a new message.

• Verify: The destination runs the Verify algorithm to verify the message provenance.

The correctness requirement is that, if the Initiate, Extend, Witness, and Verify algorithms are implemented correctly and the message is correctly sent from a source node to a destination node through a set of nodes as intermediaries, then given the correct inputs, the Verify algorithm should always accept the provenance of the message. The formal correctness definition is in Section 4.2.

3.2 Construction Overview

A practical way to introduce additional security into existing ICSs is to deploy transparent, BITWdevices [18, 19, 20, 21]. Namely, the host ICS devices send and receive messages in an as-is manner, while the added BITWdevices intercept messages and provide protection through additional checks without affecting the endpoints. For legacy compliance, F2-Prois intended for such BITWdevices. F2-Prois also implemented as a software library that can be called by the products if altering the source code is an option, e.g., pre-production or via a software update.

As illustrated in Figure 2, to provide comprehensive coverage, an F2-Pro-enabled BITWdevice (or F2-Prodevice for short) can be introduced to each key communication node (e.g., a SCADA master, IEDs, PLCs, substation gateways). Alternatively, a smaller number of F2-Prodevices could be strategically installed only for critical components.

At a high level, an F2-Prodevice at the source end of the communication intercepts and “wraps” a message for additional security. Another F2-Proat the destination end performs verification and security policy enforcement based on the contained provenance information before it “unwraps” and passes the original message to the target device. If the message passes through intermediary nodes to which F2-Prodevices are installed, intermediary BITWdevices can further “wrap” the message to attest that the message has indeed passed through the intermediary. If an intermediary device performs protocol translation, the translator’s identity and both the original and translated messages can be verified at the destination F2-Prodevice.

Interception and policy enforcement by F2-Procan be performed selectively based on, for example, the types of messages, protocols, target devices, and so forth. This way, F2-Prohas minimal impact on system throughput.

At its core, F2-Prois based on aggregate message authentication codes [6]. We use hash-based message authentication code (HMAC\(_K\)) employing SHA256 in the construction with the key K denoted with a subscript. In the rest of the article, we use the function “Agg” defined as follows:

Let “\(\Vert\),” “\(\oplus\),” “ev,” and “pID” denote the concatenation operation, XOR operation, previous node’s evidence, and previous node’s ID in the chain, respectively:

\(\begin{equation*}\text{Agg}\;\left( {\text{ev},\;\text{K},\;\text{ts},\;\text{msg},\;\text{pID}} \right)\; = \;\text{ev}\; \oplus \;\text{HMAC}_K \;\left( {\text{ts}\;||\;\text{msg}\;||\;\text{pID}} \right)\;.\end{equation*}\)

Here, the timestamp is to prevent replay attacks, while the pID serves to establish the order in the chain. Each source and intermediary node computes the Agg function with the evit obtains from the previous node (if any) and passes the resulting evidence to the next node in the chain.

All source BITWdevices store a unique secret key SK, and all destination BITWdevices store a unique verification key for each source, hereby called authentication token or AT, derived by hashing the secret key of each source with a salt value unique to the destination, such that AT\(_{SD}\) = hash(SK\(_S\) \(\Vert\) salt\(_D\)) for source S and destination D. Similarly, a hash function with sufficient bit security, such as SHA256, can be employed. An authentication token (AT) is used as the key to the Agg function.

To witness the messages passing through the intermediary nodes, intermediary BITWdevices store both a secret key and the authentication tokens corresponding to the source devices. When a message passes through an intermediary node, its BITWdevice computes an evidence and attaches the result to the encapsulated packet to attest to witnessing the message. When a message is transformed (e.g., via protocol translation) by an intermediate node, the corresponding F2-Prodevice needs to act both as a source for the transformed message and as a witness to the original message; we call this operation extend.

In the following, we present the construction of F2-Pro. Concretely, the F2-Proprotocol creates a chain of keyed cryptographic digests derived from the messages and device identifiers, hence offering a time-stringent provenance scheme. The core F2-Proprotocol supports a wide range of functionalities required in a smart grid, such as verification by intermediate nodes (e.g., firewall/gateway), combining extend and intermediate verify (e.g., message aggregation by a data concentrator when reporting measurements from IEDs).

3.3 F2-ProConstruction

F2-Prois a tuple of algorithms (Setup, Initiate, Witness, Extend, Verify). Setup creates the keys and authentication tokens and distributes them. Initiate generates cryptographic evidence for a message that has been sent by the host device that the F2-Prodevice is attached to. Witness alters the already attached cryptographic evidence as the message passes through the host device to which an F2-Prodevice is attached. Extend is similar to witness except that the message is also altered.

Finally, Verify checks the authenticity of the cryptographic evidence and either accepts or rejects it.

Initiate-verify: Figure 3 illustrates the protocol in a communication setting with one source and one destination node. The aim is to allow the user to prove its identity and message integrity to the destination with minimal overhead in terms of time added to the original protocol.

Fig. 3.

View Figure

The source F2-Propossesses a secret key (SK\(_S\)) and the destination F2-Prostores an authentication token (AT\(_{SD}\) = hash (SK\(_S\) \(\Vert\) salt\(_{SD}\))). The authentication request, which proves identity to the destination F2-Pro, is a cryptographic evidence (ev\(_{SD}\) = Agg (“”, hash (SK\(_S\) \(\Vert\) salt\(_{SD}\)), ts, “”, “”)) of a message with no content and no previous node ID and evidence. Since there may be more than one destination, there is a unique salt value associated with each destination node. This salt value can be the destination message authentication protocol (MAC)/IP address, randomly generated from a seed, or can be stored. To prevent replay attacks, the evidence should be time-bound. Hence, to send the authentication request, the source F2-Proadds a timestamp (ts) to the evidence. To authenticate a message along with its identity, the source F2-Proadds the message content (msg) to the computation, resulting in \(\begin{equation*} \text{ev}_{SD} = \;\text{Agg}\;\left( { “” ,\;\text{hash}\;\left( {\text{SK}_S ||\;\text{salt}_{SD} } \right),\;\text{ts},\;\text{msg},\; “” } \right),\end{equation*}\) where the previous evand the previous node ID fields are empty. For verification, the destination F2-Prouses the timestamp, the message, and its stored authentication token (ev’ = Agg (“”, AT\(_{SD}\), ts, msg, “”) and checks two things: if the timestamp is fresh and if ev’ equals the received ev\(_{SD}\).

This basic case covers some of the communication models discussed in Section 2.3, namely Automated Control in Substation, Status Update in Substation, Protection to Switchgear, and Local Maintenance. In the following, we demonstrate the flexibility of this design to support various smart grid communication models before we move to more time-stringent segments.

Adding Witnesses En Route (Witness): As discussed in Section 2.3, many smart grid communication models involve multi-hop communication. In some cases, a message is received by an intermediate node and then simply forwarded to the destination. For example, in the Remote Maintenance scenario, a VPN interface may operate in this way. In the SCADA Control/Monitoring case, the high-voltage substation may also forward information.

In Figure 4, note that the destination F2-Prohas two ATs, one for the source node and the other for the witness node (AT\(_{WD}\) = hash (SK\(_W\) \(\Vert\) salt\(_{WD}\))). The source F2-Pronode initiates the chain by sending ev\(_{SD}\) to the witness node. The witness F2-Prothen derives its own cryptographic evidence, using SK\(_W\) and the cryptographic evidence from the source F2-Pro(or from the last witness F2-Proif any):

Fig. 4.

View Figure

\(\begin{equation*} \text{ev}_{WD} = \;\text{Agg}\;\left( {\text{ev}_{SD} \;\text{hash}\;\left( {\text{SK}_W ||\;\text{salt}_{WD} } \right),\;\text{ts},\;\text{msg},\;S} \right).\end{equation*}\)

Aggregating the chain of cryptographic evidence in this manner limits the size of evidence to a single HMAC output, regardless of the number of witnesses on the path.

Verification at the destination side entails calculating the cryptographic evidences from the first to the last. Then, the destination checks if the last ev’ is equal to the received cryptographic evidence. In our example, with one source and one witness, the destination performs \(\begin{equation*}\begin{array}{*{20}c} {\text{ev}'_0 \; = \;\text{Agg}\;\left( {{“”}\;\text{AT}_{SD} ,\;\text{ts},\;\text{msg},\;{“”}} \right)} \\ {\text{ev}'_1 \; = \;\text{Agg}\;\left( {\text{ev'}_\text{0} \text{,}\;\text{AT}_{WD} ,\;\text{ts},\;\text{msg},\;\text{S}} \right)} \\ \end{array} \end{equation*}\) and then checks if ev’\(_{1}\) equals ev\(_{WD}\), the evidence received from the witness.

While the Initiate and Witness algorithms’ complexities are both constant, i.e., (O(1)), the complexity of the verification algorithm is linear on the number of intermediaries, i.e., (O(N)), where N is the number of intermediaries).

Message Transformation (Extend): In the setting with two sequential sources (as in Figure 5), the extending (second) source F2-Proalso acts as a witness while concatenating a new (transformed) message and calculating the next value in the chain. For instance, upon receiving the inputs, “ev\(_{S1D}\), ts, msg,” a witness would calculate its cryptographic evidence: Agg (ev\(_{S1D}\), hash(SK\(_W\) \(\Vert\) salt\(_{WD}\)), ts, msg, S1). Instead, an extending source F2-Prorenders it as follows: ev\(_{S2D}\) = Agg (ev\(_{S1D}\), hash (SK\(_{S2}\) \(\Vert\) salt\(_{S2D}\)), ts, msg \(\Vert\) msg2, S1), where msg2 is the new (transformed) message. Then, it sends ev\(_{S2D}\), ts, msg, msg2 to the next node. Note that the cryptographic evidence does not prove the correctness of translation from msg to msg2 but enables the verification of the extending node’s identity and the integrity of msg and msg2.

Fig. 5.

View Figure

We present the verification pseudocode in Algorithm 1 for an arbitrary number of nodes on the path. Lines 5 to 6 decide the indices of messages to be processed on Line 7, where the evidences are computed.

4.1 Algorithm Definitions

We use subscripts to denote an element of a set and superscript to denote a state of the set. For instance, if MSG\(_1\) extends MSG\(_0\), the extended message of {MSG\(_0\), MSG\(_1\)} is denoted as MSG\(^1\). The cryptographic evidence (ev) is to be sent along with the plaintext timestamp (ts) and message. The setup is performed at every F2-Prodevice, where each device calculates the authentication tokens from its secret key and distributes them to the corresponding destinations. At the destination F2-Prodevice, the algorithm “Verify” derives the information about which authentication tokens to use and which step of the chain involves message transformation (to add the corresponding MSG\(_i\) as an input to the chain). In our construction, the “Witness” algorithm is identical to the “Extend” algorithm with an empty message field.

• Setup: SK\(_S\) \(\leftarrow\) KeyGen(1\(^\mathcal {K}\)) – Given the security parameter \(\mathcal {K}\), a secret key (SK\(_S\)) is generated for every source S in the system.

  AT\(_{SD}\) \(\leftarrow\) AuthTokenGen(SK\(_S\), D) – Each source S, given the secret key and a salt value, generates an authentication token AT\(_{SD}\) per destination D. We assume secure distribution of these tokens to the corresponding destinations.

• ev\(_0\), MSG \(\leftarrow\) Initiate(SK\(_0\), ts, message, D) – Given the secret key, the timestamp, a message, and the destination, outputs the first cryptographic evidence (ev\(_0\)) of the chain and the set of messages with one message in—the later nodes in the path may add messages to the set (see “Extend” below).

• ev\(_{c}\) \(\leftarrow\) Witness(ev\(_{c-1}\), D, SK\(_c\), ts, MSG) – Given the previous node’s cryptographic evidence, the destination, the secret key, the timestamp, and the set of messages, outputs a witness cryptographic evidence.

• ev\(_{c}\), MSG’ \(\leftarrow\) Extend(ev\(_{c-1}\), D, SK\(_c\), ts, message, MSG) – Given the previous node’s cryptographic evidence, the destination, the secret key, the timestamp, a message, and the set of previous messages, outputs an extension cryptographic evidence and the extended message set.

• accept/reject \(\leftarrow\) Verify(ev\(_{c}\), ts, AT\(_{SD}\), AT\(_{1D},\ldots , AT_{cD}\), MSG) – Given the last node’s cryptographic evidence (ev\(_{c}\)), the timestamp, the set of authentication tokens (that consists of the verification keys of the source node AT\(_{SD}\) and other nodes on the path AT\(_{1D},\ldots , AT_{cD}\)), and the set of messages, outputs “1” for accept, “0” for reject.

After successful verification, the verified provenance information is handed over to policy checking, which is outside of the core protocol algorithms.

4.2 Protocol Correctness

Below, we denote the number of nodes and sources on the path by \({\mathcal {X}}\) and \({\mathcal {Y}}\), respectively. By the correctness requirements in Section 3.1, F2-Pro’s correctness is as follows.

\(\forall\) MSG\(_i\in\) {0,1}*, if [SK\(_S\) \(\leftarrow\) KeyGen(1\(^\mathcal {K}\)), AT\(_{SD}\) \(\leftarrow\) AuthTokenGen (SK\(_{S}\), D) for S \(\in\) [\(0,\ldots , {\mathcal {S}}-1\)] and D \(\in\) [\(0,\ldots ,{\mathcal {D}}-1\)]]; (ev\(_0\), MSG\(^0\)) \(\leftarrow\) Initiate(SK\(_{S}\), ts, MSG\(_0\), D); [ ev\(_x\) \(\leftarrow\) Witness(ev\(_{x-1}\), D, SK\(_{x}\), ts, MSG\(^{y}\)) OR (ev\(_x\), MSG\(^{y}\)) \(\leftarrow\) Extend(ev\(_{x-1}\), D, SK\(_{x}\), ts, MSG\(_y\), MSG\(^{y-1}\)) ] \(\forall\) x \(\in\) [\(1,\ldots ,{\mathcal {X}}\)] and \(\forall\) y \(\in\) [\(1,\ldots ,{\mathcal {Y}}\)]; then Verify(ev\(_{\mathcal {X}}\), AT\(_{0D}\), ..., AT\(_{({\mathcal {S}}-1)D}\), MSG\(^{\mathcal {Y}}\)) = 1 with probability 1.

4.3 Correctness Proof

To prove the correctness of the protocol, we need to show that if a message is correctly sent from a source S to a destination D through a set of nodes as witnesses/extenders, then the Verify algorithm will return 1 with probability 1.

4.4 Security Proof

We state the security for a verifiable provenance scheme using a game.

Forgery Game: If any node on the path of the message from a source to a destination deviates from the honest behavior or a message does not pass through all the honest nodes on the claimed path, then the destination will detect it with a high probability. We define a forgery game to be played between the adversary \(\mathcal {A}\), who acts as the malicious parties, and the challenger \(\mathcal {C}\), who plays the role of the destination and honest nodes.

\(\circ\) Setup:

• \(\mathcal {A}\) chooses two sets of node IDs for malicious nodes \(\mathcal {MN}\) and for honest nodes \(\mathcal {HN}\) of size h. \(\mathcal {A}\) picks unique secret keys for the nodes in \(\mathcal {MN}\) in the format defined in Setup in Section 4.1. \(\mathcal {A}\) sends \(\mathcal {MN}\), the secret keys they share with the destination SK\(_{l_i}\),¹ \(\forall \ {l_i \in \mathcal {MN}}\), and \(\mathcal {HN}\) to \(\mathcal {C}\).

• \(\mathcal {C}\) generates the secret keys for the nodes in \(\mathcal {HN}\), i.e., SK\(_{l_i}\), \(\forall \ {l_i \in \mathcal {HN}}\).

\(\circ\) Query:

• \(\mathcal {A}\) sends to \(\mathcal {C}\) a polynomial number of queries, each of which includes a timestamp ts, messages MSG = {\(m_1,\ldots , m_j\)} (\(m_1\) is for Initiate, \(m_i = m_{i-1}\) implies Witness, otherwise Extend), and the sequence of node IDs for a selected path L = {\(l_1, \ldots , l_j\)} excluding the destination.

• \(\mathcal {C}\) calculates and returns {ev\(_1, \ldots ,\)ev\(_j\)} after each query.

\(\circ\) Challenge: \(\mathcal {A}\) sends MSG* = \(\lbrace m^*_1,\ldots , m^*_k\rbrace\), \(L^* = \lbrace l^*_1, \ldots , l^*_k\rbrace\), ts*, ev* to \(\mathcal {C}\).

\(\circ\) Winning Condition: \(\mathcal {A}\) wins if Algorithm 1 returns accept with ev*, ts*, MSG*, \(L^*\) as inputs and there exists at least one honest node \(l^*_i \in L^*\), such that \(l^*_i \in \mathcal {HN}\) and {\(m^*_1\), ..., \(m^*_i\)}, {\(l^*_1\), ..., \(l^*_i\)} is not queried as a prefix of MSG, L with ts = ts* during the query phase.

5.1 Provenance Chain Starting from the Human User

When the field person uses an ICS operator device, e.g., a field service device to manage control and configuration, the destination verifies two additional pieces of information: user identity and ICS operator deviceidentity. The proof of ICS operator deviceidentity is identical to that of other nodes in the system. To harden the system against the weaknesses introduced by the human factor, the proof of user identity is provided by multiple authentication factors. Here, the possession factor comes into the picture, to be used along with the password that the user memorized to generate the user fingerprint. In the multi-factor authentication Setup, the list of authentication tokens is generated as below for each user-destination pair and stored at the destinations.

\(\begin{equation*}\text{AT}_{UD} \; = \;\text{hash}\left( {\text{SK}_U ||\;\text{password}\;||\;\text{salt}_D } \right),\end{equation*}\) where SK\(_{U}\) is the secret key associated with user U, and AT\(_{UD}\) is the authentication token stored at destination D to verify messages from user U. Later, when the user uses the field service device to send a message, the user keys in the password in the authenticator device. The authenticator runs Initiate to calculate the user one-time password (OTP):

\(\begin{equation*}\text{OTP}_{UD} \; = \;\text{hash}\left( {\text{AT}_{UD} \;||\;\text{ts}} \right).\end{equation*}\)

The user is required to select the destination for its message since the salt value and hence the OTP is associated with the destination ID. The user is expected to key in the OTP to the field service device. To provide easy and error-free use, a QR code generator/reader, NFC reader, or any one-way communication between the authenticator and field service device is beneficial. We used both NFC and QR codes in our product. Figure 7 visualizes the steps of the multi-factor authentication process detailed below. Initiate: The value that has been generated by the authenticator is treated as an initiation without message content. Naturally, the length of a user session should span multiple messages. The user identity (e.g., username, ID) can be sent in plaintext for cases where there is more than one user so that the destination can choose the right verification key for each user.

Fig. 7.

View Figure

Extend: After the authenticator’s initiation, the generated OTP is transferred to the ICS operator device. Then, the ICS operator deviceextends the initiated chain with the message (e.g., configuration command) and passes it to the control center, where the message goes through the pipeline described in Section 3.

5.2 Starting the Chain with a Public-key-based Scheme

An option to implement multi-factor authentication is employing an RSA-like public-key-based scheme (SETUP, SIGN, VERIFY) and integrating it into the provenance checking mechanism as follows. At the authenticator:

\(\begin{equation*}\text{OTP}\; = \;\text{SIGN}_{pri\upsilon k} \left( {\text{username,}\;\text{ts}} \right).\end{equation*}\)

The authenticator needs to send the username and the timestamp in plaintext to the ICS operator devicetogether with the OTP. At the ICS operator device:

\(\begin{equation*}\text{ev}\; = \;\text{Agg}\left( {\text{OTP},\;\text{hash}\left( {\text{SK}_{FSD} \;||\;\text{salt}} \right),\;\text{ts},\;\text{msg},\;\text{pID}} \right).\end{equation*}\)

The ICS operator devicethen needs to send the username and timestamp in plaintext to the control center, and these values should propagate until the destination together with the ev. To verify, the destination XORs all the evidence on the path and verifies the resulting value with the public key of the user.

The verification overhead at the destination is heavy, and this method is only possible if the destination device supports PKI. For instance, in our selected embedded device (BeagleBoard-X15 [23]), extra verification for the multi-factor authentication takes 40 usec, whereas the same verification step takes around 300 usec with a public key signature scheme. This affects the throughput of the destination device where multiple sources may have been messaging, and it also weakens the system against denial-of-service attacks.

5.3 Limiting the Scope of Authentication

The extension of F2-Prowith multi-factor authentication hardens the security for authenticating human users who connect to ICS via ICS operator devices. These commercial-of-the-shelf devices, such as laptops and tablets, are vulnerable to malware. In the case where a field service device is infected, the malicious party can use the user’s time-bound code (OTP) to issue other commands in the background for the duration of the session. Therefore, as another layer of security, we limit the scope of the OTP generated at the authenticator. Simply put, we enable the authentication scope selection for the user commands prior to OTP generation. The destination node understands the packet scope and starts the verification chain accordingly without requiring any additional communication overhead. The OTP at the authenticator is then calculated as follows:

\(\begin{equation*}\text{OTP}_{UD} \; = \;\text{hash}\left( {\text{hash}\left( {\text{SK}_U \;||\;\text{password}\;||\text{salt}_D } \right)||\;\text{ts}||\;\text{scope}} \right).\end{equation*}\)

Authentication scope restriction introduces minimal computation overhead yet prevents malicious software from issuing irrelevant and potentially more harmful commands.

A screenshot from the proof-of-concept multi-factor authentication Android application is shown in Figure 8. The user selects a destination device and session scope from a drop-down menu and scans the resulting QR code (containing the OTP) with the field service device.

Fig. 8.

View Figure

5.4 Policy Enforcement at Verifier

With the use of an authenticator, upon the successful verification of the cryptographic evidence attached to ICS messages or configuration, the verifier can derive the following information from the multi-factor user authentication added to the end-to-end provenance information through F2-Pro: (1) identity of the user, (2) identity of the authenticator, (3) identity of the ICS operator device, (4) timestamp, and (5) authentication scope.

Based on this information, the verifier device can enforce policies in terms of the combination of these. For instance, if we enforce \(user_1\) to use a specific authenticator \(authenticator_1\) and ICS operator device (e.g., mobile field service device) \(iod_1\), we can define a policy to allow \({user_1, authenticator_1,iod_1}\). If \(user_1\) is allowed to use another ICS operator device (e.g., SCADA HMI), say \(iod_2\), we can define another policy that allows \({user_1, authenticator_1,iod_2}\). The timestamp and the scope can be further defined for each combination. This way, we can flexibly define security policies to support various use cases commonly seen in the ICS context.

6.1 Attacks Countered by F2-Pro

To validate the security features of F2-Pro, we implemented three attacks that succeeded on an unprotected IEC 61850-based smart grid testbed. The first attack abuses a compromised entity within the system. This attack is a generalized rendition of CrashOverride (Industroyer) malware, which can issue IEC 61850 and IEC 104 commands either autonomously or orchestrated by a remote attacker. Once a device is compromised, the adversary can issue any command to any destination. Therefore, by compromising an entity in the system (e.g., a substation gateway from another substation), the compromised device can issue commands (e.g., a command to a circuit breaker) to several IEDs. Such commands are successfully executed, potentially damaging the system. The second attack abuses Shellshock vulnerability [2] to compromise the VPN service and escalates privileges to execute arbitrary shell commands. Consecutively, we can issue commands to IEDs and PLCs. All such commands are also executed in an unprotected system. The third attack connects a rogue laptop to the substation switch. The point of access is different, but the attack is still successful. When we activate F2-Prodevices on the wires, the first attack is countered; even though cryptographic evidence for the message is generated by the compromised device’s F2-Prodevice (i.e., a genuine secret key) and sent along with it, the destination F2-Prodevice knows from which source and from which path to expect a particular command. As the actual network path is different from the path expected by the destination F2-Prodevice, the F2-Prodevice of the destination will not run the verification algorithm (Algorithm 1), stating, “The followed path cannot be found in the policy.” For the second and third attacks, we assume a smart attacker would somehow spoof IPs and manipulate the system to claim that the correct path is followed. However, the corresponding verification cannot be deceived, as discussed with the security proof at Section 4.4, and the F2-Prodevice returns “Cryptographic evidence mismatch.”

6.2 Dependability; Failure of an F2-ProDevice or Its Network Connectivity

A failure of the F2-Prodevice can be handled by redundancy. A critical smart grid device often has hot standby redundancy and/or it may have multiple network interfaces. Redundant F2-Prodevices can be connected to the hot standby devices and to each of the standby interfaces of a critical device. Hence, the failure of a single F-Pro device can be tolerated. The degree of redundancy should be decided based on the criticality of the host system and devices. Such an architecture would also include a watchdog mechanism that monitors the availability of the F2-Prodevices, e.g., based on timeout, to enable automated fail-over.

6.3 Verification Key Security

The security of the verification keys depends on the preimage resistance of the employed hash function family. Simply put, if a probabilistic polynomial time adversary can find the secret key SK, given a verification key (= hash(SK\(\Vert\) salt)), then we can break the preimage resistance of the chosen hash function. Therefore, if the hash function employed is preimage resistant, then the verification keys are secure.

6.4 Key Management

Key management is the fundamental basis of every cryptographic application. Key management for SCADA systems has been extensively studied. The main constraints have been presented in [26]. The key management concept consists of key generation, distribution, storage, and revocation, all of which are required in our proposed solution. There are two types of key management schemes. The first and the more studied type is automated key management. The second is the manual key distribution, which is more suitable for static setups. Key management software is often a small part of the program; however, designing a key management system is a task on its own. For instance, in [27] one of the first key management protocols was proposed. Soon after, a flaw was pointed out in [28], and a fix was proposed, which then was cracked in [29]. [30] revealed a new flaw in the original protocol. All these flaws are obvious when pointed out; however, they remained hidden for a long while from inexperienced eyes. This well-known example shows us that key management should not be taken lightly, and the most advanced scheme in the literature at the time of implementation shall be employed. In this work, we assume secure key distribution. F2-Proremains neutral to the underlying method of key distribution. F2-Proimplements a manual key distribution approach, as detailed in Section 6.6, and similarly applies a basic authentication token derivation scheme that is independent of the proposed protocol and its extensions. The key derivation component is a modular aspect of the protocol that can be substituted with alternative techniques.

There are minor advantages of using authentication tokens over pairwise symmetric keys in cyberphysical systems. The first advantage is that authentication tokens provide flexibility to the source entity to generate tokens on the fly, using their single master key, without needing pairwise symmetric keys for bidirectional communication with every entity in the system. This approach saves the source from having to store a linearly growing number of keys for every destination node. Another minor advantage is that calculating the symmetric key on the fly using the master key is faster than calling a particular key for a destination from storage.

6.5 Attacks Countered by Multi-factor Authentication

Added to the attacks in Section 6.1, we have experimented with other hypothetical but realistic attacks from three different entry points in the smart grid context, as shown in Figure 6 for the authenticator device security. All these attacks were successful on the vanilla system. For these experiments, for the sake of flexibility and manageability, we utilized an open-source, software-based smart substation testbed [31] based on the IEC’s reference model of a modernized substation [14].

First, we consider an attacker compromising a VPN interface, which is typically prepared for remote maintenance by vendors or as a backup channel for SCADA communication. In particular, we set up a VPN service with shellshock vulnerability [2], which allows a remote attacker to elevate privileges to execute the shell commands. Using the compromised VPN server as a stepping stone, the attacker’s device, impersonating the ICS operator device, is able to inject malicious control commands to IEDs in the substation.

Second, we simulated a remote attacker via WAN connecting to the control center and substations. In other words, an attacker impersonates a control center to inject malicious commands. We have attached a bogus SCADA master, which does not have a legitimate key on it, to the gateway/RTU and issued ICS commands to IEDs.

The third attack simulates an attacker physically in the substation. Recall that, based on our threat models, an attacker can have access to the station level of the substation and may be able to plug his or her computer into the network or manipulate the HMI deployed there. All of these attacks are successful in executing the malicious control commands on IEDs without the proposed multi-factor authentication system in place.

We set up multiple ICS operator devices and authenticators assigned to different users. For the setup, we have given the passwords to be memorized by the users. Alternatively, the users could decide on a password and then upload their verification keys to the destination devices in a secure environment. All three attacks mentioned above are not possible after the implementation of our solution owing to the lack of valid cryptographic evidence.

Namely, in the first scenario, even if the attacker is successful in compromising the VPN server without the possession of a valid authenticator and field service device, the attack attempt is blocked. A similar argument can be made for the second case. In the third case, even if the stolen device still stores the cryptographic evidence generated in the past for some reason, a replay attack against the same or different target IED can be prevented by enforcing the scope and lifetime at the verifier. Even if the attacker learns the password of a user, steals his or her authenticator, and compromises an ICS operator device, as long as he or she cannot lay hands on the specific ICS operator devicethat is associated with the said user, he or she still cannot issue valid commands. In addition to compromising a user password, valid authenticator, and field service device, an attacker is required to place the device at the right network location in the expected ICS message delivery path.

6.6 Implementation

Figure 9 shows the deployment of the BITWdevice on the testbed. We have selected BeagleBoard-X15 (called BeagleBoard for short) [23]. It has been selected for its low cost and support for two Ethernet interfaces that enable bumping it in the wire. Hardware details can be found in [23].

Fig. 9.

View Figure

6.7 Compatibility Testing

We tested our devices on the Electric Power and Intelligent Control (EPIC) testbed [32]. EPIC is a smart power grid testbed (open to external access), which includes generation, transmission, microgrid, and smart home components. Each of the four segments of EPIC has its PLCs, IEDs, and communication systems in a fiber-optic ring network. The EPIC testbed utilizes IEC 61850 MMS and GOOSE protocols as summarized in [36]. The demo of both the F2-Proand its authenticator working on EPIC is shown in [25].

For the compatibility testing, we connected our F2-Prodevices into the generation segment (as seen in Figure 9) of the testbed for adding and verifying the cryptographic evidence as defined in Section 3. We demonstrated compatibility with the smart grid devices and network in the testbed for IEC 61850 MMS and GOOSE communication.

As with most ICSs, the EPIC testbed has a fixed topology and expected routing paths for messages. In systems with dynamically updated routing paths, certain path verification checks can still be performed with F2-Pro. If the nodes securely share their dynamically updated routing tables with each other, the destination device can verify if the message followed the right path for the given routing setting.

6.8 Evaluation

We first evaluate the core F2-Profunctions and then the two-factor authentication. Our evaluation focuses on F2-Pro’s time overhead, including the time spent on cryptographic calculations, other packet-processing operations, and the end-to-end delay when deploying our implementation in a smart-grid-like network environment. We vary the hash functions and key sizes used by F2-Proand compare it with the overhead of the public-key encryption scheme of RSA. We also report the message size overhead of F2-Proand the throughput of our implementation. All results are the average of 1,000 runs. Time Spent on Cryptographic Hash Calculations and Other Packet-processing Operations: Figure 10(a) and Figure 10(b) show the breakdown of the time spent for each operation during Initiate and Witness, respectively. The performance overhead for Extend is similar to Witness and thus omitted to save space. As can be seen, the time spent on the cryptographic hash operation is very short (i.e., less than 40 microseconds even for HMAC construction with SHA512), even when implemented on a low-cost embedded device [23]. In fact, it only constitutes a small fraction of the overall packet processing latency. Other necessary operations (such as preparing, creating, and sending the data packets) take significantly longer time than the cryptographic operations. Note that Initiate takes less time than Witness. This is because Initiate only processes a packet once, while Witness needs to receive/process/send a packet twice—first for the incoming packet to its associated smart grid device, and again for the processed packet leaving the associated device. In comparison, Figure 10(c) shows the overheads for signing a packet using RSA signatures. We have employed the OpenSSL library [37] to sign the same amount of data that we require in our setting. With the key size of 2,048 bits—which is the minimum of the ones considered secure—and with SHA256 as the digest function, the signing operation alone takes 8 ms and dominates the other packet processing operations. Thus, it is obvious that they are not suitable for use in time-stringent operations (e.g., those requiring an end-to-end delay of a few milliseconds). Figure 10(d) shows the time spent for all the four core operations by F2-Proon BeagleBoard [23]. As the figure shows, the time overheads of F2-Prooperations remain low regardless of the hash function employed. Figure 10(e) shows the time spent by F2-Profor the hashing operations for the cryptographic evidence or the verification using different key sizes. In our implementation, the AT is stored by the destination F2-Prodevice, so the time spent for verification does not change with the key size. The other three operations compute ATs on the fly using the secret keys, and hence the time consumed increases with the key size. Figure 10(f) shows the overall time spent by F2-Proto perform each operation for different key sizes. Again, there is little increase in the overall time overhead with the increase of the secret keys utilized. Overall, F2-Pro’s latency is low enough when paired with practically secure key size and hash function.

Fig. 10.

View Figure

Communication Overhead: The communication overhead is very minimal at 320 bits (h: 256 bits in the case of SHA256 and ts: 64 bits) per packet, and most importantly, its size remains the same regardless of the hop count.

Throughput Measurements: Figure 10(g) shows throughput measurements of F2-Proalso on a BeagleBoard, using iperf over TCP with message size 1,514 Bytes and with different computational latency added. The Initiate operation takes 140 to 160 usec as shown in Figure 10(a). Therefore, as seen in Figure 10(g), the F2-Proon BeagleBoard can support 39.5 MBits/s at a source F2-Pro. And the Witness operation takes 280 to 300 usec, shown in Figure 10(b); therefore, the BeagleBoard can support 27 MBits/s at an intermediate device. This translates to 3,420 packets per second for the Initiate operation and 2,337 packets per second for the Witness operation. The computation time needed for the Verify operation and to support multicast can be longer, but F2-Procan still sustain about 866 packets per second throughput when each packet incurs an extra 1 ms of computation time. In addition, our packet throughput measurement is a conservative lower bound since the packet sizes in both MMS and GOOSE are usually smaller than 1,514 Bytes. Therefore, the throughput of F2-Proon BeagleBoard is sufficient for typical traffic intensity.

End-to-end Latency Overhead: To measure the end-to-end latency overhead introduced by F2-Pro, we set up a controlled environment using virtual machines for multiple hops. The total time overhead introduced by F2-Prois shown in Table 3. The overhead is measured as the difference between the original end-to-end latency of the system without F2-Prodevices and that of a system where an F2-Prodevice is attached to each device along the path. While the no-hop case only involves F2-Prodevices initiating and verifying, in the other cases the intermediate nodes are witnessing. The overall latency for no hop, which corresponds to the most latency-stringent scenarios, is low enough to meet the 2 ms message delivery time requirement. The cases with more than two hops are for SCADA communication and the time stringency is not as strict as those with one or no hops (see Table 1), and the added latency is not significant.

7.1 Provenance Verification

Several schemes employ public key infrastructure and ameliorate it for path authentication with aggregate signatures [38, 39]. Aggregate signature enables multiple senders to sign different messages without increasing the signature size. To reduce computation and communication complexity, techniques such as signature amortization [40] and the space-efficient techniques of aggregate signatures [41, 42] have been proposed. However, under stringent latency constraints in ICSs, they are no longer options. Due to latency constraints, the IEC 62351-6 standard [43] recommends MAC-based solutions [44, 45] for message authentication, but these schemes do not focus on message provenance. Therefore, we use the aggregate MACs formally introduced by Katz and Lindell [6] as a primitive in our construction. [46, 47] provide certain public key guarantees with tradeoffs; however, they also lack efficient extension for provenance verification. Path verification in the smart grid context was explored in [48], but it focused on demand response services, which are less latency stringent. Certain schemes use blockchain to provide data provenance [49, 50] in energy systems but lack a fast message provenance scheme.

7.2 Bump-in-the-wire Approach

BITWsecurity solutions have been proposed for ICS systems, as they enable easy deployment and updating of security mechanisms without requiring major upgrades or replacements on existing ICS devices [18]. Closely related to our work are BITWsolutions for implementing confidentiality and integrity protection, such as [18, 19, 20]. [18, 19] deploys BITWdevices at each end of the communication, which are responsible for adding security metadata (e.g., MAC) at the sender side and verifying and stripping it at the other end. While our focus is on the provenance of ICS messages, ours also adopts a similar deployment model to maintain compatibility with legacy ICS devices. Unfortunately, all of these do not consider end-to-end path verification in a multi-hop network. In ICSs, multi-hop communication is common and often involves protocol translation or checking middleboxes. Thus, we aim to provide provenance checking, including path verification.

7.3 Multi-factor Authentication

The main factors of user authentication used today are what a user has (e.g., a hardware token, a sim card to send an SMS) and what a user is (e.g., fingerprint, iris) as an addition to the memorized username and password [51]. Asking the user for a shared secret is another common practice (e.g., a pre-decided photo from a list of photos), but it is not comparable to other methods regarding the added security provided. While many of the above applications increase the bar for an attacker, they have generally been implemented by employing a trusted third party. Some examples are a server issuing a smart card [52], a server knowing all shared information between a smartphone and itself so that necessary information can be generated to be verified at the server [53], and the server generating and sending the code to the user [54].

It is a common understanding that the conventional username/password authentication alone is not considered secure [55, 56, 57]. This has led to several commercial solutions for two-factor authentication, such as RSA’s SecurID [58] that works with SMS, e-mail, hardware, and software tokens; Google Duo [59] that works via U2F [60] USB device, phone calls, and mobile applications; and Symantec VIP [61] that uses hardware tokens, smartphones, and biometrics.

Kogan et al. proposed a scheme based on Lamport’s one-time password authentication scheme [62], which has evolved in time under the name S/Key [63]. In their design, a central server is considered to verify all authentication requests. The authors, therefore, place emphasis on requiring no secrets stored on the server; however, since in an ICS setup the verifiers are fully distributed and an attack on the server that can expose all second factors for all users is not the main concern, the added overheads are not justifiable in our case. Our focus is on a quickly verifiable and thus symmetric-key-based (unlike public key-based approaches [64, 65]), and a multi-factor authentication mechanism that first does not depend on any third party or centralized online entity and second works in harmony with our provenance verification scheme tailored for an ICS environment.