Security in Agent-based Automation Systems Basit A. Khan; J¨orgen Mad; Albert Treytl Austrian Academy of Sciences, Resarch Unit for Integrated Sensor Systems Viktor Kaplan Straße 2, A-2700 Wiener Neustadt {basit.khan, joergen.mad, albert.treytl}@oeaw.ac.at Abstract Agent systems are a way to increase flexibility of Manufacturing Execution Systems (MES) by scheduling tasks in a distributed autonomous way. Usage of autonomous, collaborative agents and off-the-shelf hardware and software components yet introduce vulnerabilities. This article presents a structural security model for protecting a distributed agent system based on the concept of a hierarchical model. In particular the necessary key system is introduced. The developed security model takes into account typical properties of embedded systems (low computation power, real-time capabilities, autarkic operation) used in automation environments 1 .

to flexibility and reaction to changes in the production process by introducing software agents. Since fixed structures are replaced by a dynamic, collaborative concept and common communication infrastructures like Internet technologies are more extensively used in an automation environment, higher vulnerability of the overall system is given[1, 6]. To cope with these new threats advanced security is required . This article discusses the security model and the key system being the base of the securtiy measures of the agent-based MES system of P2. The main focus is set on security requirements, the integration of low-resource devices (RFIDs) and flexible negotiation for production resources.

2 1

The PABADIS’PROMISE System

Introduction

As the complexity of information systems in automation increases, so does its potential to get exploited by unauthorized access. Digital information has become an extremely important asset of organizations [1]. Current generations of factory information and automation systems follow a strictly layered hierarchical architecture. Normally an automation system and its information system is divided into three layers (automation pyramid): • Enterprise layer responsible for strategic decisions • Manufacturing Execution System (MES) coordinating the factory floor by scheduling tasks, reserving resources and handling the flux of products and information • Field control layer that is dedicated to the shop floor control of machinery Today’s systems implement the above described structure rather static and often use a centralized and monoloithic approach. PABADIS PROMISE (P2) aims to overcome the disadvantages of this systems with respect 1 This work is performed within the European Project PABADIS’PROMISE. This STREP project is funded by the EC and referenced FP6-IST016649. http://www.pabadis-promise. org/

In opposite to conventional automation systems that execute their orders in a resource centric approach, the P2 system tries to increase flexibility and performance of the Manufacturing Execution System (MES) taking an order centric approach [3], i.e., instead of having a fixed assignment of maschines to the production steps, these steps only require abilities that can be dynamically assigned to maschines. The MES layer of P2 is represented by a set of flexible, cooperating, and autonomous software agents. The key components (see Figure 1) of the P2 system are Order Agents (OA) representing the orders and Resource Agents (RA) being the interface to the resources of the field layer. In the P2 system an order of the ERP system is passed to the OA via the interfacing Order Agent Supervisor (OAS). The first key concept of P2 is that the OA is fully responsible for the execution of its order, i.e. for each order a new OA is created that contains bill of operations and material (BOO, BOM) and performs his scheduling of the production steps. Hence, OA negotiates with RA and other OA to find the resources needed for every production step of the assigned order. Additionally, OA have the possibility to create suborders to reduce the scheduling complexity for a single OA. The RA on the other hand only manages the local schedule of its underlying resources (e.g. machine) and necessary maintenance and life cycle activities. The second key concept is that an OA is

3. Security overheads should be kept minimal for low capable devices such as RFITs

directly attached to the physical products it produces and it therefore physically migrate through the system. This is done via active RFID tags also called Radio Frequency Information Technology (RFIT).

4. Security must be integrated in existing agent communication protocols in such a way that the core functionality is not impeded and that overhead is kept at a necessary minimum.

ERP

5. Security management should be possible via a central point to ease practical operations.

Communication via Web Services

Communication via ACL

Product Data Repository

Order Agent Supervisor

Information Collector

Order Agent

Order Agent

Ability Broker

Resource Agent

Resource Agent

Resource Agent Supervisor

6. Messaging over shared media must be protected against untrustworthy listeners and senders; any listening attempt or unauthorized sending should not be possible.

Resource Agent

7. System entities shall be uniquely identifiable throughout the system.

Communication via Control Device proprietary protocols

Control Device

Control Device

Device Observer

Control Device

4

Following the concept of an overall security management each layer of the automation pyramid supports a company wide security system. Whereas the system’s entities at the enterprise layer such as ERP have a well established set of security measures already available the situation at MES and field layer, however, is more complicated. At ERP layer well defined security measures administrate all the (human) user related authentication, authorization and keep track of activities performed by the users at the enterprise layer. Resource limitations are usually not a problem at ERP. At MES and field layer, however, different security requirements steming from low capabilities or low-bandwidth communication such as RFIT exist. Additionally, often sufficient security features are missing at the lower layer of the automation system [5, 7].

Figure 1. PABADIS’PROMISE model of an automation system Since the loosely coupled agents do not form a rigid structure, the system becomes more flexible by local rescheduling and negotiation for required production resources. Hence the P2 system allows for online and flexible reactions on unplanned order changes, break downs or factory changes.

