A Security Architecture for SCADA Systems

Supervisory Control and Data Acquisition (SCADA) systems are attractive targets for attackers, as they offer an avenue to attack critical infrastructure (CI) systems controlled by SCADA systems. Ultimately, an attack on any system exploits some undesired (malicious or accidental) functionality in the components of the system. Unfortunately, it is far from practical to eliminate undesired functionality in every component of a system. The contribution of this paper is a novel architecture for securing SCADA systems that guarantee that “any malicious modification of the deployment configuration or the design configuration of the SCADA system will be detected”—even if undesired functionality may exist in SCADA system components.


Introduction
Several important systems like power grids, water supply systems, oil and gas production/distribution systems, mass transportation systems, etc., are considered as critical infrastructure (CI) systems due to the catastrophic nature of damages that can result from their failure.The task of monitoring and controlling such systems is often entrusted to Supervisory Control and Data Acquisition (SCADA) systems.
SCADA systems are an attractive target for attackers, as they offer an avenue for launching attacks against high valued CI systems.A typical SCADA system may include several remote terminal units (RTU), one or more master terminal units (MTU), a variety of communication equipment and links, computers running human machine interface (HMI) software to enable more intuitive operator driven control when necessary.Hidden malicious/accidental functionality in any In the proposed passive approach to secure SCADA systems, a resource limited trustworthy module-which we shall refer to as an STCB (SCADA Trusted Computing Base) module serves as the TCB for model-execution.The main contributions of this paper are: 1) a strategy for expressing of state-transition models for SCADA systems; and 2) a functional specification for STCB modules, for executing the model.
To improve the confidence in the integrity of STCB modules, they should ideally be manufactured under a well-controlled environment, and consummately tested for the designed functionality.To facilitate consummate testing, it is necessary to deliberately constrain STCB modules to possess simple functionality.For low-cost mass-realization of reliable STCB modules to be practical, the simple functions executed inside STCB modules should nevertheless permit them to serve as the TCB for any SCADA system-irrespective of the nature and scale of the CI system.While the "instruction set" for specifying the state transition model should be rich enough to be suitable for any SCADA system, it should simultaneously be simple enough to be executed even by severely resource limited STCB modules.
The main components of the proposed STCB based security architecture include 1) a systematic strategy for designing SCADA state-transition models for any SCADA system, consisting of a) an instruction set for expressing the model, b) role of the designer of the SCADA system, and c) role of the deployer of the system; 2) a functional specification for STCB modules, suitable for executing the instruction set for any SCADA system; and 3) an STCB protocol, for interacting with STCB modules, and obtaining SCADA state reports.

Organization
The rest of this paper is organized as follows.Section 2 is an overview of STCB approach.Section 3 outlines the STCB design process.Section 4 outlines processes for STCB deployment and operation.Section 5 provides a detailed description of the STCB functionality.Section 6 describes the STCB protocol.Finally, conclusions are offered in Section 7.

Overview of STCB Approach
While a state-based security approach can be extended to any system, such an approach is indeed natural for critical infrastructure SCADA systems.Note that the ultimate purpose of a SCADA system, viz., to monitor and report CI system states to stake-holders, is indeed identical to that of state-model based security architecture, consisting of model-driven verification and reporting.
The state reports from a SCADA system can be seen as a function of the current states of all sensors associated with the system.For a SCADA system characterized by n sensors, let 1 n v v  represent the states of the n sensors, and let [ ] ( ) represent a function that captures the "physics" of the controlled system, and reports values [ ] o o  to the stake-holder as the "state of the system".More specifically, as inputs 1 n v v  to the SCADA system (sensor measurements) may be received asynchronously, the function ( ) is often realized as ( ) ( ) ( ) where ,1 is evaluated whenever an fresh measurement i v is made available.Furthermore, in practical SCADA systems, evaluation of ( )  is performed jointly by numerous system components that may include PLCs in multiple RTUs and MTUs, the HMI, and even actions by human operators.
Consequently, notwithstanding current active measures, the integrity of the state reports is far from assured.Specifically, current active approaches include features like a) cryptographic protection of links between RTUs and MTUs [15]- [20] to prevent message injection attacks by attackers and b) intrusion detection systems to facilitate early detection of attacks [21] [22] [23] to detect and evade attacks.
The goal of the STCB security model is to guarantee the integrity of state reports provided by the agent.To achieve its goals, the STCB security model relies only on a) the integrity of STCB modules, and b) the integrity of clearly defined processes to be adopted by entities identified as the designer and the deployer of the SCADA system.The designer is an entity with good domain knowledge (regarding the CI system); the deployer is a security professional who is not required to possess any knowledge of the CI system.To the extent the stake-holder trusts the integrity of the STCB modules, and the verifiable processes adopted by the designer and the deployer, the stake-holder is assured of the integrity of the state report-even if malicious functionality may exist in SCADA system components.

