sscada: securing SCADA infrastructure communications

Transcription

1 Int. J. Communcaton Networks and Dstrbuted Systems, Vol. 6, No. 1, sscada: securng SCADA nfrastructure communcatons Yongge Wang Department of SIS, UNC Charlotte, 9201 Unversty Cty Blvd, Charlotte, NC 28223, USA E-mal: Abstract: Dstrbuted control systems (DCS) and supervsory control and data acquston (SCADA) systems were developed to reduce labour costs, and to allow system-wde montorng and remote control from a central locaton. Control systems are wdely used n crtcal nfrastructures such as electrc grd, natural gas, water and wastewater ndustres. Whle control systems can be vulnerable to a varety of types of cyber attacks that could have devastatng consequences, lttle research has been done to secure the control systems. Amercan Gas Assocaton (AGA), IEC TC57 WG15, IEEE, NIST and Natonal SCADA Test Bed Program have been actvely desgnng cryptographc standard to protect SCADA systems. Amercan Gas Assocaton (AGA) had orgnally been desgnng cryptographc standard to protect SCADA communcaton lnks and fnshed the report AGA 12 part 1. The AGA 12 part 2 has been transferred to IEEE P1711. Ths paper presents an attack on the protocols n the frst draft of AGA standard (Wrght et al., 2004). Ths attack shows that the securty mechansms n the frst verson of the AGA standard protocol could be easly defeated. We then propose a sute of securty protocols optmsed for SCADA/DCS systems whch nclude: pont-to-pont secure channels, authentcated broadcast channels, authentcated emergency channels, and revsed authentcated emergency channels. These protocols are desgned to address the specfc challenges that SCADA systems have. Keywords: supervsory control and data acquston; SCADA; dstrbuted control systems; DCS; cyber attacks; smart grd securty; crtcal nfrastructure protecton; secure communcaton Reference to ths paper should be made as follows: Wang, Y. (2011) sscada: securng SCADA nfrastructure communcatons, Int. J. Communcaton Networks and Dstrbuted Systems, Vol. 6, No. 1, pp Bographcal notes: Yongge Wang receved hs PhD from the Unversty of Hedelberg, Germany. Snce then, he had worked n the ndustry for a few years untl he joned UNC Charlotte n He has actvely partcpated and contrbuted to the standards bodes such as IETF, W3C XML Securty protocols, IEEE 1363 standardsaton groups for cryptographc technques and ANSI T11 groups for SAN network securty standards. He s the nventor of Remote Password Authentcaton Protocol SRP5 (an IEEE Standard) and dentty-based key agreement protocol WANG-KE (an IEEE Standard). Copyrght 2011 Inderscence Enterprses Ltd.

2 60 Y. Wang 1 Introducton Control systems are computer-based systems that are used wthn many crtcal nfrastructures and ndustres (e.g., electrc grd, natural gas, water and wastewater ndustres) to montor and control senstve processes and physcal functons. Wthout a secure supervsory control and data acquston (sscada) system t s mpossble to protect the naton s crtcal nfrastructures. Typcally, control systems collect sensor measurements and operatonal data from the feld, process and dsplay ths nformaton, and relay control commands to local or remote equpments. Control systems may perform addtonal control functons such as operatng ralway swtches, crcut breakers, and adjustng valves to regulate flow n ppelnes. The most sophstcated ones control devces and systems at an even hgher level. Control systems have been n place snce the 1930s and there are two prmary types of control systems. Dstrbuted control systems (DCS) and supervsory control and data acquston (SCADA) systems. DCS systems typcally are used wthn a sngle processng or generatng plant or over a small geographc area. SCADA systems typcally are used for large, geographcally dspersed dstrbuton operatons. For example, a utlty company may use a DCS to generate power and a SCADA system to dstrbute t. We wll concentrate on SCADA systems and our dscussons are generally applcable to DCS systems. In a typcal SCADA system (Cegrell, 1986), data acquston and control are performed by remote termnal unts (RTU) and feld devces that nclude functons for communcatons and sgnallng. SCADA systems normally use a poll response model for communcatons wth clear text messages. Poll messages are typcally small (less than 16 bytes) and responses mght range from a short I am here to a dump of an entre day s data. Some SCADA systems may also allow for unsolcted reportng from remote unts. The communcatons between the control centre and remote stes could be classfed nto followng four categores. 1 Data acquston: the control centre sends poll (request) messages to RTU and the RTU dump data to the control centre. In partcular, ths ncludes status scan and measured value scan. The control centre regularly sends a status scan request to remote stes to get feld devces status (e.g., open or closed or a fast closed-open-closed sequence) and a measured value scan request to get measured values of feld devces. The measured values could be analogue values or dgtally coded values and are scaled nto engneerng format by the front-end processor (FEP) at the control centre. 2 Frmware download: the control centre sends frmware downloads to remote stes. In ths case, the poll message s larger (e.g., larger than 64K bytes) than other cases. 3 Control functons: the control centre sends control commands to a RTU at remote stes. Control functons are grouped nto four subclasses: ndvdual devce control (e.g., to turn on/off a remote devce), control messages to regulatng equpment (e.g., a rase/lower command to adjust the remote valves), sequental control schemes (a seres of correlated ndvdual control commands), and automatc control schemes (e.g., closed control loops).

3 sscada: securng SCADA nfrastructure communcatons 61 4 Broadcast: the control centre may broadcast messages to multple RTU. For example, the control centre broadcasts an emergent shutdown message or a set-the-clock-tme message. Acqured data s automatcally montored at the control centre to ensure that measured and calculated values le wthn permssble lmts. The measured values are montored wth regard to rate-of-change and for contnuous trend montorng. They are also recorded for post-fault analyss. Status ndcatons are montored at the control centre wth regard to changes and tme tagged by the RTU. In legacy SCADA systems, exstng communcaton lnks between the control centre and remote stes operate at very low speeds (could be on an order of 300 bps to 9,600 bps). Note that present deployments of SCADA systems have varant models and technologes, whch may have much better performances (for example, 61,850-based systems). Fgure 1 descrbes a smple SCADA system. Fgure 1 A smple SCADA system (see onlne verson for colours) In practce, more complcated SCADA system confguratons exst. Fgure 2 lsts three typcal SCADA system confguratons (see, e.g., AGA Report No. 12, 2004). Recently, there have been several efforts to secure the natonal SCADA systems. The examples are: 1 Amercan Gas Assocaton (AGA) (AGA Report No. 12, 2004). AGA s among the frst to desgn cryptographc standard to protect SCADA systems. AGA had orgnally been desgnng cryptographc standard to protect SCADA communcaton lnks and fnshed the report AGA 12 part 1. The AGA 12 part 2 has been transferred to IEEE P IEEE P1711. Ths s transferred from AGA 12 part 2. Ths standard effort tres to defne a securty protocol, the Seral SCADA Protecton Protocol (SSPP), for control system seral communcaton. 3 IEEE P1815. Standard for Electrc Power Systems Communcatons Dstrbuted Network Protocol (DNP3). The purpose of ths standard s to document and make avalable the specfcatons for the DNP3 protocol. 4 IEC TC57 WG15. IEC TC57 WG57 standardse SCADA communcaton securty va ts IEC seres. 5 NIST (2008). The NIST Industral Control System Securty (ICS) group works on general securty ssues related to control systems such as SACAD systems.

