IEICE TRANS. ??, VOL.Exx–??, NO.xx XXXX 200x

1

PAPER

Implementing a Secure Autonomous Bootstrap
Mechanism for Control Networks
Nobuo OKABE† , Member, Shoichi SAKANE† , Kazunori MIYAZAWA† , Ken’ichi KAMADA† ,Masahiro ISHIYAMA†† , Atsushi INOUE†† , Nonmembers, and Hiroshi ESAKI††† , Member

SUMMARY
There are many kinds of control networks,
which have been used in various non-IP network areas, such as
BA (Building Automation), FA (Factory Automation) and PA(Process Automation). They are now introducing IP and face theissues of security and conﬁguration complexity. The authors haveproposed a model which intends to solve these issues while satisfying restrictions, i.e. small embedded devices, isolated networks
and private naming system/name space, which are required whenintroducing new functionality into existing control networks. Secure bootstrap sequence and device-to-device communication using the chain of trust are the points of the model. This paper
shows the practicability of the model through implementing themodel experimentally.
key words: Control networks, Security, Auto-conﬁguration

1.

Introduction

Control networks are diﬀerent from IP (Internet Protocol) with regard to their history, purposes and technology. There are numerous standards of the control networks, e.g. FOUNDATION ﬁeldbus ∗ [1],PROFIBUS ∗∗ [2], MODBUS ∗∗∗ [3] and BACnet ∗∗∗∗ [4] which have been used in various non-IP
network areas, such as BA (Building Automation),FA (Factory Automation) and PA (Process Automation). Multiple standards coexist within a single system
usually because the system’s requirements are diverse.
Many standards are introducing IP as a transport technology, e.g. FOUNDATION ﬁeldbus HSE, PROFInet,
MODBUS/IP and BACnet/IP.
There are issues when introducing IP into control networks [5]. First, current control networks havenot suﬃciently considered security [6]. Network security must be necessary when introducing IP into them.
However, security is not easy for control networks beManuscript received January 1, 2003.
Manuscript revised January 1, 2003.
Final manuscript received January 1, 2003.
†
Yokogawa Electric Corporation††
Toshiba Corporation†††
The University of Tokyo††††
This research is supported/funded by the Ministry ofInternal Aﬀairs and Communications of Japan.
∗
FOUNDATION ﬁeldbus is a registered trademark of
the Fieldbus Foundation.
∗∗
PROFIBUS is a registered trademark of PROFIBUS
International.
∗∗∗
Modbus is a registered trademark of Modicon, Inc.
∗∗∗∗
BACnet is a registered trademark of ASHRAE.

cause the small embedded devices commonly used incontrol networks have limited computational performance because of their restricted requirements of cost,
physical size and power consumption. The other issue is the conﬁguration complexity of the control networks. Devices are usually manually conﬁgured in theﬁelds whereas their user interfaces are not so powerful,
like PCs. However, the number of devices are increasing because measuring and controlling need to be more
precise. For example, a BA system of a large building complex in Japan has 170,000 control points with
16,500 devices ∗∗∗∗∗ . This will present not only thecost of engineering but also the possibility of humanerrors in the future if a labor-saving mechanism is not
introduced.
The following are restrictions when introducing
new functionality into the control networks.
• Small embedded devices:
The small embedded devices commonly used in
the control networks have limited computational
performance because of their restricted requirements of cost, physical size and power consumption. Some devices will have more powerful CPUsin the future. At the same time, low-power CPUs
will survive because choice of CPU depends upon
not only cost performance but also power consumption which has an impact against battery operation or bus width which has an impact on circuitsize.
• Isolated network environments:
The control networks do not always require connectivities to the Internet even though introducing IP. It is the user’s choice whether to connect
to the Internet. Hence, functions introduced into
them have to work well under an isolated network
environment.
• Private naming system and private name space:
Information of the control networks, not only thetraﬃc but also device’s name, has to be conﬁdential, because the information can help to indicate
corporate activities, e.g. the capability of plants.
Hence, the naming system should be closed to the
public if operators desire. It is also important not∗∗∗∗∗

http://www.echelon.com/about/press/2003/echelon_
mori.htm

IEICE TRANS. ??, VOL.Exx–??, NO.xx XXXX 200x

2