STCB System Components
The additional components introduced into a STCB-secured SCADA system include 1) an untrusted "STCB system manager" U, faithfully, valid state reports cannot be sent to the stake holders.
The state reports are relayed by the STCB manager U to an STCB module r M associated with a stake-holder.Any number of stake holder modules like r M may exist.More generally, a stake-holder module may be the CM for another STCB deployment.
For example, the state reports from different SCADA systems may be provided as "sensor reports" to a system at a higher level of hierarchy.In such a scenario, the stake-holder module r M can be seen as the CM of an STCB dep- loyment at a higher level of hierarchy.Module r M considers the state reports from the CMs of systems at the lower level as "sensor reports" from foreign STCB deployments.
Any number of hierarchical levels may exist.For example, state reports from multiple SCADA systems in a town may be inputs to a single SCADA system that monitors the health of all such systems in the town.The reports from such SCADA systems in different towns may be inputs to another SCADA system at an even higher level of hierarchy, that monitors the health of all systems in a state, and so on.


The main challenge lies in the choice of a strategy for evaluating any ( ) ( ) ( ) ( ) As no re- strictions are placed on the nature and scale of the SCADA system, some of the specific challenges are that 1) the number of sensors n can be unlimited; 2) evaluation of ( ) i  's may require evaluation of complex functions, and thus challenging to represent using merely the instruction set  .Both challenges are addressed through the use of Merkle hash trees [24].

Merkle Trees
A Merkle tree is a binary hash tree which permits a resource limited entity to assure the integrity of a dynamic database of practically any size, even while the database is stored in an untrusted location.Specifically, the resource limited entity only needs to store a single cryptographic hash-the root of the tree.A Merkle hash tree with 2 L n = leaves (for simplicity we shall assume that is a power of (2) has L levels.For storing a database with n records, each record is interpreted as a leaf of the tree.Corresponding to each leaf (record) R is a leaf-hash obtained as ( ) h R , by hashing the leaf using a secure cryptographic hash function ( ) The n leaf-hashes (say, at level 0 of the binary tree.At level 1 of the tree are n/2 leaf hashes , where ( ) Similarly, the n/2 leaves in level 1 result in n/4 nodes in level 2, and so on.Construction of the tree stops at level L with a single node 0 L v r = -the root of the tree.For any leaf i R (with corresponding leaf node ( ) ), there exists a set of L complementary nodes, say, i v , and a se- quence of L hash operations represented as , see Figure 2.
Protocols that employ Merkle hash trees can be seen as an interaction between two parties-a prover and a verifier.The prover stores all n leaves and all 2 1 n − nodes (distributed over levels 0 to L).The verifier stores only the root r (the lone node at level L).To demonstrate that a record R is part of the tree the prover provides L complementary nodes v as proof.The verifier accepts record R as authentic only if

Merkle Trees in the STCB Approach
In the STCB approach resource challenged STCB modules store only the root of the tree, and have the ability to perform operations.This capability is leveraged to assure the integrity of 1) a dynamic database of n sensor measurements; 2) any number of simple static "algorithms" to evaluate different where each algorithm is a small number of instructions (belonging to the instruction set  ) supported by STCB modules; and 3) static look-up tables (of any size) for evaluating complex functions that may be necessary to execute some (instruction in) Specifically, the STCB module 0 M for an STCB deployment stores a (static) root of a static Merkle tree, and the (dynamic) root of a dynamic Merkle tree.
The leaves of the static tree are the specifications for a specific STCB deployment-provided by the designer and the deployer of the system.The leaves of the dynamic tree are the current states of the n sensors of the system.The leaves and all intermediate nodes of both trees, are stored by the untrusted STCB manager U.

STCB Designer and Deployer
One of the main motivations for clearly demarcating between the roles of a designer and a deployer is that entities with good domain knowledge (for example, an entity with in-depth knowledge about the domain of specific CI system, like a nuclear plant) are often unlikely to be security experts.Likewise, security experts are unlikely to be experts in the domain of the specific CI system.
The designer is a domain expert with good knowledge of the CI system.The designer is required to be aware of the purpose of each sensor in the system, and the interpretation of their states.For example, (say) in a water-tank control sys-tem, "if 5 100 S > (water level greater than 100) 6 S should be zero (the pump should be off)."The responsibility of the designer is to come up with a specification for the function ( ) that captures the physics of the system.Specifically, the designer specifies two types of records.For a system with n sensors, the designer specifies 1) n static records 1 n  G G which convey cryptographic commitments to values (instructions, inputs, constants) necessary for executing each i  ; 2) n records 1 n  S S which convey the initial state of n sensors.During operation, a sensor report from i S will trigger execution of instructions defined in a record i G to modify record i S .
The deployer is a security professional who may not possess any CI system domain knowledge.The responsibility of the deployer is to procure and install STCB modules, and be aware of steps to be taken, for example, to 1) facilitate establishment of shared secrets between modules; 2) securely connect (for example, using tamper-evident connectors) physical sensor outputs to SMs, and record such bindings (for example, ( ) ,

S M
indicating that sensor 5 S is connected to module 8 M ); 3) deploy the STCB manager U-which includes installation of all hardware/software necessary to relay SM outputs to the STCB manager U, setting up a channel to the CM 0 M , and a channel to be used for conveying state reports to stake holders.However, U, and such channels, are not trusted.
Ultimately, the components of the system-model specified by the deployer take the form of two types of records.Records of type B (binding records) specify binding between a sensor identity i S and the module identity j M respon- sible for authenticating reports from i S .Records of type R (or reporting records) specify the identity of the STCB module to which a report regarding a specific system-state is to be made.

