Moving from the Design of Usable Security Technologies to the Design of Useful Secure Applications

(1)

Moving from the Design of Usable Security Technologies

to the Design of Useful Secure Applications

D. K.

Smetters

PARC

3333 Coyote Hill Rd.

Palo Alto, CA, USA

smetters @

parc.com

R. E. Grinter

PARC

3333 Coyote Hill Rd.

Palo Alto, CA, USA

beki @

parc.com

ABSTRACT

Recent results from usability studies of security systems have shown that end-users find them difficult to adopt and use. In this paper we argue t h a t improving the usability of security technology is only one part of the problem, and that what is missed is the need to design usable and useful systems t h a t provide security to end-users in terms of the applications t h a t they use and the tasks they want to achieve. We propose alternate ways of building and integrating security technologies into applications and usability methods for evaluating how successful our prototypes are. We believe that the end results of designing usable and useful (from the end-user perspective) systems will be secure applications which will reflect the needs of users who are increasingly using computers away from the office and in a wider variety of networked configurations.

Categories and Subject Descriptors

D.4.6 [ O p e r a t i n g S y s t e m s Software]: Security and Pro- tection; H.1.2 [ M o d e l s

and Principles]:

User/Machine

Systems--Human factors

General Terms

Human Factors, Security

Keywords

Usable security

1. INTRODUCTION

There is a small, but increasingly vocal movement suggest- ing t h a t usability of security technology may be one of the largest roadblocks standing in the way of increased computer security [29, 1, 26, 27]. Empirical studies have exposed usability problems in password systems [3, 1, 26], access control mechanisms [29, 18, 28], and encryption software [27]. To address these problems, the authors of these studies suggest redesigning applications to be more realistic in what

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that

copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee,

New Security Paradigms Workshop '02, September 23-26, 2002,

Virginia Beach, Virginia.

Copyright 2002 ACM ISBN 1-58113-598-X102/0009 ...$5.00

they expect of users, and education of the users themselves to be more effective participants in system security

(e.g.,

by choosing better passwords). But very little work

(e.g.,

[20, 21, 4]) attempts to design new technologies t h a t solve security problems from a usability perspective.

At the same time, a number of authors have suggested t h a t much "classical" computer security technology is designed for an environment out of step with current computer use and end-user goals [8, 23], and t h a t it may be time for a shift in the design of secure systems [8] in order to provide technology more closely in line with the needs of non-military users. This is supported by recent analyses that adoption of security technologies in the public sector is heavily influ- enced by assessments of risk versus cost [2]. This implies t h a t lack of widespread adoption of a security technology from the research community in commonly-used software may suggest t h a t the technology in question doesn't meet user needs sufficiently well to justify the cost of implement- ing it.

We take the more extreme position t h a t the environment in which security technology is deployed is undergoing rad- ical change, and t h a t change is such t h a t current usability problems are only going to get rapidly worse. We argue t h a t attempting to "add on" usability to existing security technology is no more likely to be successful than attempts to "add on" security to existing software systems designed without it, and t h a t new security technologies need to be designed from the ground up with the user foremost in mind.

To design such new technologies, we have embarked on a research program focused around the question: "if you put usability first, h o w much security can you get?" We approach this question in the context of ubiquitous computing and wireless devices, a context where usability and flexibil- ity are paramount. As part of this program we have begun to design new approaches to integrating security technology into applications, as well as new basic security technologies t h a t enhance usability. We present here several early results of our work and the work of others as examples of new ways to design usable approaches to security.

1.1 Why Now: The Changing Face of Users

The traditional "users" of security technology can be divided into three groups: the developer who integrates security into a system, the administrator who sets policy and monitors se-

(2)

curity for a n u m b e r of u s e r s a n d m a c h i n e s , a n d t h e end-user, w h o m u s t e n s u r e t h a t t h e i r own practices follow a n d help to i m p l e m e n t t h e s e policies. R e s e a r c h to d a t e h a s focused on t h e l a t t e r two groups, a n d in p a r t i c u l a r on how t h e y u s e software w h o s e basic f u n c t i o n is i n h e r e n t l y security-related (see section 2.2).

As c o m p u t i n g leaves t h e d e s k t o p a n d t h e office, s o l u t i o n s like firewalls a n d protocols are b e c o m i n g s o m e t h i n g t h a t e n d - u s e r s m u s t u n d e r s t a n d if t h e y are to protect t h e i r own devices. Moreover, each individual is m o r e likely to have a m u l t i t u d e of devices, s o m e w h i c h will never see a profes- sional s y s t e m a d m i n i s t r a t o r , b u t all of w h i c h m u s t s e a m - lessly work together. In m o r e general t e r m s , e n d - u s e r s are b e c o m i n g their own s y s t e m s a d m i n i s t r a t o r s for increasing n u m b e r s of p o t e n t i a l l y mobile devices [13]. In doing so, u s e r s ' p r i m a r y goals are f r a m e d in t e r m s of t h e work t h e y need to accomplish, n o t in t e r m s of m a n a g i n g security [27, 26], a n d t h e y are n o t s u p p o r t i v e of technologies t h a t pre- v e n t t h e m a c c o m p l i s h i n g t h o s e p r i m a r y goals [24]. A t t h e s a m e t i m e , a t t e m p t s to categorize a p r i o r i in t e r m s of roles or work processes, w h a t t h e y will need to do to a c c o m p l i s h t h o s e goals a n d a r r a n g e t h e n e c e s s a r y privileges to m a t c h , h a v e n o t b e e n successful [18, 8, 23, 24]. If o r g a n i z a t i o n a l roles a n d processes could n o t categorize t h e office work con- d u c t e d on d e s k t o p c o m p u t e r s , t h e n how will a n a p r i o r i categorization succeed in a world w h e r e devices are u s e d at work, at h o m e , a n d in public s e t t i n g s a n d w h e r e t h e s a m e m a c h i n e m a y be u s e d for a m u l t i t u d e of work a n d leisure activities a n d s o m e t i m e s in c o n j u n c t i o n w i t h technologies o w n e d by friends a n d s t r a n g e r s . Indeed, we t h i n k it is u n - likely t h a t a s s o c i a t i n g s e c u r i t y w i t h a p r i o r i c a t e g o r i z a t i o n s will a d e q u a t e l y s u p p o r t end-users.

