Securing inter-cluster communication in Personal

Networks
Assed Jehangir

Sonia M. Heemstra de Groot

Faculty of Electrical Engineering,

Mathematics and Computer Science
University of Twente
Enschede, The Netherlands
jehangira@cs.utwente.nl

Twente Institute for Wireless and

Mobile Communication, and
Delft University of Technology
The Netherlands
Sonia.Heemstra.de.Groot@ti-wmc.nl

Abstract A Personal Network (PN) is a new type of an overlay

network consisting of all personal devices belonging to a user, be
they remote or local. Such continuous and seamless connectivity
of all personal devices belonging to a user enables the
development of new applications and improved services. A
Personal Network is an intelligent and user-centric network that
assists the user in an unobtrusive way.

extended to include other devices belonging to the user, both in

his vicinity and those at remote locations. PNs are composed of
heterogeneous personal devices and are dynamic entities due to
the mobile nature of their constituents. Figure 1 outlines the
network layer PN architecture envisioned in the QoS for
PN@Home project [2].

In this paper we investigate means of securing communication

between geographically distributed Personal Network clusters.
Clusters are ad-hoc networks of co-located personal devices.
Using Virtual Private Network (VPN) technology enables the
creation of secure tunnels between gateways of different clusters,
making it possible to transfer all types of intra-cluster traffic
securely, over the insecure public network.
The ad-hoc nature of clusters when coupled with the mobile and
resource constrained nature of many personal devices makes
enforcing security a challenging task. We investigate the
suitability of existing VPN technologies to secure inter-cluster
communication. Our contribution is in identifying aspects of
existing solutions that render them unsuitable in their current
form for constrained personal devices. We propose a modified
framework based on IPSec and KINK that better satisfies the
requirements of personal devices by reducing the cost of security.
Keywords- Personal Network; inter-cluster communication;
VPN; SSL; IPSec; KINK.

I.

INTRODUCTION

The new trend in consumer electronics is to embed gadgets

with wireless transceivers. Such devices can become more
useful to users by communicating and cooperating with each
other. Imagine using digital pens that transfer notes to a central
server for later review, watches that announce caller IDs of
incoming calls, health monitoring devices that can dial for help
in emergencies and cameras that upload images automatically
to websites for mobile blogging. Now imagine the increased
possibilities if the user has seamless access to all his devices
and not only those that he is carrying with him. Such is the
vision of a Personal Network (PN) [1], a paradigm that utilizes
pervasive computing to provide its users with new and
improved services. A PN comprises a core consisting of a
Personal Area Network (PAN) which can be transparently

Figure 1. An instance of a Personal Network (PN)

Personal devices initially organize themselves in the form

of clusters. Clusters are ad-hoc networks of personal devices
that can communicate amongst each other without using any
non-personal devices. One can think of a cluster as a secured
network of co-located personal devices. Forming clusters
facilitates in securing multi-hop communication and access to
the common pool of resources. The otherwise isolated clusters
are interconnected using secure dynamic tunnels, created
between gateway devices, resulting in a network of personal
devices that are geographically dispersed.
II.

SECURING INTER CLUSTER COMMUNICATION

When designing mechanisms to secure communication

between PN clusters it is a logical step to investigate the use of
Virtual Private Network (VPN) technologies. VPNs refer to
creating semi-permanent cryptographic tunnels over public

networks between two private machines or networks, to pass