STCB Design
The designer is entrusted with the responsibility of describing function is evaluated whenever an fresh measurement from sensor i S is available.

STCB Design Tree
The designer provides a specification of ,1 Merkle tree-the design tree-with root s ξ .The tree includes where 0 ξ is itself a root of a Merkle tree with n leaves.Each leaf specifies the initial state of n sensors as records ,1 . The other n leaves correspond to the n design records ,1 . The sensor records and design records are of the form Each sensor is associated with a set of 3 w + dynamic values, where w is a constant.Specifically, 1) i v is the latest measurement of sensor i S ; 2) i t is the time of the measurement; 3) are the w outputs of function i  , eva- luated when the last report ( ) v t was received from sensor i S .The value i τ is a measure of time associated with the outputs (and is not necessarily the same as i t ).In the design record i G for sensor i S , value ( ) A is the hash of a small number (say, m) of instructions chosen from the set  .Specifically, the instructions i A define the function i  to be evaluated on receipt of a report from sensor i S .The value i λ is a one way function of a set of (say, l) constants C. Such constants may specify various values like set-points, permitted ranges of measurements, minimum expected frequency of reports from sensors, etc.In addition, such constant values may also be used as look up tables.The values ,1 , i i q S S  specify (up to) q related sensors.Such sensors are "related" to i S as the states of such sensors can influence i  .Some or all of the q values ,1 can be set to zero if less than q related sensors suffice.Finally, the value i S′ is optional, and is the identity of a "synthetic" sensor (explained later).

Example System
To describe different steps involved in the construction of a design tree we will use a simplified version of a thermal power plant with six sensors 1

6
S S  as a running example, see Figure 3.       , , , , The design records

Inputs and Outputs of i 
Due to limited memory inside STCB modules, there is a need for a strict upper bound on the number of inputs to, and outputs of, each i  .In other words, ir- respective of the total number of sensors n, note that i  s are restricted to speci- fying only 1) up to q related sensors, 2) l constants, 3) m instructions, and 4) one synthetic sensor as inputs.Each i  produces w outputs.
As i  is re-evaluated whenever a fresh report , (registers 5) m instructions i A (some of which may be set to 0 to represent "no op- eration" if m instructions are not required to evaluate i  ); The m logical operations in i A provide the instructions to recompute the outputs 1) , replace the previous values ( ) 3) and i τ is replaced with ( ) to reflect the staleness of the w outputs.
Note that dynamic values associated with any i S may be affected not just by values corresponding to sensors directly related to i S , but also sensors indirectly related to i S -for example sensors related to a related sensor j S (once re- moved) or sensors related to a sensor related to j S (twice removed) and so on.
Computing the value τ as in Equation ( 5) ensures that the value i τ will be the least of the sensor-report time t corresponding to every sensor that is directly or indirectly related sensor i S .
On a continuous basis, as and when new sensor reports are available, the states of the reporting sensors are modified.A subset of dynamic values corresponding to a subset of sensors may be reported to the stake-holder as values o o  describing the state of the system.For example, if value ) is one of the values reported as the state of the system, the time associated with the state o is reported as j τ .

Example i  for Power Plant
For the example system 0.0.3, let the maximum number of related sensors be 3 q = ; the number of outputs of each i  be 2 w = ; and the number of constants 8 l = .In this example, say there exists a rule that the values 1 2 , v v of sensors 1 2 , S S have to be within threshold ranges ( ) ( ) , , , The design of function , , , x x x x respectively.The inputs are 1 2 , v v and constants.The output is written in S is specified as a related sensor.As no other related sensors are used, S are set to 0.
As 1  is re-evaluated whenever a fresh report 1 1 , v t   is available from sensor 1 S , the inputs necessary to evaluate 1  are stored in reserved volatile registers inside STCB modules, and include 1) values in the record 1 S associated with sensor 1 S (stored in a register 0 s inside the module); 2) values 1 1 , v t   in a fresh report from sensor 1 S (register r); 3) values of record 2 S is specified for 1,1 S for related sensors, and 1,2 S and 1,3 S are set to 0 (registers 1 3 s s  ); 4) l constants in 1 C (register c); and

5) m instructions 1 A
The m logical operations in i A provide the instructions to recompute the outputs 3) and 1 τ is replaced with ( ) to reflect the staleness of the w outputs.

Synthetic Sensors
The sensors 1 n S S  can be of three types-real sensors, state-report sensors, and synthetic sensors.
Real sensors are physical sensors in the SCADA deployment.Specifically, during the STCB deployment phase, real sensors are bound to SMs.
State reports from a foreign STCB system are seen by the receiving CM as a Journal of Information Security "sensor" report; as such reports are authenticated by the CM of the foreign deployment, state-report sensors are bound to foreign CMs.
Synthetic sensors are not bound to CMs or SMs.In a design record i G , if 0 i S′ ≠ , implies that evaluation of i  results in the "synthesis of a fresh report from a (synthetic) sensor i j S S ′ = ".Just as a fresh report from a sensor i S should be followed by evaluation of i  , a fresh report from synthetic sensor j i S S′ = should be followed by evaluation of j  .
The primary motivation for using such synthetic sensors is to cater for complex i  where the fixed number of (m) instructions in i A may be insufficient.
By specifying a synthetic sensor Similarly, evaluation of j  , specified by the designer as ,1 , , , , , may be continued again, if necessary, by specifying 0 j S′ ≠ .