4 62 Y. Wang 6 Natonal SCADA Test Bed Program (Idaho Natonal Laboratory, 2008). The Department of Energy establshed the Natonal SCADA Test Bed Program at Idaho Natonal Laboratory and Sanda Natonal Laboratory to ensure the secure, relable and effcent dstrbuton of power. Fgure 2 Typcal SCADA system confguratons 2 Threats to SCADA systems Several (real and smulated) attacks on SCADA systems were reported n the past few years (Abrams and Wess, 2007; USA Today, 2007). In the Maroochy Shre attack (Abrams and Wess, 2007), an Australan man hacked nto the Maroochy Shre, Queensland computersed waste management system and caused mllons of ltres of raw sewage to spll out nto local parks, rvers and even the grounds of a Hyatt Regency hotel. It s reported that the 49-year-old Vtek Boden had conducted a seres of electronc attacks on the Maroochy Shre sewage control system after hs job applcaton had been rejected. Later nvestgatons found rado transmtters and computer equpments n Boden s car. The laptop hard drve contaned software for accessng and controllng the sewage SCADA systems. The smulated Aurora attack (USA Today, 2007) conducted n March 2007 by the US Department of Homeland Securty resulted n the partal destructon of a $1 mllon dollar large desel-electrc generator.

5 sscada: securng SCADA nfrastructure communcatons 63 SCADA systems were not desgned wth publc access n mnd; they typcally lack even rudmentary securty. However, wth the advent of technology and partcularly the nternet, much of the techncal nformaton requred to penetrate these systems s wdely dscussed n the publc forums of the affected ndustres. Crtcal securty flaws for SCADA systems are well known to potental attackers. It s feared that SCADA systems can be taken over by hackers, crmnals, or terrorsts. Some companes may assume that they use leased lnes and therefore nobody has access to ther communcatons. The fact s that t s easy to tap these lnes [avalable at (accessed on 22 February 2010)]. Smlarly, frequency hoppng spread spectrum rado and other wreless communcaton mechansms frequently used to control RTU can be compromsed as well. Several efforts (GAO T, 2004; NIST, 2008; Idaho Natonal Laboratory, 2008) have been put on the analyss and protecton of SCADA system securty. Accordng to these reports (GAO T, 2004; NIST, 2008; Idaho Natonal Laboratory, 2008), the factors that have contrbuted to the escalaton of rsk to SCADA systems nclude: The adopton of standardsed technologes wth known vulnerabltes. In the past, propretary hardware, software and network protocols made t dffcult to understand how SCADA systems operated and therefore how to hack nto them. Today, standardsed technologes such as Wndows, Unx-lke operatng systems, and common nternet protocols are used by SCADA systems. Thus the number of people wth knowledge to wage attacks on SCADA systems have ncreased. The connectvty of control systems to other networks. In order to provde decson makers wth access to real-tme nformaton and allowng engneers to montor and control the SCADA systems from dfferent ponts on the enterprse networks, the SCADA systems are normally ntegrated nto the enterprse networks. Enterprses are often connected to partners networks and to the nternet. Some enterprses may also use wde area networks and nternet to transmt data to remote locatons. Ths creates further securty vulnerabltes n SCADA systems. Insecure remote connectons. Enterprses often use leased lnes, wde area networks/nternet, and rado/mcrowave to transmt data between control centres and remote locatons. These communcaton lnks could be easly hacked. The wdespread avalablty of techncal nformaton about control systems. Publc nformaton about nfrastructures and control systems s readly avalable to potental hackers and ntruders. For example, Sean Gorman s dssertaton (see, e.g., Blumenfeld, 2003; Rappaport, 2007) mapped every busness and ndustral sector n the US economy to the fbre-optc network that connects them, usng materals that was avalable publcly on the nternet. In addton, sgnfcant nformaton on SCADA systems s publcly avalable (from mantenance documents, from former employees, and from support contractors, etc.). All these nformaton could assst hackers n understandng the systems and to fnd ways to attack them. Hackers may attack SCADA systems wth one or more of the followng actons. 1 denal of servce attacks by delayng or blockng the flow of nformaton through control networks

6 64 Y. Wang 2 make unauthorsed changes to programmed nstructons n RTU at remote stes, resultng n damage to equpment, premature shutdown of processes, or even dsablng control equpment 3 send false nformaton to control system operators to dsguse unauthorsed changes or to ntate napproprate actons by system operators 4 modfy the control system software, producng unpredctable results 5 nterfere wth the operaton of safety systems. The analyss n reports such as GAO T (2004), NIST (2008) and Idaho Natonal Laboratory (2008) show that securng control systems poses sgnfcant challenges whch nclude 1 The lmtatons of current securty technologes n securng control systems. Exstng nternet securty technologes such as authorsaton, authentcaton and encrypton requre more bandwdth, processng power and memory than control system components typcally have. Controller statons are generally desgned to do specfc tasks, and they often use low-cost, resource-constraned mcroprocessors. 2 The percepton that securng control systems may not be economcally justfable. 3 The conflctng prortes wthn organsatons regardng the securty of control systems. In ths paper, we wll concentrate on the protecton of SCADA remote communcaton lnks. In partcular, we dscuss the challenges on protecton of these lnks and desgn new securty technologes to sscada systems. 3 Securng SCADA remote connectons Relatvely cheap attacks could be mounted on SCADA system communcaton lnks between the control centre and RTU snce there s nether authentcaton nor encrypton on these lnks. Under the umbrella of NIST Crtcal nfrastructure protecton cybersecurty of ndustral control systems, AGA SCADA Encrypton Commttee has been tryng to dentfy the functons and requrements for authentcatng and encryptng SCADA communcaton lnks. Ther proposal AGA Report No. 12 (2004) s to buld cryptographc modules that could be nvsbly embedded nto exstng SCADA systems (n partcular, one could attach these cryptographc modules to modems of Fgure 2) so that all messages between modems are encrypted and authentcated when necessary, and they have dentfed the basc requrements for these cryptographc modules. However, due to the constrants of SCADA systems, no vable cryptographc protocols have been dentfed to meet these requrements. In partcular, the challenges for buldng these devces are (see AGA Report No. 12, 2004): 1 encrypton of repettve messages 2 mnmsng delays due to cryptographc operatons 3 assurng ntegrty wth mnmal latency