Now, m o r e t h a n ever, t h e challenge to create c o m p e l l i n g security is one of m a k i n g s e c u r i t y software u s a b l e as well as useful, a n d m a k i n g software t h a t is n o t focused directly on security secure. T h e s e challenges fall s q u a r e l y on t h e shoul- ders of application developers - in essence, a n y prescription f o r d e s i g n i n g secure software m u s t focus in large p a r t on

t h e m .

1.2 Why Now: The Changing Face of Systems

T h e d r a m a t i c increase in h o m e - b a s e d c o m p u t e r networking, t h e m o v e from d e s k t o p c o m p u t e r s a n d centralized servers to laptops, a n d t h e proliferation of s m a l l wireless devices s u c h as P D A s a n d cell p h o n e s h a v e t r e m e n d o u s i m p l i c a t i o n s for c o m p u t e r security, a n d p a r t i c u l a r l y how it is provisioned to a n d by end-users. T h e t r a d i t i o n a l m o d e l of c o m p u t e r security b e g a n a r o u n d controlling access to resources by m a n y users on one central m a c h i n e w h o s e software served as a po- t e n t i a l l y t r u s t e d b a s e [8]. W e are now m o v i n g to a world w h e r e each u s e r m a y h a v e m a n y c o m p u t e r s or c o m p u t i n g devices, of w h o m s / h e is f r e q u e n t l y t h e only user. T h e s e devices are o v e r w h e l m i n g l y mobile, a n d m a y m o v e r e p e a t - edly in a n d o u t of " m a n a g e d " e n v i r o n m e n t s . Devices m a y c o m m u n i c a t e m o r e often w i t h entities o u t s i d e t h e i r m a n - aged s e c u r i t y i n f r a s t r u c t u r e (if t h e y h a v e one) t h a n entities inside it, b u t still m a y need t h e ability t o a u t h e n t i c a t e a n d p r o t e c t t h o s e c o m m u n i c a t i o n s . T h e d i s t i n c t i o n b e t w e e n "clients" a n d "sezvers" b l u r s - even s m a l l wireless devices are servei~ as well as c o n s u m e r s of i n f o r m a t i o n , a n d need to be p r o t e c t e d accordingly. S h a r e d resources t h a t need m o r e

s o p h i s t i c a t e d access control are accessed over a network on s o m e server t h a t m i g h t b e in- or o u t s i d e of t h e device's ad- m i n i s t r a t i v e d o m a i n . A t t h e s a m e t i m e , t h e s e m a c h i n e s still need all of t h e p r o t e c t i o n m e c h a n i s m s designed for a n earlier, m o r e centralized world - b u t i n s t e a d of p r o t e c t i n g s h a r e d resources f r o m o v e r r e a c h i n g u s e r s o n t h e "inside," t h e y are o f t e n p r o t e c t i n g a u s e r ' s m a c h i n e f r o m a c t i o n s t a k e n by m a - licious software or i n t r u d e r s , or even accidental u s e r action.

Devices a n d s y s t e m s designed p r i m a r i l y for d i s t r i b u t e d com- p u t i n g are b e s t served by a different kind of security archi- t e c t u r e t h a n t h e i r m o r e "inwardly" focused predecessors, for w h o m d i s t r i b u t e d c o m p u t i n g was a n occasional nuisance. First, t h e fact t h a t t h e y m a y be o f t e n or always o u t of reach of a m a n a g e d s e c u r i t y i n f r a s t r u c t u r e m e a n s t h a t we need tools t h a t allow e n d - u s e r s to effectively m a n a g e their own security a n d t h a t of t h e i r devices [15, 20], r a t h e r t h a n re- lying m o r e a n d m o r e on centralized or o u t s o u r c e d security services. Second, s u c h devices are likely to rely o n cryptog- r a p h y m o r e heavily to a u t h e n t i c a t e t h e i r c r o s s - d o m a i n in- t e r a c t i o n s [8, 25], a n d to p r o t e c t c o m m u n i c a t i o n s on hostile public networks. Traditionally, s y s t e m d e s i g n s have t e n d e d to m i n i m i z e or avoid t h e u s e of c r y p t o g r a p h y , even w h e n it was t h e right tool for t h e job, b e c a u s e of its perceived slow- n e s s a n d e x p e n s e [6]. A s a result, t h e y h a v e n o t provided m a n y facilities to ease its use by developers. T h o u g h crypto- g r a p h i c libraries are b e c o m i n g u b i q u i t o u s , t h e i n f r a s t r u c t u r e a n d o p e r a t i n g s y s t e m c o m p o n e n t s n e e d e d to s u p p o r t t h e m (see Section 2.1.2) are not.

1.3 What Now: Don't We Just Need a Better

GUI?