arbitrary traffic. The benefit of using a cluster-to-cluster tunnel
and not application level security such as an SSL gateway
means that we ensure the exact same connectivity and privacy
as on a typical local private network. VPNs have been designed
and used successfully for many years to connect remote offices
of companies over the Internet. We too would like to use public
networks (like the Internet) to coalesce geographically
distributed subnets (clusters) into a private network (Personal
Network). A VPN will allow us to create an encrypted tunnel
between two clusters enabling the secure exchange of a wide
range of traffic regardless of application or protocol.
In spite of the similarities, a Personal Network has some
important differences with a typical geographically distributed
corporate network. Firstly people, unlike corporations, are
mobile thus the clusters gateway devices should be able to
handle mobility. Secondly, and arguably more significantly,
there is considerable resource disparity between a mobile
personal gateway and a static corporate style gateway. Whereas
the former would resemble a small battery operated mobile
phone the latter would be more like a typical desktop computer
(or larger). Consequently, this paper investigates the different
VPN technologies available today and evaluates their usability
in securing communication between mobile resource
constrained personal devices.
With embedded devices such as biomedical sensors, wrist
watches, digital wristbands and belt computers conceivably
being part of a PN, there is really no minimum capability
criterion for potential PN devices. Such devices are constrained
in their energy, processing power, storage space and/or user
interface. Ultimately, without a minimum capability criterion
for constrained personal devices and the cost of including
public key cryptography for the single purpose of key
establishment, we have concluded that our security
mechanisms must only rely on lightweight symmetric
cryptography. Refer to Section III.B.1 for more details. For
clarification, public key cryptography is typically used to
establish the initial keying material that is later used by
symmetric cryptographic algorithms to secure the
communication. Even if public key cryptography were to be
feasible for a given set of PN devices, it has a much higher
energy footprint due to increased computational complexity
and transmission overhead. Using purely symmetric
cryptographic primitives will allow us to support a wider
variety of devices as cluster gateways by reducing the cost of
security.
This paper is organized as follows. In Section III we
consider the suitability of leading VPN solutions for securing
inter-cluster communication in Personal Networks. In Section
IV we analyze our chosen solution in depth and propose
changes that will make it more suitable in our context.
III.

EXISTING APPROACHES

The most well known and standardized means of creating a

secure tunnel is the Internet Protocol Security (IPSec) [3]
standard. IPSec is the IETF standard VPN technology defined
for the TCP/IP suite and is used to create a majority of
commercial VPNs found today. However IPSec is

overwhelmingly used with a Public Key Infrastructure (PKI)

requiring us to evaluate its suitability for Personal Networks.
In the last few years there has been a challenge to the
widespread implementation enjoyed by IPSec in the form of
Secure Socket Layer (SSL) based VPNs. SSL VPNs use the
highly mature and prevalent SSL/TLS libraries to handle the
tunnel creation and cryptographic elements necessary to create
a VPN. They are the only serious competitor to IPSec VPNs in
terms of functionality, scalability and flexibility. Next we
investigate the suitability of the two approaches given our
constraints.
A. SSL VPNs
One of the most well known is the free and open source
OpenVPN [4]. In terms of functionality it has the same site-tosite connection functionality found in IPSec VPNs. The
OpenVPN designers claim that because it operates in userspace (unlike IPSec which operates in kernel space) it increases
security and system stability. Furthermore because of reduced
configuration options and the fact that it runs in user space, it is
easier to install and configure.
Traditionally SSL based VPNs used TCP to tunnel packets;
however IP-over-TCP-over-TCP can create several latency
problems when packet loss occurs. This is because with TCP
encapsulated within TCP, we now have two flow control layers
that are working against each other in an attempt to get packets
resent. Therefore many SSL based VPNs found today (such as
OpenVPN) use UDP to tunnel packets instead of TCP.
One often touted advantage of SSL based VPNs is that they
are better at traversing Network Address Translators (NATs)
because IPSec with Authentication Header (AH) hashes the
source address as part of its authentication process and
therefore is unable to function behind NATs. However since
we are only considering IPSec in Encapsulating Security
Payload (ESP) mode we do not consider this a drawback as the
source address is no longer part of the packet integrity check.
One downside to SSL VPNs is in packet drop performance.
IPSec will inspect and drop packets at lower level in the
protocol stack than SSL which will process it more before
rejecting it. However this will only be an issue with Denial of
Service (DoS) attacks in high capacity usage scenarios. In most
cases it is not a problem.
However our primary reason for rejecting an OpenVPN
based solution is that it does not provide an alternative to using
asymmetric cryptography. OpenVPN requires a PKI (either
RSA challenge/response or DSA digital signature) to be used in
any meaningful way. Manually pre-distributing static keys is
not only un-scalable but also unsafe as it does not provide
Perfect Forward Secrecy (PFS) by automatically updating the
keys at regular intervals.
B. IPSec VPNs
The benefits of using IPSec include that as a standard it
enjoys widespread implementation and must be included in all
IPv6 implementations. Furthermore it provides a lot of
flexibility and configuration options for different situations,
notably in key management. Recall that we rejected OpenVPN