7 sscada: securng SCADA nfrastructure communcatons 65 ntra-message ntegrty: f cryptographc modules buffer message untl the message authentcator s verfed, t ntroduces message delays that are not acceptable n most cases nter-message ntegrty: reorder messages, replay messages and destroy specfc messages 4 accommodatng varous SCADA poll-response and retry strateges: delays ntroduced by cryptographc modules may nterfere wth the SCADA system s error-handlng mechansms (e.g., tme-out errors) 5 supportng broadcast messages 6 ncorporatng key management 7 cost of devce and management 8 mxed mode: some SCADA systems have cryptographc capabltes whle others not 9 accommodate to dfferent SCADA protocols: SCADA devces are manufactured by dfferent vendors wth dfferent propretary protocols. Ths paper desgns effcent cryptographc mechansms to address these challenges and to buld cryptographc modules as recommended n AGA Report No. 12 (2004). These mechansms can be used to buld plug-n devces called sscada that could be nserted nto SCADA networks so that all communcaton lnks are authentcated and encrypted. In partcular, authentcated broadcast protocols are desgned so that they can be cheaply ncluded nto these devces. It has been a major challengng task to desgn effcently authentcated emergency broadcast protocols n SCADA systems. The trust requrements n our securty protocol desgn are as follows. RTU devces are deployed n untrusted envronments and ndvdual remote devces could be controlled by adversares. The communcaton lnks are not secure but messages (maybe modfed or re-ordered) could be delvered to the destnaton wth certan probablty. In another word, complete denal of servce attacks (e.g., jammng) on the communcaton lnks are not addressed n our protocol. Compromsng the control centre n a SCADA system wll make the entre system useless. Thus we assume that control centres are trusted n our protocol. 4 sscada protocol sute The sscada protocol sute s proposed to overcome the challenges that we have dscussed n the prevous secton. sscada devces that are nstalled at the control centre s called master sscada devce, and sscada devces that are nstalled at remote stes are called slave sscada devces. Each master sscada devce may communcate prvately wth several slave sscada devces. Once n a whle, the master sscada devce may also broadcast authentcated messages to several slave sscada devces (e.g., an emergency shutdown). An llustratve sscada devce deployment for pont-to-pont SCADA confguraton s shown n Fgure 3.

8 66 Y. Wang Fgure 3 sscada wth pont-to-pont SCADA confguraton 4.1 Vulnerabltes of a proposed protocol to AGA In ths secton, we dscuss vulnerabltes of a proposed protocol to AGA. Ths analyss shows the challenges n desgnng secure communcaton protocols for SCADA systems. A pont to pont secure channel protocol has been proposed by the AGA standard draft (AGA Report No. 12, 2004; Wrght et al., 2004) (an open source mplementaton could be found at SCADAsafe). We frst brefly revew ths protocol n the followng. Preshared secrets are nstalled nto the master sscada and slave sscada devces durng deployment. These secrets are used to negotate sesson encrypton and authentcaton keys for the two devces. Each sscada devce mantans a send sequence state varable n order to assgn a sequence number to each cphertext message t sends. The send sequence varable s ntalsed to one at sesson negotaton and ncremented wth every cphertext message sent. Let be the current send sequence number and P = p 1 p n be the plantext message that the sscada devce wants to send, where p j (j = 1,, n) are blocks of the cpher block length (for example, f AES128 s used, then p j contans 128 bts). Then the sendng sscada devce encphers P to the cphertext C as follows: where C = c c L c a 1, 2 n c j = E k [p j E k [, j, 00 ]] a = MAC k [P] E k [ ] denotes the encrypton process usng the key k, and MAC k [ ] denotes the message authentcator computaton process usng the key k. The sendng sscada devce then sends C to the recevng sscada devce. Let C = cc 1 2L cn be the message that the recevng sscada devce receves. At the recevng sde, the sscada devce mantans a receve sequence state varable n order to record the sequence number of the last authentcated message that t receved. The receve sequence varable s ntalsed to zero at sesson negotaton. Before decryptng the receved cphertext, the sscada devce checks that the sequence number contaned n the message s greater than the sscada s receve sequence varable. If t s not, the sscada devce dscards the remander of the message. Ths check s used to ensure that an adversary cannot replay old messages (n the followng, our analyss shows that ths protecton could be easly defeated). Provded the sequence number check succeeds, the recevng sscada devce decrypts the message as follows: P = pp 1 2L pn