T h e r e are t h r e e conclusions we c a n d r a w f r o m t h e fact t h a t users are u n a b l e to m a k e effective use of m u c h of c u r r e n t security technology. First, t h e p r o b l e m could be w i t h t h e users. A really g o o d e n o u g h G U I , slightly redesigned applications, or m o r e effective u s e r e d u c a t i o n a b o u t w h y t h e y o u g h t to choose b e t t e r p a s s w o r d s could be e n o u g h to m a k e t h e m willing a n d able t o tackle s e c u r i t y t a s k s as t h e y are c u r r e n t l y f o r m u l a t e d [26, 24]. T h e r e are indeed cases where usability of p a s s w o r d s y s t e m s c a n b e i m p r o v e d by r e m o v i n g t h e m o s t egregious d e m a n d s on e n d u s e r s [3, 11, 24,'22], or a d d i n g a nice G U I to a fairly s t a n d a r d piece of security software is e n o u g h to m o r e it f r o m t h e rarefied d o m a i n of sys- t e m s a d m i n i s t r a t o r s a n d place it w i t h i n reach of e n d - u s e r s - t h e m o s t effective e x a m p l e of t h i s b e i n g t h e recent slew of firewall p r o g r a m s d e s i g n e d for u s e or~ e n d - u s e r machines. However, e x p e r i m e n t a l results h a v e a l r e a d y s h o w n u s t h a t t h i s is n o t t h e case in general [27] - w r a p p i n g a b e t t e r u s e r interface a r o u n d existing s e c u r i t y t e c h n o l o g y does n o t m a k e users s u d d e n l y able to effectively u s e it.

Second, t h e p r o b l e m m a y be w i t h t h e u s e r s - t h e y m a y s i m p l y be c o m p l e t e l y i n c a p a b l e of u n d e r s t a n d i n g or u s i n g t h e technology, a n d therefore of h a v i n g a n y effective control over t h e i r own security s t a t e . Such risks, a n d s u c h choices m u s t therefore be t a k e n o u t of t h e i r h a n d s , a n d security i m p o s e d on t h e m u n i f o r m l y by s y s t e m s a d m i n i s t r a t o r s o u r o u t s o u r c e d services. Here, research h a s s h o w n u s t h a t s u c h a n a p p r o a c h is first, n o t likely to be flexible e n o u g h to let users a c t u a l l y p e r f o r m t h e i r i n t e n d e d t a s k s [8, 18, 23, 26] a n d second, c o m p l e t e l y in a p p r o p r i a t e to t h e increasingly c o m m o n s i t u a t i o n w h e r e t h e u s e r is t h e s y s t e m a d m i n i s t r a -

(3)

t o r [13].

T h e t h i r d conclusion is t h a t t h e p r o b l e m is primarily w i t h t h e technology, n o t t h e users: even if t h e t e c h n o l o g y is good, it is n o t doing w h a t it was i n t e n d e d to do ( m a k e s y s t e m s m o r e secure

in practice),

a n d b l a m i n g t h e users will n o t m a k e it a n y m o r e effective [24]. T h e m o s t e x p e d i e n t m e t h o d to increase t h e usability of s e c u r i t y technologies a n d appli- c a t i o n s is to build t h e m f r o m t h e g r o u n d u p w i t h usability as their p r i m a r y focus. G i v e n t h a t now is t h e t i m e w h e n n e w security technologies are j u s t b e g i n n i n g to be developed to cope w i t h t h e world of mobile a n d wireless devices a n d ubiq- u i t o u s c o m p u t i n g , now is t h e t i m e to m a k e s u r e t h a t t h o s e n e w technologies focus on u s a b i l i t y f r o m t h e outset.

2. HOW DO WE DESIGN FOR USABLE

SECURITY?

W e p r e s e n t h e r e two of t h e m o s t p r e s s i n g issues facing re- s e a r c h e r s w h o w a n t to design for u s a b l e security: first, how do we look a t security f r o m a software e n g i n e e r i n g perspective, a n d b o t h design p r i m i t i v e s t h a t focus on c o m b i n i n g usability a n d security as well as enable developers to u s e t h e m effectively. Second, how do we assess how well we've done?

2.1 Three Engineering Approaches to

Building Usable Security Technology

2.1.1 Build in Implicit Security

T h e first, a n d p e r h a p s m o s t i m p o r t a n t a p p r o a c h to b u i l d i n g u s a b l e s e c u r i t y t e c h n o l o g y is to a t t e m p t to build w h a t we call

implicit security

into a p p l i c a t i o n s - to u n i f y t h e often " s e p a r a t e b u t ( u n ) e q u a l " views t h e u s e r is forced to have of application goals a n d s e c u r i t y o p e r a t i o n s . A p p l i c a t i o n s w h i c h e n d e a v o r to be "security-agnostic," a n d to rely en- tirely on OS s e c u r i t y m e c h a n i s m s w i t h o u t building in a n y explicit security knowledge of t h e i r own suffer from t h e fol- lowing problem: s e c u r i t y lives in s e p a r a t e , parallel universe t h a t t h e u s e r m u s t act on in a d d i t i o n to w h a t e v e r a c t i o n s are n e e d e d to "directly" a c c o m p l i s h t h e i r desired task.

For i n s t a n c e , t a k e t h e s i m p l e t a s k of giving a file to a n o t h e r user. To t e m p o r a r i l y s h a r e a file u s i n g s t a n d a r d file s h a r i n g protocols, you m u s t b o t h o p t to s h a r e t h e file a n d c h a n g e t h e file p e r m i s s i o n s so t h a t t h e d e s t i n a t i o n p a r t y (or, if t h e d e s t i n a t i o n p a r t y is n o t a m e m b e r of y o u r security infras- t r u c t u r e a n d c a n n o t be so n a m e d , " e v e r y b o d y " ) c a n access t h a t file. A f t e r w a r d , y o u b o t h have to r e m e m b e r to " t u r n it all off" - to c h a n g e y o u r s e c u r i t y s e t t i n g s back again. In o t h e r words, for each t a s k - o r i e n t e d action, t h e u s e r m u s t p e r f o r m one or m o r e m a n u a l s t e p s to m a n u a l l y mirror t h o s e a p p l i c a t i o n goals in t e r m s of o p e r a t i n g s y s t e m security settings. C o n t r a s t t h a t w i t h t h e s t e p s needed to t r a n s f e r t h e d o c u m e n t u s i n g email. Y o u r access to t h e d o c u m e n t is de- t e r m i n e d a t t h e p o i n t at w h i c h you a t t a c h it to t h e emall message. Y o u r decision to give t h e d e s t i n a t i o n p a r t y access to t h e d o c u m e n t is i n d i c a t e d by y o u r c h o o s i n g to a t t a c h it to a mail m e s s a g e a d d r e s s e d to t h e m . If you are able to s e n d t h e m e s s a g e to t h e m e n c r y p t e d u n d e r a key you know to be theirs, y o u c a n be r e a s o n a b l y confident t h a t t h e y have a c t u a l l y s u c c e e d e d in t r a n s f e r r i n g t h e d o c u m e n t to

them.

In o t h e r words, y o u r s e c u r i t y - r e l a t e d a c t i o n s c a n be deter- m i n e d

implicitly

f r o m y o u r goal-directed actions. T h e y do

n o t require separate, error-prone layer of m i r r o r i n g actions on y o u r part.

We have b e g u n to explore t h e d e s i g n of a p p l i c a t i o n s t h a t c a n t a k e a d v a n t a g e of o p p o r t u n i t i e s for

implicit security -

w h e r e t h e u s e r t a k e s a n action t h a t i n d i c a t e s b o t h a n application goal a n d a required,

implied

s e c u r i t y operation, h a v e t h e s e occur a u t o m a t i c a l l y as a single s t e p r a t h e r t h a n r e q u i r i n g t h e u s e r to p e r f o r m m u l t i p l e parallel o p e r a t i o n s (see Section 3.3). In s u c h a n application, t h e u s e r p e r f o r m s only a c t i o n s designed to a c c o m p l i s h a p p l i c a t i o n goals, a n d t h e a p p l i c a t i o n software a u t o m a t i c a l l y invokes t h e required parallel s e c u r i t y - r e l a t e d actions.

A simple a n d effective e x a m p l e of s u c h a n a p p l i c a t i o n is t h e Secure Shell (SSH [5]). SSH allows a u s e r to m a k e a t t y - b a s e d c o n n e c t i o n to a n o t h e r m a c h i n e in a fashion al- m o s t identical (in t e r m s of u s e r experience) to t h a t u s e d by Telnet. However, t h e c o n n e c t i o n m a d e by SSH is en- c r y p t e d a n d a u t h e n t i c a t e d . SSH offers fairly s o p h i s t i c a t e d key m a n a g e m e n t a n d c o n f i g u r a t i o n options, b u t by default t h e s e are n o t visible to t h e e n d - u s e r . In its default configuration, u s e r s are a u t h e n t i c a t e d to t h e i r t a r g e t s y s t e m u s i n g s t a n d a r d p a s s w o r d - b a s e d logins, b u t t h o s e p a s s w o r d s are t r a n s m i t t e d over t h e e n c r y p t e d t u n n e l . W h i l e t h e first t i m e a u s e r logs into a t a r g e t m a c h i n e , its public key is likely to be accepted b a s e d on f a i t h ( t h o u g h t h e u s e r is given a u n - o b t r u s i v e option to verify t h e key, a n d s o p h i s t i c a t e d users c a n pre-configure t h e s y s t e m w i t h k n o w n keys for i m p o r t a n t t a r g e t m a c h i n e s ) , t h e a p p l i c a t i o n automatic'ally t r a c k s t h e keys of m a c h i n e s t h e u s e r h a s c o n n e c t e d to, a n d will w a r n t h e u s e r if t h e t a r g e t m a c h i n e p r e s e n t s a different key t h a n t h e one it h a s u s e d previously. SSH i n s t a l l a t i o n is s t a n d a r d on m a n y (primarily U n i x - b a s e d ) o p e r a t i n g s y s t e m s , a n d is i n c r e a s i n g l y effectively set u p to a u t o - c o n f i g u r e i t s e l f -

e.g.,

to g e n e r a t e a n d store its l o n g - t e r m m a c h i n e key pairs a u t o - m a t i c a l l y t h e first t i m e it is executed.

W h i l e it is n o t possible to s e a m l e s s l y i n t e g r a t e s e c u r i t y a n d u s e r goals in every s i t u a t i o n , we believe it is a valuable a n d i m p o r t a n t technique. Such a p p l i c a t i o n s h a v e t h e a d v a n t a g e of p u t t i n g t h e u s e r ' s goals first a n d f o r e m o s t , a n d a t t e m p t to let t h e u s e r a c c o m p l i s h t h o s e goals as directly as possible while a t t h e s a m e t i m e n o t lowering t h e a c t u a l security of t h e m s e l v e s or o t h e r s in a n y w a y n o t r e q u i r e d t o a c c o m p l i s h t h a t goal. 1 A p p l i c a t i o n s d e s i g n e d in s u c h a f a s h i o n c a n be, a t m i n i m u m , drop-in r e p l a c e m e n t s for earlier, less secure versions; at b e s t s u c h a p p l i c a t i o n s t a k e a d v a n t a g e of security technologies to enable n e w activities a t t r a c t i v e t o end-users.

2.1.2 Refactoring Security Infrastructure

T h e r e is a c o n s t a n t t e n s i o n in t h e design of t e c h n o l o g y between w h i c h f u n d a m e n t a l s e c u r i t y m e c h a n i s m s are p a r t of t h e o p e r a t i n g s y s t e m a n d d o m a i n i n f r a s t r u c t u r e , a n d which are ~ left to applications. Facilities p r o v i d e d by t h e o p e r a t - i n g s y s t e m have t h e a d v a n t a g e t h a t t h e y c a n be m u c h m o r e strictly enforced, a n d only h a v e to be w r i t t e n once. Facili- ties provided by a p p l i c a t i o n s m u s t f r e q u e n t l y be r e i n v e n t e d a n e w for every application, a n d are w r i t t e n by a p p l i c a t i o n 1Also n o t e t h a t even in c a s e s w h e r e s u c h a n a p p r o a c h would lower t h e theoretical s e c u r i t y of a s y s t e m , it m a y increase t h e s y s t e m ' s

effective

security, as u s e r s will now use w h a t security m e a s u r e s are in place.

(4)

developers who have little interest in and experience with security. Given these criteria, it is usually t h o u g h t t h a t as little security as possible should be left to applications.

E m p h a s i z i n g "security-agnostic" applications causes two ma- jor problems: first, it is often only t h e application t h a t has sufficient contextual information to be able to make flexible decisions about access and trust. Second, such applications cannot use t h e techniques described above to unify user goals and required security operations, and must re- sort to painful manual mirroring techniques to keep t h e two worlds in step.

At t h e same time, t h e r e are a n u m b e r of c o m m o n infras- t r u c t u r e c o m p o n e n t s t h a t are best h a n d l e d by t h e operating system, a n d an even larger n u m b e r t h a t will be needed by so many applications t h a t it is simply more effective to write t h e m once and provide t h e m as a service. S t a n d a r d software engineering techniques such as refactoring [16] can be used to identify such c o m m o n components. Many such c o m p o n e n t s

(e.g.,

a source of secure r a n d o m numbers, a relatively secure place to store keying information, a place to store system-wide t r u s t information a n d a way for domain a d m i n i s t r a t o r s to u p d a t e it,

etc. )

are provided by at least one of t h e m a j o r operating s y s t e m s in current use, b u t no single s y s t e m provides t h e m all. It would greatly ease development of applications t h a t want to use security technology if t h e y could simply rely on every OS to provide such facilities. It would also ease development of applications t h a t would allow d o m a i n - b a s e d m a n a g e m e n t of some of these components. While such facilities could be provided by a highly portable add-on toolkit instead of incorporating t h e m into t h e OS itself, such a toolkit would have to be ubiquitous enough t h a t developers could rely on its presence, r a t h e r t h a n having t o provide it as an e x t r a c o m p o n e n t to install themselves, b e stable and effective enough t h a t there w o u l d n ' t be a lot of overhead involved in version c o m p a t - ibility problems, or dealing with incompatible, c o m p e t i n g toolkits, a n d comprehensive enough t o provide all of t h e facilities needed (though this latter problem could be solved by a s t a n d a r d suite of tools). T h e security-related classes provided by t h e JavaWMclass libraries, and t h e combination of t h e OpenSSL toolkit and / d e v / r a n d o m on Linux begin to achieve this approach for a subset of t h e functionality we describe here.

2.1.3 Building LegoTMBricks for Security

• Finally, we have noticed t h a t well-designed security technologies packaged as reusable c o m p o n e n t s t h a t accomplish a single task effectively are enthusiastically a d o p t e d by application developers. A notable case in point is t h e S S L / T L S protocol [12], a s . i m p l e m e n t e d in a n u m b e r of easily obtain- able, fast, and reliable libraries such as OpenSSL a n d Sun's s t a n d a r d JavaTMimplementation. Developers a n d designers w h o are normally n o t comfortable with security technology or e r y p t o g r a p h y are comfortable with SSL, a l m o s t to ex- t r e m e s - "secure systems" becomes almost synonymous with "systems t h a t use SSL," w h e t h e r or n o t SSL is an appropriate tool for t h e security problems at hand. Kerberos [25] has also provided a frequently reused set of software tools enabling application, developers to take advantage of au- t h e n t i c a t i o n tecl:molc~gies - in this case even to t h e point of creating a new verb, to "kerberize" a piece of software.

Similarly, technologies we have designed for a u t h e n t i c a t i n g secure connections in ad-hoc networks have seen effective re- use (see section 3.2). We believe t h a t application developers can begin to make effective use of very goal-oriented security technologies if provided in forms like these, a n d have begun actively looking for c o m m o n security problems in need of such reusable solutions.

Similarly, we believe t h e field would benefit from creating a n d using security-related software idioms or "patterns" sim- ilar to t h e software use p a t t e r n s c o m m o n in other areas of development [17, 9]. These could help developers less sophis- ticated in t h e use of security technology to u n d e r s t a n d how to incorporate it more effectively into their applications.

2.2 Usability of Security Software is Not

(Necessarily) Software Security Usability

Traditional approaches to usability t e s t i n g focus on observing and interviewing end-users (either in their real-world setting using techniques such as contextual inquiry [7], or in an experimental s e t t i n g such as a usability lab). T h e test criteria focus assessing t h e end-users ability to use t h e application to get .their own or an e x p e r i m e n t a l task done. Suc- cess can be measured objectively using metrics such as task completion t i m e a n d subjectively using interview questions (during t h e experience or afterward) to find o u t w h e t h e r t h e user found t h e s y s t e m easy t o use and enjoyed t h e experience.

A fundamental problem arises w h e n t r y i n g t o apply these approaches to evaluate t h e usability of security technology. Usability m e t h o d s test t h e usability of end-user applications, and t h e r e are very few end-user security applications. Us- ability testing of security to d a t e has focused on security applications or end-user visible security mechanisms includ- ing encryption software [27], password mechanisms [1, 3, 26, 24], a n d user interfaces for m a n a g i n g policy [28].

In other words, "usability of security" t e n d s to be defined as "usability of security-related applications." While usability of security-related applications continues to b e a p a r t of t h e challenge, we need to b r o a d e n a n d refine our methodological base. This is especially i m p o r t a n t with d i s t r i b u t e d systems where every piece of software has t o deal with security issues implicitly or explicitly.

We propose t h r e e ways of usability t e s t i n g t h e usability Of secure applications. Each relies on t h e traditional foundations of d a t a gathering: recording, observing, a n d interviewing. W h a t we argue here is t h a t we need to reformulate traditional usability testing approaches to a c c o m m o d a t e t h e fact t h a t security is not t h e p r i m a r y focus of a t t e n t i o n from t h e end-user perspective, and yet it is end-users' usage t h a t we are most concerned with.

First, we can make use of d a t a logs. D a t a logs built into t h e applications can check certain secure s y s t e m behaviors. For example, w h e n an ~tpplication sends or receives d a t a logs of w h a t was t r a n s m i t t e d can show us w h e t h e r t h a t d a t a was encrypted. O n e disadvantage of d a t a logs is t h a t end-users have to be informed a b o u t their presence (to ensure fair t r e a t m e n t as subjects in t h e study). Specifically, we need to provide information a b o u t w h a t is being logged, why, how

(5)

the data will be used, and who will get to access those logs. This can be handled as part of the consent procedure.

Second, we need to design our studies, whether they be experimental or in the field, to ensure that end-users perform tasks t h a t require the use of the security infrastructure. In an experimental approach this requires designing tasks that involve actions and reactions by the end-user that will utilize the security infrastructure. In a contextual inquiry approach where the usability tester observes the end-user doing their normal computing routines at their place of computer use (at work, in a public space, at home) this will require finding appropriate activities t h a t happen "in the wild." Finding naturally occurring "candidate activities" t h a t have security implications can be achieved using fieldwork techniques, such observing and asking questions of potential users about the kinds of work t h a t they are doing and what it involves. After deploying the software the usability tester then vis- its the end-users when they axe most likely to be engaged in those candidate activities and observes whether the software is still helping them achieve their goals.

Third we need to reconsider how and about what we interview individuals about. Asking direct questions about security creates two problems. First, since we have chosen at times to make the security a seamless part of the application (from the end-user perspective) it will be difficult for them to answer questions about things they have not seen or done. Second, asking them questions about security may lead them to change their own sense of security during the interview itself. Despite these difficulties, we can design our interviews to achieve two purposes: ensure t h a t the end-user has a positive "user experience" and focus in on occasions where applications made security decisions visible. By the latter, we mean focus on the times when the security infrastructure requires that the user make choices about what to do and how to do it. 'We can frame these in terms of the application behavior and other real-world concepts such as privacy.

Finally, in addition to considering the role of human-computer interaction (HCI) for evaluating systems, we also propose considering methods for design. Specifically, fieldwork techniques could also be used to observe candidate settings for secure applications. The results from these kinds of obser- vations and interviews could support the design of end-user applications t h a t leverage the security infrastructure and help it fit (from the end-user perspective) into the activities that are a feature of the setting. In other words, field methods can serve in the requirements part of the software life-cycle as well as the evaluation part.

3. BEGINNING TO GET IT RIGHT:

EXAMPLE NEW TECHNOLOGIES AND

APPLICATIONS

We present here three examples of technologies and applications t h a t turn security on its head, and look at it from the user's point of view. All three are in active development, and future user testing will tell whether they achieve their goals of putting usable security directly into the hands of the user.

3.1 Identity-Based Encryption

One of the most fundamental problems in all of cryptogra- phy is K e y M a n a g e m e n t - getting the right keys to the right places at the right times, and being able to trust t h a t you have actually done so correctly. If it is difficult for cryp- tographers to design in theory, it is well nigh impossible for end-users to handle in practice - and yet the basic operations of key management, namely key pair generation, storage, and public key exchange are those a user must sue- cessfully go through in order to begin an application task like exchanging encrypted email [27].

Boneh and Franklin [10] have recently found a practical solution of a long-standing problem in cryptographic research t h a t turns this user problem on its head. An identity-based encryption scheme is one where there is a set of (global or domain-specific) parameters shared by all users, and given those parameters, a user's public key can be any arbitrary string - e.g., "beki~parc.com." If you know the system parameters (which you will either get as part of the installa- tion of your mail client, or which your client could retrieve automatically from the DNS server of the intended recipient's domain), you know your intended recipient's public key. You don't need to do any explicit work up front in order to be able to send encrypted email to a particular recipient. When t h a t person receives the encrypted mail, either their mail client already has a copy of their private key and can decrypt it, or they are prompted to perform a one-time retrieval of their private key from the (global or domain-specific) key server, after which they can decrypt new messages automatically. Such a system tauts the great- est demands (one-time retrieval of a private key) on the user who gains the most reward (ability to decrypt encrypted email). Such an incentive structure is much more likely to succeed [19] than one t h a t forces the sending user to make a decision every time about whether this email is sensitive enough to require obtaining the recipient's public key, or whether they might as well send it unenerypted "just this once."

