Section 16.3. Making PKI Usable


16.3. Making PKI Usable

Can PKI technology be made usable? The following examples argue strongly that with new approaches to design, it is possible to build "instant" public key infrastructures that are both easy to use and, through the use of public key cryptography, highly secure.

16.3.1. Case Study: "Network-in-a-Box"

Wireless local area networks are becoming increasingly popular in homes and small offices. Unfortunately, such networks have been subject to a number of high-profile security problems, leaving users' machines vulnerable to attackersnot only those on their block, but also those accessing their network from quite a distance using high-gain antennas. Such networks can be secured, using new standards. However, the more secure the network, the more difficult it usually is to set up and configure (see the following sidebar for an example).

CASE STUDY: TRADITIONAL PKI DEPLOYMENT FOR AN ENTERPRISE WIRELESS NETWORK

When we set up a wireless local area network (WLAN) at the Palo Alto Research Center (PARC), we opted for a PKI-based solution. This promised better security and better ease of use than a password-based system. The idea was to give each of about 200 users an X.509 certificate and to use the 802.1x wireless standard's Extensible Authentication Protocol in TLS mode (802.1x EAP-TLS[a], [b]) to authenticate to the wireless network.[c] Users requested and retrieved their certificates via a fairly automated, standard web-based interface, and configured their devices via the GUI-based 802.1x configuration software supplied with Microsoft Windows XP. To help users enroll, our administrators produced an elaborate set of instructions.

We studied eight subjects' experiences enrolling in the wireless PKI. Our subjects were sophisticated computer users, typically holding Ph.D.s in computer science. Despite using the GUI-based interface for enrollment and configuration of their machines, the process involved a total of 38 distinct steps. Each of these presented an opportunity for end users to make frustrating mistakes. The average time that it took them to request and retrieve their certificate and then configure their system was 140 minutes.[d]

Almost all of the subjects printed the instructions, and even those determined to understand what they were doing soon began following the instructions mechanically. In the end, many test subjects described enrollment as the most difficult computer task that PARC had ever asked them to do. All subjects had little idea of precisely what they had done to their computers. Several commented that if something were to go wrong, they could not perform even basic troubleshooting. For several subjects, this was the first time that they had ever experienced the inability to administer their own machines. Ironically, while PKI technology may have secured their machines for wireless use, it simultaneously reduced these end users' ability to configure and maintain their own machines.


[a] B. Aboba and D. Simon, "PPP EAP TLS Authentication Protocol (EAP-TLS)," IETF RFC 2716 (Oct. 1999); http://www.ietf.org/rfc/rfc2716.txt.

[b] ANSI/IEEE Std. 802.1x, Port-Based Network Access Control, IEEE (2001).

[c] D. Balfanz, G. Durfee, R. Grinter, and D. Smetters, "In Search of Usable SecurityFive Lessons from the Field," IEEE Security & Privacy 2:5 (Sept./Oct. 2004).

[d] Dirk Balfanz, Glenn Durfee, R.E. Grinter, D.K. Smetters, and Paul Stewart, "Network-in-a-Box: How to Set up a Secure Wireless Network in under a Minute," Proceedings of the 13th USENIX Security Symposium (2004), 207221.

A recent study investigates how to build a wireless network that is extremely easy to set up and that, at the same time, provides the strongest grade of wireless security currently available. The authors of the study call their system a "Network-in-a-Box" (NiaB).[7]

[7] Balfanz et al., "Network-in-a-Box."

This high level of security is provided by the 802.1x protocol,[8] which authenticates each wireless client before it can access the network, and then provides them with encryption keys that change rapidly and automatically to protect their data. Networks that use 802.1x ask clients to authenticate themselves using a choice of mechanisms. The most secure of these is a protocol called EAP-TLS,[9] which asks clients and the wireless infrastructure to mutually authenticate each other using digital certificates via the standard TLS[10] key exchange protocol. Deploying such a network means setting up a certification authority and an authentication infrastructure, and issuing certificates to each new client. As the example in the earlier sidebar shows, this is extremely difficult in an enterprise staffed by professional administrators. It is normally inconceivable for an average home user.

[8] ANSI/IEEE Std. 802.1x.

[9] B. Aboba and D. Simon, "PPP EAP TLS Authentication Protocol (EAP-TLS)," IETF RFC 2716 (Oct. 1999); http://www.ietf.org/rfc/rfc2716.txt.

[10] T. Dierks and C. Allen, "The TLS Protocol Version 1.0," IETF RFC 2246 (Jan. 1999); http://www.ietf.org/rfc/rfc2246.txt.