9 sscada: securng SCADA nfrastructure communcatons 67 where p = D [ c ] E [, j,00 K ]. j k j k The recevng sscada devce forwards the decrypted plantext block p j to the SCADA system as soon as they are avalable. Fnally, the recevng sscada devce computes the message authentcaton code (MAC) for the message as follows: a% = MAC [ P] k and compares t to the MAC a. If the two match, the sscada devce updates ts receve sequence varable to the sequence number of the receved message, and otherwse t logs an error. Now we present our attack on the above protocol n the followng. Assume that the adversary Carol controls the communcaton lnks between the sendng and recevng sscada devces and the current receve sequence state varable at the recevng sscada sde contans the value 0. When the sendng sscada devce sends the message cphertexts C = c 1 c 2 c n a for > 0 n the future, Carol forwards these cphertexts to the recevng sscada devce by modfyng one bt n the authentcators a (all other bts are forwarded as t s). When the recevng sscada devces receve these cphertexts, t checks the sequence numbers (whch are correct), decrypts the cphertext blocks, and forwards the decrypted plantext blocks to the SCADA system. However, snce the authentcators have been tampered, the recevng sscada devce fals to check the authentcators. Thus the recevng sscada devce wll only log errors wthout updatng ts receve sequence state varable. That s, the recevng sscada devce wll hold the value 0 for ts receve sequence state varable. At the same tme, Carol logs all these cphertexts and observes what happens n the SCADA system. Thus she can learn the meanngs of these cphertexts to the SCADA system. At some tme n the future, Carol wants the SCADA system to behave accordng to the cphertext C whch contans a sequence number larger than 0. Carol can then just forward ths cphertext to the recevng sscada devce. Of course, Carol can also tamper the authentcator so that the recevng sscada devce stll holds the value 0 n ts receve state varable after processng ths message. The recevng sscada devce wll just decrypt ths cphertext and forward t to the SCADA system snce the sequence number contaned n C s larger than 0. In another word, the SCADA system s now n the complete control of Carol s hand. Another potental ptfall n the proposed protocol s that same keys are used by two sdes. Ths leaves the door open for the attacker to replay the message from one drecton n the other drecton. Ths vulnerablty could easly be fxed by usng dfferent paddng schemes or usng dfferent keys for dfferent drectons. The orgnal authors of the protocol have recommended some fx n SCADAsafe to avod our above attacks. 4.2 Pont-to-pont secure channels In the prevous secton, we presented an attack on the frst draft of the AGA proposal. Though the protocol n the AGA proposal could be fxed, n the followng, we present a new secure soluton. In order to reduce the cost of sscada devces and management, only symmetrc key cryptographc technques s used n our desgn. Indeed, due to the slow operatons of publc key cryptography, publc key cryptographc protocols could

10 68 Y. Wang ntroduce delays n message transmsson whch are not acceptable to SCADA protocols. Semantc securty property (Goldwasser and Mchal, 1984) s used to ensure that an eavesdropper has no nformaton about the plantext, even f t sees multple encryptons of the same plantext. For example, even f the attacker has observed the cphertexts of shut down and turn on, t wll not help the attacker to dstngush whether a new cphertext s the encrypton of shut down or turn on. In practce, the randomsaton technque s used to acheve ths goal. For example, the message sender may prepend a random strng (e.g., 128 bts for AES-128) to the message and use specal encrypton modes such as channg block cpher mode (CBC) or Hash-CBC mode (HCBC). In some mode, ths random strng s called the ntalsaton vector (IV). Ths prevents nformaton leakage from the cphertext even f the attacker knows several plantext/cphertext pars encrypted wth the same key. Snce SCADA communcaton lnks could be as low as 300 bps and mmedate response are generally requred, there s no suffcent bandwdth to send the random strng (IV) each tme wth the cphertext, thus we need to desgn dfferent cryptographc mechansms to acheve semantc securty wthout addtonal transmsson overhead. In our desgn, we use two counters shared between two communcatng partners, one for each drecton of communcaton. The counters are ntally set to zeros and should be at least 128 bts, whch ensures that the counter values wll never repeat; avodng replay attacks. The counter s used as the IV n message encryptons f CBC or HCBC mode s used. After each message encrypton, the counter s ncreased by one f CBC mode s used and t s ncreased by the number of blocks of encrypted data f HCBC mode s used. The two communcatng partners are assumed to know the values of the counters and the counters do not need to be added to each cphertext. Messages may get lost and the two counters need to be synchronsed once a whle (e.g., at off-peak tme). A smple counter synchronsaton protocol s proposed for the sscada protocol sute. The counter synchronsaton protocol could also be ntated when some encrypton/decrypton errors appear due to unsynchronsed counters. In order for two sscada devces to establsh a secure channel, a master secret key needs to be bootstrapped nto the two devces at the deployment tme (or when a new sscada devce s deployed nto the exstng network). For most confguratons, secure channels are needed only between a master sscada devce and a slave sscada devce. For some confguratons, secure channels among slave sscada devces may be needed also. The secure channel dentfed wth ths master secret s used to establsh other channels such as sesson secure channels, tme synchronsaton channels, authentcated broadcast channels, and authentcated emergency channels. Assume that H( ) s a pseudorandom functon (e.g., constructed from SHA-256) and two sscada devces A and B share a secret K AB = K BA. Dependng on the securty polcy, ths key K AB could be the shared master secret or a shared secret for one sesson whch could be establshed from the shared master key usng a smple key establshment protocol (n order to acheve sesson key freshness, typcally one node sends a random nonce to the other one and the other node sends the encrypted sesson key together wth an authentcator on the cphertext and the random nonce). Keys for dfferent purposes could be derved from ths secret as follows (t s not a good practce to use the same key for dfferent purposes). For example, K AB = H(K AB, 1) s for message encrypton from A to B, K AB = H(K AB, 2) s for message authentcaton from A to B, K BA = H(K AB, 3) s for