to force a device’s identity to be global unique ifmost of the devices should not be accessed fromoutside. For the above two reasons, DNS is not anappropriate naming system for them.
We have proposed a model [7], which intends tosolves the above issues while satisfying the above restrictions when introducing IP into the control networks. It is important for them to inherit existing property when introducing new functions because they havelarge property, e.g. speciﬁcation, operational knowledge and applications. This is the reason the model
is a framework whose functions are addressed to either
below the application layer or the middle-ware insteadof inventing new control network protocols.
In this paper, we show the practicability of themodel by implementing it experimentally. This paper
shows an overview of the model in Section 2, detailsof the model in Section 3, the implemented system in
Section 4, considerations through implementation in
Section 5, related work in Section 6 and further study
items in Section 7.
2.

Proposed Model

2.1 Network Security
The authors have already studied a security mechanism[6] which can satisfy the restrictions described in Section 1. We will use this mechanism in our proposedmodel. The following are the features of the security
mechanism.
• This mechanism provides end-to-end security.
Most control networks rely on a ﬁrewall model
which assumes speciﬁc network topology. However, end-to-end security will be necessary because
wireless technology and nomadic devices break theﬁrewall model.
• Communication is protected by IPsec [8] which
provides IP packets with conﬁdentiality, integrity
and authentication with the other end. IPsec is
useful because its enforcement is independent fromapplications and sharable among them. IPsec isapplicable to small embedded devices due to notusing public key cryptography.
• It is important for IPsec to share a secret, whichis called IPsec SA (Security Association), between
both ends. Key exchange protocols will be important if running IPsec on small embedded devices
because these devices do not have a powerful userinterface like a PC, which makes manual keying
diﬃcult. The security mechanism uses not IKE(the Internet Key Exchange) [9] but KINK (Kerberized Internet Negotiation of Keys) [10] for the
key exchange protocol. IKE is the most popular
key exchange protocol for IPsec. However, it is
not suited to small embedded devices because theDiﬃe-Hellman key exchange is mandatory. KINK
can work well on small embedded devices because
KINK is based upon Kerberos † [11], where publickey cryptography is not mandated.
• In the security mechanism, a node’s identity is in
the manner of Kerberos, i.e. a principal-id, which
is a combination of a realm name and a principal
name.

2.2

Auto-conﬁguration using a Directory Service

To simplify the conﬁguration process, the model provides the device’s application layer with an autoconﬁguration mechanism. The basic ideas of the autoconﬁguration are 1) to minimize pre-installed information in a device, and 2) to acquire most informationfrom servers located in networks. IP address conﬁgurations are beyond the scope of the model. It canbe done by DHCP (Dynamic Host Conﬁguration Protocol) in IPv4 or RFC2462 in IPv6, with which themodel can be combined. The auto-conﬁguration requires not only name/address resolution like DNS but
also general data handling, e.g. searching, getting andupdating data. We introduce our own directory service
named PS (Property Server) [12]. The following are
the features of PS.
• It is not a prerequisite condition for PS to connect
to the Internet because PS does not require global
tree structures like DNS.
• PS maintains a device’s attributes as metadata ofthe device’s identity. A typical example is that
an IP address IPF OO is an attribute value of an
attribute type AT T RIP address , and the attribute,i.e. the type and the value, belongs to a device’s
identity F OO as metadata.
• PS supports two types of transactions, i.e. PUTand GET. PUT sets/updates attributes in PS.
GET acquires attributes from PS. Any requestof transaction has search conditions which designate attributes to be aﬀected. For example, identity/IP address resolution is done by GET transaction, where search conditions is the value of
AT T RIP address belonging to the identity F OO,
which returns IP address(es) IPF OO .
• PS’s protocol uses XML for the future extension.
• In the proposed model, every node belonging toa system has to use the security mechanism described in Section 2.1. Illegal access to PS fromoutside can be prohibited with IPsec security policy simply. An access control list can be introduced
into PS if accurate restrictions are required.
†

Kerberos is a trademark of the Massachusetts Instituteof Technology (MIT).

OKABE et al.: IMPLEMENTING A SECURE AUTONOMOUS BOOTSTRAP MECHANISM FOR CONTROL NETWORKS

3

Shared key KX

2.3

Bootstrap Sequence using the Chain of Trust

Device X

DHCP server

Chain of trust

NTP serverHence, the minimum information with which a device has to be pre-installed is a principal-id and a key
shared with KDC, i.e. a secret key of Kerberos. Other
information can be acquired from PS.
2.4

Device-to-Device Communication

In control networks, communication is occupied by control messages and notiﬁcation messages between devices, e.g. controllers, sensors and actuators. Hence,
devices have to discover trusted peers, then to exchange
messages with them under secure channels. The Chainof Trust can be applied in that case.
1. Devices search their peers using PS because they
have already know trusted PS. (see Section 2.3).
2. Devices should trust peers which trusted PS provides. The communication is protected by IPsec.

B) AdjustingFig.2