because its key management did not provide an alternative to

using asymmetric cryptography. Since the processing cost of
IPsec is overwhelmingly composed of processing required for
cryptography [5] we now look at some of these aspects in more
detail.
Once the initial keys are exchanged, the protection from
IPSec and SSL VPNs is similar as it depends on the specific
ciphers selected. Data passing through the virtual tunnel is kept
secure using symmetric cryptography, where both sides of the
tunnel share common keys. Symmetric encryption and message
digests use fast block ciphers so the security overhead once the
tunnel is created, is low. The primary challenge therefore is in
key distribution which typically relies on costly asymmetric
cryptography to get the common keys to both sides of the
tunnel.
Key management in IPSec is handled by the Internet Key
Exchange (IKE) protocol which requires two phases. Phase 1
called the IKE Security Association (SA) phase, establishes an
authenticated secure channel between the two communicating
peers. Phase 2 uses the secure channel established in phase 1 to
negotiate key material and security parameters for the IPSec
SA. The following are the three authentication methods
available to use with IKE phase 1:
Public Key
The exchange is protected by encrypting parameters
such as IDs and nonces with the senders private key
Digital Signature
The exchange is protected by signing a hash value over
IDs, nonces etc. using the senders private key
Pre-shared Key (PSK)
The exchange is protected by encrypting parameters
such as IDs and nonces using a symmetric key derived
by some out-of-band mechanism.
The first two are clearly based on asymmetric cryptography
and must be rejected based on our constraints. Unfortunately
upon closer examination of the IKE protocol it becomes clear
that PSK uses the Diffie-Hellman protocol in negotiating the
IKE SA and therefore also relies of asymmetric cryptography.
Furthermore many personal devices lack sufficiently powerful
user interfaces so manual keying is unpractical. When using
PSK, if the gateway devices are mobile their IP addresses
change so the proper shared key cannot be located. This
necessitates the use of what is called aggressive mode in
phase 1, where the ID is sent to the responder in clear text. Not
only does this open the system to clogging denial-of-service
attacks but also means that IDs are not kept confidential during
the exchange.
1) Cost of assymetric cryptography
Even though the IKE standard only requires RSA modular
exponentiation to be mandatory, we also considered the use of
the optional Elliptic Curve Cryptography (ECC) as a means of
reducing the cost of asymmetric cryptography. RSA has been
shown to be un-suitable for resource constrained devices [5][6]
but ECC is known to be more lightweight [6][7][8]. However

eventually we also rejected the use of ECC because its software

performance in low end processors is far from being
satisfactory [8][9] while hardware implementations are not cost
effective because they would only be used rarely (for initial key
establishment). For example, an ECC key exchange with an 8bit, 7.3828-MHz ATmega 128L processor (a MICA2 mote)
takes 35 seconds and requires 34k bytes of memory [6] when
done in software.
Energy consumption is also a prominent issue in battery
operated devices and affects their usability in the real world.
Energy is the scarcest resource in our system and our security
mechanisms must be frugal in their power consumption. Table
1 [10] summarizes the energy consumption of three common
cryptographic algorithms. We can see that AES being a
symmetric cipher incurs the same cost for both encryption and
decryption. For the other two, the first value represents the cost
of decryption and the second the cost of encryption.
TABLE I.