What was needed was a small-scale PKI (an instant PKI), one that covered a single wireless network and its clients, and one that could be configured and set up automatically. Users also needed a secure way to indicate which clients should be able to join that network, and a way to automatically have those clients obtain a certificate and be set up to use it.

The NiaB access point (NiaB AP) , shown in Figure 16-1, is the solution to these problems. It provides a complete 802.1x-secured wireless network.[11] Clients who want to enroll in that network run a small enrollment application. In addition to being an access point, the NiaB AP has the authentication services necessary to support 802.1x, a certification authority to issue certificates to wireless clients, and an enrollment component (described later) to add new clients to its network securely. When the NiaB AP is switched on for the first time, it configures itself automatically. The access point component chooses a wireless network name and channel. The CA component generates a root key pair and root certificate. The NiaB AP is configured to automatically use an upstream Internet connection if one is available, and to act as a gateway for its clientsit provides all of the services necessary for its wireless clients to safely access the Internet, such as a DHCP server, a firewall, etc. Even if the NiaB AP does not have an external connection to the Internet, it still provides a useful wireless network to its clients, allowing a group of users to easily configure a secure local wireless network.

[11] Balfanz et al., "Network-in-a-Box ".

Figure 16-1. Network-in-a-Box makes it easy to enroll in a secure wireless network


The process to easily and securely add new clients to this network is called gesture-directed automatic configuration : a user wishing to add his laptop to the NiaB network runs a small enrollment application, which tells him to "point out" the NiaB AP whose network he wishes to join. In the NiaB implementation, he points out the AP using the infrared (IR) port on his laptop (although other mechanisms could be used[12]). For a second or two, the devices exchange a small amount of information over infrared. Then, the user is prompted to separate the devices to continue the automatic configuration of the laptop. After a few more seconds, the user is informed that his laptop is ready to use. These simple steps provide a previously unconfigured laptop with everything needed to get a "network dial tone."