the clockFig.3C) Authenticating KDCD) Discovering PS

Fig.4

E) Registering own info. and getting boot info.
Fig.5
F) Discovering Device YG) Device-to-device comm.

Fig. 1
Device X

Messages of the proposed model
DHCP server

DHCP_REQ

DHCP_REP- KDC's realm name & IP address- PS service's principal-id- NTP server's IP address

Discovered KDC

Fig. 2KDC Discovery

prevent replay attacks. Second, X authenticates
KDC, which X learned with DHCP, through verifying a returned packet. TGT (Ticket Granting
Ticket) in the packet is necessary for subsequent
Kerberos services.
NTP server

Device X

KDC

NTP_REQ
Adjusted the clock

Authenticated KDC

NTP_REPKRB_AS_REQ
KRB_AS_REP- TGT(X)

Fig. 3

3.

Device Y

Fig.6

Dev-to-dev comm.

1. Devices can trust Kerberos server KDC (Key Distribution Center) by sharing a key. It is a prerequisite condition of Kerberos.
2. Devices should trust PS which trusted KDC shows.
3. Devices register their own information, e.g. a
principal-id and IP address(es), to trusted PS. The
information will be used for discovering peers (seeSection 2.4).
4. Devices should trust data which trusted PS provides. Then devices can complete the sequence.
The communication is protected by IPsec.

Bootstrap seq.

A) Advertising info. of KDC & NTP

When considering secure auto-conﬁguration, devices
have to discover a trusted PS, then exchange data withPS under secure communication channels. The following bootstrap sequence, which we call the Chain ofTrust, satisﬁes the above requirements.

PS server

KDC

Authenticating KDC

Details of the Model

Figure 1 shows the bootstrap sequence and the deviceto-device communication using the chain of trust. Details of each function is shown in Figure 2 throughFigure 6.
1. KDC Discovery (KDCD):
DHCP server(s) advertise KDC related information, e.g. KDC’s IP address(es) and realm name(s)where KDC oﬀers authentication services and NTP
related information, e.g. NTP server’s IP address(es), (see Figure 2).
2. Authenticating KDC:
Device X needs to authenticate KDC advertised
by DHCP server (see Figure 3). First, X adjusts
its clock with NTP server because Kerberos requires that every device synchronize its clock to

3. PS Discovery (PSD):
Device X acquires PS’s information from KDC (seeFigure 4). X shows its principal-id to KDC. Then
KDC returns PS’s information, i.e. PS’s principalid and IP address(es).
X has to acquire a service ticket for PSD, e.g.
TICKET(PSD), prior to the above procedures.
KRB PRIV messages, which need a service ticket,
are used for protecting PSD because IPsec/KINK
cannot be used at this moment.
4. Booting up:
Device X registers its own information to PS which
is used for device discovery, and acquires its bootdata from PS. Then, the bootstrap sequence iscompleted (see Figure 5).
First, X acquires a service ticket for KINK with

IEICE TRANS. ??, VOL.Exx–??, NO.xx XXXX 200x

4
Device X

PSD readyKDC

KRB_TGS_REP- TICKET(PSD)
PSD_REQ- X's principal-id

Discovered PS

Device X

KRB_TGS_REQ for PSD- TGT(X)
Protected by
KRB_PRIV
w/ TICKET(PSD)

Discovered Y

KINK ready

PS Discovery

KDC

PS server

KRB_TGS_REQ for KINK w/ PS- TGT(X)KINK ready

KRB_TGS_REP- TICKET(KINK w/ PS)
KINK_CREATE- IPsec SA & TICKET(KINK w/ PS)

IPsec readyFig. 6

Device-to-device communication

Table 1
H/W

Protected
by IPsec

OS, IP
IPsec
Kerberos
KINK

The speciﬁcations of the device

H8/3029@20MHz, Crypto H/W@20MHz(3DES,MD5)
Toppers FI4 w/ Original IP stack
ESP (3DES-CBC,HMAC-MD5)
Original code based RFC4120(etype:des-cbc-md5)
Original code based RFC4430

Booting up

5. Device-to-device communication:
Device X can discover device Y using PS, i.e.
device discovery, then starts the device-to-device
communication with Y (see Figure 6).
First, X discovers Y through PS. A typical example
is that X resolves Y’s IP address from Y’s identity
like DNS. IPsec between X and PS has alreadybeen established at the bootstrap sequence. Second, X acquires a service ticket for KINK with Y,
e.g. TICKET(KINK w/ Y), from KDC. Third,
IPsec is established between X and Y after exchanging KINK messages. Then the devices can
exchange application messages which are protectedby IPsec.
4.