Constants and Look-Up Tables
In general, the value i λ -which is a one way function of constants required to evaluate i  -may be a function of multiple sets of l constants (l constants in each set).More specifically, i λ is itself the root of a Merkle tree, where each leaf specifies a set of l constants.Any number of such leaves may exist, with a minimum of one.
Permitting an unlimited number of constants facilitates the use of look-up tables (LUT) for evaluating i  .An LUT for evaluating a complex function ( ) where there are no practical limits on j.In each set two of the l constants will specify the range of the independent variable x, and one will specify the corresponding dependent variable y.For 2 dimensional LUTs of the form , y f x x = , four of the l constants will specify the ranges for the two independent variables, and a fifth constant will specify the corresponding value of y.
Special instructions (say LUT1 and LUT2) in the instruction set  will specify the operands-the dependent and independent variables.As one possible design of the two instructions, instruction LUT1 interprets constants 1 c and 2 c as the range of the independent variable x and constant 3 c as the corres- ponding dependent variable y.Before the module executes the instruction LUT1, it expects the value of the input operand to be within the range of constants 1 c and 2 c -else the execution will not proceed.If the input operand satisfies the requirement, then the value of the output operand is set to 3 c .Similarly, for LUT2, constants 1 c and 2 c specify the range of the first input operand 1 x ; , c c specify the range of the second operand 2 x ; 5 c is the corresponding output y.

Instruction Set 
Each instruction in  specifies a logical operation (opcode), input operands (1, 2 or 3) depending on the type of opcode, and an output operand.The operands are restricted to be values in STCB registers 0 q  s s , c, r, etc.Specifically, as the instructions in each i  can modify only values in register 0 s (the current state of sensor i S when i  is computed), only such values, and a temporary register T can be specified as output operands.
Examples of simple logical operations include traditional operations like addition/subtraction, logical operations, bit-wise operations, COPY, MOV, etc., and some special instructions like LUT1 and LUT2.Other potentially useful special instructions for SCADA systems is a bounds checking operation CHKB which checks a specific value is within set-points specified as constants and tolerance checking TOL where two values are verified to be close enough-within a tolerance specified by a third value.
Ultimately, a comprehensive specification for STCB modules will fix values like the number of related sensors q, number of outputs w, and the number of constants l (and hence the number of addressable values in the STCB registers).
Such a specification will also include a detailed listing of all permitted opcodes and their interpretation.This paper, however, is restricted to describing some of the salient features of STCB modules.

Instructions for Thermal Power Plant Example
For the example system 3.1.1,let 1 6 v v  be the values reported by sensors S S  required to determine the state of the system.
Let us assume that the state report expected by the stake-holder is a single bit value-1 1 o = if the system is in an acceptable state, and 1 0 o = otherwise.Ac- cording to the designer, the system is in an acceptable state if the following conditions are satisfied: are all within thresholds ( ) ( ) , , respectively, where ( ) x x represents lower and higher thresholds for sensor i S .
2) The speed of turbine should be between upper and lower limits depending on the temperature and pressure inside the turbine cell.
( ) where 1 δ is another threshold (the speed of the turbine should be a specific function of the pressure and temperature inside the turbine cell).
3) The position of the fire regulator should be between upper and lower limits depending on the current speed of turbine 6 v and the current temperature and pressure values inside the boiler cell.
( ) is a function of the temperature and pressure of the boiler.
Let the maximum number of related sensors be 3 q = ; the number of outputs of each  be 2 w = ; and the number of constants 8 l = .A possible design of functions ,1 v v are within thresholds ( ) ( ) , , , The inputs are 1 2 , v v and constants.The output is written in o of related sensor 5 S ; the 1/0 result is stored in register S represents the entire state of system (acceptable-1, unacceptable-0).

STCB Deployment
The deployer of the SCADA system is trusted to verify the integrity of the physical bindings between various sensors and SMs.Specifically, the deployer is required to permanently connect the outputs of every sensor to an SM, and apply tamper-evident seals to such connections.The deployer specifies binding records of the form Table 1.Instructions for thermal power plant., , , to convey that 1) measurements corresponding to sensor i S will be reported by a module j M ; if i S is a real sensor, then j M is an SM; if i S is a state-report sensor, then j M is the identity of the CM of a foreign system.Recall that synthetic sensors are not bound to CMs or SMs and thus have no binding records.The deployer may be totally oblivious of the existence of such records; 2) i  is an achievable minimum round-trip duration between module To indicate that a module 0 M was deployed as the CM for the STCB system, the binding records includes a record for the CM 0 M as ( ) Depending on the requirements specified by the stake holder, the deployer also specifies reporting records of the form ( ) , , , ,1 to indicate that the value All such i B and j R are included as leaves of a static Merkle hash tree con- structed by the deployer-the STCB deployment tree.Let p ξ be the root of the deployment tree with leaves The end-result of the design and deployment processes are two hash trees with roots s ξ and p ξ .The design root s ξ can be seen as concise representa- tion of the physics ( ) can now be seen as the root of a Merkle tree with two sub-trees-the design tree to the left, with root s ξ , and the deployment tree to the right, with root p ξ .
The static value sp ξ is the unique descriptor for a specific STCB deployment (deployed to secure a specific SCADA system), see Figure 4.
Note that two different deployments of identical SCADA systems may have the same design root s ξ , but will have different deployment root p ξ as dif- ferent STCB modules will be used in the two deployments.If ( ) resistant, no two STCB deployments will have the same descriptor sp ξ .

