The Secure Field Bus (SecFB) Protocol -
Network Communication Security for secure
Industrial Process control
Swaminathan P Padmanabhan K
Graduate Student in Computer Professor Emeritus
Science and Engineering AC College of
IIT Madras Technology
swaminathankp(&gmail. com Anna University
Abstract
This paper describes a protocol by which
network security can be included in existing
Fieldbus systems. The protocol makes use of the
56-bit DES cipher for data encryption. It also
includes a scheme for symmetric Key exchange
and automatic Key Update at specific time
intervals. In addition, the protocol includes a
new idea called Key Refresh. The Key Refresh is
a simple scheme that can be an alternative to
operating the cipher in processor intensive
chaining or feedback modes. The industrialfield
devices are equipped with the TMS series of
Digital Signal Processors to perform DES
encryptionldecryption. Since these processors
are already present embedded in many of the
state-of art field devices, they were chosen so
that the protocol would not require additional
hardware. The protocol is generic and can run
over any of the commercial Fieldbus networks.
Security Requirements in Fieldbus
The world of process automation is changing.
Industrial field devices are being upgraded from
the old 4-20 mA analog communication standard
to the new digital architecture known as the
Fieldbus. The new technology promises a lot, in
terms of reduction of installation costs and
feasibility of intelligent request/response systems
across the network with 2-way communication
facilities. Shadowed behind this striking feature-
list however, are the familiar security
predicaments, very much part of digital
communication networks. The digital
revolution is promising to revolutionize process
automation, but without proper security, the
move would backfire and lead to information
1-4244-0549-1/06/$20.00 (2006 IEEE.
Ananthi S Pradeep R
Sr. Lecturer Graduate Student
University of St. Joseph
Madras Engineering
College
hacking, for the malignant X factor to raise its
head and threaten proper operation of these
networks. To alleviate these security hazards,
the need of the hour is an established protocol for
Data protection to run over commercial Fieldbus
networks. Our SecFB protocol is an attempt in
this regard to utilize the standardized encryption
algorithms for providing communication security
over the Fieldbus networks.
Security and safety in such systems
Associated with the Fieldbus networks are
problems of sudden unexpected sabotage and
consequent failure and damage to plant and
personnel. Secure data communication relies on
suitable encryption of the data flowing in across
the network and a decryption at the received end.
In large process plant, where the Field bus is
used from the Management or Company level
down to the plant operation level, (fig. 1), there is
a possibility at the intermediate levels for data
corruption and mismanagement. This possibility
is rare is older systems not using the bus at all,
since the layers are wired systems and there is no
possibility of data intrusion, though improper
connection changes can happen in marshalling
racks.
Even a single data packet that is purposely
sabotaged might cause plant variables to go
astray and cause damage or loss of production.
When there are three levels of bus based
communication - the Factory level, the Cell level
and the plant or field level, - (fig. 1) - the security
of the data relating to plant set points, control
system parameters and the thresholds etc has to
be maintained at all times absolutely.
 Difficulties exist in incorporating the
contemporary cryptographic algorithms over
Fieldbus networks. Some have been listed
below.
1. The end devices must be capable of
supporting the volume of computation
required to decrypt the data and apply it
to the control of process.
2. Encryption must be two-way. When
field process variable data are being
sent upwards over the bus, the same
should also be encrypted. This imposes
an additional requirement for the field
devices to run encryption algorithms.
The Algorithm of Choice
Of all the contemporary algorithms available
in the market today, we propose to use the Data
Encryption Standard (DES) as the backbone for
our SecFB protocol. There are several reasons
behind this preference for the DES.
* The DES is absolutely symmetrical.
The algorithm is public and the
encrypted message is a function of the
Input text and the 'key'. Decryption is
done using the same key
IX
Fig.1. Possibility of intervention at
various levels of the Fieldbus
A=Control level, B=Automation
level, C=Field level
* The algorithm is probably the fastest of
all the commercial cryptographic
algorithms available today
* The key length is manageable at 56 bits
and is more than enough to guarantee
security for Fieldbus networks carrying
short data chunks.
* The algorithm is an IEEE prescribed
standard
The Secure Field Bus protocol
The implementation of the protocol is based
upon a prescribed set of primitives that is
common to the various levels of the Fieldbus
architecture. The one major hurdle in the
implementation of symmetric encryption
algorithms like the DES, is the process of key
exchange. There has to be a way by which the
communicating parties can securely exchange
the key. This cannot be done by directly
transmitting the key without encryption over the
network. So, key transmission requires
encryption, which in turn requires another key
(infinite recursion!).
A straight forward solution could be to
manually exchange the keys, which would be a
one-time process during network setup.
Communication could then proceed using the
manually distributed keys and should
theoretically remain secure, but for how long?
Network interveners could employ guessing
schemes such as the known message or the
probable message attacks, or some form of key
deduction by analyzing encrypted samples, and
figure out the key. This process could happen
within days of installation, depending upon the
amount and frequency of messages transmitted
over the network. This is an added disadvantage
for Fieldbus systems as many of the control
messages are usually short and frequented over
the network.
To get over this problem, the highest level in
the Fieldbus network, namely the Master
supervisory level is equipped with a secure
trusted system known as the Key Distributor
(KD). The Key Distributor is installed in a
physically sealed environment with access
permitted only to trusted management level
personnel. It does not require frequent manual
intervention as the operating protocol is fully
automated. In fact, ZERO manual intervention is
a reasonable option.
The Initial Configuration
To kick start the protocol operation, the
following initial configuration should be
established.
 * The Key Distributor should share a
DES key with each of the devices in the
Master level and also the Field level
PLCs.
* The Key Distributor should be
recognized as the trusted system on the
network and every message sent by the
KD should be encrypted (except for few
allowable exceptions, such as acks, to
be discussed later)
This initial configuration is only required
to turn on the security system. The
manually established keys are very much
transient, and will change automatically
(without manual intervention) from time to
time, to ensure tighter system security.
IK
_-
OV
>i ia 11I
Fig 2. The presence of the Key
Distributor at the highest level
Key Exchange
Now that the initial configuration has been
put in place, the KD can securely exchange
messages with other devices in its level and also
the Field level devices (usually PLCs). This
secure channel is made use to facilitate key
exchange between Master and slave devices so
that they can proceed to communicate directly.
The actual key exchange occurs as follows.
The Master (M) starts off by sending an
encrypted message to KD (encrypted by the key
km,kd shared between M and KD) that includes
the master's identity (optional - depending upon
underlying communication protocol), the
identifier of the Field device (F, usually the PLC,
terms used interchangeably) with which it wants
to communicate, a newly generated 56-bit key
km fd for communication with F and a Time
stamp TS1. KD then proceeds to verify the key
and diverts it over to the Field device F,
encrypted by the key kfd,kd (shared between KD
and F). Along with the key, the identifier of M,
a new Timestamp (current clock) and the original
timestamp value when M initially placed the
request (TSI) are also included in the message.
The Field Device stores km,fd in its key database
against the identifier of M. It follows up by
sending a key acknowledgment (k-ack) back to
KD. Note that this k-ack need not be encrypted
because of the implicit restriction that only one
master can enter key acquisition phase with a
particular Field level device, at a time. In case
multiple masters issue key proposals, the
requests are queued up by KD and forwarded to
F one by one. The k-ack need not include the
identifier of the master to whom it corresponds,
thus saving on encryption/decryption processing
times. It however, includes a digest of the key,
so that spoofed acks can be counteracted. In the
final phase, KD redirects this received k-ack
back to the master M. Once again, there is the
similar restriction that prevents a particular
master from making key proposal for more than
one Field level device. Hence, the k-ack need
not include the identifier of the Field device.
Although these restrictions appear to be
stringent, they serve to improve performance by
reducing the need for transmitting encrypted
acknowledgments during key exchange.
The outline of the key exchange protocol is seen
below.
* M 4 KD: Ekmkd(IDM ID F km,fd
TS1)- (1)
* KD: Verify the key
* KD - FD: Ekfd,kd(IDM km,fd TS2
TS1) note TS, from (1)
* FD stores the key in its DB
* FD - KD: k-ack
(Note: Only one Master Device can enter Key acquisition
phase with a FD, at a time)
* KD - M: k-ack
(Note: Any Master can acquire key to one field device at a
time)
* M stores the key in its DB
Once Key Exchange is completed, both
parties can directly exchange encrypted
information over the network. It is advisable to
include timestamps in each message before
encryption so that replay attacks are not possible.
In addition to timestamps, the messages should
be appended with a hash (or CRC) prior to
encryption. This will ensure that no attacker is
able to transmit well-furnished junk packets in
an attempt to confuse the communicating parties.
Key Refresh (KR)
One well-known use of time stamped
messages is guarding against packet replay
attacks. But in this case the timestamp also helps
to thwart Known Text & Cipher Attacks
(KTCA) and other key guessing schemes. A
KTCA is possible if the attacker has knowledge
of both the plain text and the corresponding
encrypted version (in pairs). An obvious
vulnerability of Fieldbus networks is that control
messages from the supervisory levels are very
much recurrent. Thus, if the attacker knows the
command likely to be frequented by a particular
master, he can deduce its corresponding
ciphertext simply by a frequency analysis. To
guard against this type of attack, the protocol
mandates Key Refresh (KR) operation at fixed
time intervals, beginning from time TS1. This is
the significance of forwarding TS1 to F. Both the
communicating parties (M and F) start a counter
from the value of TS1 This interval should be
large enough for the key exchange protocol to
finish and small enough to avoid KTCA attacks.
The Key Refresh(KR) operation occurs as
highlighted below.
Key Refresh (KR):
* M - FD: Ekm,fd(IDM new km,fd)
* FD - M: ack
Here, the Master chooses a new key and
transmits it to the Field device, encrypted by the
old key. The Field device, upon receipt of the
new key, updates its database and fires back an
acknowledgment. From here on, all future
communication must use the new key.
NOTE: If we include timestamps with every
recurring control message, it is possible that the
encrypted versions will differ from one another.
However, there is the difficulty of packing the
entire packet (control msg + timestamp) into one
DES block of 64 bits. To get over this, DES can
be operated in chaining or feedback mode so
that adjacent blocks influence each other during
encryption. This however, levies an additional
undesirable load upon the Field level
microcontrollers. A better alternative is to go for
Key Refresh.
The Master Time Frame (MTF)
However, it is not advisable to allow the
Master to infinitely refresh the key without the
intervention of the Key Distributor. In case an
eavesdropper manages to crack a particular key,
he can very well keep track of all KR messages
and deduce the updated keys. To get over this
problem, a Master Time Frame (MTF) is preset,
once again beginning from TS1. At the end of
this time interval, the shared key is abandoned
and rendered invalid by both parties. Now, the
Master has to once again go through the key
exchange protocol by contacting the KD, and
propose a new key.
Security at the Field level
At the Field Level, the individual field
devices are equipped with the TMSC50 and
C240 to run the DES cipher. In case of a Multi-
Master configuration, with more than one PLC
connected to a bus, the same protocol can be
operated, with each node acting as the local Key
Distributor for itself
Conclusion
The TMS C240 is present embedded in many
of the state-of-art field devices such as motorized
control valves and sensors. Hence, it is easier to
implement the SecFB protocol without the need
for additional hardware. SecFB is highly
customizable and can run over any of the
existing commercial protocols such as the
Profibus. It was tested with the Simple FieldBus
Protocol (SFBP) [2] stack as the underlying
platform.
References:
[1] Data Encryption Standard (DES) Implementation
on the TMS320C6000, Internet Whitepaper
[2] Claudio Ghiotto and Paolo Marchetto, "Simple
Field Bus Protocol"©) Softmedia 2003, HEXEL
Electronic Lab