[12] Dirk Balfanz, D.K. Smetters, Paul Stewart, and H. Chi Wong, "Talking to Strangers: Authentication in ad hoc Wireless Networks," Proceedings of the 2002 Network and Distributed Systems Security Symposium (NDSS'02), Internet Society (2002), 2335.

This gesture-based approach to configuration is simple and intuitive for the user and, at the same time, highly secure. When the user's laptop and the NiaB AP communicate over infrared, they are actually exchanging digital fingerprint information with each other that will allow them to securely recognize each other's public keys, and the AP tells the client the name of the wireless network it should join. The infrared channel is an example of a location-limited channel.[13] Location-limited channels are channels that can be used to bootstrap secure communications between devices.

[13] Ibid.

The client enrollment software on the laptop then makes a secure connection over the wireless network to the NiaB AP, authenticating each other by proving they have the private keys corresponding to the public key fingerprints they exchanged over IR. This takes the user's clear intention to have his laptop talk to that particular NiaB AP, and turns it directly into a secure connection over which the laptop can be configured. Over that secure connection, the enrollment software on the laptop requests a certificate from the NiaB AP's CA, and then retrieves the new certificate and installs it on the laptop. The enrollment software then configures the laptop to use the new certificate to access the NiaB network securely in the future. From then on, standard software in the laptop will automatically access and authenticate to the NiaB network whenever it is in range, without further intervention from the user.

By setting up and joining a NiaB network, the user is managing an "instant" public key infrastructurea small, dedicated PKIwithout even realizing it. Instead of burdening the user with complicated certificate management semantics, this iPKI provides a simple and intuitive security model: a device can participate in the wireless network if and only if, during enrollment, it can be brought into close enough physical proximity of the access point to exchange information over infrared. For example, if a NiaB AP were to be deployed in a home, someone wishing to gain access to its wireless network would have to be able to physically enter that home. (Especially concerned users might even lock their NiaB AP in a closet.) This is a simple, intuitive trust model that is quite effective for many situations.

The gesture-based interface for enrolling in a NiaB network is designed to be as simple and intuitive as possible. Most importantly, it asks the user to perform only an action that he would have to perform anywayto indicate which network he would like to join. User studies confirm that this approach is very easy to useit took a population of 12 users on average only 2 steps and 51 seconds to set up a laptop to use a secure NiaB network, and they rated the system's ease of use very highly.[14] The interface also follows Yee's guideline:

[14] Balfanz et al., "Network-in-a-Box."

The user action indicating consent is the physical pointing out of the laptop to the access point. The authority granted is the network access given to the laptop. Without this explicit user action, no authority is granted to the laptop.

The authors of the study arrived at this easy-to-use design through an iterative process. Their interdisciplinary team (consisting both of security experts and ethnographers) first designed a prototype that they then tested with users for usability flaws. The test users indeed pointed out issues with the prototype that were addressed in the final design. The timing and satisfaction results cited earlier refer to that final design.

16.3.2. Case Study: Casca

Casca is an application that shows how small, dedicated iPKIs can be used to secure workgroup applications.[16] In Casca, users create shared virtual spaces for collaborating with other users. Each space is represented by an (initially empty) canvas on the user's screen. Users can invite others to join a space, and such members can then add objects to that space (e.g., files, cameras, or speakers) by dragging objects' representations (i.e., icons) onto the space's canvas (see Figure 16-2). For example, if Alice invites Bob to join her space, and then drags her screen component onto the space's canvas, Bob (along with any other member of that space) will have access to Alice's screen. (Bob will see an icon representing Alice's screen on his canvas, and will be able to display documents on Alice's screen by simply dragging those documents onto the icon.)

[16] W.K. Edwards, M. Newman, T.F. Smith, J. Sedivy, D. Balfanz, D.K. Smetters, H.C. Wong, and S. Izadi, "Using Speakeasy for ad hoc Peer-to-Peer Collaboration," Proceedings of the ACM 2002 Conference on Computer Supported Cooperative Work (CSCW 2002), (ACM Press, 2002), 256265.

The shared spaces provide a natural basis for security: only users that are members of a space can access the objects in that space. By making sharing a top-level primitive of the application, the design makes it easy for users to understand what they are sharing and with whom. Moreover, users don't have to do anything extra in order to specify who

Figure 16-2. A screenshot of the Casca application


should have access to (and who should be barred from access to) shared resources: assembling a workgroup to participate in a shared virtual space automatically sets up a security mechanism that enforces access control along workgroup boundaries.

It turns out that instant public key infrastructures are an ideal tool to implement the security requirements for Casca in an easy-to-use manner. Whenever a user creates a new blank canvas (thus creating a shared space that only he is a member of), a new root certificate is created for that shared space. The creator of a shared space essentially becomes the certification authority for that space (of course, the user is unaware of this). Inviting others to join the space means issuing them a new certificate signed by the space's root public key. The new member's public key is authenticated using location-limited channels (see the previous case study). Two members of a space authenticate each other by proving that their respective certificates stem from the same root. Again, all this happens under the coversusers do not see the setup or use of certificates.

The user experience is similar to the previous case study. In order to invite a new member, some sort of action is necessary on behalf of the group owner. In Casca, this happens to be a gesture that aligns the infrared ports of the group owner's computer and the new member's computer. As a result of the gesture, the group owner sees a new member alongside the group's canvas. The new member sees the group's canvas and immediately has access to all objects made available through the shared space. In addition, this also serves as an example of Yee's guideline:

In Casca, users assemble groups of colleagues with whom they wish to collaborate. This is a very task-centric activity (Casca is a collaboration tool). At the same time, this group of colleagues also represents a security policy in that it specifies that these and only these collaborators have access to the group's converspace.

16.3.3. Case Study: Usable Access Control for the World Wide Web

Instant PKIs do not always have to use location-limited channels to enroll new clients. Balfanz describes a system where web servers themselves take on the role of certification authorities, issuing certificates for potential clients of the web sites they're serving.[18] The system is designed for small-time web publishers such as hobby photographers or keepers of online diaries who want to restrict access to their online content to a select group of people. After they create new content, Balfanz suggests that a natural part of the "workflow" for these small-time web publishers is to inform their clients of the new content by announcing to them (and only to them) the creation of the new content. This intention of access control (which is expressed, say, by sending an email announcement to a select group of people) is enforced by a small, dedicated iPKI: when a recipient of such an announcement visits the web site for the first time, he automatically receives a certificate issued by the site (as opposed to some general-purpose certification authority). This certificate is then used to authenticate to the site, during both the first and subsequent visits.

[18] D. Balfanz, "Usable Access Control for the World Wide Web," Proceedings of the Annual Computer Security Applications Conference, IEEE Computer Society (2003), 406415.

Why does the site issue a certificate to any (!) client that connects, only to turn around and test for the possession of such certificates as proof of access? The idea is that the legitimate recipient of the announcement email will visit the site before any attacker, thus obtaining the certificate. The web site honors only the first certificate request from each user; subsequent requests are rejected. If, for some reason, an attacker manages to visit a web site before the legitimate recipient of the certificate does, that legitimate user will encounter an error message asking him to contact the web site's publisher. Upon such contact, the publisher can easily revoke the existing certificate (assuming that it was issued to an illegitimate user), and instead issue a new certificate to the legitimate user.

This threat model is similar to the widely used tool ssh , where there is a small chance of a man-in-the-middle attack on the first connection to a remote host. If and when such a first connection is successful, subsequent connections are secured by the full strength of the underlying protocol (in this case, SSL or TLS with client authentication).

The result is a system that, while protected with an iPKI, is to the users almost indistinguishable from a system that does not employ any security mechanisms at allthat is, the additional security does not place an additional burden on the user. As in an insecure system, web publishers publish information through a web server and announce this fact in an email message to a select group of people. And as in an insecure system, recipients of the announcement click on a link in that message and have immediate access to the published content. The only difference in the implemented system is that during their first visit, clients encounter a few "setup" screens they have to walk through. The users (both publishers and clients) never notice that they are managing, and partaking in, a public key infrastructure. What's more, this is actually an example of Yee's guideline:

Match the most comfortable way to do tasks with the least granting of authority.[19]

Because the secure version is (almost) indistinguishable from the insecure system, it represents a mechanism that users are already very comfortable with. At the same time, however, authority is granted to no one but the individuals addressed in the announcement.

16.3.4. Instant PKIs

The examples in the previous sections show that, with careful design, public key technology can be made not only useful but also usable. A set of five principles for secure and usable system design can be drawn from these and other examples.[20] Together they suggest a general new approach to usable PKI design:

[20] Balfanz et al., "In Search of Usable Security."


You can't retrofit usable security

Just as security cannot be "bolted on" to an existing system late in its design, existing unusable systems cannot be fixed simply by adding a better GUI. Systems must be designed to be both secure and usable from the ground up.


Tools aren't solutions

Components like SSL/TLS, public key cryptography, and digital certificates are important resources in building secure systems. However, by themselves, they are not solutions to a user's problemthey must be applied effectively in a well-designed application context.


Keep your customers satisfied

The only way to tell if a system is usable is to ask usersusability testing is key to being sure that a system's design is successful.


Think locally, act locally

Make technology easier to deploy and use by tailoring it to the application at hand, and by avoiding external deployment dependencies.


Mind the upper layers

Users are trying to accomplish goals expressed in the context of the application at hand. Don't ask them to make security decisions or take actions outside that contextuse the context to automate necessary security steps.

While the first three of these are important general principles for the design of any usable, secure system, the last two lead to very specific indications of how we should design a usable PKI. Think locally, act locally suggests that we should avoid designs that require establishing large, coordinated trust hierarchies, or certificates that are predesigned to fit every possible future application. This not only simplifies deployment by reducing the need for interorganization coordination, but also allows greater opportunity for autoconfiguration.

Mind the upper layers suggests that users should be allowed to focus on the task at hand, and that systems should take contextual information about what is needed to accomplish that task into account in order to figure out what security-related actions need to be performed. Users should not be asked to think about certificates directlyeither how to obtain one or whether to trust a particular CA. An increasing amount of research and experience finds that users are very confused by such requests.[21], [22], [23], [24] Instead, certificate management should be integrated into the task at hand. For instance, in the Network-in-a-Box system described earlier, users were asked to indicate by a gesture what wireless network they wanted to join. The fact that joining that network required them to obtain a certificate was not something they had to find out explicitly.

[21] Ibid.

[22] Doyle and Hanna.

[23] Gutmann.

[24] Whitten and Tygar.

This approach to simplified PKI deployment can be generalized and reused for a wide variety of applications. When used in combination with intuitive approaches to initial user authentication like the gesture-directed approaches described earlier, the combined system is secure, easy to use, and easy to deploy. As we've mentioned, the term instant PKI (iPKI) is used throughout this chapter to describe such systems.

16.3.5. What Makes a PKI Instant?

An iPKI is a lightweight PKI centered around a standalone CAone that doesn't participate in a larger CA hierarchy. Certificates issued by that CA are usually used for a single, specific application. The goal of an iPKI is to make it so simple and easy to issue certificates and configure them for use (while not sacrificing security) as to make it easier to issue a new certificate than reuse an old one. These small, special-purpose PKIs turn out to be considerably easier to configure and set up than a reusable PKImost often, PKI setup can be completely automated. And because the certificates issued are closely linked to an

CASE STUDY: USABLE PKI DEPLOYMENT FOR AN ENTERPRISE WIRELESS NETWORK

With the principles for instant public key infrastructures in mind, we redesigned the procedure for joining the wireless network at PARC described in the earlier sidebar. We reused many of the design choices from the NiaB system to greatly simplify the user experience.

A user wishing to join a laptop to the wireless network walks to a room that houses an enrollment station. The user installs and launches a client application that instructs her to align the laptop's infrared port with that of the enrollment station; she is then told that a certificate request has been received, and she can leave the room. After administrator approval, the user receives an email asking her to rerun the client application, which automatically retrieves the certificate and installs it for use with the wireless network.

This system provides an intuitive trust model. Our enrollment station is locked in a room, so someone who has physical access to the room can request a certificate, while someone who doesn't have physical access cannot. At PARC, users need to present their badges to a system administrator to enter the enrollment room.

Usability studies demonstrate that this approach is simpler and more intuitive for end users than setting up security using traditional methods. It takes users an average of 1 minute and 39 seconds, and a total of four steps, to add a new device to the wireless network. The system also gets much higher marks than the traditional system in user satisfaction and confidence. Even our system administrators, who by this time had become quite familiar with the traditional system, prefer the new system to the point where they exclusively use it to enroll end users' computers.


application context, it's much easier to make enrollment and certificate use comprehensible and easy for the end user, who prefers not to have to think about certificates at all.

A number of elements are common to iPKIs:


Application-specific, lightweight CA

An iPKI is used for a particular narrow application context (e.g., to identify all the devices that can access a particular wireless LAN, or all the devices that are allowed to use a shared repository of resources). Instead of reusing existing certificates, in an iPKI it's often easier to get a new one for a different application or different trust condition.


Automated PKI and CA setup

To make it possible to deploy many lightweight iPKIs, it must be as simple as possible to set each one upideally requiring no user intervention at all.


Simple, intuitive enrollment mechanism

To make it feasible for users to obtain multiple certificates, it must be simple for them to get each one. More importantly, each certificate and enrollment action should be embedded in a task the user knows he wants to perform (e.g., enrolling in a particular wireless LAN or inviting someone to participate in a shared repository of resources). The user should be asked to do nothing more than would be necessary to indicate what he wants to do, such as pointing out the AP serving the WLAN he wants to join via IR, instead of being asked to do separate, security-specific steps.


A simple, intuitive trust model

It should be simple and clear to the user who will and will not be able to join the iPKI. More importantly, that access model should be expressible in application terms. In the NiaB example described earlier, only people who can get physical access to the NiaB AP (close enough to exchange IR) can get onto its wireless network.


Secure bootstrapping

Making the enrollment mechanism intuitive doesn't mean that it should also then be insecuregiving out certificates without enforcing a well-thought-out trust model for who should get them, and effectively enforcing that model. In the examples presented in this chapter, authentication over location-limited channels provided a strong cryptographic binding between the user's intention (e.g., demonstrating a desire to join a WLAN and physical access to the AP and pointing out who he wants to join his shared space), and the system trust model. This form of ad hoc authentication acts to bootstrap trust in the resulting PKI.


Certificates as capabilities

Although an iPKI may issue standard X.509 identity certificates, these certificates are rarely used for their ability to provide identity information. Instead, they usually play the role of simple, easy-to-verify capabilities"anyone owning a valid certificate issued by this iPKI is allowed to do X," where X might be participating on a particular network, accessing a particular set of files, etc. (Ownership here is defined in the sense of proving possession of the private key corresponding to the public key in a certificate signed by the iPKI's CA.) This simplifies the design and implementation of applications that will use the PKI.


No need for direct user interactions with certificates

One of the corollaries of automated enrollment is that users don't have to directly manipulate certificates or even know they are in use. This improves the user experience dramatically.

The "instant PKI" approach is not all-or-nothingit's simply a collection of design choices that make it easier to deploy small, usable PKIs. Subsets of these design choices can be combined with traditional PKI techniques to generate all sorts of hybrid solutions, which are more usable than traditional PKI enrollment, while still keeping centralized management features that may be necessary in certain organizations or situations. The sidebar, "Case Study: Usable PKI Deployment for an Enterprise Wireless Network," shows an example of such a hybrid.

We close this chapter by remarking that many of the concepts discussed here are applicable above and beyond CA-based infrastructures that use public key certificates. An instant public key infrastructure is really only one example of an Instant Trust Infrastructure (ITI). Instant Trust Infrastructures may differ in the security mechanisms they employ: certificates, shared secret keys, more complicated forms of cryptographic credentials, etc. What they have in common is that they are just the right size, are application specific, and provide an easy bootstrap mechanism and an intuitive security model. Armed with those properties, Instant Trust Infrastructures in general, and iPKIs in particular, show us how to make the impossible easy and combine usability and security in one system.



Security and Usability. Designing Secure Systems that People Can Use
Security and Usability: Designing Secure Systems That People Can Use
ISBN: 0596008279
EAN: 2147483647
Year: 2004
Pages: 295

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net