STCB Operation
To commence operation in a SCADA deployment, the STCB module 0 M asso- ciated with the system is initialized with the STCB descriptor sp ξ , and the value 0 ξ corresponding to the initial state of sensors.All leaves of the tree with root sp ξ (which includes two sub-trees-the design tree and the deployment tree) are stored by U; all n leaves of the form ,1 corresponding to the initial states of all sensors are also stored by U.
During regular operation of the system the STCB manager U receives authenticated sensor reports from SMs (and possibly CMs from foreign deployments), and submits them one at a time, to the CM 0 M .Such reports take the form of a message authentication code (MAC) computed as ( ) , , , , , where 1) values ( ) , , S v t indicates a report for sensor S to convey a fresh measurement v and measurement time t; 2) c is the clock-tick value of the module that created the report; 3) sp ξ is STCB descriptor of the creator of the report (which was the value used to initialize the module); 4) K ′ is a shared secret between the creator (SM or foreign CM) and receiv- Along with the report from sensor i S (authenticated by a module j M ), U also submits a binding record i B constructed by the deployer, consistent with the static root sp ξ .
The STCB manager U is then required to submit other values required for the CM to evaluate i  .Such values include: 1) sensor state record i S ; 2) the state records of the (up to) q related sensors; 3) a design record i G consistent with descriptor sp ξ ; 4) l constant values i C ; and 5) m instructions i A .
As dynamic sensor states associated with the n sensors are maintained by U as leaves of dynamic a Merkle tree with root ξ , sensor state records provided by U will be accepted as valid only if they can be verified to be consistent with a copy of the dynamic root ξ stored inside the CM 0 M .The instructions i A will be accepted as valid only if ( ) To "remember" such changes to i S the module modifies the dynamic root ξ .If untrusted U does not modify i S in the same manner, then i S will no longer be consistent with the root ξ stored inside the CM.Thus, if U provides a fresh sensor report to the CM to invoke i  , it is forced to modify the state of i S exactly in the manner specified by the designer.If U does not invoke functions to evaluate any i  , the time i t associated with i S cannot be updated.Thus, in any state-report that directly or indirectly depends on sensor i S the time τ will be stuck at i t , and will thus be recog- nized as stale by the stake-holder (or CM of a foreign deployment).

STCB Interfaces
To interact with the STCB modules (SMs and CM), U employs various interfaces exposed by the modules.An interface To the extent the SMs and the deployer (who is trusted to verify and specify bindings between sensors and SMs) are trusted, we can trust the authenticity of sensor reports provided to the CM module.To the extent the CM module 0 M , and the designer (who is responsible for specifying the functions trusted, the stake-holder trusts the integrity of the state reports.
In practice, the SMs will need to be located as close as possible to the sensors to improve the security of the binding between sensors and SMs.The CM could be housed in any location-for example, a secure location far removed even from the SCADA control center.Components of U will need to be housed close to SMs, and close to the CM.

STCB Architecture
STCB modules have a unique identity, and a unique secret issued by a trusted key distribution center (KDC).(say) M can use their respective secrets (say) i Q and j Q issued by the KDC to compute a common pairwise secret ij K [25].Specifically, associated with a pair of modules M M is a non-secret value ij P which is also made available by the KDC (for example, in a public repository), where ij P is computed as Module i M and j M can compute a common secret ( ) , 0 Computed by Module , Computed by Module , , , 2) a non-volatile session counter σ , which is incremented; and 3) a random secret γ , which is spontaneously generated inside the module.

Module Registers
Non-volatile storage inside the module is used to store three values-secret Q issued by the KDC, session counter σ , and module identity M.
Every module has the following reserved volatile registers: The self-secret γ spontaneously generated inside the module remains privy only to the module.This secret is used for computing self-certificates.A self-certificate is a "memorandum to self",-memoranda issued by the module for verification by itself at a later time, during the same session σ .The register sp ξ is the (160-bit) descriptor of the STCB system.The register ξ is the dynamic root of a Merkle tree.Register p contains various parameters regarding a peer module from which 1) sensor/state report has to be received, or 2) a report has to be sent.
The register c is reserved for storing a set of l constants to be used to evaluate some i  corresponding to a sensor i S .Values that reflect the current state i S of i S should be stored in register 0 s .The states of q related sensors are stored in registers Register r is reserved for a freshly received sensor report from i S .
For example, if at some instant of time, 1) the contents of the dynamic record i S corresponding to sensor i S is stored in location 0 s , and 2) records corresponding to sensor ,1 are stored on location 1 q  s s respectively, and 3) values from a fresh report from sensor i S are stored in register r, then , ˆmeasurements of related sensors of The SM register in S indicates the sensor to which the module is bound (if the module is used as a SM) or is set to zero (if the module is used as a CM).If the module is used as an SM, the register in v always contains the (dynamic) sensor measurement.
STCB modules have a built in hash function ( )