A demonstration system for identity-based encryption and a plug-in for the Eudora email client program are available on the Internet (http://crypto.stanford.edu/ibe). Work is ongoing in our group and others to take advantage of IBE's usability properties to enable secure networking (IPSEC), and extend its use in email.

3.2 Authentication for Ad Hoc Networks

An increasingly common problem faced by users is t h a t many of the devices and individuals they wish to securely communicate with are not part of their own infrastructure or security domain. Existing security technology concentrates primarily on making authentication and access control decisions about users and activities within t h a t domain, and as- sumes t h a t no interaction will occur with entities outside the domain without much prior infrastructure arrangement [8, 25]. Cryptographic approaches allow users to exchange data securely with anyone with whom they can exchange an au- thenticated public key, but current applications don't provide easy ways to let users take advantage of this fact. This means that users have no tools to use to perform secure operations t h a t target or "name" entities outside of their existing security domain, and t h a t non-infrastructure users

(6)

(e.g., h o m e u s e r s or s m a l l o r g a n i z a t i o n s ) m u s t p u t in t h e effort to build an i n f r a s t r u c t u r e before t h e y c a n secure a n y of t h e i r c o m m u n i c a t i o n s .

A s e t t i n g w h e r e t h i s is p a r t i c u l a r l y i m p o r t a n t is t h a t of wireless a d - h o c networking: secure c o m m u n i c a t i o n between ar- b i t r a r y co-located devices t h a t s h a r e no a priori t r u s t infor- m a t i o n o t h e r t h a n t h a t t h e i r owners wish t h e m to c o m m u - nicate w i t h each other. In p a r t i c u l a r , we w a n t to c a p t u r e t h e u s e r i n t u i t i o n t h a t t h e y w a n t t h e i r device to c o m m u - nicate (only) w i t h that p a r t i c u l a r c o m m u n i c a t i o n p a r t n e r - to have t h e act of p o i n t i n g o u t w h o y o u w a n t to talk to also implicitly indicate to t h e software w h o was a u t h e n t i - c a t e d to c o m m u n i c a t e w i t h you. T h e devices in q u e s t i o n are typically mobile a n d c o m m u n i c a t i n g p r i m a r i l y over a n u n s e c u r e d wireless network, so are at g r e a t risk for m a n - i n - t h e - m i d d l e attacks.

O u r solution involves c o m b i n i n g s e n ~ i n g a s m a l l a m o u n t of a u t h e n t i c a t i o n i n f o r m a t i o n over a privileged, physically con- s t r a i n e d channel, w i t h a key e x c h a n g e p e r f o r m e d over t h e m a i n wireless link [4]. T h e a u t h e n t i c a t i o n i n f o r m a t i o n is c o m p r i s e d of a c o m m i t m e n t to a public key, a n d "helper" i n f o r m a t i o n like t h e s o u r c e ' s c u r r e n t I P a d d r e s s a n d desired c o n t a c t port. T h i s a u t h e n t i c a t i o n i n f o r m a t i o n is t r a n s m i t - t e d over a c h a n n e l s u c h as infrared or c o n t a c t t h a t h a s t h e p r o p e r t y t h a t it is difficult for a n a t t a c k e r to t r a n s m i t t h e i r own d a t a in t h a t c h a n n e l w i t h o u t b e i n g detected. T h e protocol is i m m u n e to e a v e s d r o p p i n g a t t a c k e r s w h o s i m p l y listen in on either t h e privileged c h a n n e l or t h e m a i n wireless link; t h e y d o n ' t know t h e a p p r o p r i a t e private keys to be able to i m p e r s o n a t e a l e g i t i m a t e conversant.

T h i s a p p r o a c h h a s m a n y a d v a n t a g e s (see [4] for c o m p l e t e details): from t h e u s e r ' s p o i n t of view, t h e y are s i m p l y "point- ing out" t h e printer, laptop, or o t h e r device w i t h which t h e y w a n t to e x c h a n g e i n f o r m a t i o n u s i n g c o n t a c t or IR; t h e sys- t e m s t e p s in to m a k e s u r e t h a t t h e y are only e x c h a n g i n g i n f o r m a t i o n w i t h t h a t desired t a r g e t device. 2 A n y s t a n - dard, t r u s t e d , public-key-based key e x c h a n g e protocol (e.g.,

SSL) m a y be u s e d over t h e wireless link to secure t h e bulk of c o m m u n i c a t i o n . Devices m a y u s e single-use e p h e m e r a l keys to m a i n t a i n t h e i r privacy, or l o n g - t e r m keys to allow t h i s one a u t h e n t i c a t i o n e v e n t r e q u i r i n g physical p r o x i m i t y to b o o t s t r a p secure c o m m u n i c a t i o n f r o m a r b i t r a r y locations in t h e future. Devices need no p r e - e x i s t i n g t r u s t i n f r a s t r u c - t u r e or resolvable " n a m e s , " b u t c a n t a k e a d v a n t a g e of t h e m if t h e y have t h e m - e.g., a n employee from a corporation, X, t h a t h a s an e s t a b l i s h e d P K I , c a n u s e t h i s a p p r o a c h to easily identify t h e particular C o r p o r a t i o n X employee he wishes to c o m m u n i c a t e w i t h now. His software c a n b o t h e n s u r e t h a t h e c a n only t a l k to C o r p o r a t i o n X employees a n d use t h e t a r g e t ' s keying i n f o r m a t i o n to i n d e x into t h e c o m p a n y d a t a b a s e to p r e s e n t a d d i t i o n a l i n f o r m a t i o n a b o u t t h e target (e.g., n a m e , p h o t o ) to t h e user. A d d i t i o n a l privileged c h a n n e l t y p e s w i t h broadcast capability, e.g., a n audio c h a n - nel, c a n be u s e d to securely b o o t s t r a p g r o u p key e x c h a n g e

