Palo Alto Research Center

Network-in-a-Box:How to Set Up a Secure Wireless Network in Under a Minute

Dirk Balfanz, Glenn Durfee, Rebecca E. Grinter, D.K. Smetters, Paul Stewart

May 26, 2004

This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rightstherein are retained by authors or by other copyright holders. All persons copying this information are expected toadhere to the terms and constraints invoked by each author’s copyright. In most cases, these works may not bereposted without the explicit permission of the copyright holder.

Copyright c©2004 Palo Alto Research Center Incorporated. All Rights Reserved. This work was originally pub-lished by the USENIX Association.

Network-in-a-Box:How to Set Up a Secure Wireless Network in Under a Minute

Dirk Balfanz, Glenn Durfee, Rebecca E. Grinter, D.K. Smetters, Paul StewartPalo Alto Research Center

3333 Coyote Hill RoadPalo Alto, CA 94304

{balfanz, gdurfee, grinter, smetters, stewart }@parc.com

Abstract

Combining effective security and usability is oftenconsidered impossible. For example, deploying effectivesecurity for wireless networks is a difficult task, even forskilled systems administrators – a fact that is impedingthe deployment of many mobile systems.

In this paper we describe a system that lets typicalusers easily build a highly secure wireless network. Ourmain contribution is to show how gesture-based user in-terfaces can be applied to provide a complete solutionfor securing wireless networks. This allows users to in-tuitively manage the network security of their mobile de-vices, even those with limited user interfaces. We demon-strate through user studies that our secure implementa-tion is considerably easier to use than typical commer-cially available options, even those that provide lowersecurity. Our gesture-based approach is quite general,and can be used to design a wide variety of systems thatare simultaneously secure and easy to administer.

1 Introduction

Connecting mobile computers together in a wirelessnetwork can be largely automated. Today, many defaultnetworking configurations allow computers to connect toany wireless access point, to obtain IP addresses, gate-way information and DNS server locations automaticallythrough DHCP,etc.Mobility of devices makes this auto-configuration a necessity: when devices are removedfrom one environment and introduced into another, usersshould not be burdened with reconfiguring their devicesmanually.

This situation, however, shifts dramatically when werequire our wireless network to besecure. A securewireless network only admits certain (authorized) de-vices, and protects those devices and their communi-

cation from attack. Today, securing a wireless (or in-deed, any) network usually requires substantial amountsof manual work. The burden placed on the user rangesfrom specifying passwords for access points and clientsto managing a Public Key Infrastructure (PKI), completewith setting up a certification authority, issuing certifi-cates and installing them on client computers, configur-ing client security,etc.The more secure the network, themore complex the configuration. This means that strongwireless security solutions are often completely out ofreach for typical end users.

The difficulties of deploying secure wireless networksis perceived as just one example of the general tensionbetween security and usability, which has led many to be-lieve that there is an unresolvable trade-off between thetwo. The tension between security and ease of networkconfiguration significantly adds to the cost of setting upand maintaining secure networks. This is aggravated inwirelessnetworks, where the lack of physical barriers toaccess makes strong network security crucial. Consider,for example, a company that has an Ethernet-based in-tranet that can only be accessed from inside the companybuilding, while the 802.11-based wireless network canbe accessed from the public parking lot across the street.

In this paper, we show that security and ease of net-work configuration do not, in fact, have to be at oddswith each other. We describe a method to set up a se-cure wireless network without any manual configuration.We solve the problem of introducing wireless devices tothe network, distributing initial keys between them andpieces of the network infrastructure (e.g.,access points)– and thus establishing trust – by usinglocation-limitedchannels[5]. As a result, a user can add a laptop to a se-cure wireless network by walking up to an access pointand physically pointing out the access point to his laptop.The laptop and the access point exchange public keys andother relevant information through the location-limitedchannel, before proceeding with a completely automated

Figure 1. Connecting a laptop to a secured wireless network in 32 seconds. All the user has todo is briefly align the infrared ports of laptop and access point and press the Enter key twice.These are snapshots from a live Network-in-a-Box demonstration.

configuration of the laptop. This includes configurationof the network security settings (as well as more tradi-tional configurations such as IP addresses, gateway in-formation,etc.).

To demonstrate the utility of our approach, we de-signed and built a secure wireless access point and con-figuration software for mobile devices. Our gesture-based interface reduced the time needed for a user to en-roll a laptop into a secure wireless network from over9 minutes to under 60 seconds. At the same time, weincreased the security of that network from (rather inse-cure) WEP to 802.1x EAP-TLS [17]. Our technologymakes it possible for mobile devices to be configuredquickly and to easily move to new secure networks.

The rest of the paper is structured as follows. In Sec-tion 5 we describe related work. In Section 2, we presentbackground information on gesture-based authenticationand wireless security protocols necessary to understandthe rest of the paper. In Section 3 we present the de-sign and implementation of an easy-to-use secure wire-less network consisting of a single “smart” access point.We have experimentally demonstrated the usability ofthis system, with results shown in Section 3.4. In Sec-tion 4 we show how to extend our approach to configur-ing large enterprise wireless networks consisting of manycommercial off-the-shelf access points. We conclude inSection 6.

2 Background

2.1 Gesture-Directed Automatic Configuration

Authentication is the most basic security problemfaced by mobile networked devices: once two devicescan securely recognizeeach other, they can then se-curely exchange data, set network configurations, issuecredentials, and so on. Traditional approaches to thisproblem assume that both devices already participatein some manually-configured shared infrastructure, forexample, that they have been configured with identicalpassphrases, each other’s public key, or the public key

of a common certification authority. For mobile devices,and new consumer devices brought into the home, thiswill not be the case. We need a way to allow two de-vices to communicate securely with each other even ifthey know nothing about each othera priori.

We solve this problem in a simple, easy-to-use man-ner. A user wishing to initiate communication be-tween his device and another device in the area simply“points out” his desired communication partner, using alocation-limited channel[5] – e.g.,touching the two de-vices together, or indicating the desired target using in-frared, as with a remote control. With this simple andintuitive gesture, the user actually sends a small amountof configuration and cryptographic information – finger-prints of public keys – across this more trusted channel,and the target device sends a small amount of informa-tion back. This allows those two devices then to authen-ticate each other and communicate securely over the net-work.

There are many types of location-limited channels. Aswe are sending only public information over this channel,we require of such a channel only that it be very difficultfor an attacker to transmit information in that channelwithout being detected; the channel need not be intrin-sically “private” or impervious to eavesdropping. Chan-nels such as infrared or contact give a strong intuitivefeeling of “pointing out”. A simple, passive USB stor-age token can be used to exchange authentication infor-mation between less mobile devices in a location-limitedway. Audio channels allow the exchange of authentica-tion information between a number of devices at once,thus enabling secure group communication [5, 24]. Thework presented here builds on infrared location-limitedchannels.

Location-limited channels often have lower band-width and higher latency than typical network media, soboth the amount of data exchanged and the number ofrounds of communication must be kept to a minimum.In the work presented here, two devices exchange cryp-tographic digests of their public keys over the location-limited channel, plus a small amount of network infor-

mation. Subsequent communication takes place over theless secure (wireless) network, and is secured using stan-dard public key protocols, where trust in the public keysis established by matching their cryptographic digestswith those received on the location-limited channel. Thisallows the creation of a secure tunnel in which any num-ber of rounds of more bandwidth-intensive network con-figuration and network provisioning protocols can be ex-ecuted, such as protocols for requesting and deliveringdigital certificates.

