wilamowski-b-m-irwin-j-d-industrial-communication-systems-2011

Security in Industrial Communication Systems 22-13
message and a random number using a shared secret key. However, due to key length and several protocol
flaws, this mechanism cannot be considered as secure [SC1]. In addition to this basic authentication
mechanism, a more advanced one based on MD5 is available for LonWorks/IP. However, since MD5 is
not collision resistant, it is also regarded as insecure.
IEEE 802.15.4 supports security mechanisms at the data link layer. The current version IEEE 802.15.4-
2006 uses a variant of the counter with CBC-MAC (CCM) algorithm called CCM to guarantee data
integrity, freshness, and confidentiality. ZigBee in its current version ZigBee 2007 utilizes the IEEE
802.15.4-2003 transmission services of the data link layer. However, ZigBee 2007 does not use the security
mechanisms provided by IEEE 802.15.4-2003—they are completely replaced by a more advanced
security concept. This concept supports the use of different key types and provides advanced key management
services. Again, CCM* is used as a cryptographic algorithm.
Beside the security features within the protocol, an important issue is the connection of the building
to remote maintenance centers. For such connections, buildings are equipped with gateways that allow
remote access to the underlying fieldbus. Typical security measures for these gateways are IP connections
protected by transport layer security (TLS) or VPN that securely tunnel the commands from the
remote site to the fieldbus (see Section 22.5.3). In rare cases also Web Services Security is used. To the
fieldbus site, the gateways usually provide no security or the security protocols mentioned above.
22.5.2 Security in Industrial Communication
Although almost never used, some industrial automation fieldbusses support security. However, these
security measures are very limited in scope and capabilities, and therefore cannot be considered as
serious protection if a considerable threat level needs to be assumed. The fieldbus systems for industrial
and process automation currently standardized by the IEC in the standards IEC 61784-1 [IEC1] and the
underlying IEC 61158 series [IEC2] are a heterogeneous collection of solutions. Their security features
can be divided into two categories: in systems like ControlNet, P-Net, and SwiftNet, hardly any state-ofthe-art
security measures are used at all. Foundation Fieldbus, Profibus, WorldFIP, and Interbus on the
other hand implement very similar application layer services and protocols modeled after their fieldbus
ancestor MMS. The simple access protection mechanism of these systems is based on access rights management
similar to UNIX-based systems. Every object has a 8 bit long password associated with it and a
list of 8 different access groups coded in an 8 bit word. Both password and access groups are transmitted
in plain text. If they match for a specific request, the additional access rights parameter defines the
allowed operations. Usually the access rights depend on the type of object and allow reading, writing,
executing, deletion, etc.
Unfortunately, these security means are not mandatory for implementation, and the password itself,
additionally, has no explicit protection. That is, it is transmitted in clear text, and hence should not
be used at all. A note in IEC 61158-5 reveals the actual intention of the security mechanisms: “This is
not a protection against intentional misuse of the communication facilities of a field device but helps
to protect a system for accidental erroneous use of process data.” This statement is in fact true for all
traditional fieldbus systems in industrial and process automation. Hence, to secure data traffic security
measures can only be implemented on top of the protocol stack. That is, the fieldbus is only used as a
transparent transport channel to transmit secure messages over standard fieldbus protocols and services.
Such an application-level approach could easily achieve end-to-end security, which is the goal
in many applications, anyway. Similar approaches have already been implemented for safety applications
such as the Profisafe profile of Profibus (IEC 61158). Drawback of adding such an application-level
approach for security is to cause problems with interoperability, since in general the interoperability
mechanism of the underlying fieldbus system cannot be used. Existing variable types or messages cannot
be used since they define no properties for security measures. Hence, the only way is to use general
purpose messages and redefine their behavior. Although a parallel usage of secure and insecure devices
is possible with this approach, the practical application demands a joint use. Yet connecting secure and
© 2011 by Taylor and Francis Group, LLC