2 T h a t device may. be malicious, b u t t h a t is t h e risk of choosing to' talk to s t r a n g e r s . We believe t h a t it s h o u l d be possi~ ble for t h e u s e r to a s s u m e t h e risk of t a l k i n g to a p a r t i c u l a r u n k n o w n device w i t h o u t forcing t h e m also to expose t h e m - selves a n d t h a t c o m m u n i c a t i o n to every o t h e r device able to listen to t h e wireless network.

protocols, for i n s t a n c e in a conference s e t t i n g .

T h i s simple solution to a c o n s t r a i n e d p r o b l e m h a s b e c o m e a b u i l d i n g block, like SSL, t h a t we find useful in a n increasing n u m b e r of applications. W e t h i n k t h a t t h e d e v e l o p m e n t of s u c h "usable security" p r i m i t i v e s will g r e a t l y ease f u t u r e d e v e l o p m e n t of secure applications.

3.3 Application Tasks with Implicit Security

In Section 2.1 we s u g g e s t e d t h a t w h e n possible applications be designed u s i n g implicit security - w h e n a u s e r t a k e s an action in application t e r m s , s / h e also t a k e s a security action - t h e a c t i o n s are coupled, a n d c a n n o t be s e p a r a t e d . T h i s reduces t h e r e q u i r e m e n t s on t h e user, a n d helps to prevent t h e p r o b l e m s of " d a n g l i n g s e c u r i t y s t a t e " - w h e r e t h e sys- t e m ' s security c o n f i g u r a t i o n is n o t in s t e p w i t h w h a t t h e user sees, b e c a u s e s / h e h a s f o r g o t t e n to t a k e one of t h e explicit m i r r o r i n g a c t i o n s n e c e s s a r y to keep t h e two in sync. A p p l i c a t i o n s t h a t t a k e t h i s a p p r o a c h c a n m u c h m o r e easily m a k e b o t h a p p l i c a t i o n a n d s e c u r i t y s t a t e visible to t h e user at all t i m e s - s u c h reflection m a k e s it m u c h easier for t h e u s e r to avoid m i s t a k e s a n d m a k e effective security ( a n d even privacy) decisions [27, 2 9 , 2 8 , 14].