This gesture-based approach to authentication sup-ports a variety of trust models. Participants can be con-figured to allow only the last party with whom they per-formed a location-limited exchange, to set up a secure,authenticated network connection to them; or the trustestablished through the location-limited exchange may“expire” in a short amount of time, as appropriate for theapplication.

In summary, a user gesture briefly establishes alocation-limited channel, which in turn allows softwareto bootstrap a secure tunnel for the provisioning and au-tomatic installation of network and security configura-tion information. We refer to this process asgesture-directed automatic configuration.

2.2 Wireless Security Protocols

The most popular standard for wireless networks isIEEE 802.11.1 Adoption of 802.11 wireless networksfor critical applications has been hampered by high-profile reports of security flaws. The security and encryp-tion component of the original 802.11 standard, WEP(“Wired Equivalent Privacy”), requires clients and accesspoints to share a single secret passphrase or key whichthey use to encrypt all wireless traffic. Unfortunately,highly-publicized attacks on WEP [7, 11, 36] have com-pletely discredited WEP as an effective security mecha-nism.

To address these problems, industry and standardsbodies are proposing new security protocols for 802.11,which will appear over the next few years. These pro-tocols – “Wi-Fi Protected Access” (WPA [2]) and the802.11i standard [18] combine use of an existing stan-dard protocol, 802.1x [17] which is used to authenticatedevices and users wishing to join the wireless network,with the ability to automatically derive and update en-cryption keys to secure wireless data. These protocolsdiffer primarily in how the data is encrypted with thesekeys, and provide different degrees of backward com-patibility with deployed hardware. The 802.11i standard

1802.11 comes in a variety of subtypes with differing frequencyand bandwidth characteristics. Although the implementation discussedhere uses only 802.11b, all results are general and apply equally wellto 802.11a, 802.11g,etc..

wireless client access point authentication server

EAP-TLS authentication

RADIUS

WEP/WPA Key

WEP/WPA Key

TLS Master Secret

…

every 15 minutes

EAPOL RADIUS

Figure 2. Roles and message flows with802.1x authentication using the EAP-TLSprotocol.

is intended as the final standard for security in 802.11wireless networks, while WPA is intended as a temporarybackward-compatible intermediate step, and is based ona draft of 802.11i.

The core of these two protocols – 802.1x-based au-thentication combined with automatic frequent update ofthe keys used to secure wireless data – has begun to seewidespread use in advance of WPA and 802.11i deploy-ment. As 802.1x is currently the most secure availableoption to transparently secure an 802.11 wireless LANs,we chose it for our implementation. As our work focuseson configuring trust for the 802.1x authentication proto-col common to all three, our results immediately gener-alize to both WPA and 802.11i. In fact, our approachgeneralizes to allow easy configuration of IPsec-basedwireless LAN security (see Section 3.2.2), or any othersecurity mechanism authenticated using a Public Key In-frastructure.

The 802.1x Protocol. The 802.1x security stan-dard [17] defines a mechanism for providing access con-trol for any IEEE 802 LAN, including 802.11 wirelessnetworks. In an 802.1x-compliant wireless network (asshown in Figure 2), each access point plays the role of anauthenticatorforcing every client to authenticate beforeallowing access to the wireless network. Prior to success-ful authentication, a client may only send 802.1x proto-col messages to the access point (AP); it is not allowedto send any data frames. The access point itself is not ca-pable of making any authentication decisions. Instead, itforwards all 802.1x messages from the client to a back-end authentication server(AS) via the RADIUS [31]protocol; the AS checks the credentials of the client andindicates to the access point whether the client is autho-rized to access the network. Optionally, the AS provides

the AP information which allows it to securely transmitunique short-lived data encryption keys to each client [8].This latter step is used in the wireless context to protectclient data transmitted over the air.

The 802.1x protocol is “pluggable”, allowing any oneof a wide number of authentication protocols to be rununder the wrapper it uses – EAP, the Extensible Au-thentication Protocol [6]. The most secure of these isEAP-TLS [1], a wrapper around the widely deployedTLS (SSL) key exchange protocol [9], which requiresall wireless clients and the network infrastructure itselfto use digital certificates for authentication. Keying ma-terial exchanged as part of this TLS handshake is thenused to automatically give authenticated clients encryp-tion keys that they can use to secure their traffic on thewireless network. These keys are updated frequentlywithout human intervention.

Current 802.1x deployments frequently opt forpassword- or shared secret-based authentication options,in order to avoid the difficulty of issuing a digital cer-tificates to each client device. However, in addition toits greater security, EAP-TLS has a number of desirablefeatures. First, as every client (and the authenticationserver) possesses a unique digital certificate and corre-sponding private key, access for individual clients can berevoked in case of compromise; in contrast, shared-secretvariants of EAP [6] require client machines to be rekeyeden massewhenever the compromise of a single machineoccurs. Password-based EAP protocols are subject tothe same password-guessing attacks as other password-based systems [32], and can additionally be subject toman-in-the-middle attacks [4]. Furthermore, digital cer-tificates and private keys are usually stored on disk pro-tected by both the operating system and the user’s pass-word; they are unlocked as soon as a user logs into amachine. This provides quick, frequent and automaticauthentication of both the user and the device, desirablefor security and to allow seamless roaming. This approx-imates more closely a single sign-on system than does apassword-based authentication method, where reauthen-tication requires caching or frequent re-entry of the pass-word.

Once a digital certificate and other configuration in-formation has been installed on every client, an 802.1x-secured wireless network using EAP-TLS is extremelyeasy to use – it requires no user intervention. The clients(and the authentication server) use their certificates andcorresponding private keys to authenticate themselves toeach other, requiring no input from the user.

Unfortunately, it is the process of enrolling every de-vice in a common PKI – provisioning the digital certifi-cates – that is a daunting task for system administrators,and out of reach of typical end users. In our organization,for instance, the process of setting up a PKI for use with

802.1x/EAP-TLS required each user, for each device, tofollow a minimum of thirty-eight separate documentedsteps, requiring several hours of end-user time over twodays. These consist of using a very typical web-based en-rollment interface to request a certificate, and then con-figuring Microsoft’s standard 802.1x client to securelyaccess a particular wireless network.

Clearly, a much simpler solution would not only betheoretically interesting, but practically useful. In thenext section, we describe how to apply gesture-directedautomatic configuration to simplify setting up a securewireless network consisting of a single access point; inSection 4, we describe our solution for an enterprise-scale wireless network.

3 A “Network-in-a-Box”

Our “Network-in-a-Box” consists of a custom-builtwireless access point (NiaB AP), providing a complete802.1x-secured wireless network, and software for clientdevices to enroll in that network. After a gesture-directedautomatic configuration step (during which users pointtheir device at the access point), client devices are fullyconfigured to participate in the wireless network.

During this process, the access point issues digital cer-tificates for use in the EAP-TLS-based wireless securitysystem. The user is managing a small PKI without evenrealizing it. Instead of burdening the user with compli-cated certificate management semantics, we provide asimple and intuitive security model: A device can par-ticipate in the wireless network if and only if, during en-rollment, it can be brought into close physical proximityof the access point. For example, if a NiaB AP were tobe deployed in a home, then someone wishing to gainaccess to its wireless network would have to be able tophysically enter that home. (Especially concerned usersmight even lock their NiaB AP in a closet.) This is asimple, intuitive trust model that seems quite effectivefor many situations.

