Certificate Based Security at Device Level of Automation System Olli Post*. Jari Seppälä** Hannu Koivisto***
*Department of Automation Science and Engineering, Tampere University of Technology, Tampere, Finland (
[email protected]). **(
[email protected]) *** (
[email protected]) Abstract: This paper discusses the security at device level of automation system. Process networks are traditionally considered to be isolated networks. However manufacturers of devices tend to use backdoor in their products to remotely manage them. Also merging of TCP/IP-stack and using wireless connections at device level is gaining interest. Therefore the assumption of isolation is rejected and some security measures at device level are considered in this paper. OPC UA is an application framework that enables global connectivity. There is some security consideration in the specification of OPC UA. However these security measures aren’t efficient enough to be used at device level. Thus, implementing a new authentication only security policy profile or using OPC UA for data transfer and IPSec for authentication is proposed.. Keywords: OPC UA, IPSec, device level, security
1. INTRODUCTION There has been a continuous change in process networks since analogue data transfer was replaced by fieldbuses. Today there is a growing interest towards the merging of TCP/IP stack and wireless techniques as part of process networks. TCP/IP stack in process networks enables remote management of field devices using web technologies and wireless techniques reduce dependency from cables. Traditionally, process networks have been assumed to be isolated networks. There are no connections from outside to process networks. Therefore restricting physical access to process networks has been considered to be adequate security measure for process networks. Process networks have also been considered to be obscure. At attacker would have to be familiar with techniques used in process networks and he would also have to poses inside knowledge about the automation system to succeed. Security measures in process networks have been targeted against errors made by legit users. However if TCP/IP stack, web technologies and wireless techniques are used in process networks, it can’t be assumed to be isolated anymore. For example TCP/IP and web technologies provide a path from outside to process networks. Treytl et al., has noted that the focus of attacks to automation systems seems to be shifting from internal attacks to external attacks. However it appears that these external attacks aren’t targeted specifically to automation systems but they inflict them as well. (2005) This demonstrates that process networks aren’t obscure anymore. Byres & Hoffman have noted that backdoor accesses such as desktop modems, wireless networks, laptop computers and trusted vendor connections are remarkable source of attacks (2003). In process networks it is typical for every manufacturer of a device in automation system to leave a backdoor connection to that particular device. Another crack in the isolation assumption is wireless devices. Controlling access to wireless
media is very hard if not impossible. Because of backdoor in process networks and wireless devices, it is clear that process network can’t be assumed to be isolated neither. Therefore new security measures towards illicit users must be considered in process networks.
2. DEVICE LEVEL In this paper automation systems are considered to have two types of devices: computers and I/O-devices. Computers are devices that have enough calculation power and memory for security measures. Computers can use the same security measures used in Internet. I/O-devices on the other hand lack resources and therefore the same security measures can’t be used to communicate with I/O-devices as can be used communication between computers. Thus, automation systems have two data transfer interfaces computer to computer interface and computer to I/O-device interface. The latter is in interest in this paper. The devices and fieldbuses connecting these devices constitute device level. Computers at device level can be for example PLCs or controllers. Another peculiarity at device level is that its data transferred periodically in one way only. The data is control and measurement data that is send periodically. There is no need to establish connections because if one packet is lost another will be sent after the predefined period. After the new packet arrives the information in the previous packet is useless. The International Society of Automation (ISA) has defined specific features for device level (2004). The features that are important in the sense of this paper are that unwanted
incidents can cause serious damage to property and people, events in the network are time critical, integrity of data is very important but it isn’t confidential. Confidentiality guarantees the data from unauthorized disclosure and it can be assured using encryption. Integrity guarantees that data is transferred unaltered and it can be assured using authentication. Encryption consumes more calculation power than authentication. For example in IPSec encryption consumes multiple times more calculation power than authentication (Elkeelany et al., 2002). Because of these specific features calculation power consumed should be as little as possible. Thus there is no need for encryption to be used at device level. Only Authentication should be used
can be used to crypt and/or authenticate (Douligeris et al., 2007). It has been used in Internet for a long time and therefore it can be assumed to be secure. Another technique to be considered is TLS (Dierks & Allen, 1999). It also crypts and/or authenticates and it is commonly implemented in web browsers and therefore it could be used for remote management of devices at device level (Treytl et al., 2004). However TLS is an application layer protocol and it requires TCP on the transport layer (Alshami & Saito, 2005). At device level UDP is used as a transport layer protocol and therefore TLS can’t be used at device level. Thus, IPSec was chosen under inspection in this paper.
5. MEASUREMENTS 3. OPC UNIFIED ARCHITECTURE OPC Unified Architecture (OPC UA) is an application framework for data transfer in automation systems and it is specified by OPC Foundation. There are already nine other OPC specifications used in automation systems. All these specifications are used in its specific niche. OPC UA is supposed to operate in all the niches and ultimately to replace all the other OPC specifications and to provide global connectivity. The information security in OPC UA is specified in parts 2,4 and 7 of OPC UA specification. Part 2 considers how secure channel and session are established (2009). Secure data transfer in OPC UA is based on x.509 certificates and part 4 considers how these certificates are validated (2009). It should be noted that the specification doesn’t consider how certificates should be distributed or revoked. These issues cause considerable problems at device level. The hierarchical nature of x.509 might also cause problems. Therefore it might be feasible for a system provider to act as a certificate authority at device level. The actual security policy profiles of OPC UA are specified in the part 7 (2009). There are three of them: basic128rsa15, basic256 and none. Basic128rsa15 is a suite of algorithms that include aes128 for encryption, sha-1 for authenticating and rsa15 for key wrap. Basic256 on the other hand uses aes256 for encryption, sha-1 for authenticating and rsaOaep for key wrap. Security policy profile none doesn’t include any security algorithms. It should be noted that the first two security policy profiles encrypt always messages and therefore other more efficient security measures are considered at device level.
The measurement environment consists of one computer hosting two identical virtual computers. Between these two virtual computers is a virtual switch. The measurements are done at the virtual switch using tcpdump. These virtual computers are devices that do not lack calculation power or memory and therefore these experiments slightly lack authenticity. As traffic in process network is one way only, the time that it takes for the sender to process the packet and send it, for the packet to be on the wire and for the receiver to receive and process the packet is measured. This time is presented in (1). (1) is time that computer consumes processing a packet, is time that computer consumes sending the packet, is time a packet is on the wire and is time that computer consumes receiving a packet. Because sender and receiver are identical computers (1) can be altered (2). (2) Because it is difficult to measure accurate time delays of a packet inside two computers the measurements were done in one point of the network. First a packet is sent from UA2 client and its timestamp is captured at the virtual switch. Then UA1 server receives it processes it and sends an identical packet back to the client. As the packet arrives to the virtual switch its timestamp is captured. The time delay is presented in (3).
(3) 4. TLS AND IPSEC It is possible that OPC UA security policy profiles are not efficient enough to be used at field device level. It might be more efficient to use OPC UA for data transfer and authenticate data using another technique. IPSec could one option for that purpose. IPSec is a network layer protocol that
Because virtual computers are on the same host computer is very small and it is assumed to be 0. Therefore both (2) and (3) can be altered to (4).
(4)
Because both formulas are the same the measurements depict correctly the phenomena.
profiles are measured because these security profiles might be easily included to the specification should the need arise.
The traffic used in the measurements is OPC UA messages. These messages are generated using OPC UA Java reference model. In the measurements three packet size were used: 1 024, 10 240 and 102 400 bytes. The first packet size depicts a situation of low congestion. The second depicts a situation of medium congestion and the last one high congestion. The last one depicts for example how client and server survive from denial of service attack. There are also six different security profiles used. The three OPC UA security profiles are used as well as IPSec. In IPSec security profile messages are generated using OPC UA security policy profile none and authentication is done using authentication header of IPSec. There are also two security profiles that are almost the same security policy profiles as are specified in the OPC UA specification. The difference is that these profiles only authenticate instead of authentication and encryption. However it should be noted that these two profiles aren’t included in the OPC UA specification. 12 000 measurements were done for each packet sizes and each profiles.
Fig. 2: Sample time delays of packet size 10 240 bytes
From figure 1 can be seen that profiles that only authenticate data add only minor delay to the security profile none compared to the security profiles that encrypt also. It can be also noted that authentication methods produce a bit different results. In figure 2 is presented sample time delays using OPC UA message size of 10 240 bytes. From this figure can be also seen that encryption adds more time delay to packets compared to authentication only. From this figure can also be noted that although different authentication only profiles produce similar results the results differ slightly.
Fig. 1: Sample time delays of packet size 1 024 bytes
6.RESULTS In figure 1 is presented sample time delays for packet size of 1 024 bytes. This is the message size of OPC UA. In the xaxel is presented the measurements in chronological order and in the y-axis time delay in milliseconds. None is security policy profile none, 128enc is security policy profile basic128rsa, enc256 is security policy profile basic256 and IPSec is authentication using IPSec. Security profiles sign128 and sign256 are the same security profiles as specified in OPC UA specification but these profiles only authenticate data instead of encrypting and authenticating it. These
Fig. 3: Sample time delays of packet size 102 400 bytes
Table 1. Results and their confidence intervals
none sign128 sign256 ipsec enc128 enc256
1024 bytes 1.163±0.0136 1.627±0.0156 1.246±0.0290 1.267±0.0127 2.257±0.0308 2.255±0.0306
In figure 3 is presented sample measurements of OPC UA message size of 102 400 bytes. This packet size is very large to be used at the device level data transfer but it is supposed to simulate a situation where process network is for example under a denial o f service attack. From figure x.3 can be seen that encrypting packets add significant time delay compared to authentication only profiles. The results are presented in the table 1. The confidence interval of results is 95% and the distribution is assumed to be normal. From table 1 can be noted that authentication truly is more efficient security measure to be used at the device level instead of encrypting. These security profiles also do not add significant delay compared to security profile none. However it should be noted that these measurements were done on a device that has sufficient amount of calculation power and memory instead of real device level devices. Unsurprisingly basic128rsa is more efficient than basic256 to be used at the device level. There is however one peculiarity in the results. The results produced by authentication only security profiles produce slightly differing results which is surprising since all the authentication profiles use the same SHA-1 authentication method. These differences might be caused by java virtual machine or virtualization of virtual computers.
7. CONCLUSIONS AND FUTUREWORK Results show that OPC UA security profiles are not efficient enough to be used at device level. Two proposals are made to overcome this problem. New authentication only security policy profile could be included into OPC UA specification or OPC UA could be used for data transfer and IPSec for authentication. However these results should be assured using device level devices. Because authorization in both OPC UA and IPSec is guaranteed using certificates, future work should be done on the way certificates are handled at the device level. For
10 240 bytes 1.602±0.0546 1.927±0.0467 1.839±0.0510 2.063±0.0516 5.678±0.0499 7.405±0.0585
102 400 bytes 5.815±0.1074 7.726±0.0881 9.454±0.1027 8.450±0.1180 40.192±0.1171 50.845±0.1959
example PLC or controller could act as a certificate authority at device level. REFERENCES Alshamsi, A., Saito, T., 2005. A technical comparison of IPSec and SSL. In: IEEE (Institute of Electrical and Electronics Engineers), The 19th International Conference on Advanced Information Networking and Applications. Tamkang, Taiwan 28-30 March 2005. Byres, E. & Hoffman D., 2003. The Myths and Facts behind Cyber Security Risks for Industrial Control Systems. In: ISA (International Society of Automation), Process Control Conference 2003. Dierks, T. & Allen, C, 1999. The TLS Protocol Version 1.0, Request for Comments: 2246. Douligeris, C. et al., 2007. Network Security Current Status and Future Directions. Hoboken, NJ: WileyIEEE Press. Elkeelany, O,; Matalgah, M.M., Sheikh, K.P., Thaker, M., Chaudhry, G., Medhi, D. & Qaddour, J., 2002. Performance Analysis of IPSec Protocol: Encryption and Authentication. In: IEEE (Institute of Electrical and Electronics Engineers), International Conference on Communications 2002.New York, United States of America 28 April - 2 May 2002. International Society of Automation, 2004. ISATR99.00.022004 Integrating Electronic Security into the Manufacturing and Control Systems Environment OPC Foundation, 2009. OPC Unified Architecture Specification, Part: 2 Security Model, Release 1.01 OPC Foundation, 2009. OPC Unified Architecture Specification, Part: 4 Services, Release 1.01 OPC Foundation, 2009. OPC Unified Architecture Specification, Part: 7 Profiles, Release 1.00. Treytl, A., Sauter, T. & Schwaiger, C., 2004. Security measures for industrial fieldbus systems - state of the art and solutions for IP-based approaches. In: IEEE (Institute of Electrical and Electronics Engineers), IEEE International Workshop on Factory Communication Systems. Vienna, Austria 22-24 September 2004. Treytl, A., Sauter, T. & Schwaiger, C., 2005. Security measures in automation systems-a practice-oriented approach. In: IEEE (Institute of Electrical and
Electronics Engineers), 10th IEEE Conference on Emerging Technologies and Factory Automation.
Catania, Italy 19-22 September 2005.