Protected by IPsec

ity, i.e. object code size and performance, experimentally. Table 1 shows the speciﬁcations of an experimentally implemented device, whose CPU is H8/3029(Renesas Technology Corp.), which has cryptographic
hardware in a Xilinx’s FPGA. Renesas’s H8 family is
a popular low-end CPU in Japan. Table 2 shows the
speciﬁcations of servers which were used for the system.

PS_ACK- X's booting data

Fig. 5

KINK_REPLY- IPsec SA

App

PS_ACK

Booted up

Protected by IPsec

KRB_TGS_REP- TICKET(KINK w/ Y)

App

Protected
by IPsec
PS_PUT: my IP address- My info (X's principal-id & IP address)

PS_GET: my booting data?
- My info (X's principal-id)

PS_ACK- Y's IP address

IPsec ready

KINK_REPLY- IPsec SA

Registered X's IP info

Device Y

KINK_CREATE- IPsec SA & TICKET(KINK w/ Y)

PS, e.g. TICKET(KINK w/ PS), from KDC. Second, IPsec is established between X and PS after
exchanging KINK messages. Third, X registers its
own information, e.g. a principal-id and IP address(es), which other devices or servers can use
for discovering. Fourth, X acquires its boot data.
Then X completes the bootstrap sequence.
Device X

KDC

KRB_TGS_REQ for KINK w/ Y
- TGT(X)

PSD_REP- PS's principal-id & IP address

Fig. 4PS server

PS_GET: Y's IP address from name?
- My info (X's principal-id)- Y's principal-id

Implemented System

We implemented the model to examine its practicabil-

Table 2
DHCP
NTP, KDC

PS

4.1

The speciﬁcations of the servers
CPU:pentium-III@1.2GHz,
MEM:128MB, OS:freebsd4.10R
CPU:pentium-III@750Mhz,
MEM:896MB, OS:linux2.6.8,
Kerberos:Heimdal-0.6.2, KINK:racoon2
CPU:celeron@1.7GHz, MEM:1GB,
OS:linux2.6.8.1

Object Code Size

Table 3 shows the code size of the device. The total size
will be about 30K bytes greater if the cryptography, i.e.
3DES and MD5, is implemented by software instead of
hardware.

OKABE et al.: IMPLEMENTING A SECURE AUTONOMOUS BOOTSTRAP MECHANISM FOR CONTROL NETWORKS

5
Table 3

Object code size of the device (K bytes)

ModuleOS
IP (v4/v6)
IPsec

Size
64
132
8

ModuleKerberos
KINK
CryptoApp
total

Table 5

Size
25
20
7
16
272

Processing time of the sequences on the device (msec)w/

Bootstrap
Device-to-Device

511 (282)
165 (125)

Table 6

IPsec ESP

Performance of the Bootstrap Sequence

Table 4 shows the processing time of each function
on the device, whose conditions are with and without
cryptographic hardware. The values without parentheses mean net processing times, and the values in parentheses mean waiting times from sending a request til
receiving a reply. KINKI and KINKR mean the processing of KINK initiator and responder. PSP U T,IP sec
means PS’s PUT transaction which is for registering
the device’s IP address. PSGET,IP sec means PS’s GETtransaction which is for getting the device’s boot data
(512bytes). Both transactions include the overhead of
IPsec ESP. The waiting times of KINKI , i.e. the values
in parentheses, are varied because they depend upon
the performance of a peer. The waiting time of 112
msec occurs where a device initiates KINK with PS.
The device with and without cryptographic hardware
make a kink initiator wait for 73 msec and 93 msec respectively. Kerbeeros related performance, i.e. TGT,TGS, PSD, KINKI and KINKR , is improved and about
ﬁve times faster at the greatest than the previous prototype.
Those values exclude the processing time of IP address conﬁgurations, i.e. DHCP in IPv4 or RFC2462
in IPv6, and L2 address resolution, i.e. ARP (Address
Resolution Protocol) in IPv4 or ND (Neighbor Discovery) in IPv6.
Table 4

Processing time of each function on the device (msec)

crypto H/W
KDCD
NTP
TGT
TGS
PSDKRB P RIV
KINKI
KINKR
PSP U T,IP sec
PSGET,IP secw/
59 (0.5)
58 (0.5)
26 (34)49 (35)114 (35)65 (112 or 73)
73 (0)
40 (13)51 (17)w/o
59 (0.5)
58 (0.5)
74 (34)178 (35)318 (35)
81 (112 or 93)
93 (0)
164 (13)362 (17)

4.3

73

93

w/

w/o

4.8µsec/byte

300µsec/byte

Performance of the Device-to-Device Communication

As described in Section 2.4, the device-to-device communication has the overhead (see F through G of Figure
1 or Figure 6 for details). If the device is an initiator of
the communication, the overhead is PSGET,IP sec , TGS
and KINKI . If the device is a responder of the communication, it is only KINKR . Once IPsec is establishedbetween devices, the performance of IPsec is one of the
major factors.
The overhead of the sequence and IPsec are shownin Table 5 and Table 6. The values without parentheses mean net processing times and the values in parentheses mean waiting times. The throughput of IPsec
ESP inbound is omitted because both performances arenearly the same.
5.

Considerations

5.1

Object Code Size

Object code size is improved from the previous prototype [13], i.e. from 419K bytes to 272K bytes. Kerberos related implementations(Kerberos and KINK)
contributes the improvement. The previous implementation was ported from MIT implementation whereas
the current one is our original code which simplify program of encoding/decoding messages, especially ASN.1.
To reduce the current code, it is necessary to shrink theIP part which occupies about 50% of the entire code.
Hardwired functions, such as oﬀ-load engine, may contribute the code size. It can be a further study item toshrink the object code size.
5.2

The bootstrap sequence described in Section 2.3
requires the following functions: KDCD, NTP, TGT,
two TGSs, PSDKRB P RIV , KINKI , PSP U T,IP sec and
PSGET,IP sec (see A through E of Fiture 1 or Figure 2 through Figure 5 for details). the processing
time of the sequence is shown in 5 The values withoutparentheses mean net processing times and the values
in parentheses mean waiting times.

1472 (282)621 (145)

Responderw/
w/oProcessing time of IPsec on the device

crypto H/W

4.2

Initiator
w/ocrypto H/W

Performance of the Bootstrap Sequence

The sequence takes 793 msec or 1754 msec with or without cryptographic hardware (see Table 5). It will usually take one or several days to start the entire system if
the system is a large one due to starting subsystem bysubsystem for making sure. If assuming to start a system described in Section 1 with device-by-device manner, i.e. seventeen thousand devices, within 24 hours,

IEICE TRANS. ??, VOL.Exx–??, NO.xx XXXX 200x

6

every device will have to start within 5 seconds on average. The actual margin is longer than the above time
because of starting a system in a subsystem-by subsystem manner instead of device-by-device usually. Hence,the performances of the sequence can be acceptable.
We may have to consider for burst accesses toservers if the system has a large number of devices.
For the device side, randomly delayed bootstrap can
be a solution. However, the necessity and the validity
are future study items. For the server side, redundancy
can be a solution, i.e. the redundancies of KDCs andPSs. It is not diﬃcult to make KDC redundant [14].
But it is a further study item for PS.
5.3

Performance of Device-to-Device Communication

The overhead of the initiator takes 290 msec or 766
msec with or without cryptographic hardware (see Table 5). The overhead happens when both the device
starts and the lifetime of Kerberos’s tickets or IPsec
SAs is expired. The former case can be acceptable withthe reasons in Section 5.2. The latter case should beconsidered because the response time of control network systems should usually be on the hundred microsecond order. However, the overhead can be acceptable if the lifetimes are long enough, e.g. days, weeks
or months, and are tuned operationally. The overheadof the responder can also be acceptable because it isshorter than the initiator’s. Another possible way is
to introduce priority into the IP packet processing ofa device. For example, the overhead described above
will have less impact if the IP stack of the device has
fast-path and slow-path, and application packets are
assigned to fast-path and other packets including Kerberos and KINK are assigned to slow-path. This canbe a further study item.
As an example of IPsec’s throughput, the processing time for 1024-byte payload takes 5 msec or 307 msec
with or without cryptographic hardware (see Table 6).
Considering the response time, i.e. the hundred microsecond order, the former case is fast enough, but thelatter is not. The performance can be improved with
AES instead of 3DES if the device cannot introduce
cryptographic hardware.
5.4

NTP Server

Kerberos assumes that the clock of each device is adjusted to the clock of the KDC. It is used for preventing
from some replay attacks. This is why our proposedmodel uses NTP server. However, for example, a malicious NTP server can advertise bogus time to devices.
If a diﬀerence between the clocks of the KDC and thedevice is more than the allowable clock skew, the KDC
will reject any request from the device, then the bootstrap sequence will be failed.
[15] showed an extension that was able to relax

the requirement of the time synchronization. The extension has already included into the speciﬁcations ofboth Kerberos and KINK. If the diﬀerence is greaterthan the skew limit, the KDC returns an error message
that includes the diﬀerence. Consequently, the device
stores the diﬀerence, and uses it to adjust the time toprocess further messages. Hence, the device can ﬁnish
its bootstrap sequence.
If a system requires a trusted NTP server thedevice-to-device communication can be used additionally. First, the NTP server implements the proposedmodel described in Section 2. Second, the NTP server
starts its service before any device starts. Third, a device can ﬁnd the NTP server from PS, then can synchronize its clock again under security of Kerberos, KINK
and IPsec after the device completes its bootstrap sequence.
6.

Related Work

There are models of device’s auto-conﬁguration. Thissection shows diﬀerences between our model and others.
Jini † has the following features: 1) Engaged distributed object technology, e.g. RMI, CORBA, SOAP,
can distribute service entities over networks. 2) Servers
named Lookup Service manage objects named Proxy.
A client has to load an appropriate Proxy when using a
distributed service remotely. 3) Lookup Service, which
is necessary for registering a Proxy by a service entityand for loading a Proxy by a client, can be discovered
on demand with IP multicast. Jini may be suited tothe purpose at which our model aims since both models can provide any required data to devices. The earlyversion of Jini had security issues, e.g. [16], then Jiniv2 [17] enhanced it. However, it is diﬃcult to compare the actual security mechanism of Jini with thatof our model because it is hidden away from the speciﬁcation by Java Class. Hence, Jini’s applicability to
devices cannot be identiﬁed. Jini v2 introduced Trust
Veriﬁer by which a client can verity the integrity of aloaded Proxy. The idea of Trust Veriﬁer can be useful for our model because our model can also provide
program code to devices remotely.
SLP (Service Location Protocol) [18] provides locations of services as URLs. SLP servers, i.e. Service
Agent and Directory Agent, can be discovered on demand with IP multicast. Cache servers named Directory Agent contribute scalability to SLP. Please notethat SLP does not have any service entity itself. Ourmodel has a service entity named PS which can provide
any required data, e.g. application program and data,
under a secure environment. Hence, to examine if SLP
can be used in our model is appropriate rather than tocompare both models equally. SLP may be applicable
to KDCD instead of DHCP.
†