3.1 User Experience

Imagine a user who wants to set up a secure wirelessnetwork to use with his laptop. Our user starts by bring-ing home a new NiaB AP (our prototype NiaB AP is thesmall white box shown in Figure 1). When he plugs itin for the first time, it initializes itself and autoconfiguresthe network services it will provide.

To add his laptop to the NiaB network, the user startsa NiaB enrollment application on that laptop. The ap-plication can be either pre-installed by the laptop ven-dor, or provided with the NiaB AP.2 The enrollment soft-ware (shown in Figure 3) asks the user to “point out”

2If a USB token is used to exchange authentication information (see

Figure 3. Screenshots from the Network-in-a-Box client software for Microsoft Windows XP TM .

the NiaB AP whose network he wishes to join. In ourimplementation, he does this using the infrared port onhis laptop. For a second or two, the devices exchangea small amount of information over infrared; then, theuser is prompted to separate the devices to continue theautomatic configuration of the laptop. After a few moreseconds, the user is informed that his laptop is ready touse. These simple steps provide a previously unconfig-ured laptop with everything needed to get a “networkdial-tone”.

If the user later wants to add his laptop to another se-cure network, he simply runs the client software again.As the client application contains no pre-configured in-formation about a particular network, instead getting allthe information it needs about whom to trust and whatnetwork to join via the infrared exchange, it can beused repeatedly to configure the same laptop for mul-tiple secure networks. Once credential information foreach network of interest has been configured, the usercan switch between them “on the fly” using whateverlocation-management facilities his operating system pro-vides. For example, our Windows XP-based implemen-tation targets the built-in “Wireless Zero Config” service,which automatically switches between configured wire-less networks as the laptop moves around, without re-quiring any user intervention.

3.2 System Design

As described in Section 2, an 802.1x-based wirelessnetwork contains a number of components: one or moreaccess points, an authentication server making determi-nations about what clients are allowed to access the net-work, and, in the case of EAP-TLS, a certification au-thority, which issues certificates. As shown in Figure 4,our NiaB AP contains all three of these components, aswell as general system services such as DHCP and a fire-wall, and a http-based management interface. It is there-

Section 2.1), it can also be used to install the software.

fore able to provide EAP-TLS-secured network access toclients without requiring other network components. TheNiaB AP also contains a novel component – an “enroll-ment station”. This component is responsible for han-dling requests for automatic client configuration madeover location-limited channels like infrared or USB.

System Initialization. When the NiaB AP is switchedon for the first time, the access point component auto-matically chooses itself a wireless network name andchannel. (The network name is “NiaB Network +<number>”, where the number is chosen randomly be-tween 1 and 1000 to keep your NiaB AP from inter-fering with your neighbor’s.) The certification author-ity component generates a root key pair and root certifi-cate. By default, the NiaB AP will request its own IP ad-dress through DHCP, while providing IP addresses for itsclients through DHCP from a non-routable address pool.If the NiaB AP does not have an external connection tothe Internet, it still provides a useful wireless network toits clients, allowing a group of users to easily configure asecure local wireless network.

We also built in a reset feature to return a NiaB AP toa “new” state. The reset feature is activated by pressing a(physical) button on the device. Upon reset, the NiaB APdisconnects and removes all records of existing clients.It generates a new network name, root key pair, and rootcertificate. This automatically invalidates the certificatesof previous clients, as they are signed by the old root key,rather than the new one.

Device Enrollment. When a user initiates enrollmentby executing our enrollment software on a client com-puter, the software performs a number of steps. First, itcreates a cryptographic key pair, which consists of a pri-vate key that will remain encrypted on his computer, anda public key that eventually (as described below) will beencapsulated in a digital certificate for use in authenticat-ing to the network.

laptop with NiaBenrollment software

NiaB AP

• 802.11 Access Point• Enrollment Station• Certification Authority• Authentication Server

Figure 4. The Network-in-a-Box provides the functionality of several network components.

When the user makes the temporary infrared connec-tion, his computer and the NiaB AP exchange what wecall preauthentication information: the enrollment sta-tion component in the NiaB AP sends the name of itswireless network (802.11 SSID) along with the SHA-1digest of its public key to the user’s computer. The user’scomputer responds with a the SHA-1 digest ofits (newlycreated) public key.

Since the user’s computer now knows the wirelessnetwork name, it can contact the NiaB AP over thehigher-bandwidth 802.11 network, and the infrared con-nection between the two devices is no longer necessary.

Next, the enrollment station component on the NiaBAP and NiaB enrollment software on the user’s computerrun EAP-PTLSover the wireless link. EAP-PTLS is anEAP plug-in protocol we designed specifically for pro-visioning network access for NiaB client computers, andis described in greater detail in Section 3.2.1. At thispoint the NiaB AP disregards all traffic from the clientcomputer except for EAP messages, as required by the802.1x protocol (see Section 2.2).

The EAP-PTLS exchange encapsulates a TLS hand-shake, in which the client computer and the NiaB APpresent each other their full public keys and prove thatthey possess the corresponding private keys. The publickeys are automatically checked to make sure they matchthe digital fingerprints previously exchanged over the in-frared location-limited channel, allowing the client andNiaB AP to authenticate each other. The AP can confirmthat the client performing the EAP-PTLS handshake overthe wireless network was indeed physically present at theNiaB AP earlier, and the client can be sure it is talking tothe AP of interest.

Once the TLS tunnel has been established via EAP-PTLS, the enrollment software sends a certificate requestto the NiaB AP through this tunnel. The enrollment sta-tion component passes this request on to the certifica-tion authority component, which creates a certificate forthe client and returns it over the TLS connection. Theenrollment software on the user’s computer installs thenew certificate, and automatically configures the laptop’s802.1x security client software to use it.

Using the Network. At this point, the laptop has ev-erything it needs to participate fully in the secure wire-less network. Normal authentication occurs via an802.1x authentication protocol exchange with the au-thentication server component on the NiaB AP. Since theclient computer has just been configured with a digitalcertificate, it is able to use EAP-TLS to authenticate tothe wireless network. This is the final “steady-state” forthe client, requiring only standard 802.1x client software;our enrollment software is no longer needed and can beeither removed from the client computer, or used againat a later point to add the laptop to additional secure net-works.

Once the lower-level 802.1x authentication succeeds,higher-level network provisioning takes place: TheDHCP server on the NiaB AP assigns an IP address to theclient computer, along with addresses of DNS servers,IP gateways (both, in fact, pointing to the NiaB AP),etc.Again, we don’t provide any special software for this stepon the client side, and instead rely on standard softwarebuilt into the operating systems of the client computers.

3.2.1 EAP-PTLS Protocol

The EAP-PTLS protocol is a simple variant of the stan-dard EAP-TLS authentication protocol [1]. Like EAP-TLS, the wireless client and authentication server (in thiscase, the NiaB AP itself) perform a standard TLS ex-change: exchanging certificates, demonstrating that theyeach possess the private key corresponding to the publickey in that certificate, and establishing a secure tunnel forfurther communication. However, in the case of EAP-PTLS, the certificates used are self-signed, and are sim-ply carriers for the public keys whose fingerprints werepreviously exchanged over the location-limited chan-nel. Both the client and server are satisfied with theauthentication exchange only when, at the conclusionof a successful TLS handshake, the key used by eachparty matches the fingerprint previously received overthe location-limited channel.