ENERGY CONSUMPTION OF THREE COMMON CRYPTOGRAPHIC

ALGORITHMS

Algorithm

Energy/op (HW)

Energy/op (SW)

AES (128b)

0.045 J

17.9 J

RSA (1024b)

2.41 / 0.37 J

546 / 16 J

ECC (163b)

0.66 / 1.1 J

134 / 196 J

Using specialized cryptographic hardware instead of the

general purpose CPU reduces the overall energy usage as well
as code size. It also allows the product designer to use a lower
power CPU since more of it will now be available to
applications rather than for communications. However we
already rejected hardware implementations of ECC because
they are not cost effective.
From Table 1 we see that symmetric cryptography requires
between 1 (SW) and 4 (HW) orders of magnitude less energy
than ECC. Not only is symmetric cryptography much cheaper
to implement in hardware than asymmetric cryptography (due
to much fewer number of gates [5]), it is also more cost
effective because symmetric cryptographic primitives are used
much more frequently. Moreover in future we may have even
weaker processors as the number of gadgets people own
increase, and the need to increase their battery life becomes
more essential. In the next section we look at a little known
alternative to IKE phase 1, known as KINK [11], which is
purely based on symmetric cryptography.
IV.

KERBERIZED INTERNET NEGOTIATION OF KEYS

The IETF Kerberized Internet Negotiation of Keys (KINK)

working group has created a protocol to facilitate centralized
key management for IPSec security based on the Kerberos
architecture [12], as an alternative to IKE phase 1. Kerberos
provides an efficient means of mutual authentication and replay
protection using a trusted third-party model based purely on
symmetric cryptography.
The performance goals of the KINK protocol are having a
low computational cost, low latency, and a small footprint. It
limits computational cost by avoiding the use of public key

cryptography and reduces latency by only using two messages

to establish the necessary security associations. Its limited
complexity versus IKEs necessity of using public key
cryptography means that it is more compatible with the
constrained devices typically found in PNs.
Since KINK uses Kerberos as the underlying authentication
mechanism, a KINK initiator needs to get a Kerberos ticket for
each responder before the actual key negotiations begin. This
would be a typical Kerberos exchange (depending on local
policy considerations) and is not part of the KINK
specification. The specification only defines the steps to follow
once the ticket is obtained. KINK uses a simple and lightweight
Command/Reply messages exchange for each of its Create,
Delete and Status message flows.
Once the two peers share a Kerberos session key it is used
to create the shared state necessary to run normal IKE phase 2
negotiations. As a result everything defined for IKE phase 2
(new group mode, quick mode, etc.) is supported by KINK.
The specification, now a proposed standard, is publicly
available and has already been implemented in racoon2, an
open source implementation of IPSec key management
protocols.
Figure 2 illustrates the system architecture based on the
KINK protocol. Since KINK is designed for communicating
entities within a centrally managed domain we see that the
initiator and responder belong to the same domain as the
Kerberos server. The server is able to issue tickets because it
maintains a database of secret keys, one for each device
belonging to the domain. This relationship is illustrated by the
dotted lines in the figure. In step 1, the initiator requests a ticket
from the Kerberos server corresponding to the responder. Once
the ticket is obtained, the initiator uses the Command/Reply
messages exchange (step 2) to derive the necessary IKE phase
2 parameters used to create the IPSec SAs.

them available when needed and do not need access to any