Jini is a trademark of Sun Microsystems, Inc.

OKABE et al.: IMPLEMENTING A SECURE AUTONOMOUS BOOTSTRAP MECHANISM FOR CONTROL NETWORKS

7

UPnP †† (Universal Plug and Play) [19] uses
SOAP (Simple Object Access Protocol), HTTP and
TCP for control messages and GENA (General Event
Notiﬁcation Architecture), HTTP and TCP for notiﬁcation messages whereas existing control networks usually use UDP for those purposes. This means that they
will have to be changed if introducing UPnP. Hence, thegoal of UPnP is diﬀerent from our model because oneof our goals is to minimize the impact on them whenintroducing an auto-conﬁguration mechanism. Publickey cryptography is mandated for UPnP. So UPnP’s
applicability to devices is also diﬀerent from our model.
7.

Further Study Items

7.1

Sharing Mechanism of a Kerberos’s Secret Key

Kerberos assumes that each device shares their Kerberos’s secret keys with KDC. However it is importantfor control networks how to share a secret key between
a device and KDC because there can be a huge numberof devices whose user interfaces are limited in a system. There are two approaches to share a secret key.
One is to ship a device with a secret key. The user
reads the secret key, then sets it to KDC. The other is
on-site installation. The user creates and installs a secret key into the device. However, we have to consider
those approaches further because of their insuﬃciency
as described below.
For the former approach, it assumes that KDC has
a pair of a public key and a private key, and KDC is
speciﬁed before a device is shipped. Then it will bepossible to ship the device with a Kerberos’s secretkey and a KDC’s public key. Consequently, the device can provide the secret key which is protected with
the KDC’s public key. For example, this technique may
be suited to small embedded devices mentioned in Section 1 if using low exponent RSA because the operations of encryption and veriﬁcation are cheap while theoperations of decryption and signature are expensive.
However, this technique has the following restrictions.
1) A device requires a communication channel to readthe secret key encrypted with the KDC’s public key. 2)
The channel is out-of-band from the proposed model
described in Section 2. 3) Readout is done with deviceby-device manner. 4) A device has the KDC’s publickey when shipping. Please note that the secret key canbe updated with Kerberos’s administration command,e.g. kpasswd, remotely after ﬁnishing sharing the secret key.
For the latter approach, [20] proposed resurrecting
duckling security policy model where a weak device canestablish a master-slave relationship with other device
securely under ad-hoc environment. In ad-hoc environ††