A n application we are c u r r e n t l y developing [14] t a k e s t h i s a p p r o a c h to l e t t i n g u s e r s s h a r e n o t o n l y files, b u t services - access to printers, projectors, etc. In t h i s application, users w h o wish to s h a r e t h i n g s w i t h each o t h e r set u p a s h a r e d "space." Users invited to join t h e s p a c e c a n see t h e o b j e c t s a n d services in t h e "space," a n d k n o w w h e n o t h e r users are a d d e d t o t h e space. To s h a r e a file or a service w i t h t h e o t h e r m e m b e r s of a space, a u s e r s i m p l y d r o p s t h e object o n t o t h a t space; it t h e n b e c o m e s visible to b o t h t h e m a n d t h e o t h e r s p a c e m e m b e r s . T h i s interface conflates visibility w i t h access - if you c a n see it, y o u c a n u s e it, a n d if you c a n ' t use it, you d o n ' t even know i t ' s there. Similarly, t h e application m a k e s it i m m e d i a t e l y visible to t h e u s e r w h a t t h e y are m a k i n g accessible to o t h e r s - all d a t a a n d services t h a t are s h a r e d w i t h a n y s p a c e are listed explic!tly in a des- i g n a t e d p a n e l of t h e application, m a k i n g it e a s y for t h e m to rapidly remove a n y s h a r e d object f r o m all 'spaces. I n s o m e sense, security is p r i m a r y in t h i s a p p l i c a t i o n , as t h e concept of a "space" is basically a n access concept.