In EAP-TLS, the TLS handshake is only used for au-thentication and for agreement on keying material that isused to derive keys to protect future wireless traffic. Nodata is actually sent down the secure tunnel. In EAP-

PTLS, we do send data over the secure TLS tunnel. Weuse the Certificate Management Protocol (CMP) [3], astandard protocol for requesting and retrieving certifi-cates, to allow the new client to send a certificate requestto the authentication server through this tunnel. This re-quest is forwarded to a Certification Authority (CA) in-ternal to the NiaB and immediately approved and signedby the root key in the NiaB. Although the design choiceof using CMP may seem like overkill in this scenario (theinternal NiaB CA always approves incoming certificaterequests), it allows us to easily generalize our solution tothe enterprise scenario described in Section 4.

3.2.2 “Phone Home” Service

Our solution for provisioning 802.1x-based security gen-eralizes well to other security applications such as VirtualPrivate Networks (VPNs). Consider a user who has suc-cessfully configured a home network, and then wishesto access the devices and services on that network whilehe is away from home. This is a feature not typicallyprovided by consumer home gateway devices. A moresophisticated gateway device or firewall machine mightallow the user to configure a password-based approach toproviding remote access to his home; access to which isoften not encrypted.

We added features to the NiaB AP to make it easy toallow devices to access the home network using an IPsec-based VPN. This VPN uses the same certificate as wasissued by the NiaB AP when the device enrolled in thehome network. We have implemented automatic config-uration of such a service, which we call “Phone Home”,as part of our Windows XPTM NiaB client enrollmentsoftware. The Phone Home service is set up at the sametime as the enrollment in the wireless network, requiringno additional effort from the user.

As part of device enrollment, the NiaB enrollmentsoftware configures appropriate IPsec policies and Re-mote Access Service (RAS) Phonebook entries to allowthe client computer to initiate a standard Windows-styleL2TP-based IPsec VPN connection back to the externalIP address of the enrolling NiaB [38]. This new “PhoneHome” VPN connection appears as a standard “NetworkConnection” on the user’s desktop. Clicking on it movestheir machine virtually “inside” their home network in asecure fashion. All communication with the home net-work is encrypted and authenticated, and the remote de-vice automatically receives a new, “virtual” IP addressinside the home network’s address space. All commu-nication now goes through the firewall provided by theNiaB.

Provisioning and access to the “phone home” serviceis controlled using the NiaB management interface (seeSection 3.2.3 below). Although clients are configured to

be able to use the service by default, such access can bedisabled on a client-by-client basis at the NiaB, indepen-dent of the access those clients have to the NiaB’s localwireless network. This is useful, for example, in the casewhere a home user decides that a guest may get accessto the wireless network, but should not have access tonetwork resources from outside of the home.

3.2.3 System Management and Client Revocation

In order to allow the user to monitor the status of hisNiaB system, alter any of the autoconfiguration parame-ters inappropriate for his situation (e.g.,to turn on PPPoEif his ISP requires it, or to configure a static IP addressfor the external interface of the NiaB AP), we providea simple web-server based management interface. Thisinterface is largely similar to that provided by standardcommercial access points, though is easier for users tofind, and does not require the use of a password for se-cure access.

Through the NiaB’s DNS proxy (configured to be theDNS server for all NiaB clients), we redirect any entriesin the “.niab” domain to the NiaB AP itself. Therefore,entering “http://www.niab” in a web browser automati-cally takes you to the NiaB management page, withoutrequiring the user to enter a specific configuration IP ad-dress. A shortcut to this page is provided as part of clientconfiguration. Since individual NiaB clients can be rec-ognized by their certificates, policy configuration can beused to allow only a subset of those clients to accessthe NiaB management interface (e.g., the first client tojoin the network, and any other clients he specifically en-ables). This use of client authentication to control accessalso saves the user from having to change and rememberan administrator password.

Most importantly, this configuration interface allowsa user to permanently revoke access to NiaB services(wireless network and VPN) to any client, by revokingthat client’s certificate – this is done simply by clicking abutton in the management interface next to the name ofthe device to be removed from the network. At that point,a new Certificate Revocation List is automatically gener-ated by the NiaB AP, and all currently-connected clientsare asked to reauthenticate. To temporarily restrict clientaccess, the management interface allows wireless andVPN access to be separately enabled and disabled foreach enrolled client. While this interface may not be asdirectly intuitive as our gesture-directed enrollment in-terface, it does provide useful functionality – revocationof individual devices. We have not yet experimentallystudied how usable this simple interface is, but we mayexplore more intuitive alternatives in future work.

3.3 Implementation Details

3.3.1 NiaB Access Point

We have implemented our NiaB access point on theOpenBrick platform [13] – a small, x86-based computerproviding most of the ports and peripherals standard tolarger PCs. We have modified the hardware to add an in-frared port to the front of each device, along with a redLED that is used to inform the user when the NiaB AP istransmitting infrared data. This LED provides valuablefeedback to the user as to whether they have lined thedevice infrared ports up properly.

The NiaB access points are running a modified dis-tribution of RedHat Linux 9.0, and release 2.6.4 of theLinux kernel. This version was selected for its greaterstability and for its native support for IPsec. The Linuxkernel provides native firewalling capabilities, which weconfigure to provide protection from the Internet for thehosts on the NiaB-provided wireless network. The NiaBaccess points also act as DHCP servers and DNS cachesfor their clients.

Implementations of our base protocols – gesture-directed authentication using location-limited channels,the EAP-PTLS enrollment protocol, certificate issuancefunctions, and Certificate Management Protocol (CMP)messaging used to request certificates,etc., are writtenas libraries in C++ to facilitate reuse. All cryptographicoperations are implemented using OpenSSL 0.9.7.

Access point functionality for the NiaB access pointsis provided using the HostAP project’s access point soft-ware [29], slightly modified to provide the additionallogging and management interfaces we require. We setup the HostAP access point software to be a 802.1xpassthrough to an internal RADIUS server for authen-tication decisions (see Figure 4).

The RADIUS server we use is a modified version ofFreeRADIUS 0.8.1 [28]. FreeRADIUS itself providesa pluggable implementation of the EAP protocol archi-tecture, making it easy to add implementations of newEAP subtypes. We use that architecture to add a C++implementation of EAP-PTLS (see Section 3.2.1). Wemodified the implementation of EAP-TLS provided byFreeRADIUS to add additional configuration and sup-port for the use of Certificate Revocation Lists (CRLs),and to access the client authentication information con-trolled through our management interface.

To provide “phone home” functionality, we use theIPsec support present in the Linux kernel (version 2.6),and modified a version of the IKE daemon raccoon tocheck both CRLs and our client authentication informa-tion database to verify clients.

Our management interface is provided usingmini httpd 1.17 [33], a small web server, chroot’ed for

greater protection, coupled with a variety of Perl andPython scripts. Standalone certification authority andCRL generation functionality is implemented in a C++library which uses OpenSSL to handle cryptographicoperations and certificate and CRL formatting.

3.3.2 NiaB Client Software