UPnP is a trademark of the UPnP Implementers Corporation.

ment, a device have to assume the absence of an online server. Figure 7 shows a summary of resurrecting
duckling security policy model. A device called a duckling has two states, i.e. imprint-able and imprinted,
and the initial state is imprint-able. When other device
called a mother duck sets a shared key called an ignition key, the duckling changes the state to imprinted,
then obeys the mother duck. When the duckling deletes
the ignition key by the mother duck ’s order, the duckling changes the state to imprint-able, then is ready toaccept a new mother duck. If a writer which installs a
Kerberos’s secret key into a device is a mother duck andif a device where the secret key is installed is a duckling,
the Kerberos’s secret key will be installed into the device under ad-hoc environment such as an installationﬁeld. It may be better to separate the Kerberos’s secret key from the ignition key. However, this technique
has the following restrictions. 1) A device has a communication channel with a writer. The channel have toprovide conﬁdentiality and integrity by itself, e.g. electrical contact rather than wireless, because an ignition
key from a mother duck to a duckling is plain text (see[20] for details). 2) The channel is out-of-band from the
proposed model described in Section 2. 3) Installation
is done with device-by-device manner.

a mother duck (a master)
installing an ignition key

issuing any command

an ignition key installed
imprint-able(accepting any master)start

Fig. 77.2