A t t h e s a m e t i m e t h i s access i n f o r m a t i o n is visible to t h e user, t h e details of how it is i m p l e m e n t e d are not. Security- related t a s k s h a p p e n s e a m l e s s l y as p a r t of u s e r actions directed toward explicitly a p p l i c a t i o n goals. C r e a t i n g a space c a u s e s t h e creation of root credentials t h a t will be u s e d to secure access to t h a t space. A d d i n g s o m e o n e to t h e space involves in p a r t g e n e r a t i n g credentials for t h e m , t h a t t h e y will later use to prove to o t h e r m e m b e r s of t h e space t h a t t h e y belong to t h e space. T h e s e credentials are created by t h e u s e r t h a t chose to a d d t h e m t o t h e s p a c e (by t h a t u s e r ' s software, w i t h o u t t h e i r direct involvement). T h e s e credentials (essentially public key certificates) allow all m e m b e r s of t h e s p a c e to a u t h e n t i c a t e o t h e r m e m b e r s of t h e space, even if t h e y were invited in by different people, a n d m a p o n t o t h e X509 certificates e x p e c t e d by s t a n d a r d SSL i m p l e m e n - t a t i o n s , so provide a n e a s y m e a n s to e n c r y p t a n d p r o t e c t t h e integrity of all c o m m u n i c a t i o n b e t w e e n devices involved in t h e space. F u t u r e u s e r t e s t i n g w i t h t h i s application will m a k e it clear w h e t h e r we h a v e m e t o u r goal of m a t c h i n g

(7)

application goals and security actions.

4. CONCLUSIONS

Ubiquitous computing makes usability a critical challenge for security. W h a t has not been clear is the right way to address this problem. We propose a more extreme view t h a n has previously been taken: t h a t underlying security technology must change, and must be redesigned from the beginning with usability in mind. We have provided several examples of cryptographic and security technologies developed using such an approach, and are currently embarking on a research program to develop systems using these technologies and test t h e m with users. We believe t h a t this will require collaboration between the human-computer interaction and security research communities (as is already beginning at this workshop) to ensure t h a t systems are usable and secure. It will be a combination of these interactions t h a t will make security useful for end-users.

5. REFERENCES

[1] A. Adams and M. A. Sasse. Users axe not the enemy: Why users compromise computer computer security mechanisms and how to take remedial measures.

Communications of the A CM,

42:40-46, December 1999.

[2] R. Anderson. Why information security is hard - an

economic perspective. In

Proceedings of the 17th

Annual Computer Security Applications Conference,

2001.

[3] R. J. Anderson.

Security Engineering: A Guide to

Building Dependable Distributed Systems.

John Wiley and Sons, 2001.

[4] D. Balfanz, D. K. Smetters, P. Stewart, and H. C. Wong. Talking to strangers: Authentication in ad-hoc

wireless networks. In

Proceedings of Network and

Distributed System Security Symposium 2002

(NDSS'02),

San Diego, CA, February 2002.

[5] D. J. Barrett and R. E. Silverman.

SSH The Secure

Shell.

O'Reilly, 2001.

[6] T. A. Berson. Cryptographic abundance.

Technology

Review,

105:90-93, 2002.

[7] H. Beyer and K. Holtzblatt.

Contextual Design: A

Customer-Centered Approach to Systems Design.

Morgan Kaufmann, San Francisco, CA, 1997. [8] R. Blakely. The emperor's old armor. In C. Meadows,

editor,

New Security Paradigms Workshop.

ACM,

1996.

[9] R. Blakley. Security design patterns. http://www.opengroup.org/security/gsp.htm. [10] D. Boneh and M. Franklin. Identity-based encryption

from the Weil pairing. In

Proc. CRYPTO 01,

pages

213-229. Springer-Verlag, 2001. LNCS 2139. [11] R. Dhamija and A. Perrig. Dejh vu: A user s t u d y

using images for authentication. In

Proceedings of the

9th USENIX Security Symposium,

2000.

[12] T. Dierks and C. Allen.

The TLS Protocol Version

1.0.

I E T F - Network Working Group, The Internet Society, January 1999. RFC 2246.

[13] W. K. Edwards and R. E. Grinter. At home with

ubiquitous computing: Seven challenges. In

UbiComp

'01,

Atlanta, September 2001. Springer-Verlag. LNCS 2201.

[14] W. K. Edwards, M. Newman, T. F. Smith, J. Sedivy, D. Balfanz, D. K. Smetters, H. C. Wong, and S. Izadi. Speakeasy: an extensible framework for peer-to-peer

collaboration. In

Proceedings of the Conference on

Computer-Supported Cooperative Work.

ACM Press, 2002.

[15] C. M. Ellison. Establishing identity without

certification authorities. In

Proceedings of the 6th

USENIX Security Symposium,

San Jose, July 1996.

[16] M. Fowler.

Refactoring: Improving the Design of

Existing Code.

Addison-Wesley, 1999.

[17] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.

Design Patterns: Elements of Reusable

Object-Oriented Software.

Addison-Wesley, 1995. [18] R. E. Grinter. Supporting articulation work using

configuration management systems.

Computer

Supported Cooperative Work: The Journal of

Collaborative Computing,

5(4):447-465, 1996. [19] J. Grudin. Why CSCW applications fail: problems in

the design and evaluation of organization of

organizational interfaces. In

Proceedings of the

Conference on Computer-Supported Cooperative Work,

pages 85-93. ACM Press, 1988.

[20] U. HolmstrSm. User-centered design of security

software. In

Human Factors in Telecommunications,

Copenhagen, Denmark, May 1999.

[21] U. Jendricke and D. G. tom Markotten. Usability meets security - the identity-manager as your personal

security assistant for the internet. In

Proceedings of

the 16th Annual Computer Security Applications

Conference,

2000.

[22] I. Jermyn, A. Mayer, F. Monrose, M. K. Reiter, and A. D. Rubin. The design and analysis of graphical

passwords. In

Proceedings of the 8th USENIX Security

Symposium,

Washington DC, 1999.

[23] D. Povey. Optimistic security: a new access control

paradigm. In

New Security Paradigms Workshop,

Arlington, VA, 1999. ACM.

[24] M. A. Sasse, S. Brostoff, and D. Weirich.

Transforming the 'weakest link' - a h u m a n / c o m p u t e r interaction approach to usable and effective security.

B T Technology Journal,

19(3):122-131, July 2001. [25] J. G. Steiner, C. Neuman, and J. I. Schiller. Kerberos:

An authentication service for open network systems.

In USENIX Association, editor,

USENIX Conference

Proceedings (Dallas, TX, USA),

pages 191-202, Berkeley, CA, USA, Winter 1988. USENIX Association.

(8)

[26] D. Weirich and M. A. Sasse. Pretty good persuasion: A first step towards effective password security for the

real world. In

New Security Paradigms Workshop,

pages 137-143, Cloudcroft, NM, 2001. ACM. [27] A. Whitten and J. D. Tygar. Why Johnny can't

encrypt: A usability evaluation of PGP 5.0. In

Proceedings of/the 8th USENIX Security Symposium,

Washington, DC, August 1999.

[28] M. E. Zurko, R. Simon, and T. Sanfilippo. A user-centered, modular authorization service built on

an RBAC foundation. In

IEEE Symposium on

Security and Privacy,

pages 57-71, 1999.

[29] M. E. Zurko and R. T. Simon. User-centered security.

In C. Meadows, editor,