The client application described above is implementedfor Microsoft Windows XPTM , and has been tested suc-cessfully on a wide variety of laptop hardware using anumber of different 802.11 client cards, both internaland external. A command-line client for Linux has beentested on a somewhat smaller range of laptop hardware.

We implemented client-side protocols and routinesfor CMP, EAP-PTLS, location-limited channels, and cer-tificate handling as portable libraries written in C++.All cryptographic operations are implemented usingOpenSSL 0.9.7.

To support frame handling for sending and re-ceiving raw Ethernet packets (necessary for executingEAP-PTLS over the wireless connection), we use theNDISUIO API [34] for Microsoft WindowsTM and libd-net [22] and libpcap [23] for Linux. The user inter-face of our Microsoft WindowsTM uses Microsoft Foun-dation Classes. For basic wireless support, we usethe NDISUIO API for the Microsoft Windows XPTM

client, and the Linux Wireless Extension and WirelessTools [12] for Linux. Our NiaB client software sets up802.1x support for Windows XPTM using the WirelessZero Configuration Service [16] and for Linux using thexsupplicant 802.1x client software package [27].

Again, our software is used only when a client is en-rolling in a new wireless network and does not inter-fere with the normal day-to-day use of such networks.Though our software supports being used repeatedly toadd the client device to more than one secure wirelessnetworks, switching between those networks in opera-tion is then done using the mechanisms provided by theoperating system in use.

3.4 User Studies

We undertook a series of usability studies [10] bothto test if our system actually makes it easier to set up asecure wireless network, and to obtain feedback to itera-tively improve our design.

3.4.1 Procedure

Our usability tests had two objectives. First, we wantedto know whether our system, NiaB, allowed users to eas-ily and securely connect to a wireless network. Our sec-ond objective was to compare our solution against a com-

Commercial AP NiaBTime (min) Steps Time (min) Steps

Avg 9:39 14 0:51 2

Ease Satisfaction Confidence Ease Satisfaction ConfidenceAvg 3 3 2 1 1 1

Table 1. User studies comparing the stand-alone Network-in-a-Box to a commercial accesspoint.

mercially available alternative. We picked a commer-cially available access point based on several criteria:it should be designed for end users, not enterprises; itshould be a market leader; and, enrollment should occuron the same operating system as our solution (to avoidconfounding variables by switching platforms).

Usability tests assign tasks to users to see whetherthey can complete them successfully and to learn whaterrors they make. The task we chose was to ask a user toconnect a laptop to a secure wireless network. Thoughpractical deployments of our client software were doneon a wide variety of laptop hardware and wireless net-work cards, we asked all participants to use the samelaptop in order to limit setup time and variability in ourquantitative studies. The laptop came pre-loaded with thesetup software for both NiaB and the commercial AP. Inboth cases, the setup software provided a “wizard”-styleinterface for the user. The commercial AP’s wizard re-quired 10 steps, the NiaB’s wizard required two (eachstage in the connection process where the user has tomake a decision was counted as a step).

Subjects were asked to connect to both access points,one after the other. Users were timed how long it tookthem to complete each connection task. We also countedhow many errors they made and how many steps theytook.

We selected our subjects from a pool of our co-workers. To avoid a bias in our data towards people withsignificant computer science skills we recruited broadlyfrom both the research and administrative staff. Further,we administered a screening questionnaire to ensure thatwe selected subjects with a broad range of backgrounds.We screened for education (technical vs. non-technical)and experience (wireless network owned and adminis-tered, no wireless network and never set up). We selectedthe broad range of subjects to avoid an emphasis towardsreduced times (for both the commercial and NiaB AP)that would derive from either educational background orexperience with wireless networking technologies.

To avoid potential learning bias (being able to connectmore quickly the second time than the first based on newknowledge) we selected an even number of participants,

split them into two groups, one of which connected to theNiaB AP and then the commercial AP and the other whoconnected to the commercial AP and then the NiaB AP.After each connection activity participants were asked torate their experience in terms of ease, satisfaction, andconfidence.

Our testing was done in two iterations. We recruitedsix subjects for the first iteration. We picked six sub-jects because previous research shows that five subjectsreveal approximately 80% of the usability errors in a sys-tem [26]. In addition to comparing the commercial APand NiaB, the first iteration was also used to refine theNiaB user interface. In the second iteration subjects eval-uated a revised NiaB interface using the same task as thefirst iteration. By keeping the task design the same wewere able to compare across the two studies, and the re-sults from the second iteration increased our chances offinding almost all of the usability errors.

3.4.2 Results

The results from the two iterations are shown in Ta-ble 1. They show that users took much less time (approx-imately a 10x speed-up) on average to connect to NiaBAP than the commercial AP. NiaB also required fewersteps – points where the user has to make decisions –than the commercial AP. More significantly, on averageusers took two steps to join the NiaB network, the samenumber needed to enroll correctly. This was not true forthe commercial AP, for which users took an average of14 steps – 4 more than intended. In other words, userswere making errors in the set up process for the commer-cial AP and frequently having to repeat steps and recoverfrom mistakes.

The likelihood of making errors and the number ofsteps involved in the commercial AP set up task con-tributed to users ratings of ease, satisfaction, and con-fidence. On scales of 1 (most positive) to 5 (most neg-ative) users rated ease of task, satisfaction in the expe-rience, and confidence that they could do it again, morehighly for NiaB. These positive feelings towards NiaBwere borne out in qualitative interviews, too.

One advantage that iterative usability testing offers is

the opportunity to identify and fix problems with the in-terface. The first iteration uncovered two usability issues.First, although people managed to successfully use thelocation-limited channel, they did not realize that theycould move the laptop away from the access point oncethe initial data was exchanged. Second, people did not al-ways know when they had actually finished the task andcould use the network. These findings allowed us to re-design the interface, and retest it with users. Results fromour second iteration show that we provided more appro-priate feedback to let users know to unalign the infraredports after the location-limited data exchange, and com-municated more effectively when they were completelyfinished.

4 Securing Enterprise-Scale Networks

We extended our easy-to-use approach for enrollingin secure wireless networks to enterprise-class networkswith many access points. We deployed our enterprise so-lution to handle enrollment in the wireless security sys-tem of a small enterprise consisting of approximately 250users.

There are two important differences betweenenterprise-class networks and the small networks wehave considered previously. First, their architecture isdifferent – enterprise networks have many access pointscommunicating with a central backend authenticationinfrastructure. Second, enterprise networks have con-siderably more complex security requirements than arepresent in the home.

We address these differences by encapsulating ourgesture-directed enrollment functionality in one or more“enrollment stations” – usually a simple box, or PC, con-figured to allow gesture-directed user authentication overone or more location-limited channels, but not itself anaccess point. Depending on the security needs of the en-terprise, this enrollment station can implement securityrequirements considerably more sophisticated than thatused in the stand-alone case.

By placing the enrollment station in a locked roomto which only employees of the enterprise have access,one ends up with an intuitive security model very similarto that used in the stand-alone case. By adding securitycameras monitoring the enrollment station, an enterpriseadds the ability to audit its use after the fact. Or an enter-prise may want a member of the IT staff to approve eachuser enrollment manually,e.g.,after checking the user’semployee badge, or entering additional configuration in-formation to be added to the enrolling device.

An important design goal for our enterprise solutionis to integrate with existing off-the-shelf commercial de-vices and software. In our system, the access points, au-thentication server, and certification authority can all be