imprinted(obeying a master)

executing RESET command,then deleting an ignition key

a duckling (a slave)

Resurrecting duckling security policy model

Kerberos’s Inter-realm Operation

It is common for management to divide a large system into small manageable domains, which are called
realms in the manner of Kerberos. In the case of Kerberos, inter-realm is the technique to federate operational realms by sharing a secret between KDCs (seeFigure 8). However, inter-realm has issues when being
applied to control networks as follows.
• inter-realm costs a device when the device speaks
to another device which belongs to a diﬀerent
realm (see Figure 9). 1) The device has to traverse realms until it reaches the destined realm. 2)
The device has to ﬁnd a path to traverse realms.
It is the device’s responsibility to ﬁnd the next hop

IEICE TRANS. ??, VOL.Exx–??, NO.xx XXXX 200x

8

KDCC

sharing a secret KBC

sharing a secret KCD

devices

KDCB

KDCD

realm C

devices

devicesrealm B

realm D

sharing a secret KAB
KDCA
devicessharing a secret KDE

Traversing

X

KDCE

Y

devicesrealm A

realm E

Fig. 8An example of inter-realm

inter-realm relationship

KDCA

Cross-realm TGTAB
device X ofrealm A

KDCB

Cross-realm TGTBC
Cross-realm TGTDEKDCD

TICKETXY

Exchanging KINK
with TICKETXY

Fig. 9KDCE
device Y ofrealm E

which is intended to solve the issues, i.e. security andconﬁguration complexity, while satisfying the restrictions, i.e. small embedded devices, isolated networks,
private name space/naming system and inheriting theproperty. Secure bootstrap sequence and device-todevice communication using the chain of trust are thepoints of the model.
There are several further study items. The ﬁrst is
to shrink the IP protocol stack. The object code sizeof the prototype device achieves 270K bytes. It will benecessary to shrink the IP protocol stack if smaller codeis required. The second is priority processing in the IP
protocol stack. The device’s performance of the bootstrap sequence and device-to-device communication canbe acceptable if the lifetimes of Kerberos’s ticket and
IPsec SAs are turned operationally, and if cryptography
is implemented reasonably, i.e. cryptographic hardware
or faster algorithm than 3DES in software. However theoverheads can not be zero. Hence, priority processingin the IP protocol stack, such as fast-path and slowpath, may reduce inﬂuence of the overheads. The thirdis redundancy of the servers, i.e. KDC and PS. The
fourth is the mechanism of sharing a Kerberos’s secretkey between a devince and KDC. The ﬁfth is to optimize inter-realm operation for small embedded devices.

An example of traversing realms
Referencesof KDC. 3) The device has to acquire special tickets, which are called cross-realm TGT, to traverse
realms. The number of tickets to be acquired arein proportion to the number of realms to be traversed. These can be expensive for small embedded devices.
• Host centric fashion mentioned above can be acause of inconsistency if a system has a huge number of and a variety of devices. For example, it isthe device’s responsibility to ﬁnd the next hop of
KDC. However, compatibility of device’s behavior
about ﬁnding path is not obvious because the speciﬁcation of Kerberos does not deﬁne about traversing realms precisely. Consequently, the device’s
behavior depends upon its implementation.
• Inter-realm is formed by chaining KDCs. The device will be unable to traverse KDCs even if one of
the intermediate KDCs is unavailable.
PKINIT [21], PKCROSS [22] † and KDC referrals[23] which are under discussion in IETF may be able tosolve some of the above issues.
8.

