Proxy-Based Security Protocols in Networked Mobile Devices" M. Burnside, D. Clarke, 1". Mills, A. Maywah, S. Devadas, R. Rivest MIT Laboratoryfor ComputerScience 200 Technology Square, Cambridge, MA 02139 USA

(event, declarke, mills, s m a y w s h , devadas, r i v e s t } Q m i t . e d u

ABSTRACT

i n t e g r a t i n g w e a r a b l e a n d e m b e d d e d devices into a ubiquit o u s c o m p u t i n g environment. T h e s e hurdles include designing devices s m a r t enough t o c o l l a b o r a t e w i t h each other, increasing ease-of-use, a n d e n a b l i n g enhanced c o n n e c t i v i t y between the different devices. • W h e n c o n n e c t i v i t y is high, t h e security of t h e s y s t e m is a key factor. Devices m u s t only allow access to a u t h o r i z e d users a n d m u s t also keep t h e c o m m u n i c a t i o n secure when t r a n s m i t t i n g or receiving p e r s o n a l or p r i v a t e information. I m p l e m e n t i n g typical forms of secure, p r i v a t e c o m m u n i c a t i o n using a public-key i n f r a s t r u c t u r e on all devices is difficult because t h e necessary c r y p t o g r a p h i c a l g o r i t h m s are CPU-intensive. A c o m m o n public-key c r y p t o g r a p h i c algor i t h m such as R S A using 1024-bit keys takes 43ms to sign a n d 0.6ms to verify.on a 200MI-Iz ]ntel P e n t i u m P r o (a 32b i t processor) [30]. Some devices m a y have. 8.-bit microcontrollers running at 1-4 MHz, so public-key c r y p t o g r a p h y on t h e device itself m a y n o t be an option. Nevertheless, public-key b a s e d c o m m u n i c a t i o n b e t w e e n devices over a netw o r k is still desirable. T h i s p a p e r presents our a p p r o a c h to addressing these issues. We describe the a r c h i t e c t u r e of our resource discovery a n d c o m m u n i c a t i o n s y s t e m in Section 2. T h e device-top r o x y security p r o t o c o l is d e s c r i b e d in Section 3. We review S P K I / S D S I a n d p r e s e n t t h e proxT-to-proxy protocol t h a t uses S P K I / S D S I in Section 4. R e l a t e d work is discussed in Section 5. T h e s y s t e m is e v a l u a t e d in Section 6.

W e describe a resource discovery a n d c o m m u n i c a t i o n syst e m designed for security a n d privacy. All o b j e c t s in the s y s t e m , e.g., appliances, w e a r a b l e gadgets, software agents, a n d users have associated t r u s t e d software proxies t h a t eit h e r r u n on t h e appliance h a r d w a r e or on a t r u s t e d computer. W e describe how security a n d p r i v a c y are enforced using two s e p a r a t e protocols: a p r o t o c o l for secure devicet o - p r o x y c o m m u n i c a t i o n , a n d a p r o t o c o l for secure proxyt o - p r o x y c o m m u n i c a t i o n . Using two s e p a r a t e protocols allows us to r u n a c o m p u t a t i o n a i l y - i n e x p e n s i v e p r o t o c o l on impoverished devices I a n d a s o p h i s t i c a t e d p r o t o c o l for resource a u t h e n t i c a t i o n a n d c o m m u n i c a t i o n on m o r e powerful devices. We detail the device-to-proxy p r o t o c o l for lightweight wireless devices a n d t h e p r o x y - t o - p r o x y p r o t o c o l which is b a s e d on S P K I / S D S I (Simple P u b l i c K e y I n f r a s t r u c t u r e / Simple D i s t r i b u t e d Security I n f r a s t r u c t u r e ) . A p r o t o t y p e s y s t e m has been constructed, which allows for secure, y e t efficient, access to networked, mobile devices. We present a quantit a t i v e evaluation of this s y s t e m using various metrics.

Keywords authorization, certificate, certificate chain, certificate chain discovery, mobile device, pervasive, protocol, proxy, security, ubiquitous, wireless

1.

1.1 Our Approach

INTRODUCTION

To allow t h e a r c h i t e c t u r e to use a public-key security m o d e l on t h e network while keeping t h e devices themselves simple, we create a software p r o x y for each device. All o b j e c t s in t h e system, e.g., appliances, w e a r a b l e gadgets, software agents, a n d users have associated t r u s t e d software proxies t h a t either r u n on an e m b e d d e d processor on the appliance, or on a t r u s t e d c o m p u t e r . In t h e case of t h e p r o x y r u n n i n g on a n e m b e d d e d processor on t h e appliance, we assume t h a t device t o p r o x y c o m m u n i c a t i o n is i n h e r e n t l y secure, s If t h e device has m i n i m a l c o m p u t a t i o n a l power, 2 a n d comm~micates t o its p r o x y t h r o u g h a w i r e d or wireless network, we force t h e c o m m u n i c a t i o n to adhere to a devicet o - p r o x y p r o t o c o l (cf. Section 3). Pxox/es c o m m u n i c a t e w i t h

A t t a i n i n g t h e goals of ubiquitous a n d pervasive c o m p u t iug [6, 2] is b e c o m i n g more a n d m o r e feasible as t h e n u m b e r of c o m p u t i n g devices in t h e world increases rapidly. HoWever, t h e r e are still eigniRcant hurdles to overcome when *This work was f u n d e d b y Acer Inc., D e l t a Electronics Inc., H P Corp., N T T Inc., N o k i a Research Center, a n d Phflips Research u n d e r t h e M I T P r o j e c t O x y g e n p a r t n e r s h i p , a n d b y D A R P A t h r o u g h the Ofllce of Naval Research u n d e r cont r a c t n u m b e r N66001-99-2-891702.

Permission to ~ digital o¢ hard copies ol~all or pan of this work for personal o¢ classroom use is granted without lee provided that copies arc not mad= or disffibmcd for profit or comme~ial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on sc/'vcn or to redistribute to lists, requires prior specific p,mnissioa and/or a fee. SAC 2002, M_Adrid,Sl~in Copyright 2002 ACM 1-58113-445-2/02/03 ...$5.00.

XFor example, in a video c a m e r a , t h e software t h a t controis various a c t u a t o r s runs on a powerful processor, a n d t h e p r o x y for t h e c a m e r a can also run on t h e e m b e d d e d processor. aThis is t y p i c a l l y t h e case for lightweight devices, e.g., rem o t e cont.rols, active badges, etc.

265

each o t h e r u s i n g a secure p r o x y - t o - p r o x y p r o t o c o l b a s e d o n S P K I / S D S I ( S i m p l e P u b l i c K e y I n f r a s t r u c t u r e / S i m p l e Dist r i b u t e d S e c u r i t y I n f r a s t r u c t u r e ) . H a v i n g two different protocols allows u s to r u n a c o m p u t a t i o n a l / y - i n e x p e n s i v e secur i t y p r o t o c o l on i m p o v e r i s h e d devices, a n d a s o p h i s t i c a t e d p r o t o c o l for resource a u t h e n t i c a t i o n a n d c o m m u n i c a t i o n o n m o r e powerful devices. W e describe b o t h protocols i n this paper.