11 sscada: securng SCADA nfrastructure communcatons 69 message encrypton from B to A, and K BA = H(K AB, 4) s for message authentcaton from B to A. Optonal MAC s used for two partes to acheve data authentcaton and ntegrty. MAC that could be used for sscada mplementaton ncludes HMAC (Bellare et al., 1996; Krawczyk et al., 1997), CBC-MAC (NIST, 1981), and others. When party A wants to send a message m to party B securely, A computes the cphertext c = E ( CA, KAB, ca m) and message authentcator mac = MAC( K AB, CA c), where c A s the last l bts of H(C A ) (l could be as large as possble f bandwdth s allowed and 32 bts should be the mnmal), E ( CA, KAB, ca m) denotes the encrypton of c A m usng key K AB and random-prefx (or IV) C A and C A s the counter value for the communcaton from A to B. Then A sends the followng packets to B: A B: c, mac (optonal) When B receves the above packets, B decrypts c, checks that c A s correct, and verfes the message authentcator mac f mac s present. As soon as B receves the frst block of the cphertext, B can check whether c A s correct. If t s correct, then B contnues the decrypton and updates ts counter. Otherwse, B dscards the entre cphertext. If the message authentcator code mac s present, B also verfes the correctness of mac. If mac s correct, B does nothng, otherwse, B may choose to nform A that the message was corrupted or try to re-synchronse the counters. There are several mplementaton ssues on how to delver the message to the target (e.g., RTU). For example, we gve a few cases n the followng. 1 B uses the counter to decrypt the frst block of the cphertext, f the frst l bts of the decrypted plantext s not consstent wth H(C A ), then the reason could be that the counter C A s not synchronsed or that the cphertext s corrupted. B may try several possble counters untl the counter checkng process succeeds. B then uses the verfed counter and the correspondng key to decrypt the message and delver each block of the resultng message to the target as soon as t s avalable. If no counter could be verfed n a lmted number of trals, B may notfy A of the transmsson falure and ntate the counter synchronsaton protocol n the next secton. The advantage of ths mplementaton s that we have mnmsed delay from the cryptographc devces, thus mnmse the nterference of SCADA protocols. Note that n ths mplementaton, the message authentcator mac s not used at all. If the cphertext was tampered, we rely on the error correcton mechansms (normally CRC codes) n SCADA systems to dscard the entre message. If CBC (respectvely HCBC) mode s used, then the provable securty propertes (respectvely, provable onlne cpher securty propertes) of CBC mode (respectvely HCBC mode) (Bellare et al., 2000, 2001) guarantees that the attacker has no chance to tamper the cphertext so that the decrypted plantext contans correct CRC that was used by SCADA protocols to acheve ntegrty. 2 Proceed as n the above case 1. In addton, the mac s further checked and the decrypted message s delvered to the SCADA system only f the mac verfcaton passes. The dsadvantage for ths mplementaton s that these cryptographc operatons ntroduce sgnfcant delay for message delvery and t may nterfere wth SCADA protocols.

12 70 Y. Wang 3 Proceed as n the above case 1. The decrypted message s delvered to the SCADA system as soon as they are avalable. After recevng the entre message and mac, B wll also verfy mac. If the verfcaton passes, B wll do nothng. Otherwse, B re-synchronses the counter wth A or ntates some other excepton handlng protocols. 4 In order to avod delays ntroduced by cryptographc operatons and to check the mac at the same tme, sscada devces may delver decrypted bytes mmedately to the target except the last byte. If the message authentcator mac s verfed successfully, the sscada devce delvers the last byte to the target. Otherwse, the sscada devce dscards the last byte or sends a random byte to the target. That s, we rely on the error correcton mechansms at the target to dscard the entre message. Smlar mechansms have been proposed n AGA Report No. 12 (2004). However, an attacker may nsert garbage between the cphertext and mac thus t trck the sscada devce to delver the decrypted messages to the SCADA system. If ths happens, we essentally do not get advantage from ths mplementaton. Thus ths mplementaton s not recommended. 5 Instead of prepend c A to the plantext message, one may choose to prepend three bytes of other specally formatted strng to the plantext message (three bytes bandwdth s normally avalable n SCADA systems) before encrypton. Ths s an acceptable soluton though we stll prefer our soluton of prependng the hash outputs of the counter. There could be other mplementatons to mprove the performance and nteroperablty wth SCADA protocols. sscada devce should provde several possble mplementatons for users to confgure. Indeed, sscada devces may also be confgured n a dynamc way that for dfferent messages t uses dfferent mplementatons. In some SCADA communcatons, message authentcaton-only s suffcent. That s, t s suffcent for A to send (m, mac) to B, where m s the cleartext message and mac = MAC( K AB, CA m). sscada devce should provde confguraton optons to do message authentcaton wthout encrypton. In ths case, even f the counter value s not used as the IV, the counter value should stll be authentcated n the mac and be ncreased after the operaton. Ths wll provde message freshness assurance and avod replay attacks. sscada should also support message pass-through mode. That s, message s delvered wthout encrypton and authentcaton. In a summary, t should be possble to confgure an sscada devce n such a way that some messages are authentcated and encrypted, some messages are authentcated only, and some messages are passed through drectly. It s straghtforward to show that our pont-to-pont secure channels provde data authentcaton, data ntegrty, data confdentalty, and weak data freshness (.e., messages arrve at the destnaton n the same order that was sent from the source). 4.3 Counter synchronsaton In the pont-to-pont message authentcaton and encrypton protocol, we assume that both sscada devces A and B know each other s counter values C A and C B. In most cases, relable communcaton n SCADA systems s provded and the securty protocols n the prevous secton work fne. Stll we provde a counter synchronsaton protocol so

13 sscada: securng SCADA nfrastructure communcatons 71 that sscada devces could synchronse ther counters when necessary. The counter synchronsaton protocol could be ntated by ether sde. Assume that A ntates the counter synchronsaton protocol. Then the protocol looks as follows: A B N : A B A: C, MAC( K, N C ) B BA A B Ths counter synchronsaton protocol s analogous to that n Perrg et al. (2002). The ntal counter values of two sscada devces could be bootstrapped drectly. The above counter synchronsaton protocol could also be used by two devces to bootstrap the ntal counter values. A master sscada devce may also use the authentcated broadcast channel that we wll dscuss n the next secton to set several slave sscada devces counters to the same value usng one message. 4.4 Authentcated broadcast channels Encrypton and authentcaton alone are not suffcent for SCADA applcatons. For example, t s not acceptable to authentcate a message ndvdually n an emergent shutdown when tmely responses from the RTU s are crtcal. In order to support authentcated broadcast, we use one way key chans. Ths channel can be used to establsh other channels such as authentcated emergency channels (see next secton). Typcal authentcated broadcast channels requre asymmetrc cryptographc technques; otherwse any compromsed recever could forge messages from the sender. Cheung (1997) proposed a symmetrc cryptography based source authentcaton technque n the context of authentcatng communcaton among routers. Cheung s technque s based on delayed dsclosure of keys by the sender. Later, t was used n the Guy Fawkes protocol (Anderson et al., 1998) for nteractve uncast communcaton, and n Bergadano et al. (2000a, 2000b), Brscoe (2000) and Perrg et al. (2000, 2001) for streamed data multcast. Perrg et al. (2000, 2001) adapted delayed key dsclosure based TESLA protocols to sensor networks for sensor broadcast authentcaton (the new adapted protocol s called μtesla). One-way key chans used n these protocols are analogous to the one-way key chans ntroduced by Lamport (1981) and the S/KEY authentcaton scheme (Haller, 1995). In the followng, we brefly descrbe the authentcated broadcast scheme for SCADA systems. At the sender (normally the master sscada devce or a computer connected to t) set up tme, the sender generates a one-way key chan n the setup phase. In order to generate a one-way key chan of length n, the sender chooses a random key K n frst, then t apples the pseudorandom functon H repeatedly to K n to generate the remanng keys. In partcular, for each < n, K = H(K + 1). For the purpose of broadcast authentcaton, the sender splts the tme nto even ntervals I. The duraton of each tme nterval s denoted as δ (e.g., δ = 5 seconds or 5 mnutes or even 2 hours), and the startng tme of the nterval I s denoted as t. In another word, t = t 0 + δ. At tme t, the sender broadcasts the key K. Any devce that has an authentc copy of key K 1 can verfy the authentcty of the key K by checkng whether K 1 = H(K ). Indeed, any devce that has an authentc copy of some key K υ (υ < ) can verfy the authentcty of key K snce K υ = H ( υ) (K ). Let d (a unt of tme ntervals) be the key dsclosure delay factor. The value of d s applcaton dependent and could be confgured at deployment tme or after deployment