central entity. For clarification, note that a scheme based on
tickets is quite different from pre-distributing pair-wise keys
because the latter does not easily allow new devices to be
added to a pre-existing network since existing devices will not
have the new devices keys.
A. Personal TGS
Since the authority responsible for issuing tickets in a PN is
a personal device functioning as a Ticket Granting Server
(TGS), we call such a device a personal TGS. As part of our
model, each new device added to the PN must be personalized
before it can become part of the PN. Therefore we propose preloading gateway devices with the necessary tickets during
personalization so that they do not have to request them later
from the personal TGS. Automatically transferring tickets thus
does not constitute an additional burden for the user.
Device personalization is done in the imprinting phase
where the necessary keys and tickets are securely transferred to
the new component. The concept of imprinting was originally
proposed by Stajano and Anderson in [13] as part of their
resurrecting duckling security model. The imprinting process
results in the creation of a security association between two
devices that do not have a pre-existing relationship. This secure
association is built when the master device (called the mother)
imprints the slave device (called the duckling) by transferring a
secret key using physical contact (to ensure the authenticity and
confidentiality of information).
In our model each new PN component is imprinted with the
personal TGS before it can become part of the PN. Imprinting
will result in the secure transfer of a secret key (shared between
the new device and the personal TGS) and all necessary tickets
to the gateway device. The personal TGS is able to issue tickets
because it has secret keys (exchanged during the imprinting
phase) with all devices in the PN. After the completion of the
imprinting phase the imprinted gateway device is able to
authenticate with all other gateway devices using pre-loaded
tickets, thus not requiring online access to the personal TGS.
Since devices no longer need to request tickets from the
central entity before beginning the actual key negotiations with
their peers, this reduces tunnel setup latency and also energy
usage. However, such an approach would not be suitable for
large scale fixed networks with many users because such
networks require the flexibility to authorize temporary access
to services. Since all devices in a PN are owned by the same
user this functionality is not necessary.

Figure 2. KINK architecture

Unfortunately the KINK architecture as shown in Figure 2

does not fit in with our requirement of supporting mobile
personal devices. The dynamic nature of the Personal Network
means that online access to a central authority for
authentication can not be guaranteed. Therefore we propose
simple modifications to the KINK architecture that will allow
us to use it in an offline manner. Specifically, we propose a
mechanism for preloading tickets into devices so that they have

It is important to note that unlike a certificate, a given ticket

is only valid for authenticating with one specific device. This
requires pre-loading gateway devices with as many tickets as
there are gateway devices in the PN. Fortunately a typical PN
only has a handful of gateway capable devices. Moreover
recent advances in memory technology mean that storage costs
and dimensions have reduced substantially, for example, micro
SD cards - the size of a fingernail- allow storage of up to 4
GBs.
As of yet we have not proposed any modification to the
KINK implementation, but only to how tickets are made

available to it. However pre-loading tickets may require a

modified KINK message exchange because the relevant ticket
is not always available with the KINK initiator. Since new
gateway devices are only pre-loaded with tickets corresponding
to gateway devices that are already part of the PN, the
necessary ticket is always with the device added later to the
PN. Depending on the order that the two gateway devices were
added to the PN (i.e. imprinted), either the initiator or the
responder can be holding the ticket. In the former case, KINK
message exchange would proceed as usual. However, the latter
case would require an extra message to be exchanged whereby
the initiator would request the responder to begin
authentication. Figure 3 illustrated the modified KINK
architecture where the initiator does not hold the necessary
ticket. We see that the two authenticating peers do not need
access to the offline personal TGS in order to create an IPSec
SA. Furthermore, because Kerberos relies on time stamps for
authentication our modified KINK protocol should use
challenge/response authentication mechanism of the Needham
Schroeder protocol [14] instead, which is more suitable for
tickets that are valid for extended periods.

resource constrained devices typically found in Personal