1.2

~

e J:te dLetk~n~

Prototype Automation System .

.

.

.

.

.

:

~ CR Proxy [

!oo-) ]

),

F i g u r e 1: S y s t e m O v e r v i e w 3. T h u s , t h e device-side p o r t i o n .of t h e p r o x y m u s t b e cust o m i z e d for each p a r t i c u l a r device.

2.2 SYSTEM ARCHITECTURE

Proxy

T h e p r o x y is software t h a t r u n s o n a n e t w o r k - v i s i b l e comp u t e r . T h e p r o x y ' s p r i m a r y f u n c t i o n is to m a k e accessc o n t r o l decisions o n b e h a l f of t h e device it r e p r e s e n t s . I t m a y also p e r f o r m s e c o n d a r y f u n c t i o n s s u c h as r u n n i n g s c r i p t e d a c t i o n s o n b e h a l f of t h e device a n d i n t e r f a c i n g w i t h a direct o r y service. T h e p r o x y p r o v i d e s a v e r y s i m p l e A P I to t h e device. T h e sendToProzy 0 m e t h o d is called b y t h e device t o s e n d messages t o t h e proxy. T h e aertdToDe~/ce 0 m e t h o d is a called by t h e p r o x y t o s e n d meesa~es t o t h e device. W h e n a p r o x y receives a m e s s a g e from a n o t h e r proxy, d e p e n d i n g o n the message, t h e p r o x y m a y tranAlate it i n t o a form t h a t c a n b e u n d e r s t o o d b y the prox-y's p a r t i c u l a r device. I t t h e n forw a r d s t h e m e s s a g e t o t h e device. W h e n a p r o x y receives a m e s s a g e f r o m its device, it m a y tremslate t h e m e s s a g e i n t o a g e n e r a l f o r m u n d e r s t o o d b y all proxies, a n d t h e n f o r w a r d t h e m e s s a g e t o o t h e r proxies. A n y t i m e a p r o x y receives a message, before p e r f o r m i n g a t r a n s l a t i o n a n d p a s s i n g ' t h e message o n t o t h e device, i t p e r f o r m s t h e access c o n t r o l checks d e s c r i b e d i n S e c t i o n 4. For ease of a d m i n i s t r a t i o n , we g r o u p proxies b y t h e i r adm i n i s t r a t o r s . A n a r l m i n i s t r a t o r ' s set of p r m d e s is called a prozy f a r m . T h i s set specifically i n c l u d e s t h e p r o x y for t h e a A m i = i q t r a t o r ' s K21, w h i c h is c o n s i d e r e d t h e r o o t p r o x y of t h e p r o x y f a r m . Vv'hen t h e a d m i n i s t r a t o r axlds a n e w device to t h e s y s t e m , t h e device's p r o x y is a u t o m a t i c a l l y given a d e f a u l t ACL, a d u p l i c a t e of t h e A C L for t h e w 4 m i - i s t r a t o r ' s K21 proxy. T h e a ~ l m l n i s t r a t o r c a n m a n u a l l y c h a n g e t h e A C L later, if he desires. A n o t e w o r t h y advmxtage of o u r p r o x y - b a s e d a r c h i t e c t u r e is t h a t it addresses t h e p r o b l e m of v i r u s e s i n pervasive comp u t i n g e n v i r o n m e n t s . S o p h i s t i c a t e d v i r u s s c a n n i n g softwaze c a n b e i n s t a l l e d i n t h e proxy, so it c a n s c a n a n y code before it is d o w n l o a d e d o n t o t h e device.

T h e s y s t e m has t h r e e p r i m a r y c o m p o n e n t types: devices, proxies a n d servers. A de~ice refers t o a n y t y p e of s h a r e d n e t w o r k resource, e i t h e r h a r d w a r e or software. I t could b e a p r i n t e r , a wireless s e c u r i t y c a m e r a , a l a m p , or a software agent. Since c o m m u n i c a t i o n protocols a n d b a n d w i d t h b e t w e e n devices c a n vary widely, each device has a u n i q u e prozl7 t o u n i f y its i n t e r f a c e w i t h o t h e r devices. T h e servers p r o v i d e n a m i n g a n d discovery facilities t o t h e v a r i o u s devices_ W e a s s u m e a o n e - t o - o n e c o r r e s p o n d e n c e b e t w e e n devices a n d proxies. W e also a s s u m e t h a t all users are e q u i p p e d w i t h K21s, whose proxies r u n o n t r u s t e d c o m p u t e r s . T h u s our s y s t e m o n l y n e e d s t o deal w i t h devices, proxies a n d the server n e t w o r k . T h e s y s t e m we describe is i l l u s t r a t e d i n F i g u r e 1.

2.1

~Ldlag.~

Pro,~y.4o-pmxy pe'otocoJ

U s i n g t h e ideas d e s c r i b e d above, we h~ve c o n s t r u c t e d a p r o t o t y p e a u t o m a t i o n s y s t e m which allows for secure, y e t efllcient, access t o n e t w o r k e d , m o b i l e devices. I n this s y s t e m , each user wears a b a d g e called a K21 which identifies t h e user a n d is l o c a t i o n - a w a r e : it "knows" the w e a r e r ' s l o c a t i o n w i t h i n a b u i l d i n g . User i d e n t i t y a n d l o c a t i o n i n f o r m a t i o n is securely t r a n s m i t t e d t o t h e u s e r ' s software p r o x y u s i n g t h e d e v i c e - t o - p r o x y protocol. Devices t h e m s e l v e s m a y b e m o b i l e a n d m a y c h a n g e locations. A t t r i b u t e search over all c o n t r o l l a b l e devices c a n b e p e r f o r m e d t o find t h e n e a r e s t device, or t h e m o s t a p p r o p r i a t e device u n d e r s o m e m e t r i c , s B y e x p l o i t i n g S P K I / S D S I , s e c u r i t y is n o t c o m p r o m i s e d as n e w users emd devices e n t e r t h e s y s t e m , or w h e n users a n d devices leave the s y s t e m . W e believe t h a t t h e use of two different p r o t o c o l s , a n d t h e use of t h e S P K I / S D S I f r a m e w o r k i n t h e p r o x y - t o - p r o x y p r o t o c o l h a s r e s u l t e d in a secure, scalable, efficient, a n d e a s y - t o - m a . l n t a l n a u t o m a t i o n s y s t e m .

2.

Server Network

Devices

