Flexi-DNP3 : Flexible Distributed Network Protocol Version 3 (DNP3) for

SCADA security

Sankalp Bagaria, Shashi Bhushan Prabhakar, Zia Saquib Centre for Development of Advanced Computing, Mumbai, India

Email: { sankalp, shashi, saquib } [AT] cdac [DOT] in

Abstract: Legacy SCADA systems are inherently insecure. They were built using specialized and proprietary protocols and used serial link, radio or leased line for communication. As these protocols were little known and specific to the industry they catered to, security was not important for them. But, recently because of increased terrorist attacks and migration of these protocols to TCP/IP, they have become susceptible to foreign attacks. We propose a mechanism to secure existing and future DNP3 networks. We built a BITW (bump - in – the – wire) prototype which exchanges keys and uses those keys to encrypt the data flowing on the network. We used DNPSec as our framework for BITW. Keywords: SCADA system, bump-in-the-wire, network security, SCADA protocols, DNP3, DNPSec, Flexi-DNP3

I. SCADA Systems

Supervisory Control and Data Acquisition (SCADA) systems are industrial control systems. Remote Terminal Units (RTUs) are connected to the Programmable Logic Controllers (PLCs). They are employed in many process industries including those of production, manufacturing, power generation, refining, fabrication etc. and infrastructure industries like water management, pipelines, power transmission and distribution, large communication systems etc. An SCADA system consists of the Master Terminal Units (MTUs) that gather data from RTUs, processes them and then sends signals to same or different RTUs to control processes. An RTU collects data from a sensor, valve etc. and converts it to electrical signal to be sent to MTU. It then receives signals from MTU and closes/ opens a switch or changes the speed of the pump etc. The MTUs communicate with RTUs using SCADA protocols like Modbus, DNP3 etc. In this paper, we will restrict ourselves to DNP3 protocol but what we say here is applicable to other SCADA protocols also which run on the TCP/ IP network.

II. Need for Security

SCADA systems that used proprietary protocols to communicate, were little known and had benefited from “security by obscurity”. Moreover, the SCADA networks were not connected to public networks. They ran on private networks over serial link and radio. These proprietary protocols were not designed keeping security in view. They were more concerned about availability and personnel safety issues. But, with the connection of these networks to enterprise networks and even to Internet, these networks have become susceptible to cyber-warfare/ cyber – terrorism. World over, it is being felt increasingly that the hackers employed by terrorist groups are a threat to industries and infrastructure. So, increasingly, a need is being felt to write new protocols.

III. DNP3 protocol There are many SCADA protocols like MODBUS, IEC 61850, DNP3, etc. DNP3 [3] is a popular and widely used protocol in process industries as well as infrastructure management. In DNP3 protocol, the MTU sends a request to RTU for data, the RTU collects information from sensors and actuators and sends back to MTU. The RTU can send unsolicited data also. Please refer Appendix A for details of DNP3 protocol.

IV. DNPSec Protocol DNPSec [1] is a protocol that addresses the security needs. It aims to provide security to the DNP3 protocol without increasing the message size or deleting any data from the packet header. DNPSec does so by removing CRCs from DNP packet and adding an Authentication Data trailer to the payload. DNPSec protocol achieves security by encrypting the payload. Please refer Appendix B for details of DNPSec protocol.

2011 International Conference on Recent Trends in Information Systems

978-1-4577-0792-6/11/$26.00 ©2011 IEEE293

V. Justification for BITW

There are thousands of existing networks that use the legacy SCADA protocols. These networks cannot be replaced overnight. So, there is a need to make changes in the existing protocols and in such a way that existing equipments and infrastructure are least affected. And, Bump-In-The-Wire (BITW) [2] seems an ideal solution for this. Since, the BITW is external to the SCADA device, it doesn't require making changes in existing RTUs and MTUs.

VI. Modifications made in the DNPSec Protocol

Size of the DNPSec Packet was fixed at 292 irrespective of the size of the DNP packet. The payload, if lesser than that, is padded with dummy data so that payload size can be of 256 bytes. And with DNPSec header and the authentication data, it comes to 292. DNPSec packet is identified from DNP3 and other packets on network by finding sync bytes 0x0564 at byte position 8-9 of the DNPSec packet. Consequently only payload data (256 bytes) is encrypted instead of encrypting payload and original LH header. This scheme provides the same confidentiality level as the original DNPSec scheme. The original DNPSec protocol has Key Sequence Number. When KSN reaches maximum and is re-cycled to 0, the MTU sets SK bit and send the new session key. Instead of this arrangement, we reserve the SK bits and instead use C-DAC's SecKeyD key distribution protocol (patent pending) to negotiate the key and freshness no. between BITWs of MTU and RTU. And, this negotiation of keys can be done after a configurable number of data exchanges.

VII. Our Implementation with flexible KSN and cryptographic algorithms