Conclusion

Through implementing the model experimentally, thispaper shows the practicability of our proposed model†[22] has already expired. However, PKCROSS can revive after PKINIT is completed because PKCROSS depends
upon PKINIT.

[1] Fieldbus Foundation, FF-581-1.3, FOUNDATION Speciﬁcation: System Architecture, 2003.
[2] PROFIBUS International, IEC 61158, Digital Data Communication for Measurement and Control - Fieldbus for Use
in Industrial Control Systems, 1999.
[3] MODBUS.ORG, Modbus Application protocol V1.0, 2002.
[4] ASHRAE, ANSI/ASHRAE Standard 135-1995, BACnet A
Data Communication Protocol for Building Automation
and Control Networks, 1995.
[5] N. Okabe, “Issues of Control Networks When Introducing
IP,” The 2005 Symposium on Applications and the Internet
Workshops (SAINTWKSP 2005), Jan. 2005.
[6] N. Okabe, S. Sakane, K. Miyazawa, K. Kamada, A. Inoue,and M. Ishiyama, “Security Architecture for Control Networks using IPsec and KINK,” The IEICE Transaction on
Communications, vol.J88-B, pp.1910–1921, Nov. 2005.
[7] A. Inoue, M. Ishiyama, K. Kamada, S. Sakane, and N. Okabe, “A Secured Autonomous Bootstrap Mechanism forControl Networks,” Annual Review of Communications,
Volume 57, International Engineering Consortium, Nov.
2004.
[8] S. Kent and R. Atkinson, “Security Architecture for theInternet Protocol.” RFC2401, 1998.
[9] D. Harkins and D. Carrel, “The Internet Key Exchange(IKE).” RFC2409, Nov. 1998.
[10] S. Sakane, K. Kamada, M. Thomas, and J. Vihuber, “Kerberized Internet Negotiation of Keys (KINK).” RFC4430,
March 2006.
[11] C. Neuman, S. Hartman, and K. Raeburn, “The Kerberos Network Authentication Service (V5).” RFC4120,
July 2005.
[12] K. Kubo, J. Murakami, and T. Hoshi, “Hybrid Peer-to-Peer
System for Network Monitoring of Field Devices,” SICE
Annual Conference 2003, Aug. 2003.

OKABE et al.: IMPLEMENTING A SECURE AUTONOMOUS BOOTSTRAP MECHANISM FOR CONTROL NETWORKS

9[13] N. Okabe, S. Sakane, M. Ishiyama, A. Inoue, and H. Esaki,“A Prototype of a Secure Autonomous Bootstrap Mechanism for Control Networks,” The 2006 Symposium on Applications and the Internet (SAINT 2006), Jan. 2006.
[14] C. Kaufman, R. Perlman, and M. Speciner, Network Security: Private Communication in a Public World, ch. 10,
Prentice Hall, 1995.
[15] D. Davis, D.E. Green, and T. Ts’o, “Kerberos with clocks
adrift: History, protocols, and implementation,” USENIX
Computing Systems, Jan. 1996.
[16] P. Eronen and P. Nikander, “Decentralized Jini Security,” Network and Distributed System Security Symposium(NDSS01), Feb. 2001.
[17] Sun Microsystems, Inc., Jini Speciﬁcations Archive - v2.1,
Oct. 2005.
[18] E. Guttman, J. Veizades, and M. Day, “Service Location
Protocol, Version 2.” RFC2608, June 1999.
[19] UPnP Forum, UPnP Device Architecture 1.0, Version 1.0.1,
2003.
[20] F. Stajano and R. Anderson, “The Resurrecting Duckling:
Security Issues for Ad-hoc Wireless Networks,” Security
Protocols, 7th International Workshop Proceedings, LNCS,
pp.172–194, 1999.
[21] L. Zhu and B. Tung, “Public Key Cryptography for Initial Authentication in Kerberos.” draft-ietf-cat-kerberospk-init-34, Feb. 2006.
[22] M. Hur, B. Tung, T. Ryutov, C. Neuman, A. Medvinsky,
G. Tsudik, and B. Sommerfeld, “Public Key Cryptography for Cross-Realm Authentication in Kerberos.” draftietf-cat-kerberos-pk-cross-08, Nov. 2001.
[23] L. Zhu and K. Jaganathan, “Generating KDC Referrals
to Locate Kerberos Realms.” draft-ietf-krb-wg-kerberosreferrals-07, March 2006.