Initializing Peer Parameters
The pairwise secret K that a module M shares with a peer module M ′ is used for computing message authentication codes (MAC) for outgoing messages to peer M ′ , and for verifying incoming MACs from peer M ′ .Specifically, the secret used by M for computing outgoing MACs is ( ) where σ is the session counter of M; consequently, the secret used for verifying MACs re- , where σ ′ is the session counter of M ′ .STCB modules possess reserved registers to store the identity M ′ of a peer module (to which it needs to send a message, or from which it needs to receive a message), the session counter σ ′ of the peer, and MAC secrets in K and out K .

Function
To facilitate secure communications between two modules ( ) , 0, i M computes the pairwise secret using the public value ij P ; j M computes the same value without using ij P (or 0 ij P = as XORing with 0 results in no change).

Self Certificates
Two types of certificates are computed by STCB modules-binary hash tree certificates, and offset certificates.

Binary Tree Certificates
A binary hash tree certificate is computed as ( )

F x x y f x y f x h x x y y F x x y y z z h x x y y h y y z z
concatenates two such certificates to create another certificate.Specifically, a certificate binding node x (and x′ ) to an ancestor y (and y′ ) and a certificate binding a node y (and y′ ) to an ancestor z (and z′ ) can be combined to a certificate binding node x (and x′ ) to an ancestor z (and z′ ).
The primary need for the function ( ) mtc F is due to restrictions on the size of inputs to module functions.Specifically, we can now place a hard limit on the size of the input x v -to (say) 8 hashes.For computing relationships between a node and the root of a tree with a million leaves (20 levels) three calls to ( ) mt F (to produce certificates binding 1) a level zero node to a level 8 node, 2) level 8 node to a level 16 node, and 3) a level 16 node to a level 20 node) and two calls ( ) mtc F (to combine the first two certificates, and combine the resulting certificate with the third certificate) can be used.

Offset Certificates
An offset certificate is computed as ( ) , , , , , and states that the module M (that issued the certificate) had performed a handshake within a duration  with a module M ′ , and had estimated the offset between their clocks to be os .The certificate also states that the handshake was performed when it's session counter was σ and the session counter of M ′ was σ ′ .The offset certificate is issued by a function ( ) hs F is then invoked in the responder module with inputs ( ) , , , , ( ) hs F is then invoked on the initiator for the second time, at time . The offset between the clock of the initiator and the responder can be estimated by the initiator to within the round-trip duration . The best estimate of the initiator is that, when the clock tick count of responder was r c , the clock tick count of the initiator was ( ) thus, the best estimate of the offset is ( ) The output of ( ) hs F in this case is the offset certificate.This certificate can be provide to the module at any time to convince the module that "the offset to M ′ was estimated as os with a tolerance of  ", and that "the offset to M ′ was estimated when the session counters of the modules were i σ and r σ ".If any of the two session counters had changed since the certificate was issued, the certificate becomes invalid. (

Initializing STCB Modules
Initializing an STCB module M implies initializing three internal registers reserved for values , sp ξ ξ and in S .Specifically, a module M can be initialized to participate in a deployment sp ξ only if a binding record for module M can be demonstrated to be consistent with sp ξ .
As 0 ξ is a node in a tree with root sp ξ , U can use Similarly, as binding record [ ] , , , that exists in deployment tree is used to initialize the register in S Now U can use , , , , F can be used to initialize a module M as 1) a CM for a deployment sp ξ or 2) as an SM for a sensor S in deployment sp ξ .
To initialize a module as a CM for the deployment, the inputs ( ) are such that ρ is a binary tree certificate relating a node 0 ξ ξ = to prove to the module that "in an STCB system with descriptor sp ξ , the module M (which is being initialized) is authorized to report measurements corresponding to sensor S′ ".Accordingly, the register in S in the module M is set to S′ .
For a module j M initialized as a SM for a sensor k S , the output of the sen- sor k S is physically connected to module j M using a tamper-evident seal by the deployer.The physical connection ensures that the sensor measurement k v is always available in the register in v of the SM.measurement Later (during regular operation) module

Sensor and State Reports
In an STCB deployment with SMs , , , , , where for sensor reports (from SMs to in S S = is the identity of a sensor that is bound to the module that created the report, and 2) t c = is the current clock tick count of the creator of the report; 3) sp ξ is the value used to initialize the module.
A report from 0 M to stake holders is made in accordance with a record [ ] ( ) Corresponding to a state report for a "sensor" r S , while the STCB module 0 M that generates the report is initialized with the sp ξ , the stake-holder module r M -which in general can be seen as the STCB module associated with a foreign STCB system may be initialized with a different descriptor sp ξ ′ .
For the module r M to accept the report from a foreign system, the deploy- ment tree in the foreign system with root sp ξ ′ should include a binding record 0 , , , 0