E a c h device, h a r d w a r e or software, has a n a s s o c i a t e d t r u s t ed software proxy. I n t h e case of a h a r d w a r e device, t h e p r o x y m a y r u n o n a n e m b e d d e d processor w i t h i n t h e device, or o n a t r u s t e d c o m p u t e r n e t w o r k e d w i t h t h e device. I n t h e case of a software device, t h e device c a n i n c o r p o r a t e t h e p r o x y software itself. E a c h device c o m m u n i c a t e s w i t h its o w n p r o x y over t h e a p p r o p r i a t e p r o t o c o l for t h a t p a r t i c u l a r device. A p r i n t e r w i r e d i n t o a n E t h e r n e t c a n c o m m u n i c a t e w i t h its p r o x y u s i n g T C P / I P . A wireless c a m e r a uses a wireless p r o t o c o l for t h e s a m e p u r p o s e . T h e K21 (a s i m p l e device w i t h a lightweight processor) c o m m u n i c a t e s with' its p r o x y u s i n g the p a r t i c u l a r d e v i c e - t o - p r o x y p r o t o c o l d e s c r i b e d i n S e c t i o n aFor e x a m p l e , a user m a y wish to p r i n t to t h e n e a r e s t p r i n t e r t h a t h e / s h e has access to.

266

CommandEvent Used to i n s t r u c t a device to t u r n on or of[, for example. E r r o r E v e n t G e n e r a t e d a n d broadcast to all listeners when a n error condition occurs. StatusChangeEvent G e n e r a t e d when, for example, a device changes its location. Q u e r y E v e n t W h e n a server receives a Q u e r y E v e n t , it performs a DNS ( D o m a i n N a m e Service) or INS lookup on the query, a n d r e t u r n s the results of the lookup in a ResponseEvent. l ~ L e s p o n s e E v e n t G e n e r a t e d in response to a Q u e r y E v e n t .

Proxy Fm

Gateway

Device 1

Device 2

Proxy 1 Gateway

Proxy 2 Device 3

Proxy 3

F i g u r e 2: P r e d e f l n e d E v e n t T y p e s F i g u r e 3: D e v i c e - t o - P r o x y C o m m u n i c a t i o n

2.3

This network consists of a d i s t r i b u t e d collection of indep e n d e n t n a m e servers a n d roarers. In fact, each server acts as b o t h a n a m e server and a router. This is similar to the n a m e resolvers in the I n t e n t i o n a l N a m i n g System (INS) [1], which resolve device n a m e s to I P addresses, b u t can also route events. If the d e s t i n a t i o n n a m e for a n event matches multiple proxies, the server network will route the event to all m a t c h i n g destinations. W h e n a proxy comes online, it registers the n a m e of the device it represents with one of these servers. W h e n a proxy uses a server to perform a lookup on a n a m e , the server searches its directory for all n a m e s t h a t m a t c h the given n a m e , a n d r e t u r n s their IP addresses.

2.4

its lease by sending the same n a m e / I P address pair to the server, otherwise t h e server removes it from the directory. In this fashion, if a device silently goes otiline, or the I P address changes, the proxy's lease will no longer get renewed a n d the server will quickly notice a n d either remove it from the directory or create a new lease with the new IP address. For example, imagine a device with the n a m e [name----fool which has a proxy r u n n i n g on 10.1.2.3:4011. W h e n t h e device is t u r n e d on, it informs its proxy t h a t it has come online, using a protocol like the device-to-proxy protocol described in Section 3. T h e proxy begins to broadcast lease-request packets of the form ([name----fool, 10.1.2.3:4011) on the local subnetwork. W h e n (or if) a server receives one of these packets, it checks its directory for [name--fool. If [name----fool is not there, the server creates a lease for it b y adding the n a m e / I P address pair to the directory. If [name-'=foo] is in the directory, the server renews the lease. Suppose at some later time the device is t u r n e d off. W h e n the device goes down, it brings the proxy offiine with it, so t h e lease •request packets no longer get broadcast. T h a t device's lease stops getting renewed. After some short, pre-defined, period of time, the server expires the uurenewed lease and.removes it from the directory

C o m m u n i c a t i o n via Events

We use an event-based c o m m u n i c a t i o n m e c h a m s m i n our system. T h a t is, all messages passed b e t w e e n proxies are signais i n d i c a t i n g t h a t some event has occurred. For example, a light b u l b m i g h t generate light-on a n d light-off events. To receive these messages, proxy z can add itself as a n eventlistener to proxy Z/- Thus, when y generates an event, z will receive a copy. In addition, the system has several pre~defmed event categories which receive special t r e a t m e n t at either the proxy or server layer. T h e y are s u m m a r i z e d i n Figure 2. A developer can define his own events as well. T h e server network simply passes developer-defined events t h r o u g h to their destination. T h e p r i m a r y advantage of t h e event-based m e c h a n i s m is t h a t it eliminates the need to r e p e a t e d l y poll a device to d e t e r m i n e changes i n its status. Instead, when a change occurs, the device broadcasts a n event to all listeners. Systems like S u n Microsystems' Jini [26] issue "device drivers" (RMI stubs) to all who wish to control a given device. It is t h e n possible to make local calls on t h e device driver, which are t r a n s l a t e d into R M I calls on the device itself.

2.5

overview

Servers a n d the Server N e t w o r k

3. 3.1

DEVICE-TO-PROXY PROTOCOL FOR WIRELESS DEVICES Overview