14 72 Y. Wang (e.g., usng the secure broadcast protocols tself). After d s fxed, the sender wll use keyng materals derved from key K +d to authentcate broadcast messages durng the tme nterval I. Thus the message beng broadcast durng tme nterval I could be verfed by the recever durng the tme nterval I +d after the sender broadcasts K +d at tme t +d. It s easy to see that n order to acheve authentcty, the sender and the recever need to be loosely tme synchronsed. Otherwse, f the recever tme s slower than the sender s tme, an attacker can use publshed keys to mpersonate the sender to the recever. Typcally the key dsclosure delay should be greater than any reasonable round trp tme between the sender and the recever. If the sender does not broadcast data frequently, the key dsclosure delay may be sgnfcantly larger. For example, dδ could take the value of several hours for some SCADA systems. If a recever (typcally a slave sscada devce) s deployed at some tme durng the nterval I, the sender needs to bootstrap key K on the one-way key chan to the recever. The sender also needs to bootstrap the key dsclosure schedule whch ncludes the startng tme t of the tme nterval I, the key dsclosure delay factor d, and the duraton δ of each tme nterval. All these nformaton could be bootstrapped to the recever usng the pont-to-pont secure channel that we have desgned n the prevous secton or usng other channels such as manual nput. Durng a tme nterval I j (j > ), the recever receves the broadcast key K j from the sender and verfes whether K j 1 = H(K j ). If the verfcaton s successful, the recever updates ts key on the one-way key chan. If the recever does not receve the broadcast key durng the tme nterval I j (ether due to packet loss or due to actve denal of servce attacks such as jammng attacks), t can update ts key n the next tme nterval I j+1. When a recever gets a packet from the sender, t frst checks whether the key used for the packet authentcaton has been revealed. If the answer s yes, then the attacker knows the key also and the packet could be a forged one. Thus the recever needs to dscard the packet. If the key have not been revealed yet, the recever puts the packet n the buffer and checks the authentcty of the packet when the correspondng key s revealed. As stated above, f the sender and the recever agree on the key dsclosure schedule and the tme s loosely synchronsed, then message authentcty s guaranteed. However, the protocol does not provde non-repudaton, that s, the recever cannot convnce a thrd party that the message was from the clamed sender. If we assume that the tme between the sender and the recever are loosely synchronsed and the pseudorandom functon H( ) and the MAC are secure, then an analogous proof as n Perrg et al. (2000) could be used to show that the above authentcated broadcast channel s secure. Note that we say that a pseudorandom functon H( ) s secure f the functon famly f k (x) = H(k, x) s a pseudorandom functon famly n the sense of Goldrech et al. (1987) when k s chosen randomly. That s, a functon famly {f k ( )} s pseudorandom f the adversary wth polynomally bounded resources cannot dstngush between a random chosen functon from {f k ( )} and a totally random functon wth non-neglgble probablty. We say that a message authentcaton scheme MAC s secure f a polynomally bounded adversary wll not succeed wth non-neglgble probablty n the followng game. A random l-bts key k s chosen by the user. The adversary chooses messages m 1,, m t and the user generates the MAC codes on these messages usng the key k. The adversary succeeds f she could then generate a MAC code on a dfferent message m m 1,,m t.

15 sscada: securng SCADA nfrastructure communcatons 73 Though the tme synchronsaton between the sender and the recever plays an mportant role n the securty of the protocol, they do not need to have 100% accurate clocks. If ther clocks are suffcently accurate, then tme synchronsaton protocol could be desgned to synchronse ther clocks to meet the securty requrements. The tme synchronsaton protocols could be based on the pont-to-pont secure channels dscussed n the prevous secton. 4.5 Authentcated emergency channels In our basc authentcated broadcast protocol, the recever cannot verfy the authentcty of the message mmedately snce t needs to wat for the dsclosure of the key after a tme perod of dδ. Ths s not acceptable for some broadcast messages such as an emergency shutdown. In order to overcome ths challenge, the sender may reveal the key used for emergency messages mmedately or shortly after the message broadcast. Ths wll open the door for an adversary to modfy the emergency messages. For example, f the message passes through a node D before t reaches a node C, D can dscard the message and create a dfferent emergency message and forward t to C. In another case, an attacker may jam the target C durng the emergency broadcast perod and sends C a dfferent emergency message (authentcated usng the revealed key for the emergency message) later. However, these attacks are generally not practcal snce f the bad guy jams the channel n a wreless envronment, then he jams hmself and he cannot receve the authentcated broadcast message ether. 4.6 Authentcated emergency channels wth fntely many messages In ths secton we desgn authentcated emergency channels whch can only broad fntely many emergency messages. Assume that emergency messages are e 1,..., e u. Wthout loss of generalty, we may assume that e = for u. Before the sender could authentcally broadcast these messages, t needs to carry out a commtment protocol. Let υ be a fxed number. Durng the message commtment procedure, the sender N υ chooses υ random numbers N1, K for each u. It then computes r,j = H(e N j ) for all u and j υ. Usng the authentcated broadcast channel, the sender broadcasts the commtments {r,j : u and j υ} to all recevers. Recevers store these commtments n ther memory space. Each tme when the sender wants to broadcast the message e to recevers emergently, t chooses a random unused j υ, and broadcasts (e, j, N j ) to all recevers. The recever verfes that r,j = H(e N j ). If the verfcaton s successful, t knows that the message e comes from the sender and delvers t to the target. At the same tme, the recever deletes the commtment r,j from ts memory space. Note that after each message commtment procedure, the sender could broadcast each message at most υ tmes. Thus the sender may decde to ntate the message commtment protocol when any one of these messages has been broadcast suffcently many tmes (e.g., υ 1 tmes). Each tme when the message commtment protocol s ntated, both the sender and the recever should delete all prevous commtments from ther memory space. The securty of the emergency channel could be proved formally under the assumpton that the pseudorandom functon H( ) s a secure one-way functon. That s,