Sensor Updates and Incremental State Evaluations
Values r in a fresh sensor report from i S are part of the inputs used to evaluate i  .Evaluation of i  results in modifications to the state i S of sensor i S .
Before i  can be evaluated it should be ensured that appropriate values are loaded on to registers r, 0 s , 0 q  s s , and c.
Recall that register r is populated by function The main purpose of it should be ensured that the current state of sensor i S is loaded onto register 0 s , and the states of related sensors 2) the instructions A should be such that ( ) 3) i λ and i α should exist in the design record 1 0 , , , 4) the values 0 S ∈s (the identity of the sensor to be updated) and S ∈  r (the sensor from which a fresh report has been received) should be the same.
During execution of the algorithm A, in situations where many options exist for choosing the set of constants C consistent with λ it is the responsibility of U to choose the correct set of constants that satisfy the range of the independent variable(s).On successful evaluation of the algorithm A the status of sensor 0 S in register 0 s will be updated.If x is the hash of register 0 s before the update, and if x′ is the hash of register 0 s after the update, then a new root ξ ′ and a certificate ρ should be provided as input satisfying ( )

STCB Protocol
The STCB protocol can be seen as the actions to be performed by the untrusted STCB manager U to submit sensor reports from SMs and CMs of foreign deployments to the CM 0 M of the STCB deployment, obtain state-reports from 0 M , and submit such reports to stake holders (or CMs of foreign deployments).

Generation of Offset Certificates
The first step in the operation of an STCB deployment is that of performing handshakes between various modules to obtain offset certificates.In general one offset certificate will be generated for every module specified in the binding records of the deployment.
For a STCB system with n sensors (real, state-report and synthetic) the total number of binding records is 1 n′ + , where n n′ − is the number of synthetic records: no binding record exists for synthetic records, and one binding record is for the CM 0 M .The total number of distinct modules in general will be n n ′′ ′ ≤ .
Specifically, while there will exist one module corresponding to every real sensor, as a single CM may report multiple states, the number of state-report sensors may be greater that the number of foreign CMs that provide state reports.
A total of n′′ hand shake sequences will be invoked to obtain n′′ offset cer- tificates.Recall that each such sequence begins with a challenge from the CM 0 M generated using

Generating Static Binary Tree Certificates
The second step is for U to obtain binary tree certificates corresponding to all leaves of the static tree with root sp ξ .Specifically, as U maintains the tree with root sp ξ , U can readily provide the complementary nodes for any leaf in the static tree to function , and obtain certificates of the form ( ) , , , , where s x is the cryptographic hash of the s th leaf of the static tree.The total number of static leaves is ( ) ( ) 1) n is the number of design records: one for each sensor (real, state-report, or synthetic); 2) one leaf corresponds to the value 0 ξ in the design tree; 3) 1 n′ + is the number of binding records (including one for the CM 0 M ); and 4) m is the number of reporting records.

Initialization and Regular Operation
The third step is the initialization of STCB modules to operate in deployment sp ξ -by invoking ( ) init F on each STCB module.For initializing the modules the two binary tree certificates are required: one linking 0 ξ to sp ξ , and one linking a binding record for the module with the static root sp ξ .
On completion of the three steps, the STCB manager maintains a dynamic Merkle tree with leaves as sensor records.As the initial values of such records are specified by the designer, the root of the tree should be the same as the initial value To create a sensor report from an SM, U will invoke ( ) snd F on an SM.Some Journal of Information Security sensor reports corresponding to state reports from foreign CMs may also be received by U.
Once a sensor report for some sensor i S has been received, U is expected to make appropriate modifications to the sensor state i S , and accordingly, modify Corresponding to the sensor state record for sensor i S and q related sensors U invokes ( ) bt F to obtain 1 q + certificates binding the sensor state records to dynamic root ξ .Following this, the STCB manager uses ( ) ld F up to 1 q + times to load the 1) previous sensor state i S on to register 0 s and 2) the states of related sensors on to registers 1 q  s s .Finally, the STCB manager invokes

Conclusions
The ever growing complexity of systems poses a severe threat-the possibility of hard-to-detect hidden functionality that can be exploited to take control of the system.Current strategies for securing SCADA systems are predominantly focused on development of suitable intrusion detection systems.Such security measures ignore the very real possibility of hidden functionality in the intrusion detection systems themselves.
In the proposed approach to secure SCADA systems only STCB modules are trusted to provide the assurance that "no attack will go undetected".The proposed approach involves three stages-a design process carried out by a designer with good domain knowledge, a deployment process carried out by a security professional, and regular operation of the STCB system.The designer and deployer together specify a concise description sp ξ of the system.During regular operation, an STCB module reports the state of a system identified as sp ξ to stake-holders.Some of the important features of the STCB approach that make it well suited for any SCADA system of any size include 1) the ability to support hierarchical deployments; 2) the ability to support any type of function  -if necessary through the use of 1-D, or 2-D look up tables (which are also specified as leaves of the design tree); and 3) the ability to specify synthetic sensors.
Such features are intended to enable the use of STCB modules for any system.
The first pre-requisite for deployment of STCB based security solutions is the actual availability of STCB modules/chips.Towards this end, the work that has been performed is a small first step-identification of a functional specification of such chips.In arriving at an appropriate functional specification, some our main goals have been 1) reducing computational and memory requirement inside STCB chips; 2) reducing interface complexity (size of inputs and outputs to/from the STCB chips); and 3) simplifying the STCB protocol-which is a specification of a sequence of interactions with the STCB modules-to realize the desired assurances.
The proposed functional specification (for STCB modules) is merely a specification, and not the specification.Just as there are numerous ways to realize a block-cipher or a hash function, there are numerous ways to arrive at a "set of STCB functions" (which can be leveraged to realize the same assurances).The functional specification in this paper is however the first of its kind.