commercial off-the-shelf, knowing nothing about any ofour configuration protocols. At the same time, we pro-vide opportunities for system administrator control andintervention that are desirable in the enterprise setting.

4.1 User Experience

The user experience of enrolling in the enterprise ver-sion of our system is similar to that of the stand-aloneNiaB system. The user physically brings her new mo-bile device to one of perhaps many enrollment stationsdistributed throughout the enterprise.

A user accessing the enrollment station performs abrief location-limited exchange, and is then told than anenrollment request has been submitted on her behalf. Shethen leaves the enrollment station. As mentioned above,an IT staff member may want to further review and ap-prove her request off-line, or perform additional config-uration or processing, so it may take some time for hercertificate request to be fulfilled.

All further device configuration takes place over thewireless network, using any of the enterprise’s accesspoints. The user does not need to visit the enrollmentstation again. She may at will re-run the client enroll-ment application (possibly prompted by an email froman administrator) to check whether or not her enrollmentrequest has been approved; eventually the software indi-cates that the request has been approved, and the certifi-cate and configuration information is installed automati-cally on her device. She may then begin using the securewireless network normally.

4.2 System Design

In this section, we describe the changes in design fromthe stand-alone NiaB required to make an enterprise so-lution (as shown in Figure 5). We separate the com-ponents built into the stand-alone NiaB AP. The accesspoints, certification authority, and authentication serverfunctionalities are standard solutions that do not need tobe aware that they are participating in our system. Theenrollment station is designed to handle our EAP-PTLSprotocol and speak with a Certification Authority for cer-tificate management.

Client Enrollment Software. The client configurationsoftware is similar to what we use in the stand-aloneNiaB case. The most significant change is that the clientsoftware is written to be aware of the fact that a requestfor a certificate may not be approved immediately – wait-ing for the approval of a system administrator could de-lay enrollment.

In the stand-alone NiaB system, the Certification Au-thority either immediately grants or rejects the certificate,

Certificate

enrollment station certification authority

access point

authentication server

Location-limited channel exchange

1.

realm proxyCertificate Request (EAP-PTLS)2.

Certificate (EAP-PTLS)5.

6. Secure Wireless (802.1x + EAP-TLS)

Cert Request3.

4.

Figure 5. Message flows in the enterprise version. Only the enrolling laptop and the “enrollmentstation” are aware that they are participating in a NiaB-enabled network.

and the authentication server returns the resulting certifi-cate or rejection message to the client. In the enterpriseversion, however, the certificate request enters a databaseof pending requests that might need to be examined, ap-proved, or rejected by an administrator.

Because the client and enrollment station are speakingthe Certificate Management Protocol inside of the EAP-PTLS tunnel, the enrollment station is able to send tothe client a request number and a result code indicatingthat the request is pending. Subsequent execution of theclient enrollment software polls for this request number,also using CMP messages in the EAP-PTLS tunnel. Un-til the request has been approved, the client receives anindication that it is still pending, and can repeat the re-quest later (see Figure 5).

We note that as long as the server and client cachethe information they exchanged over the location-limitedchannel, they do not need to repeat a location-limited ex-change. These later attempts to retrieve a certificate thathas already been requested can be performed over thewireless network without any intervention by the user.Though the authentication exchange over a location-limited channel must be done in physical proximity tothe enrollment station, all further interaction with eachclient can be done using any access point in the infras-tructure.

Once approved, the certificate is returned to the clientthe next time the client polls for it; the client enrollmentsoftware automatically configures the client device to usethe new wireless network just as in the stand-alone case.

Enrollment Station. We configure the standard off-the-shelf authentication server to forward EAP-PTLStraffic to the enrollment station. We accomplish this bytaking advantage of RADIUS proxying (during enroll-ment the client claims to belong to a recognizable specialrealm, “host@preauth”). Authenticated clients then en-gage in the normal EAP-PTLS enrollment protocol withthe radius server running on the enrollment station, butthe resulting certificate requests are then forwarded to anenterprise CA. Since we are using EAP-PTLS, the en-rollment station does this only for clients it trusts due toprior interaction over the location-limited channel. Whenthe client checks to see whether its certificate has beenissued, its EAP-PTLS exchanges are again forwarded tothe enrollment station, which retrieves the issued certifi-cate from the enterprise CA.

4.3 Implementation Details

In this section we describe the particular implemen-tation we are using in our organization; obviously, giventhe focus on interoperability with commercial software,many of these components would vary from installationto installation.

Access to the wireless network is provided by stan-dard commercial access points; the AuthenticationServer we use is a commercial RADIUS server (FunkSoftware’s Steel Belted RadiusTM). This AS is config-ured, using standard RADIUS proxying facilities, to for-ward EAP-PTLS messages from clients requesting en-rollment in the system to the RADIUS server running onthe enrollment station.

Standard Enrollment “Enterprise NiaB” EnrollmentTime (min) Steps Time (min) Steps

Avg 140 38 1:39 4

Ease Satisfaction Confidence Ease Satisfaction ConfidenceAvg 5 4 4 1 1 1

Table 2. User studies comparing our “Enterprise NiaB” solution to a typical commercial alter-native.

For our current deployment, we are using a modifiedstand-alone NiaB as our enrollment station. It runs acopy of FreeRADIUS that responds to only one EAPtype, namely our EAP-PTLS protocol. It listens forclient authentication requests over location-limited chan-nels, thus limiting initial requests for enrollment to de-vices with physical access to the enrollment station. Itmatches the authentication information it receives overthese location-limited channels with the public keys usedin requests for PTLS authentications forwarded by themain Authentication Server.

Our enterprise CA was developed in-house. It is writ-ten in Java, and provides a web-based interface used byboth people and the EAP-PTLS enrollment protocol topost certification requests. Each certificate request thatcomes in from the NiaB enrollment station must be re-viewed, edited and approved by a human before the cer-tificate is issued. Once the certificate has been issued,the user owning the device receives an e-mail message,indicating that they should re-run the NiaB enrollmentsoftware on their device to retrieve their certificate andfinish device configuration. This step can be done at anyphysical location within our enterprise.

4.4 Enterprise User Studies

We deployed this software as the primary enrollmentmechanism for our secure enterprise wireless network.Anecdotally it seemed a success – not only were endusers happier with the process, but our IT staff preferredto use the system to enroll laptops they were configuringfor other users. To confirm these perceptions, we per-formed quantitative user studies.

4.4.1 Procedure

In order to see whether our system made enrolling in anenterprise secure wireless network easier, we undertooka comparative usability test. Like the stand-alone NiaBtest described in Section 3.4, we wanted to see whetherour enterprise solution was easier to use than a currentlycommercially available alternative, described briefly be-low. We observed five individuals conducting both types

of enrollment. We followed the same subject selectionprotocol as previously described, but although we usedthe same subject pool we recruited different subjects forthis second test.

4.4.2 Control – Standard Enterprise Enrollment

We looked at users performing standard procedures forrequesting a digital certificate, installing that certifi-cate, and then configuring a standard commercial 802.1xclient to use that certificate to authenticate to a particu-lar network. The interface for requesting and installingcertificates was a web-based one, very similar to thatused by commercial Certification Authorities such asVerisign, or Microsoft’s Certificate Server software. The802.1x client software was provided with Microsoft Win-dows XPTM , and comes with a dialog-based graphicalconfiguration interface. Users were provided with exten-sive documentation as to how to perform all enrollmentand configuration steps, complete with screen shots. Thetotal procedure required 38 steps.