3

P2 Security Architecture

Security Requirements

The use of standard IT technologies, a collaborative agent system, and low-resource RFIT introduces new threats to the usually closed automation environments. Security threats from the agent system point of view are: • modification of agent data and code during transmission, • abuse of a platform by a malicious or strayed agents including authentication theft,

3 Zone Security Model (Resources)

• misuse of resources (unauthorized access) or wrong pairing of entities, i.e. loss of origin or untraceable initiary (unauthenticated communication).

Enterprise Layer

ERP RAS

RA

Structural threats to the platform (e.g. physical manipulation) are kept out of scope for this article. The following requirements are the base of the P2 security system:

Resource

RA

Resource

Control Layer

RA

Resource Field Layer

1. All entities in the system must properly authenticate themselves and based on this authentication access is granted.

Figure 2. Automation pyramid and the Three-Zone-Model concerning security for resource management

2. All messages circulating in the system shall be authenticated and integrity must be maintained. Confidentiality, non-repudiation and auditability are no primary goals in industrial automation.

In PABADIS’PROMISE a security architecture is developed that considers this situation and integrates the se2

curity needs of the loosely coupled agents. Figure 2 indicates the position of the P2 security architecture inside the automation pyramid. Focus of the work is mainly at the control or MES layer but also the interfaces to the surrounding layers are touched to allow seamless integration. The problem of securing the MES is the use of devices with low resources in the MES layer and the field layer that are not capable of carrying the additional load of (strong) security measures. Hence, a hierarchical security concept is applied that is organized in three zones of different mutual trust. This is a common approach in industrial automation [2, 4]. For the purpose of the PABADIS’PROMISE system a security system with three main zones (see Figure 3) is a suitable solution for the MES layer. The three zones match the three functional areas of MES: high layer components of ERP; MES layer with order and resource agents and interfacing between ERP and MES (DMZ)2 . Further sub-zones, called local and functional domains, are introduced which are encapsulating operations such as real-time communication that conflicts with usual security measures.

connected only through RFID communications. Hence, within the third zone only less resource consuming and therefore usually not that strong security measures exist for authentication and access control. Nevertheless, the overall security is maintained since entrance to the zone is protected by strong security measures in the zone(s) above. Each data or request for operation must pass all zones on the way to its destination to allow weak authentication and encryption inside the zone, e.g., a request from ERP first has to pass the webservice security, then the checks at the OAS, the firewall to the factory zone and the authentication inside the factory zone. If a security check fails the requested operation is not permitted and an exception handling takes place which is part of the P2 protocols. Domains are of special importance inside the factory zone. Whereas functional domains behave similar to a further sub-zone by grouping entities that need to work closely together (e.g., groups of drilling machines that do a joint scheduling) local domains refer to interoperation within limited local areas.

5

Zone 1 external

P2 Key System

EP (ERP)

The described security measures focus on the communication aspect since it is the key aspect to allow the physically mobile OA to negotiate for the required resources. Protection of the platform is nevertheless important, but not tackled in this article and is mainly based on principal services of the underlying Java. The security measures are based on the key system described in this section. Within P2 there are two types of communication channels and two different types of entities. The first type of communication channel is a fixed network that connects (locally) stationary agents, in particular RA and can support extensive communication. The other type of channel is RFIT transmission that is limited in the sense of bandwidth and communication speed. Taking computational resources into account two different kinds of devices can be distinguished: The first kind of devices can be graded as to be highly powerful. Such devices could be a high end server to a state of the art (industrial) PC and usually host the central entities of the system. The other kind of devices are the devices having very low processing and memory capabilities — namely these are the RFIT tags hosting the OA. These device capabilities also influence the security system and the key system that is the base for all cryptographic functions. Figure 4 shows the hierarchic key system. High end devices (PDR, OAS, RAS, RA Device type A) use asymmetric keys and are organized in a peerto-peer structure. On top of the structure the P2 Trusted Third Party (P2 TTP) is established as central entity to authenticate, manage, and distribute keys. Any entity of the agent system accepts this P2 TTP agent as a trustworhy start of authority. RFIT devices hosting OA and having low processing power (Device type B) use symmetric al-

Zone 2 DMZ Product Data Repository

Order Agent Supervisor

P2_TTP

Resource Agent Supervisor

Zone 3 factory

OA

RA

Resource

RA

Resource

RA

Resource

Sec. Notify Ability Broker

OA RFID Reader

Local Domains

Functional Domains

Figure 3. Three-Zone-Model The top most Zone is termed as Zone 1: external. External here means outside of the MES layer and includes some ERP components of the enterprise layer. In the middle of the three zone model is Zone 2: Demilitarized Zone (DMZ). At DMZ the supervising entities (RAS, OAS, P2 TTP, PDR) are located. These entities translate the semantics and syntax of the ERP payload to the factory layer. It is also responsible for establishing secure connections to ERP which is mainly based on standard Internet technologies such as SSL/TLS and XMLencryption for Webservices security to the limited security operations of the factory floor. At the bottom of the Three-Zone-Model the third Zone named as Factory Zone is placed. Due to hardware limitations of the embedded systems running OA and RA neither they are capable of doing strong computations nor they can deal with high communication loads. For example OA are usually run on embedded devices which are moving around with their associated product and are often 2 The interface to the field layer is completely hidden by RA and therefore not tackled.