Networks. Consequently we will be able to support a wide
variety of personal devices as cluster gateways. We have
proposed pre-deploying tickets into gateway devices during
imprinting thus making KINK more suitable for mobile ad-hoc
environments and reducing its latency and energy usage. The
main disadvantage of our proposal is in delayed device
revocation, but given the nature of Personal Networks where
devices have long term trust relationships we feel that this is
acceptable side-effect.
FUTURE WORK
We have already leveraged similar concepts for securing
intra-cluster communication and are working on a prototype for
a secure PN. In the future we would like to investigate
solutions based on using tickets to authenticate between
domains, i.e. for securing inter-PN communication.
ACKNOWLEDGMENT
This work was supported by the Dutch Ministry of
Economic Affairs under the Innovation Oriented Research
Program (IOP GenCom, QoS for Personal Networks @ Home)
and the Freeband PNP 2008 project.
REFERENCES
[1]

[2]
[3]
[4]
[5]

Figure 3. Modified KINK architecture suitable for PNs

The main disadvantage of our proposed modifications is

the difficulty of performing timely revocation in the absence of
an online personal TGS. As such our protocol has something in
common with signed certificates and solutions proposed for
them can be applied. If the personal TGS is not always online
but is nevertheless online at frequent intervals, we can use
routinely distributed revocation lists. In this approach the
personal TGS distributes updated revocation lists at regular
intervals to all gateway devices. Fortunately due to the long
term relationship of devices within a PN, revocation will only
be needed in cases where such a device is lost, sold or
compromised.
V.

CONCLUSIONS

In this paper we have proposed a framework for secure

inter-cluster communication in Personal Networks based on
IPSec and KINK. The limited complexity of our proposed
mechanism versus IKEs necessity of using public key
cryptography means that it is more compatible with the

[6]

[7]

[8]

[9]

[10]
[11]
[12]
[13]

I. G. Niemegeers and S. M. Heemstra de Groot, Research issues in adhoc

distributed
personal
networking,
Wireless
Personal
Communications, vol. 26, no. 2-3, pp. 149167, August 2003.
QoS
for
Personal
Networks
@
Home
project:
http://qos4pn.irctr.tudelft.nl/
S. Kent and R. Atkinson, Security Architecture for the Internet
Protocol, RFC 2401.
OpenVPN: http://openvpn.net/
N. Okabe, S. Sakane, et al, Security Architecture for Control Networks
using IPsec and KINK, International Symposium on Applications and
the Internet (SAINT05), Trento, Italy.
D. J. Malan, M. Welsh and M. D. Smith, A public-key infrastructure
for key distribution in TinyOS based on elliptic curve cryptography, 1st
Annual IEEE Communications Society Conference on Sensor and Ad
Hoc Communications and Networks (SECON04), Santa Clara,
Calafornia, USA.
N. Gura, A. Patel, A. Wander, H. Eberle and S. C. Shantz, Comparing
Elliptic Curve Cryptography and RSA on 8-bit CPUs, 5th International
Workshop on Cryptographic Hardware and Embedded Systems
(CHES04), Cambridge, Boston, USA.
N. R. Potlapally, S. Ravi, A. Raghunathan and N. K. Jha, Analyzing the
Energy Consumption of Security Protocols, International Symposium
of Low Power Electronics and Design, 2003, Seoul, Korea.
H. Yan and Z. J. Shi, Studying Software Implementations of Elliptic
Curve Cryptography, 3rd International Conference on Information
Technology: New Generations (ITNG'06), Las Vegas, Nevada, USA.
Jan-Erik Ekberg, Key establishemnt in constrained devices, Research
Seminar on Network Security, 2006, Helsinki, Finland.
S. Sakane, K. Kamada, M. Thomas and and J. Vilhuber, Kerberized
Internet Negotiation of Keys (KINK), RFC 4430.
J. Khol and C. Neuman, The Kerberos Network Authentication
Service, RFC 1510.
F. Stajano and R. Anderson, The resurrecting duckling: Security issues
for ad-hoc wireless networks, 3rd AT&T Software Symposium, Oct
1999.

[14] R. Needham and M. Schroeder, Using encryption for authentication in

large networks of computers, Communications of the ACM,
21(12):993999, Dec 1978.