4.4.3 Results

The results from two iterations of study are shown in Ta-ble 2. The first interesting result was the sheer amountof time end users took to enroll in the 802.1x-securedwireless network using the standard interface – an aver-age of 140 minutes (2 hrs and 20 mins). We found thisresult very surprising. This observation underscores thefact that the intuitions of domain experts – who couldperform the same steps in minutes, if not seconds – arenot always useful in evaluating system usability, and theimportance of obtaining direct feedback about users’ ex-periences with security systems.

Using our gesture-directed enterprise solution, thetime to enroll dropped dramatically, from 140 minutesto under 2 minutes. The total number of steps to requestand install a client certificate and configure the client de-vice was reduced from a total of 38 steps to 4 steps. Moresignificantly, users reported making a variety of errors inthe 38-step process, unlike the enrollment procedure ofour enterprise solution, where they made none.

The reduction in time and the fact that users did notmake errors contributed to the users’ ratings of ease, sat-isfaction, and confidence. On scales of 1 (most positive)to 5 (most negative) users rated ease of task, satisfactionin the experience, and confidence that they could do itagain more highly for our “enterprise NiaB” wireless en-rollment system.

4.5 Discussion

While the enterprise version of our system is designedto meet the fundamental architectural and security con-straints of almost any corporate network, we have onlybeen able to experimentally test it in a relatively smallenterprise consisting of about 250 users. It remains tobe seen whether such a system could scale to meet thedemands of a community of 10,000 users supported by asignificant IT staff. Traditionally, approaches like oursare thought inappropriate for enterprise environments:large enterprises often prefer completely automated con-figuration approaches without any per-machine interac-tion. They also usually have all machine configura-tion performed by administrators, rather than end users,thereby potentially putting less of a premium on usabil-ity.

To counter these arguments, we first point outthat the use of certificate-based authentication meth-ods and EAP-TLS provides greater security than bothpassword-based approaches and automatic configurationapproaches without per-device authentication. The lat-ter approach usually encodes all necessary authentica-tion information in a static software install replicated oneach machine. This can include things like the certifi-cate of the access point or authentication server, allowingone-way authentication of the infrastructure by the client(which presumably authenticates using a password). Inmore dangerous approaches, such installers can includesecret keys shared across all devices in a network, or evena certificate and private key for the user.

We find this approach unsatisfactory for a numberof reasons. First, it requires the user to download cus-tomized software for each network they want to join. Incontrast, our client obtains all the information it needsto configure a particular network from the AP or enroll-ment station – it can be re-used to enroll a device inmultiple networks. The fact that our client software is“generic” in this way means that it could be pre-installedby an operating system vendor, without requiring furthercustomization for a particular network. Second, blindlydownloading enrollment information or keys to a poten-tial new client in a customized installer may make it eas-ier to configure that client to use a network, but it doesn’tsolve the fundamental trust assignment problem – au-thenticating that a particular device ought to be in fact

the one to receive those keys. At best, this problem canbe sidestepped by requiring that client to authenticate us-ing a previously-existing password infrastructure. Ourgoal was to allow easy, secure enrollment in a wirelessnetwork even in the case where no pre-existing trust in-frastructure existed.

Our approach can also be very appealing even in en-terprises where all new machines are initially configuredby an administrator. First, we find anecdotally that eventhe experienced systems administrators in the small en-terprise in which we deployed our system vastly pre-ferred to use it to configure new devices for other usersthan the previous, manual option. Given the increas-ing demands on administrators and the fact that manyof them are not security experts, increased usability ofsecurity can be valuable to them as well.

Second, in large organizations, administrative taskssuch as WLAN enrollment will happen repeatedly overthe lifespan of a given device – returning it to an adminis-trator every time is inconvenient. Increasingly, users in-troduce personal devices, such as PDAs, into their work-place. System administrators do not have the time andfacilities to configure each device that an employee mayneed to use at work. In all of these cases, it may be easierto have employees enroll their own devices into a wire-less network as needed, rather than expecting them to bepreconfigured by an administrator.

5 Related Work

The use of a gesture-based user interface to commu-nicate a small piece of information for bootstrapping alarger data exchange is a relatively recent idea. In re-sponse to increasing realization that ubiquitous comput-ing will demand that users select among many comput-ers around them, systems such as gesturePen [37] haveused infrared-based pointing mechanisms to allow usersto select desired targets. The role of gesturePen is tohelp users establish data communications with comput-ers around them, and the infrared channel is used to ex-change IP address information. Our work relies on thesame intuitive user experience as gesturePen, but buildson it by providing a secure information exchange.

Gesture-based user interfaces have also found otherapplications, some with security in mind [5, 30], somewithout [19]. To our knowledge we are the first to ap-ply this idea to provide a complete solution for securingwireless 802.11 networks.

The idea of location-limited channels originated in[35] (although not under that name). In [5], this ideawas expanded to use public key cryptography, enabling amuch wider range of potential types of location-limitedchannels. The list of possible location-limited channels,and their uses, continues to expand [20, 21, 30].

Our system reduces network security to the physicalsecurity at the time of enrollment – a simple, intuitivemodel accessible to non-technically-savvy users. Thisis in contrast to Microsoft’s CHOICE network [25] andthe Secure Wireless Gateway (SWG) [14], which do notrequire physical proximity, but are much harder to use.For example, in Microsoft’s CHOICE network, users en-ter an existing Passport password into a web page everytime they want to use a public wireless network. TheSWG asks a user to log in to a secure web site using anexisting password and execute additional configurationsteps. While entering a password may not seem like aburden, adding seemingly simple steps like this actuallyhas large impact for non-technically-savvy users [10].Furthermore, gesture-based automatic configuration canbe used with a wide variety of embedded devices thatmay not allow users to enter passwords.

Both SWG and Microsoft CHOICE require the userto have an existing trust relationship with the networkprovider, while our approach allows mutual authentica-tion between users and network providers that share nopreexisting relationship. We also point out that our sys-tem conveys all of the security advantages of using dig-ital certificates in a Public Key Infrastructure. This isin contrast to SWG, which secures wireless access usingIPSec configured with a shared secret.

The perceived difficulties associated with managingPublic Key Infrastructures often lead users to look forother, less secure alternatives. There has been somework, however, to make PKIs more usable (see, for ex-ample, [15]). The location-limited channels we use al-low us to side-step much of the bootstrapping problemsusually found when trying to build a global Public-KeyInfrastructure. We also show with our work that one canquite effectively use a “small-scale” PKI without inherit-ing the usability problems usually associated with largerPKIs.

6 Conclusions

Security and usability are typically thought to be atodds with each other: highly secure systems are thoughtto be necessarily difficult to use, and systems that can beeasily managed by end users are thought to be inherentlyinsecure. Yet deploying systems of mobile devices, inwhich ease of administration and security are both press-ing concerns, requires a resolution to this apparent con-flict. We have demonstrated, by way of example, thatsecurity and usability are not always irreconcilable. Our“Network-in-a-Box” system provides an example of howgesture-based user interfaces can lead to systems that areboth secure and easy to use.

We have implemented our NiaB system, both in astand-alone and an enterprise version, to test out our de-