3

since some RFITs only offer hardware support for these algorithms. The P2 TTP is the root of the P2 key hierarchy and serves as a secure repository for top level OA keys. In the implementation the P2 TTP will be a public key infrastructure certificate authority but it is also intended to integrate the functionality of the Kerberos Server that is used by JADE-S in this entity to fulfill the requirement of a central security maintenance.

gorithms and a hierarchical key structure. P2_TTP

OAS

PDR

RAS

RA 1

OA 1 OA 4

RA 3

OA 2

OA 5 OA 7

RA 2

OA 6 OA 8

6 OA 3

OA 9

Introduction of flexible software agents at the MES layer requires new security to cope with mobile programs and spontaneous cooperation. The key component to deal with these requirements is a three zone security model with local domains and a mixed hierarchical symmetric and asymmetric key system. This allows to setup a defense in depth concept that enables the system engineer to integrate weak components such as RFIT and low resource Programmable Logic Controls that are not capable of implementing heavy security functions. Further, already ongoing work is dedicated to the implementation in JADE-S and to the performance evaluation of the proposed structure to verify the feasibility in big-scale industrial applications.

Asymmetric key Infrastructure Symmetric key Infrastructure

Figure 4. P2 Key System High end devices upon their initial installation register at the P2 TTP and publish their public keys and receive a certificate to be able to communicate with their peers. This system is straight forward to classical public key infrastructures except that inside MES only one layer of certification is used. Resource limited devices on the other hand require a hierarchical symmetric key system due to the limited capabilities. The main design task is to integrate the creation of (suborder) OA that should operate autarkic and to reduce the overhead of communication to derive a key. Figure 5 depicts the key derivation process: A key is always derived from the name of the OA and the secret (symmetric) key of its ancestor. In this way the key to communicate with an OA or its subagent can always be derived from the secret key of the top OA since the list of ancestors can be publicly transmitted. E.g., OA 9 wants to communicate with RA 3 as shown in Figure 4. RA 3 first receives the list of ancestors from OA 9. It then uses the top key of OA 1 and the names given in the ancestors list to recalculate the key of OA 9 (see Figure 5). OA1

References [1] E. Byres and J. Lowe. The myths and facts behind cyber security risks for industrial control systems. In Proceedings of VDE Kongress 2004, Berlin, pages 213–218, October 2004. [2] D. Dzung, M. Naedele, T. P. von Hoff, and M. Crevatin. Security for industrial communication systems. In Proceedings of the IEEE, volume 93, pages 1152–1177, June 2005. [3] A. L¨uder, J. Peschke, A. Bratukhin, A. Treytl, A. Kalogeras, and J. Gialelis. The PABADIS’PROMISE-architecture. page T213. ANIPLA 2006, November 2006. [4] C. Schwaiger and T. Sauter. Security strategies for field area networks. In Proceedings of 28th Annual Conference of the IEEE Industrial Electronics Society (IECON), pages 2915– 2920, Sevilla, Spain, November 2002. [5] C. Schwaiger and A. Treytl. Smart card based security for fieldbus systems. In 2003 IEEE Conference on Emerging Technologies and Factory Automation Proceedings, volume 1, pages 398–406, Lisbon, Portugal, September 2003. [6] A. Treytl, P. Palensky, and T. Sauter. Security considerations for energy automation networks. In M. L. Chavez, editor, Proceedings of 6th IFAC International Conference on Fieldbus Systems andtheir Applications, IPV – IFAC Proceedings Volume, pages 158–165, Puebla, Mexico, November 2005. Elsevier. [7] A. Treytl, T. Sauter, and C. Schwaiger. Security measures for industrial fieldbus system — state of the art and solutions for ip-based approaches. In L. Lo Bello, editor, Proceedings of the 2004 IEEE International Workshop on Factory Communication System, pages 201–209, Vienna, Austria, September 2004. ISBN 0780387341.

Key for OA4=ƒhash( OA1 Private key , Name of OA 4)

OA4

Key for OA6 =ƒhash( OA4's Private Key , Name of OA6 )

OA6

Conclusion

Key for OA9 =ƒhash( OA6's Private Key , Name of OA9 )

OA9

Figure 5. Key generation for OA The key of OA 1 is put to P2 TTP by the OAS during the creation of OA 1. RA 3 can obtain the key of OA 1 out of the P2 TTP for authentication. This key chaining allows a RA to communicate with all child-OA that are created by the top OA. This is especially important since the creation of a child-OA usually depends on non-predictable parameters of the scheduling. For derivation use of SHA1 hash function is intended. Alternatives are DES or AES 4