We implemented DNPSec with modifications. Each MTU and RTU is connected to an external BITW. The layout of the experimental setup is as shown in Figure 1. While setting up the BITWs, a seed key is stored at each RTU – side BITW. The MTU-side BITW stores all the seed – keys too. Then, after every N message exchanges between a RTU and MTU, the , we exchange a symmetric key between that RTU's BITW and MTU-BITW using CDAC's key-distribution protocol SecKeyD (patent – pending) [6]. N is configurable. AES algorithm is used for encryption/ decryption of the messages containing keys exchanged between RTUs and MTU because it provides more security than Blowfish for the same number of bits. The BITW connected to MTU captures the DNP3 packet coming from MTU, converts it to DNPSec packet after encrypting the payload using the secret symmetric key, pre – exchanged using C-DAC's SecKeyD protocol. Encryption

provides secrecy and confidentiality. The BITW encapsulates DNP packet within DNPSec and adds Authentication Data for integrity check. Authentication data is calculated using SHA1 algorithm on KSN, DNP original header and payload. TCP/ IP CRC and payload length fields are also recalculated to reflect the changes we have made in the captured packet. Iptables was configured to capture the desired packets. Library libipq was used to take these packets captured at the kernel – level and make them available to the user-level application for processing. And after the above processing, the packet was allowed to go on its way to the RTU.

Figure 1: Layout of Architecture

The switch/ hub sneds this data to the appropriate RTU. But, the BITW attached to the RTU intercepts the DNPSec message, verifies the Authentication Data, removes DNPSec header, adds appropriate DNP3 header and decrypts the payload using the secret key and Blowfish algorithm. Blowfish has been used for encryption/ decryption of payload because it is lightweight and executes fast. It also adjust TCP/IP CRC and payload length to reflect these changes. Different symmetric encryption/decryption algorithms with varying key-length can be used.

VIII. Further Work The Flexi-DNP3 uses the libipq library for packet capture and processes the packet at the user-level. It can also be implemented in the kernel/ hardware level. Performance will improve further. The whole set up has also to be tested in an industrial setting. The Flexi-DNP3 can be made configurable so that the algorithms to be used for any key exchange and data exchange can be negotiated between BITWs of RTU and MTU.

294

IX. Conclusion DNPSec provides confidentiality, integrity, and authenticity in the DNP3. As verified by Scyther tool, SecKeyD protocol prevents replay, man-in-middle and other attacks. We implemented DNPSec with modifications and linked it with SecKeyD. A new session key is negotiated after a configurable number of messages (Max : 2^32 – 1) has been sent by MTU to RTU. This layout of BITWs was integrated with DNP3 protocol's simulation in our labs and the implementation was verified to work as expected. The increase in RTT from MTU to RTU and back to MTU due to BITWs was found to be less than 1 ms. Appendix A: Details of DNP3 protocol [3]:

Figure 2: DNP3User Data Frame The DNP3 protocol has three layers i.e. data link layer, pseudo transport layer and application layer. The DNP3 data link header contains sync information, length of the DNP3 frame, destination address, source address and CRC information. The payload of the DNP3 frame contains blocks of 16 Byte data followed by 2 Byte CRC. There can be at the most 16 blocks with the last block containing at maximum 10 data Bytes.

Figure 3: DNP3 frame data structure

Appendix B: Details of DNPSec protocol [1] : The DNPSec fields are as follows: 0 – 3 New Header (4 bytes) DA: 0-1 Destination Address (2 bytes) MH: 2(bit 0) 0: Primary Master Host, 1: Secondary Master Host SK: 2(bit 1) 0: Fetch the database for the session key 1: The frame contains a KSN value from the Master. 2(bits 2-7)-3 Reserved (2 bytes) 4 – 7 Key Sequence Number (4 bytes) 8 – 15 Original LH Header (8 bytes) 8 – 9 Sync (2 bytes) 10 – 10 Length (1 byte) 11 – 11 Link Control (1 byte) 12 – 13 Destination Address (2 bytes) 14 – 15 Source Address 16 – 271 Payload data (256 bytes) 16 – 265 TPDU data 166 – 271 Padding dummy data 272 – 291 Authentication Data (20 bytes) KSN is a counter that is incremented after every send. New session key is sent by master after every 2^32 -1 messages. As per original DNPSec, payload and original LH header are encrypted using session-key. Authentication data is integrity check value for KSN, original LH header and payload data. It is calculated using SHA1.

References:

1. Munir Majdalawieh, Francesco Parisi-Presicce and

Duminda Wijesekera, DNPSec: Disrtibuted Network Protocol Version 3 (DNP3) Security Framework. In Advances in computer, Information, and system Sciences, and Engineering: Proceedings of IETA 2005, T?eNe 2005, EIAE 2005, pages 227-234. Springer, 2006

2. Patric P. Tsang and Sean W. Smith, YASIR: A Low-Latency, High-Integrity Security Retrofit for Legacy SCADA System, 23rd International Information Security Conference (SEC 2008): 445-459

3. Distributed Network Protocol, http://www.dnp.org/

4. UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI, Prentice Hall, 1998, ISBN 0-13-490012-X.

5. Deon Reynders, Steve Mackay and Edwin Wright, Practical Industrial Data communications: Best Practice Techniques, Newnes Publications, 2005, ISBN 0 7506 6395 2

295

6. Zia Saquib, Om Pal, Peeyush Jain, Sharda Saiwan, Dhiren Patel, SecKeyD (Secure Key Distribution Protocol in Constrained Environment), Patent

Application no. 2429/MUM/2010, India

296