Figure 1 .
Figure 1.Top: STCB components.Bottom: Information flow in the STCB model.The STCB module rM associated with the stake-holder can be the CM for a deployment at a higher hierarchical level.

Figure 2 .
Figure 2. A binary hash tree with 8 leaves.The set of complementary nodes for 6 R are "the siblings of all ancestors of 6 R "-7 v (sibling of 6 v ), 1 2 v (sibling of ancestor 1 3 v )

1 S
temperature sensor inside boiler.

2 S
coal weight sensor (coal fed into the boiler).

3 S
position of fire regulator.

4 S
temperature inside turbine cell.

5 S
pressure inside turbine cell.
implies a record corresponding to a real sensor; 0 θ ≠ implies report from a foreign STCB system with STCB descriptor sp ξ θ = .
j τ ) "measurement" from state-report sensor r S .

Figure 4 .
Figure 4. Static descriptor spξ is a concise summary of the specification for an STCB system.

ξMτ
can be provided as input, along with the state record j S consistent with ξ , to request the STCB module 0 in a state-report "sensor" r S .
Every module possesses three values that are affected whenever a module is powered on: 1) a clock tick counter c, which is set to 0; module can execute a set of m instructions A , where each instruction (chosen from the set  ) identifies a) an opcode (type of logical operation), b) one or more input operands (from the values stored in registers 0 s , 1 q  s s , c, T), depending on the type of opcode; and c) the output operand ( temporary register T).

FF
can be invoked on pair of modules to perform a handshake, after which the initiator of the handshake obtains an estimate of the clock offset of the responder.Before to set up respective peer identities, session counters, and secrets in K and out K to be used for incoming and outgoing MACs.has three inputs-a received MAC µ′ (from peer M ′ ) with time stamp c′ , and a time-stamp c  that was previously sent to peer M ′ (which had triggered the response µ′ from M ′ ).The output of intended for the peer or a self-MAC intended for itself, indicating the estimated offset for peer M ′ .( ) hs F is first invoked on the initiator with all inputs ( ) current clock-counter and the session counter of the initiator and r σ is the ses- sion counter of the responder.
and ′  are set to 0).To initialize the module as a SM the certificate, inputs S′ and  are non-zero.The binary tree certificate should relate

jM
cannot be initialized to act as a SM for any other sensor k S S ′ ≠ , as no record binding S′ to j M can be demonstrated to be a part of the tree with root sp ξ .s provided input is simply loaded onto register j s where j is the index specified.Specifically, the record is loaded only if the inputs ρ and ( ) h s are consistent with dynamic root ξ .

MM , and STCB module 0 M
, the state reports are made available to a module r M associated with the stake holder.In general, r M can be seen as an STCB module associated with a different STCB system at a higher level of hierarchy.The handshake sequence (which involves two calls to sequences have been completed, k self-certificates of type OS os ρ are created by 0 M -one corresponding to each SM, and one self-certificate is created by r M .Such certificates indicate both the estimated offset os, and the maximum error  in the estimate os.Now modules are ready to exchange authenticated messages.More specifically, SMs send authenticated and time-stamped sensor reports to 0 can send state reports to r M .Such messages exchanged between modules are computed as ( )

(
used to load the dynamic values S associated with any sensor on to any of the 1

F
STCB module.Once all STCB modules have been initialized, sensor reports from SMs (or CMs of foreign deployments) are submitted to the CM as and when they are received.In general, not all sensors may report at the same frequency.As all SMs send messages only to the CM, needs to be invoked only once on each SM (which was already performed before invoking ( ) hs F to generate offset certificates).

theF
Merkle tree maintained by U. Let ξ ξ′ → be the change in the root of the dynamic tree, corresponding to the modification i i include a MAC received from an SM/CM, a binding record along with a certificate linking the record to sp ξ , and an offset certificate corresponding to the reporting module.

ρF
obtained as per Equation(25), a certificate binding design record i G to STCB descriptor sp ξ , the set of m instructions i A , a set of l constants, and a certificate binding the constants to a value λ in the design record.Only if the modification i i ′ → S S computed by the CM is exactly the same as that performed by the STCB manager U will the update be successful in modifying the dynamic root ξ stored inside the CM to ξ ′ .At any time the STCB manager can invoke a is invoked on a CM a certificate binding a reporting record to the static root should be provided as input.
the trusted confines of resource challenged STCB modules.Recall that we desire to deliberately constrain STCB modules to possess only modest memory and computational abilities.Consequently, we constrain STCB modules to perform only logical and cryptographic hash operations.By performing simple logical operations the STCB modules support a simple instruction set  for representing different the system.The deployment root p A where i α is specified in the design record