16 74 Y. Wang for any gven y wth approprate length, one cannot fnd an x such that H(x) = y wth non-neglgble probablty. Theorem 4.1 Assume that the authentcated broadcast channel s secure and the pseudorandom functon H( ) s a secure one-way functon. Then the authentcty of messages that recevers accept from the emergency channel s guaranteed. Sketch of proof. Assume for a contradcton that the authentcty of the emergency protocol s broken. That s, there s an adversary A who controls communcaton lnks and manages to delver a message m to the recever such that the sender has not sent the message but the recever accepts the message. We show n the followng that then H( ) s not a secure one-way functon. Specfcally, let t be the total number of messages that the sender can broadcast n the emergency channel wth one commtment {r,j }, and y 1,..., y t be t randomly chosen strngs wth approprate lengths (.e., they are potental outputs of H). We wll construct an algorthm P that uses A to compute a pre-mage x = H 1(y ) of some strng y wth non-neglgble probablty. Snce the broadcast channel s secure, we can always assume that the commtment {r,j } that the recevers accept are authentc. The algorthm P works by runnng A as follows. Essentally, P smulates an authentcated broadcast channel for A wth a sender A and a recever B. 1 P chooses a random number l t. 2 P computes a commtment {r,j } as specfed n the emergency broadcast protocol. P pcks t l + 1 random values from the commtment {r,j } and replace them wth y l, y l+1,..., y t. 3 P runs the sender s algorthm to authentcally broadcast the modfed commtment to B. 4 For the frst l 1 emergency messages, P runs the sender s algorthm of the emergency broadcast protocol wth no modfcaton to broadcast the pre-mages of the l 1 unmodfed commtments. 5 P then wats for A to delver a fake message x that B accepts as an authentc emergency broadcast. P outputs x as one of the pre-mages of y l,..., y t. We brefly argue that P outputs the pre-mage of one of the strngs from y 1,..., y t wth non-neglgble probablty. Snce A succeeds wth non-neglgble probablty n convncng the recever to accept a fake message, t must delver ths message as the l-th message for some l t n the authentcated emergency channel. Thus for ths l, the algorthm P outputs a pre-mage for one of the gven strngs wth non-neglgble probablty. QED. Theorem 4.1 shows that messages receved n the emergency channel are authentc. However, t does not show whether these messages are fresh. Indeed, when the sender broadcasts an emergency message at the tme t, the adversary may launch a denal of servce attack aganst the recever or just does not delver the message to the recever. Thus the recever wll not be able to delete the commtment of ths message from ts memory space. Later at tme t, the adversary delvers ths message to the recever and the recever accepts t. In our emergency channel, there s no way to avod ths knd of delayed message attacks. Thus when message freshness s mportant, one may use the

17 sscada: securng SCADA nfrastructure communcatons 75 revsed authentcated emergency broadcast channel that we wll dscuss n the next secton. 4.7 Revsed authentcated emergency channel There are bascally two ways to guarantee the freshness of a receved message. The frst one s to use publc key cryptography together wth tme-stamps. The second soluton s to let the recever send a nonce to the sender frst and the sender authentcates the message together wth the nonce. As we have mentoned earler, publc key cryptography s too expensve to be deployed n SCADA systems. For the second soluton, the delays ntroduced n once submsson process are generally not acceptable n an emergent stuaton. In ths secton, we ntroduce a revsed emergency broadcast protocol, whch provdes weak freshness of receved messages. Here weak freshness means that the receved message s guaranteed to be n certan tme lmt T. In another word, at tme t, the adversary cannot convnce a recever to accept a message that s posted before the tme t T. Let the u emergency messages be e 1,, e u. Smlar to the prevous protocol, the sender needs to carry out a commtment protocol before the authentcated emergency broadcast. In the revsed protocol, the sender chooses v random numbers N1, K N υ and υ expraton tme ponts T1 < T2 <KT υ for each u. It then computes r, j= H ( e N j Tj ) for u and j υ. Usng the authentcated broadcast channel, the sender broadcasts the commtments { r, j: u and j υ } to all recevers. Recevers store these commtments n ther memory space. The functonalty of expraton tme ponts n the revsed protocol s to guarantee that the commtment r,j for the message e expres at the tme T j. In another word, when the recever receves (e, N j, T j ), t wll accepts the message only f the current clock tme of the recever s earler than T j. If the sender wants to send the message e to recevers at tme t, t chooses a random unused j υ such that t < T j, the estmated transmsson tme from the sender to recever s less than Tj t, and T j s the earlest tme n the commtments that satsfes these condtons. Then the sender broadcasts (e, j, N j, T j ) to all recevers. The recever verfes that r,j = H(e N j T j ) and the current clock tme of the recever s earler than T j. If the verfcaton s successful, t knows that the message e comes from the sender and delvers t to the target. At the same tme t deletes the commtment r,j from ts memory space. Otherwse, the recever dscards the message. The mplementaton of the revsed emergency broadcast protocol has the flexblty to choose the gaps between expraton tme ponts T for each u. The smaller the gap, the better the freshness property. However, smaller gaps between T j s add addtonal overhead on the communcaton lnks. It s also possble, for dfferent messages e, one chooses dfferent values υ. For example, for more frequently broadcast message, the value of υ should be larger. It s also mportant to guarantee that the commtment s always suffcent and when only a few commtments are unused, the sender should ntate a procedure for a new commtment. The securty of the revsed emergency broadcast protocol can be proved smlarly as n Theorem 4.1. It s stll possble for an adversary to delay an emergency message (e, j, N j, T j ) broadcast by the sender durng the tme perod [ Tj 1, Tj ] untl T. However, she cannot delay the message to some tme ponts after T j. In another word, weak freshness of receved messages are guaranteed n the revsed authentcated emergency channel. j s j