T h e device-to-proxy protocol varies for different types of devices. I n particular, we consider lightweight devices with l o w - b a n d w i d t h wireless network connections a n d slow CPUs, a n d heavyweight devices with h i g h e r - b a n d w ! d t h connections and faster CPUs. We assume t h a t heavyweight devices are capable of r u n n i n g proxy software locally (i.e., the proxy for a p r i n t e r could r u n on the p r i n t e r ' s C P U ) . W i t h a local proxy, a sophisticated protocol for secure device-to-proxy c o m m u n i c a t i o n is unnecessary, a s s u m i n g critical parts of the device are t a m p e r resistant. For lightweight devices, the proxy m u s t r u n elsewhere. This section gives an overview of a protocol which is l o w - b a n d w i d t h a n d n o t C P U - i n t e n s i v e • t h a t we use for fightweight device-to-proxy c o m m u n i c a t i o n .

Resource discovery

T h e m e c h a n i s m for resource discovery is similar to the resource discovery protocol used by Jini. W h e n a device comes online, it instructs its proxy to r e p e a t e d l y broadcast a request for a server to the local subnetwork. T h e request contains the device's n a m e a n d the IP address a n d p o r t of its proxy. W h e n a server receives one of these requests, it issues a lease to the proxy. 4 T h a t is, it adds the n a m e / I P address pair to its directory. T h e proxy m u s t periodically renew

3.2

Communication

Our p r o t o t y p e system layers the security protocol deseribed below over a simple radio frequency (RF) protocol. T h e

4Handling the scenario where t h e device is m a k i n g false claims a b o u t its a t t r i b u t e s in the lease request packet is

the s u b j e c t of ongoing research.

267

R F c o m m u n i c a t i o n b e t w e e n a device a n d its p r o x y is h a n dled b y a g a t e w a y t h a t t r a n s l a t e s packetized R F c o m m u n i c a t i o n into U D P / I P packets, which axe then r o u t e d over t h e n e t w o r k to t h e proxy. T h e gateway also works in the opposite d i r e c t i o n b y c o n v e r t i n g U D P / I P packets from the p r o x y into R F packets a n d t r a n s m i t t i n g t h e m t o t h e device. A n overview of t h e c o m m u n i c a t i o n is shown i n F i g u r e 3. T h i s figure shows a c o m p u t e r r u n n i n g three proxies; one for each of three s e p a r a t e devices. T h e figure aLso shows h o w m u l t i p l e gateways c a n b e used; device A is u s i n g a different gateway from devices B a n d C.

3.3

u s i n g t h e t i m e difference.

S P K I / S D S I (Simple P u b l i c K e y I n f r a s t r u c t u r e / S i m p l e Dist r i b u t e d Security I n f r a s t r u c t u r e ) [7, 22] is a security infrast r u c t u r e t h a t is d e s i g n e d t o facilitate t h e d e v e l o p m e n t of scalable, secure, d i s t r i b u t e d c o m p u t i n g systems. S P K I / S D S I provides f i n e - g r a i n e d access control u s i n g a local n a m e space a r c h i t e c t u r e a n d a simple, flexible, t r u s t policy model. S P K I / S D S I is a p u b l i c key i n f r a s t r u c t u r e w i t h a n egalit a r i a n design. T h e principals are the public keys and each p u b l i c key is a certificate a u t h o r i t y . E a c h p r i n c i p a l c a n issue certificates o n t h e s a m e basis as a n y other principal. T h e r e is no hierarchical global i n f r a s t r u c t u r e . S P K I / S D S I c o m m u n i t i e s are b u i l t f r o m t h e b o t t o m - u p , in a d i s t r i b u t e d m a n n e r , a n d do n o t r e q u i r e a t r u s t e d "root."

Security

T h e p r o x y a n d device c o m m u n i c a t e t h r o u g h a secure channel t h a t e n c r y p t s a n d a u t h e n t i c a t e s all t h e messages. T h e H M A C - M D 5 [13][20] a l g o r i t h m is used for a u t h e n t i c a t i o n a n d t h e R C 5 [21] a l g o r i t h m is used for e n c r y p t i o n . B o t h of these a l g o r i t h m s use s y m m e t r i c keys; the p r o x y a n d t h e device s h a r e 128-bit keys.

3.3.1

4.1

Authentication

Encryption

T h e d a t a is e n c r y p t e d u s i n g the RC5 e n c r y p t i o n algor i t h m . W e chose R C 5 b e c a u s e of its simplicity a n d perform a n c e . O u r I~C5 i m p l e m e n t a t i o n is b a s e d on t h e O p e n S S L [16] code. R C 5 is a block cipher; it u s u a l l y works on eightb y t e blocks of d a t a . However, by i m p l e m e n t i n g it u s i n g o u t p u t feedback ( O F B ) mode, it c a n b e used as a s t r e a m cipher. T h i s allows for e n c r y p t i o n of a n a r b i t r a r y n u m b e r of b y t e s w i t h o u t h a v i n g to worry a b o u t blocks of d a t a . O F B m o d e works b y g e n e r a t i n g a n e n c r y p t i o n p a d from a n i n i t i a l vector a n d a key. T h e e n c r y p t i o n p a d is t h e n X O R ' e d w i t h t h e d a t a to p r o d u c e t h e ciphertext. Since X (~ Y (B Y = X , t h e c i p h e r t e x t c a n b e d e c r y p t e d by prod u c i n g t h e s a m e e n c r y p t i o n p a d a n d X O R ' i n g it w i t h t h e ciphertext. Since this o n l y requires t h e RC5 e n e r y p t i o n routines to g e n e r a t e the e n c r y p t i o n pad, s e p a r a t e e n c r y p t a n d d e c r y p t r o u t i n e s axe n o t required. For our i m p l e m e n t a t i o n , we use 16 r o u n d s for RC5. We use different 128-bit keys for e n c r y p t i o n a n d a u t h e n t i c a t i o n .

3.4

SPKI/SDSI Integration

We have a d o p t e d a client-server a r c h i t e c t u r e for t h e proxies. W h e n a p a r t i c u l a r p r i n c i p a l , a c t i n g o n b e h a l f of a device or user, makes a r e q u e s t v i a one p r o x y to a device repres e n t e d b y a n o t h e r proxy, t h e first p r o x y acts like a client, a n d t h e second as a server. Resources o n the server are either p u b l i c or p r o t e c t e d b y S P K I / S D S I ACLs. A S P K I / S D S I A C L consists of a list of entries. Each e n t r y has a s u b j e c t (a key or group) a n d a t a g which specifies t h e set of opera~ tious t h a t t h a t key or g r o u p is allowed to perform. To gain access to a resource p r o t e c t e d b y a n ACL, a requester m u s t include, in his request, a c h a i n of certificates d e m o n s t r a t i n g t h a t he is a m e m b e r of a g r o u p i n a n e n t r y o n t h e ACL. s If a r e q u e s t e d resource is p r o t e c t e d b y a n ACL, t h e princip a l ' s r e q u e s t m u s t be a c c o m p a n i e d b y a "proo] o/ authenticity" t h a t shows t h a t it is a u t h e n t i c , a n d a "prooJ o/authorization" t h a t shows t h e p r i n c i p a l is a u t h o r i z e d to p e r f o r m t h e p a r t i c u l a r r e q u e s t o n t h e p a r t i c u l a r resource., T h e p r o o f of a u t h e n t i c i t y is t y p i c a l l y a s i g n e d request, a n d the proof of a u t h o r i z a t i o n is typically a c h a i n of certificates. T h e principal t h a t s i g n e d t h e r e q u e s t m u s t b e t h e s a m e p r i n c i p a l t h a t t h e c h a i n of certificates authorizes. T h i s s y s t e m design, a n d t h e protocol b e t w e e n t h e proxies, is very similar to t h a t u s e d i n S P K I / S D S I ' s P r o j e c t G e r o n imo, i n which S P K I / S D S I was i n t e g r a t e d into A p a c h e a n d Netscape, a n d u s e d to p r o v i d e client access c o n t r o l over the web. P r o j e c t G e r o n i m o is described i n two M a s t e r ' s theses [3, 14].

H M A C ( H a s h e d Message A u t h e n t i c a t i o n Code) p r o d u c e s s M A C (Message A u t h e n t i c a t i o n Code) t h a t c a n v a l i d a t e t h e a u t h e n t i c i t y a n d i n t e g r i t y of a message. H M A C uses secret keys, a n d t h u s o n l y s o m e o n e who knows a p a r t i c u l a r key c a n create a p a r t i c u l a r M A C or verify t h a t a p a r t i c u l a r M A C is correct.

3.3.2

P R O X Y TO P R O X Y P R O T O C O L

4.

4.2

Protocol

T h e protocol i m p l e m e n t e d b y t h e client a n d server proxies consists of four messages. T h i s p r o t o c o l is o u t l i n e d in F i g u r e 4, a n d following is its description:

Location

Device l o c a t i o n is d e t e r m i n e d u s i n g the Cricket l o c a t i o n s y s t e m [ I 8 , 17]. Cricket has several useful features, i n c l u d ing user privacy, d e c e n t r a l i z e d control, low cost, a n d easy d e p l o y m e n t . E a c h device d e t e r m i n e s its o w n location. It is u p to t h e device to decide if it w a n t s to let others know where it is. I n t h e C r i c k e t s y s t e m , b e a c o n s are placed o n t h e ceilings of rooms. T h e s e b e a c o n s periodically b r o a d c a s t l o c a t i o n i n f o r m a t i o n (such as " R o o m 4011 ~) t h a t c a n b e h e a r d b y Cricket listeners. A t t h e same t i m e t h a t this i n f o r m a t i o n is b r o a d c a s t in t h e I~F s p e c t r u m , the b e a c o n also b r o a d c a s t s a n u l t r a s o u n d pulse. 3Arhen a listener receives t h e I~F message, it m e a s u r e s t h e t i m e u n t i l it receives t h e u l t r a s o u n d pulse. T h e listener d e t e r m i n e s its d i s t a n c e to t h e b e a c o n

1. T h e client p r o x y s e n d s a request, u n a u t h e n t i c a t e d a n d u n a u t h o r i z e d , t o t h e server proxy. 2. I f t h e client r e q u e s t s access to a p r o t e c t e d resource, the server r e s p o n d s w i t h t h e A C L p r o t e c t i n g the resource s SFor e x a m p l e s of S P K I / S D S I ACLs a n d certificates, see [7] or [3]. SThe ACL itself c o u l d b e a p r o t e c t e d resottrce, p r o t e c t e d b y a n o t h e r ACL. I n t h i s case, the server will r e t u r n t h e l a t t e r ACL. T h e client will n e e d t o d e m o n s t r a t e t h a t t h e user's key is o n this ACL, either directly or v i a certificates, before g a i n i n g access to the A C L p r o t e c t i n g t h e o b j e c t t o which access was o r i g i n a l l y r e q u e s t e d .

268

(requed)

a n d t h e tag f o r m e d f r o m t h e client's request. A t a g is a S P K I / S D S I d a t a s t r u c t u r e which represents a set of requests. T h e r e are e x a m p l e s of tags in t h e SPKI/SDSI I E T F d r a f t s [7]. If t h e r e is no A C L p r o t e c t i n g t h e req u e s t e d resource, t h e request is i m m e d i a t e l y honored.

1. lmtlnl umid~ml~:m~l, umuldhonzedJ~Jl~,

2. S~w~ wn/t'~n~ion faik. A C L 1 d ~ a m mm~d.

3. Ca) T h e client p r o x y generates a chain of certificates

a l e ~ Crew

using t h e S P K I / S D S I cerLifi~te ~ o l n d ~ e r ~ algorithm [4, 3]. T h i s certificate chain provides a proof of authorization t h a t l~he user's key is aut h o r i z e d to perform its request. T h e certificate chain discovery a l g o r i t h m t a k e s as i n p u t t h e A C L a n d t a g from t h e server, t h e user's p u b l i c key (principal), t h e user's set o f certificates, a n d a t i m e s t a m p . If it exists, t h e algor i t h m r e t u r n s a chain o f user certificates which provides p r o o f t h a t t h e user's public key is aut h o r i z e d t o p e r f o r m t h e o p e r a t i o n ( s ) specified in the tag, a t t h e t i m e specified in t h e t i m e s t a m p . If t h e a l g o r i t h m is u n a b l e t o generate a chain because t h e user does not have t h e necessary certificatee, ~ or if the user's key is d i r e c t l y on t h e ACL, t h e a l g o r i t h m r e t u r n s an e m p t y certificate chain. T h e client generates t h e t i m e s t a m p using its local clock.

3. Cliem a m ACL ~ d bqj to Bm~m~ c ~ . m e n~lUeSt wilb

4. Sm'vm ws/fies n x j ~ . Iftl~mlUmaLs v ~ ] L . JLis hODmlHL H ~h- mqDdg dram BOt v ~ f y , it hs dmmd a n d l n ea~nariJ nmmn~L

F i g u r e 4: S P K I / S D S I trol Protocol

Access Con-

If t h e request verifies, it is honored. I£ it does n o t verify, i t is d e n i e d a n d t h e server p r o x y r e t u r n s an error to t h e client proxy. T h i s error is r e t u r n e d whenever t h e client presents an a u t h e n t i c a t e d r e q u e s t t h a t is denied.

(b) T h e client creates a S P K I / S D S I sequence [7] consistin K of t h e t a g a n d t h e t i m e s t a m p . It signs this sequence w i t h t h e user's p r i v a t e key, a n d includes a copy of t h e user's p u b l i c key in t h e S P K I / S D S I sdgnature. T h e client t h e n sends t h e t a g - t i m e s t a m p sequence, t h e signature, a n d t h e certificate chain g e n e r a t e d in s t e p 3a to the server.

T h e p r o t o c o l can b e viewed as a t y p i c a l challenge.response protocol. T h e s e r v e r r e p l y in s t e p 2 of t h e p r o t o c o l is a challenge t h e server issues t h e client, saying, UYou a r e t r y i n g t o access a p r o t e c t e d file. Prove to m e t h a t you have t h e credentials to p e r f o r m t h e o p e r a t i o n you are requesting on t h e resource p r o t e c t e d b y this ACL." T h e client uses t h e A C L t o h e l p it p r o d u c e a certificate chain, using t h e S P K I / S D S I certificate chain discovery algorithm. It t h e n sends t h e certificate chain a n d signed request in a s e c o n d request t o t h e server proxy. T h e signed request provides p r o o f of a u t h e n t i c ity, a n d t h e certificate chain provides p r o o f of a u t h o r i z a t i o n . T h e server a t t e m p t s t o verify the second request, a n d if it succeeds, it honors t h e request. T h e t i m e e t a m p in t h e t a K - t i m e s t a m p sequence helps to p r o t e c t against c e r t a i n t y p e s of r e p l a y attacks. For example, s u p p o s e t h e server logs requests a n d suppose t h a t this log is n o t disposed of properly. I f an a d v e r s a r y gains access t o t h e logs, t h e t h n e s t a m p p r e v e n t s h i m from replaying requests f o u n d in t h e log a n d gaining access t o p r o t e c t e d resources. 9

•4. T h e server verifies t h e request by:

(a)

Proxy to Proxy

Checking t h e t i m e s t a m p in t h e t a g - t i m e s t a m p sequence a g a i n s t t h e t i m e on the server's local clock to ensure t h a t t h e request was m a d e recently, s

(b) R e c r e a t i n g t h e t a g from t h e client's request a n d checking t h a t it is t h e u r n e as t h e t a g in t h e tagt i m e s t a m p sequence. (c) E x t r a c t i n g the public key from t h e signature. (d) Verifying t h e s i g n a t u r e on t h e t a g = t i m e s t a m p sequence using t h i s key.

4.2.1

(e) V a l i d a t i n g t h e certificates in the certificate chain.

Additional Security Considerations

T h e S P K I / S D S I protocol, as described, addresses t h e issue of p r o v i d i n g client access control. T h e p r o t o c o l does n o t ensure confidentiality, a u t h e n t i c a t e servers, or provide p r o t e c t i o n a g a i n s t r e p l a y a t t a c k s from t h e network. T h e Secure Sockets Layer (SSL) p r o t o c o l is t h e m o s t widely used security p r o t o c o l tod~y. T h e T r a n s p o r t Layer Secur i t y ( T L S ) p r o t o c o l is t h e successor t o SSL. P r i n c i p a l goals of S S L / T L S [19] include providing confidentiality a n d d a t a i n t e g r i t y of t r a ~ c between t h e client a ~ d server, a n d providing a u t h e n t i c a t i o n of t h e server. T h e r e is s u p p o r t for client

(f) Verifying t h a t there is a chain of a u t h o r i z a t i o n from an e n t r y on t h e A C L t o t h e key fxom t h e signature, via t h e certificate chain presented. T h e a u t h o r i z a t i o n chain m u s t a u t h o r i z e t h e client t o perform the requested operation. ~If t h e u s ~ does n o t have t h e necessary 'certificates, t h e client could i m m e d i a t e l y r e t u r n a n error. I n our design, however, we choose n o t to r e t u r n an error a t this point; instead, we let t h e client send an e m p t y certificate chain to t h e eerver. T h i s way, when t h e request does n o t verify, t h e client can p o s s i b l y b e sent some error i n f o r m a t i o n b y t h e s e r v ~ which lets t h e user know where he should go t o get valid certificates. Sin our p r o t o t y p e i m p l e m e n t a t i o n , t h e server checks t h a t t h e t i m e s t a m p in t h e client's t a g = t i m e s t a m p sequence is w i t h i n /~ve m i n u t e s of t h e server's local time.

Din order to use t h n e s t a m p s , t h e client's clock a n d server's clock need t o be fairly synchron/zed; S P K I / S D S I a l r e a d y m a k e s an a s s u m p t i o n a b o u t fairly s y n c h r o n i z e d clocks when v~lidity t i m e p e r i o d s are specified in certificates. A n altern a t i v e a p p r o a c h t o using t i m e s t a m p s is t o use nonces in t h e protocol.

269

SPKI/SDSI Access Control Protocol Application Protocol Key-Exchange Protocol with Server Authentication TCP/IP

Figure

5: E ~ m m p l e

Layering

of Protocols

wireless n e t w o r k s [25, 24]. I n t h i s m o d e l , w h e n d e v i c e s b e g i n t h e i r lives, t h e y m u s t b e " i m p r i n t e d = b e f o r e t h e y ea,~ b e used. A m a s t e r ( t h e m o t h e r d u c k ) i m p r i n t s a d e v i c e ( t h e d u c k l i n g ) b y b e i n g t h e first o n e t o c o m m u n i c a t e w i t h it. A f ter imprinting, a device only listens to its m~ter. During t h e p r o c e s s o f i m p r i n t i n g , t h e m a s t e r is p l a c e d i.n p h y s i c a l c o n t a c t w i t h t h e d e v i c e a n d t h e y s h a r e a s e c r e t k e y t h a t is t h e n u s e d for s y m m e t r i c - k e y a u t h e n t i c a t i o n a n d e n c r y p t i o n . T h e m a s t e r c a n also d e l e g a t e t h e c o n t r o l of a d e v i c e t o o t h e r devices so t h a t c o n t r o l is n o t a l w a y s l i m i t e d t o j u s t t h e m a s t e r . A d e v i c e c a n b e "killed" b y i t s m a s t e r t h e n r e s u r r e c t e d b y a n e w o n e in o r d e r for i t t o s w a p m a s t e r s .

a u t h e n t i c a t i o n , b u t c l i e n t a u t h e n t i c a t i o n is o p t i o n a l . T h e S P K I / S D S I A c c e s s C o n t r o l p r o t o c o l c a n b e l a y e r e d over a k e y - e x c h a n g e p r o t o c o l like T L S / S S L t o p r o v i d e a d d i t i o n a l security. T L S / S S L c u r r e n t l y uses t h e X.509 P K I to a u t h e n t i c a t e servers, b u t i t c o u l d j u s t as well u s e S P K I / S D S I in a similar manner. In addition to the features already s t a t e d , S S L / T L S also p r o v i d e s p r o t e c t i o n a g a i n s t r e p l a y a t tacks from the network, and protection against person-inthe-middle attacks. With these considerations, the layering of t h e p r o t o c o l s is s h o w n in F i g u r e 5. I n t h e figure, ' A p p l i c a t i o n P r o t o c o l ' refers t o t h e s t a n d a r d c o m m u n i c a t i o n p r o t o col b e t w e e n t h e c l i e n t a n d s e r v e r p r m d e s , w i t h o u t security. S S L / T L S a u t h e n t i c a t e s t h e s e r v e r proxy. H o w e v e r , it d o e s n o t i n d i c a t e w h e t h e r t h e s e r v e r p r o x y is a u t h o r i z e d t o a c c e p t the client's request. For example, it may be the case that t h e c l i e n t p r o x y is r e q u e s t i n g t o p r i n t a ' t o p s e c r e t ' d o c u m e n t , say, a n d o n l y c e r t a i n p r i n t e r s s h o u l d b e u s e d t o p r i n t 'top secret' documents. With SSL/TLS and the SPKI/SDSI C l i e n t A c c e s s C o n t r o l P r o t o c o l we h a v e d e s c r i b e d so far, t h e client p r o x y will k n o w t h a t t h e p u b l i c k e y o f t h e p r o x y w i t h w h i c h it is c o m m u n i c a t i n g is b o u n d t o a p a r t i c u l a r a d d r e s s , a n d t h e s e r v e r p r o x y will k n o w t h a t t h e c l i e n t p r o x y is a u t h o r i z e d t o p r i n t t o it. H o w e v e r , t h e client p r o x y still will n o t k n o w if t h e s e r v e r p r o x y is a u t h o r i z e d t o p r i n t ' t o p secret' documents. If it sends the 'top secret' document to be p r i n t e d , t h e s e r v e r p r o x y will a c c e p t t h e d o c u m e n t a n d p r i n t it, even t h o u g h t h e d o c u m e n t s h o u l d n o t h a v e b e e n s e n t t o it in t h e first place. To a p p r o a c h t h i s p r o b l e m , we p r o p o s e e x t e n d i n g t h e S P K I / S D S I p r o t o c o l so t h a t t h e client r e q u e s t s a u t h o r i z a t i o n f r o m t h e s e r v e r a n d t h e s e r v e r p r o v e s t o t h e c l i e n t t h a t i t is authorized to handle the client's request (before the client s e n d s t h e d o c u m e n t off t o b e p r i n t e d ) . To e x t e n d t h e p r o t o col, t h e S P K I / S D S I p r o t o c o l d e s c r i b e d in S e c t i o n 4.2 is r u n f r o m t h e c l i e n t p r o x y t o t h e s e r v e r p r o x y , a n d t h e n r u n in t h e reverse direction, from the server proxy to the client proxy. T h u s , t h e c l i e n t p r o x y will p r e s e n t a S P K I / S D S I c e r t i f i c a t e c h a i n p r o v i n g t h a t it is a u t h o r i z e d t o p e r f o r m i t s r e q u e s t , a n d t h e s e r v e r p r o x y will p r e s e n t a S P K I / S D S I c e r t i f i c a t e c h a i n p r o v i n g t h a t i t is a u t h o r i z e d t o a c c e p t a n d p e r f o r m t h e c l i e n t ' s r e q u e s t - A g a i n , if a d d i t i o n a l s e c u r i t y is n e e d e d , t h e e x t e n d e d p r o t o c o l c a n b e l a y e r e d over S S L / T L S . N o t e t h a t t h e S P K I / S D S I A c c e s s C o n t r o l P r o t o c o l is a n e x a m p l e of t h e e n d - t o - e n d a r g u m e n t [23]. T h e access c o n t r o l d e c i s i o n s a r e m a d e in t h e u p p e r m o s t layer, i n v o l v i n g o n l y t h e c l i e n t a n d t h e server.

5.

5.2

J i u i [26] n e t w o r k t e c h n o l o g y f r o m S u n M i c r o s y s t e m s c e n ters around the idea of federation building. Jiui avoids t h e use o f prc0des b y a s s l , m i = g t h a t all d e v i c e s a n d services in t h e s y s t e m will r u n t h e J a v a V i r t u a l M ~ - h i ~ e . T h e S I E S T A p r o j e c t [8] a t t h e H e l s i n b i U n i v e r s i t y of T e c h n o l o g y h a s s u c c e e d e d in b u i l d i n g a f r a m e w o r k for i n t e g r a t i n g J i u i and SPKI/SDSI. Their implementation has some latency concerns, however, when new authorizations are granted. U C B e r k e l e y ' s N i n j a p r o j e c t [27] u s e s t h e S e r v i c e D i s c o v e a t S e r v i c e [5] t o s e c u r e l y p e r f o r m r e s o u r c e d i s c o v e r y i n a wide-area network. Other related projects include Hewlettp s c t ~ r d ' s C o o l T o w n [9], I B M ' s T S p a c e s [11] a n d U n i v e r s i t y o f W a s h i n g t o n ' s P o r t o i n n o [29]..

Other projects using SPKI/SDSI

$_~

Other projects using SPKI/SDSI include Hewlett-Packa r d ' s e - S p e a k p r o d u c t [10], I n t e l ' s C D S A r e l e a s e [12], a n d B e r k e l e y ' s O c e a n S t o r e p r o j e c t [28]. H P ' s e S p e a k uses S P K I / S D S I c e r t i f i c a t e s for s p e c i f y i n g a n d d e l e g a t i n g a u t h o r i z a tious. I n t e l ' s C D S A r e l e a s e , w h i c h is o p e n - s o u r c e , i n c l u d e s a S P K I / S D S I s e r v i c e p r o v i d e r for b u i l d i n g ce~rtificates, a n d a m o d u l e ( A u t h C o m p u t e ) for p e r f o r m i n g a u t h o r i z a t i o n c o m p u t a t i o n s . O c e a n S t o r e uses S P K I / S D S I n a m e s in t h e i r n a m ing architecture.

6.

EVALUATION

6.1

Hardware Design

D e t a i l s o n t h e d e s i g n o f a b o a r d t h a t c a n a c t as t h e c o r e o f a l i g h t w e i g h t d e v i c e , o r as a w e a r a b l e c o m m u n i c a t o r , a r e

~ven m [15].

6.2

Device-to-Proxy Protocol

I n t h i s s e c t i o n we e v a l u a t e t h e device-to-prcet~y p r o t o c o l d e s c r i b e d in S e c t i o n 3 in t e r m s o f i t s m e m o r y a n d p r o c e s s i n g requirements.

6.2.1

MemoryRequirements

T a b l e 1 b r e a k s d o w n t h e m e m o r y r e q u i r e m e n t s for v a r i ous s o f t w a r e c o m p o n e n t s . T h e c o d e size r e p r e s e n t s m e m o r y u s e d in F l a s h , a n d d a t a size r e p r e s e n t s m e m o r y u s e d in R A M . T h e d e v i c e f u n c t i o n a l i t y c o m p o n e n t i n c l u d e s t h e packet and location processing routines. The RF code comp o n e n t i n c l u d e s t h e H F t r a n R m i t a n d r e c e i v e r o u t i n e s as well as t h e C r i c k e t l i s t e n e r r o u t i n e s . T h e miRcellaneous c o m p o n e n t is c o d e t h a t is c o m m o n to all o f t h e o t h e r c o m p o n e n t s . The device code requires approximately 12KB of code space and 1KB of data space. The security algorithms, HMAC-MD5 and RC5, take up most of the code space.

RELATED W O R K

5.1

Proxy to Proxy. Communication

D e v i c e to Proxy Commnnication

T h e R e s u r r e c t i n g D u c k l i n g is a s e c u r i t y m o d e l for a d - h o c

270

Component

Device F u n c t t o n a l t t y I~F Code HMAC-MD5 RC5 Miscellaneous Total

C o d e Size (KB) 2.0 I.I 4.6

3.2 1,0 11.9

D a t a Size

sexy. T h e two protocols we have d e s c r i b e d have vastly different characteristics, because t h e y a p p l y to different scenarios. T h e device-to-proxy p r o t o c o l was designed to e n a b l e secure c o m m u n i c a t i o n of d a t a from a lightweight device. T h e S P K I / S D S I - b a s e d p r o x y - t o - p r o x y p r o t o c o l was designed to provide flexible, fine-grained, access control between proxies. T h e proxy architecture a n d the use of two different protocols has resulted, we believe, in a secure, y e t efficient, resource discovery a n d c o m m u n i c a t i o n system.

(bytes)

191 153 386 256 0 986

qPable 1: C o d e a n d d a t a s i z e o n t h e A t m e l p r o c e s s o r [Function ] T i m e (ms) I Clock Cycles HC5 e n c r y p t / d e c r y p t (zt bytes) 0.163n + 0.552 652n + 2208 HMAC-MD5 u p to 56 b y t e s 11.48 45,920 T a b l e 2: P e r f o r m a n c e tion code

of encryption

8.

[1] W . A d j i e - W i n o t o , E. Schwartz, H. Bala~rishnem, a n d J. Lilley. T h e Design a n d I m p l e m e n t a t i o n of an Intentional N a m i n g System. Operating S~stems Review, 34(5):186-301, D e c e m b e r 1999. [2] G. Banavex, J. Beck, E. Gluzberg, J. Munson, J. Sussman, a n d D. Zukowski. Challenges: A n A p p l i c a t i o n Model for Pervasive C o m p u t i n g . In Proc. ACM MOBIGOM, A u g u s t 2000. [3] D. Clarke. S P K I / S D S I H T T P Server / Certificate Chain Discovery in S P K I / S D S L M a s t e r ' s thesis, M a . ~ a ~ u s e t t s I n s t i t u t e of Technology, 2001. [41 D. Clarke, J.-E. Ellen, C. Ellison, M. F r e d e t t e , A. Morcos, a n d l~. L. Rivest. Certificate C h a i n Discovery in S P K I / S D S I . Journal of Computer Security, 2001. To appear. [5] S. Czerwinski, B. Zhao, T. Hodes, A. Joseph, a n d R. K a t z . A n A r c h i t e c t u r e for a Secure Service Discovery Service. In Proc. MOBICOAI, A u g u s t 1999. [6] M. Dertouzos. T h e F u t u r e of C o m p u t i n g . Scientific American, A u g u s t 1999. [7] C. Ellison, B. Frantz, B. L a m p s o n , R. Pdvest, B. T h o m a s , a n d T. Ylonen. Simple P u b l i c K e y Certificate. The lnternet Society, J u l y 1999. See http://world.std.com/,~cme/spki.txt. [8] P. Eronen a n d P. Nikander. Decentralized Jini Security. In Proc. of the Network and Distributed System Security Symposium, F e b r u a r y 2001. [9] Hewlett-Packard. CoolTown. See http://cooltown.hp.com. [10] Hewlett-Packard. e-Speak. See http://www.e-speak.hp.com. [11] IBM. TSpaces: Intelligent Connectionwexe. See

and authentica-

B o t h of these algorithms were o p t i m i z e d in assembly, which reduced their code size by more t h a n half. T h e code could be b e t t e r optimized, b u t this gives a general idea of how much m e m o r y is required. T h e code size we have a t t a i n e d is small enough t h a t it can be i n c o r p o r a t e d into v i r t u a l l y any device.

6.2.2

Processing Requirements

The security algorithms p u t t h e most d e m a n d on the device. Table 2 breaks down t h e a p p r o ~ m a t e t i m e for each a l g o r i t h m as detailed in [15]. T h e I~C5 processing t i m e varies linearly with the n u m b e r of b y t e s being e n c r y p t e d or decrypted. T h e H M A C - M D 5 routine, on the other hand, takes a c o n s t a n t a m o u n t of t i m e up to 56 bytes. This is because H M A C - M D 5 is designed to work on blocks of d a t a , so a n y t h i n g less t h a n 56 bytes is padded. Since we limit the R F p~cket size to 50 bytes, we only analyze t h e H M A C MD5 running time for packets of size le~s than or equal to 50 bytes.

6.3

SPKI/SDSI E v a l u a t i o n

The protocol described in Section 4 is efficient. T h e first two steps of t h e protocol are a s t a n d a x d r e q u e s t / r e s p o u s e pair; no c r y p t o g r a p h y is required. T h e significant steps in the protocol are step 3, in which a certificate chain is formed, and s t e p 4, where the chain is verified. Table 3 shows analyses of these two steps. T h e p a p e r on Certificate Chain Discovery in S P K I / S D S I [4] should be referred to for a discussion of the t i m i n g analyses. T h e C P U times are app r o x i m a t e times m e a s u r e d on a Sun Microsystems Ultra-1 r u n n i n g SunOS 5.7.

7.

REFERENCES

http:/ /www.aimaxlen.ibm.com/cs/TSpaces. [12] Intel. Intel C o m m o n D a t a Security Architectuxe. See

http://deve]oper.intel.com/iai/security. [13] H. Krawczyk, M. Bellare, a n d R. C a n e t t i . H M A C : K e y e d - H a s h i n g for Message A u t h e n t i c a t i o n . I n t e r n e t Request for C o m m e n t s R F C 2104, F e b r u a r y 1997. [14] A. Maywah. A n I m p l e m e n t a t i o n of a Secure W e b Client Using S P K I / S D S I Certificates. M a s t e r ' s thesis, Massachusetts I n s t i t u t e of Technology, 2000. [15] T. Mills. A n A r c h i t e c t u r e a n d I m p l e m e n t a t i o n of Secure Device C o m m u n i c a t i o n in Oxygen. M a s t e r ' s thesis, Massachusetts I n s t i t u t e of Technology, 2001. [16] OpenSSL. The O p e n S S L Project. http://www.openssl.org. [17] N. P r i y a n t h a . P r o v i d i n g Precise I n d o o r L o c a t i o n I n f o r m a t i o n to Mobile Devices. M a s t e r ' s thesis, Massachusetts I n s t i t u t e of Technology, J a n u a r y 2001.

CONCLUSIONS

We believe t h a t the trends in pervasive c o m p u t i n g axe increasing the diversity a n d heterogeneity of networks a n d their c o n s t i t u e n t devices. Developing security protocols t h a t can h a n d l e diverse, mobile devices networked in various ways represents a m a j o r challenge. In this paper, we have t a k e n a first step t o w a r d meeting this challenge by observing the need for multiple security protocols, each with different characteristics a n d c o m p u t a t i o n a l requirements. W h i l e we have described a p r o t o t y p e s y s t e m with two different protocols, other t y p e s of p r o t o c o l s could be included if deemed neces-

271

Protocol step Cert chain discovery Chain validation

Timing analysis The worst case is O(nal), where n = number of certs, and I = length of longest subject. However, the expected time is O(rd). The worst case is O(n), where n = number of certs.

Approx C P U time 330ms, with n = 2 and l = 2. 200ms, with n ----2.

T a b l e B: P r o x y - t o - P r o x y P r o t o c o l a n a l y s i s .

[18] N. Priyantha, A. Chakraborty, and H. Balakrishnan. The Cricket Location-Support System. In Proc. A C M MOBICOM, August 2000. [19] E. Rescola. SSL and TLS: Designing and Building Secure Systerr~. Addison-Wesley, 2001. [20] R. Bivest. The MD5 Message-Digest Algorithm. Internet Request for Comments R F C 1321, April 1992. [21] R- Rivest. The RC5 Encryption Algorithm. In Proc_ of

the Igg~ Leu~en Workshop on Fast So~uare Encryption, 2001. [22] P~. L. Rivest and B. Lampson. SDSI - A Simple Distributed Security Infrastructure. See http: / /theory.lcs.mit.edu/ rivest/sdsil0.ps. [23] J. H. Seltzer, D. Reed, and D. D. Clark. End-to-End Arguments in System Design. See http: / / w w w . m i t . e d u / ~ Saltzer/publications/endtoend/. [24] F. Stajano. The Resurrecting Duckling - W h a t next? In Proc. of the 8th International Workshop on Security Protocols, April 2000. [25] F. Stajano and K. Anderson. The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks. In Proc. Security Protocols, 7th

International Workshop, 1999. [26] Sun Microsystems Inc. Jini Network Techonology. http'.//www.sun.com/jini. [27] UC Berkeley. The Ninja Project: Enabling Internet-scale Services from Arbitrarily Small Devices. See ht tp: //ninj a.cs.berkeley.edu. [28] UC Berkeley. The OceanStore Project: Providing Global-Scale Persistent Da~a. See http.//oceanstore.cs.berkeley.edu. [29] University of Washington. Portolano: An Expedition into Invisible Computing. See http: //portolana.cs.washington.edu_ [30] M. Weiner. Performance Comparison of Public-key Cryptosystems. R S A Laboratories' Cr~pto Bytes, 4(1)~ 1998-

272