2009 International Conference on Advances in Computing, Control, and Telecommunication Technologies
Cryptographic Key Management for SCADA System: An Architectural Framework Om Pal#, Sharda Saiwan#, Peeyush Jain#, Zia Saquib#, Dr. Dhiren Patel* #
Centre for Development of Advanced Computing, Mumbai, India {ompal,sharda,peeyushj,saquib}@cdacmumbai.in * Indian Institute of Technology, Gandhinagar, India
[email protected] Abstract— SCADA (Supervisory Control And Data Acquisition) security has become a challenging issue today because of its connectivity with the outside world and remote access to the system. One critical security aspect for SCADA systems is that the communication needs to be secured. Several techniques have been proposed for securing the communication channels, but the cryptographic key distribution and key management are still open issues. This paper focuses on the issues and architectural framework of cryptographic key management for SCADA systems. A comparative analysis of suitable architectures for key management of SCADA systems is presented. Keywords— Cryptographic Key Management, Multicasting, Network Security, SCADA communications, SCADA networks.
I. INTRODUCTION A SCADA (Supervisory Control And Data Acquisition) system is an industrial control system used for monitoring and controlling a process in national infrastructure such as water management, electric power grid, oil and gas, etc. As the technologies move from closed, isolated and proprietary environment to more open, standardized and interconnected environments, the systems have become more vulnerable to attacks. Protection of such critical infrastructure is vital because of such an attack impacts the life, economy, environment, psychology and the pride of the nation. Therefore, information security management principles and processes need to be applied to secure the SCADA systems. As depicted in Fig. 1, SCADA system usually consists of a human-machine interface (HMI), a supervisory system (controller or MTU), SubMTUs, remote terminal units (RTUs), programmable logic controllers (PLCs) and a communication infrastructure connecting the supervisory system to the RTUs. The communication topology of the SCADA architecture is static i.e. the communication paths are fixed and there are very few changes in the communication network. The communication occurs between HMI to MTU, MTU to SubMTU, SubMTU to SubMTU, MTU to RTU, SubMTU to RTU, and RTU to RTU. The HMI communicates with MTU using TCP/IP protocols in client-server architecture.
978-0-7695-3915-7/09 $26.00 © 2009 IEEE DOI 10.1109/ACT.2009.51
CONTROL STATION CORPORATE MTU
MTU
INTERNET RTU
SubMTU SubMTU
SubMTU
RTU RTU RTU
RTU
RTU
Figure1. SCADA architecture
The most widely used communication protocol used in SCADA systems is DNP3 (Distributed Network Protocol version 3.0). Others are IEC 60870-5-101 and 104, IEC 61850 and Modbus. When these protocols were designed, cyber security was not an issue, because the system was running in a closed environment. As the system is becoming more interconnected to the outside world, the necessity of securing these protocols is increased. SCADA network can be secure in a number of ways such as use of cryptographic primitives, installing firewalls, IDPS (Intrusion Detection and Prevention System), device security, network enhancements, and so forth. We identify SCADA communication protocol such as DNP3 as the most essential and appropriate place to enhance the security and propose various methods to secure the protocols. Secure keys need to be established before cryptographic techniques can be used to secure communications in SCADA. To ensure authenticity, confidentiality and integrity, cryptographic key distribution and key management come naturally into consideration. However, we are also working on other areas like, key distribution, encryption/decryption, IDPS and developing a security layer in DNP3 stack where the cryptographic solutions will be implemented for securing the SCADA system. Rest of the paper is organized as follows: In Section 2, we discuss key challenges of SCADA systems and related work in Section 3. Section 4 covers detailed discussion on various architectural frameworks for cryptographic key management with Conclusions in Section 5 and References at the end. 169
II. KEY CHALLENGES The modern SCADA systems face different types of threats, like unauthorized access either by human (intentionally or accidentally) or by specialized software. Another threat may be unauthorized access to network packets, which causes packet injection, violation of integrity and confidentiality, improper commands for RTUs, etc. Anybody can control a SCADA device with injection of malicious packets into the network. To secure the system from such types of threats, the security requirements can be classified as •
Authentication. It is very important to ensure that the origin of an object is what it claims to be.
•
Integrity. The manipulation of messages between nodes and insertion of new nodes can be hazardous. A malicious attacker could cause physical damage if they have the ability to alter or create messages.
•
Confidentiality. Ensuring that no one can read the message except the intended receiver.
•
Non-repudiation: A mechanism to prove that the sender cannot deny about sending a message later.
There are significant challenges that must be overcome to properly secure the SCADA networks. The key technical challenges revolve around the limitations of what can be installed and configured on the SCADA systems and the technical limitations of other components within the SCADA environment. •
Limited computational capacity: The RTUs have very low computational power.
•
Limited Space Capacity: Memory of RTUs is usually quite low.
•
Low bandwidth: The data transmission rate for SCADA systems is low.
•
Real-time processing: Transmission and processing of data in SCADA systems should be timely. Otherwise it may cause latency problems.
These constraints should be a basic consideration for applying a security mechanism. The number of keys at RTU and MTU should be minimum. MTU manages and maintains the data and keys from the thousands of RTUs. So the number of keys at RTU and MTU reflect the key management scheme for SCADA system. Many efforts have been made for SCADA System Security including key Management, but they have some limitations as we will discuss in the next section. III. RELATED WORKS Initially, a cryptographic key management approach, Key Establishment for SCADA (SKE) [1] was proposed by Sandia National Laboratories in 2002. In this technique, the communication is divided in two categories such as controller to subordinate (C-S) communication and subordinate to
subordinate (S-S) communication. The C-S is treated as master-slave communication and is ideal for symmetric key technique. The C-C is treated as peer-to-peer communication for which public key protocols can be used. In C-S communication, each controller has a Long Term Key (LTK) shared with its subordinate i.e. the LTK is known to both the parties. The controller also has its own General Seed Key (GSK). Now the controller sends a General Key (GK) to each of its subordinates. The GK is a hash of GSK and a 128 bit random number. For communication, the sender obtains a Session Key (SK) from GK. The SK is used for encryption/decryption. All keys used are 128 bit in length. In S-S communication, each SS is given a Public Key (PK), Public Key Signature Key (PKSK), and a Public and Private Key pair (PU,PR). For communication, the two subordinates derive a Common Key (CK) using a key exchange algorithm, which uses the previous keys. RTU to RTU communication is not possible in this mechanism. Also it does not support broadcast and multicast communication. In other words, as the MTU does not store common key for a group of RTUs it has to encrypt data with each key of RTUs individually to broadcast a message. Hence, it needs Ο(n) computational cost when n is the number of RTUs. Key Management Architecture for SCADA systems (SKMA) [2] was proposed by Information Security Institute that overcomes the limitations of SKE. A Key Distribution Center (KDC) is used to maintain a long term key for each node. When a new node joins the system, a node-KDC key is manually installed in it. When two nodes need to communicate, a node-node key is created with the help of node-KDC key. This is also a long term key. For communication, a session key is generated using the nodenode key. This technique supports RTU to RTU communication but does not support broadcast. Furthermore, each RTU needs to store two types of long term keys, one for node to KDC communication and another for node to node communication, which increases the storage overheads. In 2002, Mingyan Li [5] proposed a multicasting and broadcasting approach for key management. In this approach shared keys are stored in database of MTU (2n-1 keys) and RTU (1+log2n keys) and these keys are used at run time, where n is number of RTUs. A multicast and broadcast scheme is also proposed by Donghyun Choi [3]. This approach combines the Logical Key Hierarchy (LKH) and Iolus framework scheme. In LKH, a logical tree of keys is constructed to support multicast and broadcast communication. However, this approach provides multicasting in a limited fashion. The drawbacks of this scheme are the increased number of keys stored in RTUs and extra computational overhead at MTU. It requires n keys to be stored in root node and 1+log2n for a leaf node, where n is the number of RTUs. We are working on an architectural framework for security layer below the DNP3 stack (below the Data link layer), which consist of IDPS (Intrusion Detection and Prevention System) for TCP/IP and DNP3 network, Cryptographic Key 170
RTU1
1 key
RTU2
1 key
MTU
n keys
MTU
RTU3
1 key
RTU4
RTU1
------------ n
n keys
1 key
RTU2
n keys
n keys
RTU3
n keys
Figure2. MTU-RTU Direct Communication
Distribution, Key Management and Encryption/Decryption. In this paper, we concentrate on architectural analysis and issues for cryptographic key management. IV. ARCHITECTURAL FRAMEWORK FOR KEY MANAGEMENT Considering the limited memory capacity and processing power at RTU, it is necessary to store minimum number of keys at RTU without compromising the functionalities and security requirements. Number of keys stored in SCADA system is proportional to desired functionality like broadcasting, multicasting and need of communication between RTU to RTU, MTU-RTU, SubMTU to RTU, MTU to SubMTU. In this section we present the analysis on key management for various architectures with desired functionalities.
Figure3. RTU-RTU Direct Communication
key for each RTU) and number of keys at each RTU is also n (one key for MTU and n-1 keys for rest of the RTUs). When a new RTU joins, MTU establishes a unique key with this RTU, and between new RTU and every existing RTU. If there are n nodes on the network then establishment of n number of keys takes place. When any RTU leaves the network then every node deletes the key of leaving RTU from its database. Advantages • Direct communication between any two nodes is possible. • Less number of message encryption and decryption at run time because any two nodes can communicate directly without involvement of MTU. Disadvantages • More number of keys is needed at RTU. • Does not support broadcasting and multicasting.
A. Framework without SubMTUs In many critical infrastructures, most of the communication happens between MTU and RTU. If two RTUs want to communicate then MTU permits this communication under its control. Without knowledge of MTU, any two RTUs can not communicate, hence communication takes place through MTU. Every RTU shares one common key with MTU. Total number of RTUs attached with MTU is n. So number of keys at each RTU is 1 (common with MTU). Number of keys at MTU is n (one common key with each RTU). When new RTU joins, MTU assigns a new key for this RTU. MTU also stores the key in its database. When any RTU leaves, MTU deletes the key of leaving RTU from its database. Advantages • Less number of keys at RTU. Disadvantages • No direct communication between two RTUs. It is possible only through MTU. • For RTU to RTU communication double encryption and double decryption of message is needed. • Does not support broadcasting and multi-casting. • More load at MTU. Scenario 1: RTU-RTU Direct Communication There are possibilities that each RTU communicates with another RTU. For such communications mesh topology is the most appropriate topology(Fig. 3). So, total number of RTUs attached with MTU is n. So number of keys at MTU is n (one
B. Framework with SubMTUs Managing of all RTUs by one MTU may not be a good architectural design. In exceptional cases if a fraudulent RTU successfully established the connection with MTU then with DOS attacks, there are chances to flood the MTU which causes the shut down of the whole network. It is also tough to bear the full load of the network by single MTU. For solving such issues, load of MTU can be shared with multiple SubMTUs. In such type of architecture RTU communicates with MTU through SubMTUs (Fig. 4). In such type of architecture MTU stores common keys with SubMTUs only. Let total number of SubMTUs is m and number of RTUs at each SubMTU is n. So number of keys at each RTU is 1 (only one common key with SubMTU). Total number of keys at each SUBMTU is 1+n (one common key with MTU and one common key with rest of the each RTU). Number of keys at MTU is m (one common key for every SubMTU). When new RTU wants to join any SubMTU, MTU assigns a new key to this RTU and same key to corresponding SubMTU. When any new SubMTU joins the MTU, common key is established between MTU and new SubMTU. When any RTU leaves the network, then SubMTU deletes the key of leaving RTU from its database with the permission of MTU. When any SubMTU leaves the network then MTU deletes the key of SubMTU from its database. RTUs of deleted SubMTU can attach to other SubMTU.
171
m keys
MTU
SubMTU1
1+n keys
RTU1
1 key
SubMTU2
1+n keys
SubMTU3
SubMTU4
1+n keys
SubMTU1
------ m
RTU3
RTU4
1 key
1 key
1 key
SubMTU2
SubMTU3
1+n keys
1+n keys
RTU1
RTU2
RTU3
1 key
1 key
1 key
1+n keys
1+n keys
RTU2
m(1+n) keys
MTU
------ n
SubMTU4
------ m
1+n keys
RTU4
------ n
1 key
Figure4. MTU-SubMTU-RTU Communication
Figure5. MTU-RTU Direct communication in case of SubMTU failure
Advantages • Less number of keys at RTU. • Direct communication between MTU-SubMTU, SubMTU-RTU is possible.
Key Reduction at MTU: Using Choi’s [3] concept, m number of keys at MTU side can be reduced but for this, extra computation cost at run time is needed. Let k1, k2, k3,...kn is the set of keys stored at SubMTU1 and at MTU. Now MTU and SubMTU1 can calculate common key for communication between MTU and SubMTU1 at run time by using K= F(k1, k2, k3,...kn). Hence remaining keys at MTU are mn and remaining keys at SubMTU1 are n because m number of keys is reduced at MTU and one key is reduced at SubMTU1. The key between the MTU and SubMTU is now dependent on the number of RTUs. There is little advantage in being able to calculate one key with making it dependent on a variable number of RTUs.
Disadvantages • More number of encryption and decryption of message at run time. • RTU-RTU communication possible only through MTU or SubMTU. • Does not support broadcasting and multicasting. Scenario 1: Incidental Failure of SubMTU
Advantages • Minimum communication for every RTU is assured in case of corresponding SubMTU failure. • Less number of keys at RTU. • Direct communication between MTU-SubMTU, SubMTU-RTU is possible and in exceptional cases direct communication between MTU-RTU is also possible.
In case of SubMTU failure, it is better to give limited authority to RTU to communicate with MTU directly. We assume that SubMTU failure takes place rarely. With this concept, all RTUs attached with failed SubMTU could be prevented from fully shutting down. In general, RTU abandons a failed SubMTU and joins another SubMTU. But in this approach, an RTU can be attached to MTU instead of SubMTU, if SubMTU failure is incidental (Fig. 5). In this case, number of keys at MTU is increased because MTU shares common keys with SubMTUs as well as RTUs. Let, total number of SubMTUs is m and number of RTUs at each SubMTU is n. So number of keys at each RTU is 1 (only one common key for both MTU and SubMTU). Total number of keys at each SubMTU is 1+n (one common key with MTU and one common key with each RTU). Total number of keys at MTU is m(1+n) (one common key for each SubMTU and one common key for each RTU). When new RTU joins to any SubMTU, the MTU assigns a new key to this RTU. MTU sends the key to corresponding SubMTU and also stores the key in its database. When any new SubMTU joins the MTU then after authentication, common key is established between MTU and new SubMTU. When any RTU leaves the network, MTU deletes the key of leaving RTU from its database and from the database of corresponding attached SubMTU. When any SubMTU leaves the network then MTU deletes the key of SubMTU from its database. RTUs of deleted SubMTU can be attached to other SubMTU.
Disadvantages • More number of encryption and decryption of message at run time. • RTU-RTU communication possible only through MTU or SubMTU. • Does not support broadcasting and multicasting. • More number of keys at MTU and SubMTU. Scenario 2: With Multicast Support Using concept of shared key [5] among a group of RTUs, broadcasting and multicasting can be achieved. In Fig. 6, using MTU as a root node, all RTUs as leaf nodes and conceptual join points as middle nodes, a binary tree is created. Conceptual point is a shared key point for more than one node. Let J1 is a key of RTU1 and J2 is the key of RTU2 then using G1 = G (J1, J2) shared key G1 is created for both RTUs. This shared key will be stored at RTU1, RTU2 and MTU. MTU uses G1 as key for message multicasting to RTU1 and RTU2.
172
MTU
(2n-1) keys
G1=G(J1,J2)
G2=G(J3,J4)
SubMTU1 (Conceptual points)
RTU1
1+log2n keys
m keys
MTU
G3=G(G1,G2)
RTU2
1+log2n keys
1+n keys RTU3
1+log2n keys
SubMTU2
SubMTU3
1+n keys
1+n keys
RTU1
RTU2
RTU3
1+k1 keys
1+k2 keys
1+k3 keys
SubMTU4
------ m
1+n keys
RTU4
---- n 1+log2n keys
Figure6. Multicast Communication
After creation of G1 and G2, shared key G3 is created for RTU1, RTU2, RTU3 an RTU4 set. In this way shared keys for whole tree are created. Root node stores all shared keys and keys of all RTUs but any RTU stores only shared keys of one path from its location to MTU. Hence total number of keys at MTU is 2n-1 and at any RTU is 1+log2n. MTU can broadcast the message to all RTUs by using shared key of root node. The multicast message has the shared address of the conceptual point to which it is addressed. Major drawback of this architecture is that it does not provide full multicasting i.e. multicasting for RTUs of different branches is not possible. For example multicasting for RTU1 and RTU4 is not possible. When a new RTU joins, conceptual point between new node and appropriate node in existing network is created. Sibling of new node is decided on the basis of locality and functional grouping. Re-calculation of conceptual point is done if it is associated with path which is affected by joining new node. When any RTU leaves the network then recalculation of all conceptual points which are on the path of leaving RTU is done. Key Reduction at MTU: Using Choi’s [3] concept, n-1 number of keys at MTU can be reduced but it involves more computational cost at run time. MTU can store one key of every RTU and MTU can calculate shared key at run time for multicasting and broadcasting. After using key reduction concept, remaining number of keys at MTU is n. Advantages • Supports broadcasting and partial multicasting. Disadvantages • Does not support full multicasting. • More number of keys at RTU and MTU. • Double encryption and decryption of message in case of RTU to RTU communication. Scenario 3: RTU-RTU Communication Within a Set
RTU4
------ n
1+k4 keys
Figure7. RTU-RTU Direct Communication
Let there are ki RTUs in a favorite set for a particular RTU i then ki+1 number of keys will be stored at RTU i and one extra key will be stored on each RTU which belong from favourite set of RTU i. If RTU i is already member of favorite set of RTU j then extra common key between i and j will not be established at the time of creation of favorite set for RTU i. Major drawback of this architecture is that for creation of favorite set, past communication knowledge of whole network is needed. When the RTU is configured, it will be known to which other RTUs it will have to communicate frequently. Total number of SubMTUs is m, and number of RTU at each SubMTU is n. So total number of keys at RTU i is 1+ ki. For example: Favorite (RTU1)={RTU2, RTU3}. There are two elements in favorite set of RTU1 so total key storage at RTU1 = 3. Total key storage at RTU2 = 2. Total key storage at RTU3 = 2. Total number of keys at each SubMTU=1+n, one common key with MTU and one common key with every RTU is needed. Total number of keys at MTU=m, one common key for every SubMTU is needed. When new RTU joins to any SubMTU, MTU assign a new key to this RTU and transfer the key to corresponding SubMTU. After key establishment between new RTU and SubMTU, discovery of favourite set for new RTU begins and after favorite set, discovery key is established between new RTU and each member of favourite set. When any new SubMTU joins the MTU then after authentication, common key is established between MTU and new SubMTU. When any RTU leaves, MTU deletes the key of leaving RTU from the database of corresponding SubMTU and favourite RTUs. When any SubMTU leaves then MTU deletes the key of SubMTU from its database. RTUs of deleted SubMTU can be attached with other SubMTU. Advantages • Direct communication between MTU to SubMTU, SubMTU to RTU, and RTU to any RTU of its favorite set is possible. • Less number of message encryption and decryption at run time is needed.
In some cases, an RTU might be interested to communicate with a particular set of RTUs frequently. In such type of scenario, that RTU can store common keys with all RTUs of its favourite set and one common key for SubMTU. If the communication between two RTUs is not frequent then communication takes place through MTU. 173
Disadvantages • Need to store more number of keys at RTU. • Does not support broadcasting and multicasting. V. CONCLUSIONS Due to the possibility of cyber attacks and its impact on critical infrastructure it is necessary to develop a protection system mitigating such type of severe threats. Recently, a lot of effort has been put in this area but still cryptographic key management methods for security of SCADA systems can be improved. In this paper, we have discussed issues and challenges on cryptographic key management for SCADA systems. We also discussed suitable architectures with different scenario for SCADA system under constraints. We have also described why particular architecture is suitable for specific scenario of SCADA system along with the advantages and disadvantages of every proposed architecture and unsolved issues like multicasting. REFERENCES [1] [2]
[3]
[4]
[5]
[6] [7] [8]
C. L. Beaver, D.R. Gallup, W. D. NeuMann, and M.D. Torgerson “Key Management for SCADA (SKE)”, printed at Sandia Lab March 2002. Robert Dawson, Colin Boyd, Ed Dawson, Juan Manuel, Gonz´alez Nieto “SKMA – A Key Management Architecture for SCADA Systems”, Fourth Australasian Information Security Workshop (AISW-NetSec 2006). Sungjin Lee, Donghyun Choi, Choonsik Park, and Seungjoo Kim” An Efficient Key Management Scheme for Secure SCADA Communication”, Proceedings Of World Academy Of Science, Engineering And Technology Volume 35 November 2008. Ludovic Piètre-Cambacédès, Pascal Sitbon “Cryptographic Key Management for SCADA Systems, Issues and Perspectives”, Proceedings of the 2008 International Conference on Information Security and Assurance (isa 2008) Pages 156-161. Mingyan Li, R. Poovendran and C. Berenstein “Design of Secure Multicast Key Management Schemes With Communication Budget Constraint”, IEEE Communications Letters, Vol. 6, No. 3, March 2002. Mariana Hentea “Improving Security for SCADA Control Systems “, Interdisciplinary Journal of Information, Knowledge, and Management Volume 3, 2008. T. Paukatong “SCADA Security: A New Concerning Issue of an Inhouse EGAT-SCADA”, Electricity Generating Authority of Thailand, 53 Charan Sanit Wong Rd., Bang Kruai, Nonthaburi 11130, Thailand. Barry Charles Ezell “Infrastructure Vulnerability Assessment Model (IVAM) “, Risk Analysis, Vol. 27, No. 3, 2007.
174