18 76 Y. Wang 5 Conclusons In ths paper, we systematcally dscussed the securty ssues for SCADA systems and the challenges to desgn such a sscada system. In partcular, we present an attack on the protocols n the frst verson of AGA standard draft (Wrght et al., 2004). Ths attack shows that the securty mechansms n the frst draft of the AGA standard protocol could be easly defeated. We then proposed a sute of securty protocols optmsed for SCADA/DCS systems whch nclude: pont-to-pont secure channels, authentcated broadcast channels, authentcated emergency channels, and revsed authentcated emergency channels. These protocols are desgned to address the specfc challenges that SCADA systems have. Recently, there has been a wde nterest for the secure desgn and mplementaton of smart grd systems (DOE, 2009). SCADA system s one of the most mportant legacy systems of the smart grd systems. Together wth other efforts such as Idaho Natonal Laboratory (2008), NIST (2008), IEEE P1711, IEEE P1815, IEC TC57 and IEC , our work n ths paper presents an ntal step for securng the SCADA secton of the smart grd systems aganst cyber attacks. Acknowledgements The author would lke to thank the anonymous referees for the excellent comments on the mprovement of ths paper. References Abrams, M. and Wess, J. (2007) Bellngham, Washngton, control system cyber securty case study, avalable at Case Study report%2020sep071.pdf (accessed on 22 February 2010). Abrams, M. and Wess, J. (2007) Malcous control system cyber securty attack case study Maroochy water servces, Australa, avalable at brefng.pdf (accessed on 22 February 2010). AGA Report No. 12 (2004) Cryptographc protecton of SCADA communcatons: general recommendatons, Draft 2, 5 February 2004, The draft 2 s no longer avalable onlne, The draft 3 s avalable for purchase at http: // (accessed on 22 February 2010). Anderson, R., Bergadano, F., Crspo, B., Lee, J., Manfavas, C. and Needham, R. (1998) A new famly of authentcaton protocols, Operatng Systems Revew, October, Vol. 32, No. 4, pp Bellare, M., Boldyreva, A., Knudsen, L. and Namprempre, C. (2001) On-lne cphers and the Hash-CBC constructons, Advances n Cryptology Crypto 2001, Lecture Notes n Computer Scence 2139, Sprnger-Verlag. Bellare, M., Canett, R. and Krawczyk, H. (1996) Message authentcaton usng hash functons the HMAC constructon, RSA Laboratores CryptoBytes, Sprng, Vol. 2, No. 1. Bellare, M., Klan, J. and Rogaway, P. (2000) The securty of the cpher block channg message authentcaton code, Journal of Computer and System Scences, Vol. 6, No. 3, pp Bergadano, F., Cavagnno, D. and Crspo, B. (2000a) Chaned stream authentcaton, Selected Areas n Cryptography, Waterloo, Canada.

19 sscada: securng SCADA nfrastructure communcatons 77 Bergadano, F., Cavagnno, D. and Crspo, B. (2000b) Indvdual sngle source authentcaton on the mbone, ICME 2000, August, pp Blumenfeld, L. (2003) Dssertaton could be securty threat, Washngton Post, avalable at wp-dyn/a jul7 (accessed on 22 February 2010). Brscoe, B. (2000) FLAMeS: fast, loss-tolerant authentcaton of multcast streams, Techncal report, avalable at (accessed on 22 February 2010). Cegrell, T. (1986) Power System Control Technology, Prentce-Hall Internatonal (UK) Ltd. Cheung, S. (1997) An effcent message authentcaton scheme for lnk state routng, 13th Annual Computer Securty Applcatons Conference. DOE (2009) Study of securty attrbutes of smart grd systems current cyber securty ssues, Aprl, avalable at (accessed on 22 February 2010). GAO T (2004) Crtcal nfrastructure protecton: challenges and efforts to secure control systems, Testmony Before the Subcommttee on Technology Informaton Polcy, Intergovernmental Relatons and the Census, House Commttee on Government Reform, 30 March, avalable at (accessed on 22 February 2010). Goldrech, O., Goldwasser, S. and Mcal, S. (1987) How to construct random functons, J. of the ACM, Vol. 33, No. 4, pp Goldwasser, S. and Mchal, S. (1984) Probablstc encrypton, Journal of Computer and System Scences, Vol. 28, pp Haller, N. (1995) The S/KEY one-tme password system, IETF RFC 1760, February. Idaho Natonal Laboratory (2008) SCADA test bed program, avalable at (accessed on 22 February 2010). IEC , User group mallst nformaton, avalable at (accessed on 22 February 2010). IEC TC57, avalable at (accessed on 22 February 2010). IEEE P1711, Tral use standard for a cryptographc protocol for cyber securty of substaton seral lnks, avalable at 10.doc (accessed on 22 February 2010). IEEE P1815, Standard for electrc power systems communcatons dstrbuted network Protocol (DNP3). Krawczyk, H., Bellare, M. and Canett, R. (1997) HMAC: keyed-hashng for message authentcaton, Internet RFC 2104, February. Lamport, L. (1981) Password authentcaton wth nsecure communcaton, Commun. ACM, Vol. 24, No. 11. NIST (1981) DES model of operaton, FIPS Publcaton 81 (FIPS PUB 81). NIST (2008) Industral control system securty (ICS), avalable at (accessed on 22 February 2010). Perrg, A., Canett, R., Song, D. and Tygar, J. (2001) Effcent and secure source authentcaton for multcast, Network and Dstrbuted System Securty Symposum, NDSS 01. Perrg, A., Canett, R., Tygar, J. and Song, D. (2000) Effcent authentcaton and sgnng of multcast streams over lossy channels, IEEE Symposum on Securty and Prvacy. Perrg, A., Szewczyk, R., Tygar, J., Wen, V. and Culler, D. (2002) SPINS: securty protocols for sensor networks, Wreless Networks, Vol. 8, pp

20 78 Y. Wang Rappaport, J. (2007) What you don t know mght hurt you: Alum s work balances natonal securty and nformaton sharng, avalable at (accessed on 22 February 2010). SCADAsafe, avalable at USA Today (2007) AURORA case: US vdeo shows hacker ht on power grd, avalable at (accessed on 31 May 2010). Wrght, A.K., Knast, J.A. and McCarty, J. (2004) Low-latency cryptographc protecton for SCADA communcatons, Proc. 2nd Int. Conf. on Appled Cryptography and Network Securty, ACNS 2004, LNCS 3809, Sprnger, pp