sign. Through user studies, we experimentally measureda significant decrease in the time required by users to setup a secure wireless network as compared to a typicalcommercial access point. This improvement – from ap-proximately ten minutes down to under a minute – is es-pecially favorable when one notes that our solution setsup the highly secure 802.1x/EAP-TLS standard, versusthe significantly less secure password-based WEP stan-dard used by the commercial access point.

Our approach, gesture-directed automatic configura-tion, relates digital security to physical security in a waythat users find intuitively easy to understand. Althoughwe have applied this technique to address the particularlypressing problem of securing 802.11 wireless networks,the approach is quite general and can be used to designa variety of systems that are both secure and easy to ad-minister.

7 Acknowledgments

We like to thank the anonymous reviewers and TimDiebert for their helpful comments. Alp Simsek built the“phone home” service described Section 3.2.2. RaghuGopalan provided valuable feedback about our enterprisedeployment.

References

[1] B. Aboba and D. Simon.PPP EAP TLS AuthenticationProtocol (EAP-TLS). IETF - Network Working Group,The Internet Society, October 1999. RFC 2716.

[2] Wi-Fi Protected Access. WPA. http://www.wifialliance.org/opensection/protected_access.asp .

[3] C. Adams and S. Farrell.Internet X.509 Public Key Infas-tructure Certificate Management Protocols. IETF - Net-work Working Group, The Internet Society, March 1999.RFC 2510.

[4] N. Asokan, V. Niemi, and K. Nyberg. Man-in-the-middlein tunnelled authentication protocols. In11th SecurityProtocols Workshop, Cambridge, United Kingdom, April2003. Springer-Verlag.

[5] Dirk Balfanz, D.K. Smetters, Paul Stewart, and H. ChiWong. Talking to strangers: Authentication in ad-hocwireless networks. InProceedings of the 2002 Networkand Distributed Systems Security Symposium (NDSS’02),San Diego, CA, February 2002. The Internet Society.

[6] L. Blunk and J. Vollbrecht.PPP Extensible Authentica-tion Protocol (EAP). IETF - Network Working Group,The Internet Society, March 1998. RFC 2284.

[7] Nikita Borisov, Ian Goldberg, and David Wagner. In-tercepting mobile communications: The insecurity of802.11, 2001.

[8] P. Congdon, B. Aboba, A. Smith, G. Zorn, and J. Roese.IEEE 802.1x Remote Authentication Dial-In User Service(RADIUS) Usage Guidelines. IETF - Network WorkingGroup, The Internet Society, September 2003. RFC 3580.

[9] T. Dierks and C. Allen. The TLS Protocol Version 1.0.IETF - Network Working Group, The Internet Society,January 1999. RFC 2246.

[10] Joseph S. Dumas and Janice C. Redish.A Practical Guideto Usability Testing. Ablex Publishing Corporation, 1993.

[11] S. Fluhrer, I. Mantin, and A. Shamir. Weaknesses in thekey scheduling algorithm of RC4. InEight Annual Work-shop on Selected Areas in Cryptography, August 2001.

[12] Wireless Tools for Linux. http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html .

[13] The OpenBrick Foundation. OpenBrick.http://www.openbrick.org/ .

[14] Austin Godber and Partha Dasgupta. Secure wirelessgateway. InProceedings of the ACM Workshop on Wire-less Security (WiSe-02), pages 41–46, New York, Septem-ber 28 2002. ACM Press.

[15] Peter Gutmann. Plug-and-play PKI: A PKI your mothercan use. InProceedings of the 12th USENIX Secu-rity Symposium, pages 45–58, Washington, D.C., August2003.

[16] The Cable Guy. Windows XP wireless auto configura-tion. www.microsoft.com/technet/columns/cableguy/cg1102.asp , November 2002.

[17] IEEE. ANSI/IEEE. 802.1x: Port-based network accesscontrol, 2001.

[18] IEEE. ANSI/IEEE. 802.11i: MAC enhancements for en-hanced security, 2003.

[19] Tim Kindberg, John Barton, Jeff Morgan, Gene Becker,Debbie Caswell, Philippe Debaty, Gita Gopal, Mar-cos Frid, Venky Krishnan, Howard Morris, Celine Per-ing, John Schettino, Bill Serra, and Mirjana Spasojevic.Places and things: Web presence for the real world. In3rd IEEE Workshop on Mobile Computing Systems andApplications (WMCSA 2000), 2000.

[20] Tim Kindberg and Kan Zhang. Secure spontaneous de-vice association. InUbiComp 2003, 2003.

[21] Tim Kindberg and Kan Zhang. Validating and securingspontaneous associations between wireless devices. InProceedings of the 6th Information Security Conference(ISC03), 2003.

[22] The Dumb Networking Library. libdnet. http://libdnet.sourceforge.net/ .

[23] The Packet Capture Library. libpcap.http://www.tcpdump.org/ .

[24] C. Lopes and P. Aguiar. Aerial acoustic communications.In Proceedings of the 2001 IEEE Workshop on Applica-tions of Signal Processing to Audio and Acoustics, NewPaltz, NY, October 2001.

[25] Microsoft. The CHOICE network. http://www.mschoice.com/ .

[26] Jakob Nielsen and Thomas K. Landauer. A mathematicalmodel of the finding of usability problems. InACM Con-ference on Human Factors in Computing Systems (IN-TERCHI ’93), pages 206–213, 1993.

[27] Open Source Implementation of IEEE 802.1x. xsuppli-cant.http://www.open1x.org/ .

[28] The FreeRADIUS Server Project. FreeRADIUS.http://www.freeradius.org/ .

[29] The HostAP Project. HostAP. http://hostap.epitest.fi/ .

[30] Jun Rekimoto, Yuji Ayatsuka, Michimune Kohno, andHauro Oba. Proximal interactions: A direct manipula-tion technique for wireless networking. InProceedings ofINTERACT 2003, 2003.

[31] C. Rigney, A. Rubens, W. Simpson, and S. Willens.Remote Authentication Dial-In User Service (RADIUS).IETF - Network Working Group, The Internet Society,June 2000. RFC 2865.

[32] Robert Moskowitz. Weakness in passphrase choice inWPA interface, 2003.

[33] Acme Software. minihttpd. http://www.acme.com/software/mini_httpd/ .

[34] Network Driver Interface Specification. NDIS.http://www.ndis.com/ .

[35] Frank Stajano and Ross J. Anderson. The resurrectingduckling: Security issues for ad-hoc wireless networks.In 7th Security Protocols Workshop, volume 1796 ofLec-ture Notes in Computer Science, pages 172–194, Cam-bridge, United Kingdom, 1999. Springer-Verlag, BerlinGermany.

[36] Adam Stubblefield, John Ioannidis, and Aviel D. Ru-bin. Using the Fluhrer, Mantin, and Shamir Attack toBreak WEP. InProceedings of the 2002 Network andDistributed Systems Security Symposium (NDSS’02), SanDiego, CA, February 2002. The Internet Society.

[37] Colin Swindells, Kori M. Inkpen, John C. Dill, andMelanie Tory. That one there! pointing to establish deviceidentity. InACM Conference on User Interface Softwareand Technology (UIST 2002), pages 151–160, 2002.

[38] W. Townsley. Layer Two Tunneling Protocol (L2TP).IETF - Network Working Group, The Internet Society,December 2002. RFC 3438.