Abstract—An Ambient Computational Environment (ACE) is a set of devices and services that allow a user to operate without the usage of many cumbersome devices attached to the user’s person. Security in such an infrastructure is a must for apparent reasons. This paper addresses the design and implementation issues related to securing an ACE, namely identification (authentication) of users and services in the ACE and ensuring encrypted communications between users and services alike. A limited form of Public Key Infrastructure has been put in place in the ACE. Identification through X.509 digital certificates and RSA Key pairs also ensures compatibility with other non-ACE applications.

Keywords: Ambient Computational Environment, PKI, Diffie-Hellman, SPEKE, X.509

      I.           Introduction

An Ambient Computational Environment (ACE) is meant to assist users perform the same operations that they do today. All ACE users would have workspaces and work the same way they do so in today’s world. Mobility is the key issue in ACE – a mobile user is “device free”, that is, he does not have a set of cumbersome devices such as cell phones, laptops with wireless 802.11 cards, and pagers with him. The user has to be mobile, with the same capabilities he has in today’s communication infrastructure. Whether it is taking a presentation to the conference room or porting the address book to the iPAQ, user mobility and its relation to service accessibility is the core issue. Critical to the issue of implementing this fundamental philosophy of mobility in ACE is the process of embedding all devices in the environment itself. Devices in the ACE are meant to refer to almost the entire gamut of physical instruments in today’s networked world. They include normal desktop systems, cameras, projectors (wired and wireless), fingerprint identification units, IButton™ receptacles and smart card readers, handheld PDAs, etc. All these devices are embedded in the environment and assist the users mobility. With ACE, you can still present your PowerPoint file in the conference room projector; only you do not need to lug your laptop to the projector room, set up the projector and do a host of other things! All you would need to do would be to start the presentation in your computer walk to the conference room and your presentation would be ready. All the devices that you would ever need are in the Environment itself. The Environment itself computes and serves the user. The user is thus said to be in an Ambient Computational Environment. There is not anything “new” in ACE; rather, what is new is how the devices and services are integrated. When a new type of device is incorporated, be it the latest iPAQ or a Java™ enabled cellular phone, they would integrate into ACE smoothly. The user need not type in his address book into his new cell again. It would already be there simply on account of the fact that the cell phone is there in the ACE. The Ambient Computational Environment approach takes pervasive communication and computing to the extreme.

      II.          The ACE Architecture

The ACE architecture is based on a number of devices embedded in the environment, which are controlled by corresponding daemons/services.  A camera for instance is a device in the ACE, which is controlled by a corresponding service. Some services do not concern themselves with any devices. They perform monitoring jobs in the ACE. The services provide the lowest common denominator for all activities in the ACE. All user interaction and control in the ACE at the bottom level is through these services.  There are further levels of wrappers that go above all the services. The wrappers are dependent on the type of the service and the need of the user. There are over forty services in the ACE at present, each catering to a narrow subset of the functions that are required for the ACE to function. There may be many instances of a service or a single instance of it. For instance, a service that monitors the ACE resources, the System Resource Monitor, has a single instance in the ACE while a subsidiary service that monitors the resources of each individual host, the Host Resource Monitor, has multiple instances in the ACE. This basic design helps in two very fundamental issues. Any new device or a host needs the barest minimum of services running on it to be part of the ACE. Hence a single instance of a properly designed service on a new device is sufficient to make a new device such as a Java™ based cell phone part of the ACE. Other crucial services that are needed for the ACE to function can have many instances. This leads to the whole new possibility of distributing the services. Hence no service in the ACE becomes a single point of failure. Replication of services not only becomes a possibility in the ACE, but also is a feature inbuilt into the service’s structure.

All services in the ACE subscribe to a central service: the ACE Service Directory (ASD). As the name suggests, the ASD acts as a directory service inside the ACE to provide information about all the services in the ACE. The ASD itself is also a service in the ACE with one crucial difference. It is available on a well-known machine and on a known port, which is specified in a configuration file. All the services in the ACE communicate with each other and with the devices depending on their function. Services get information about other services from the ASD. Hence the ASD is crucial to the working of the ACE. However, the relationship between the services and the ASD is not the same as that of a client-server relationship. Services continue functioning if the ASD dies or has not started yet. They continuously poll for the presence of the ASD and resume normal functioning once the ASD is up and functioning. While service do communicate with each other, the ASD only serves the purpose of disseminating information about each service in the ACE. All future communication between the services takes place on an individual basis. Hence the ASD is not loaded with traffic from all the services in the ACE.

Communication between all the services occurs by means of ACE network commands. Each service has a command interface through which instructions can be issued to it. The set of commands in each services command interface are the orders that the service can directly take. The command interface also defines the service’s interaction with other services and other applications (wrappers) in ACE. Besides these, each service can throw out a notification in the ACE.  Any service can register for a notification from any other service. Notifications are typically meant for events in the ACE that do not occur with a predictable regularity, but are important so that other services need to be informed about the events. All notifications also occur through the mechanism of ACE network commands. The significance of this grouping of the services communication modes will be evident when the security issues in the ACE are discussed. Apart from these two (main) modes of communications (command interface and notifications), a service, depending on its function, can also connect to another service and transfer large streams of data. For e.g. the Audio and Video capture and play daemons shuttle around audio and video streams between themselves in the ACE. This forms part of the ACE solution for interactive conferencing. The ACE Architecture is therefore a robust structure with the base already built in for commissioning services. These commissioned services are easily incorporated into the ACE and can inherit the properties and capabilities of those services already commissioned. Consequently, any new device or host can easily be introduced into the ACE and made part of it, taking full advantage of the ACE features and contributing equally to the ACE.

    III.        Security Issues in the ACE

         The ACE architecture is replete with references to the ACE services. Over forty services have been deployed in the ACE. These services, as mentioned before, form the lowest common denominator over which the ACE functions. All services communicate with each other by means of the ACE network commands. They send out notifications about relevant events and shuffle data (audio and video) around the network. The ACE user utilizes these services to operate in the ACE. The user may interact with the ACE by means of a desktop host or a laptop or a tablet or a PDA or any other futuristic communication device. The basic security issues, which are common to all systems, are those of authentication, authorization and accounting. As applied to ACE, the immediate issues that arise are those of user authentication and authorization. More important are the same issues when applied to the ACE services themselves. Hence, all security problems and their solutions (design and implementation) are narrowed down on these two entities, the ACE user and the ACE service. The broad goal of providing security in the ACE translates into providing an infrastructure for identifying the ACE user and the ACE service and ensuring secure communications in the ACE.

A.       Identification

 The core issue here is to identify the main players in the ACE, namely the user and the service. The identification mechanism can be anything as long as it provides ease of usage to the user. Services can be coded to use any authentication scheme. The implementation issues with services are one of efficiency of the authentication scheme. But with users, the issue is one of usability. The most common identification mechanism, in this case is the username-password combination. While this is fraught with the usual danger of users choosing bad passwords, it’s by far the most commonly used authentication scheme in today’s networked world. It is essential for ACE to support and integrate schemes that are secure and through which ACE can interact with the rest of the world. These dual goals of high level security while maintaining a high level of usability to the user are often conflicting, if not impossible, in areas which require a very high level of security. However, ACE strives to achieve both these goals by deploying more than one authentication mechanism, such as other popular authentication mechanisms including biometrics and electronic mechanisms such as smart cards, etc.

            The ACE structure is designed so that independence and hierarchy are both achieved for each ACE domain. It is noted that this is an intuitively conflicting goal. What is actually implied here is that while the ACE domains shall continue to function independent of each other, permissions translations and mobility of the user (and hence his security settings) shall be hierarchical. For e.g. in the University of Kansas, the EECS department shall have an independent ACE domain while the research branch of the EECS department, ITTC, shall have another ACE domain in their building. These ACE domains shall have their own set of services with their own ASD. However, when a user transits from one domain to another, authentication has be made in such a manner that the user in the new domain should inherit his settings (personal preferences to security settings) smoothly. Herein comes a hierarchical setting where the EECS domain, on account of being the parent of its research wing, shall be master of the authentication mechanism. A limited form of Public Key Infrastructure (PKI) comes as a natural solution in this situation. A master certificate authority in one domain can issue identifying certificates to the ACE entities (the user and the service). This is an ideal solution to the ACE services, which can now connect to the outside world by means of a simple web-browser or connect to any other service (in its own domain and outside its domain) and establish a session key for secure communications. Note that this solves the dual problem of identification of the users and services and that of secure communication, to a limited extent.

B.       Secure Communications

As mentioned before, the ACE is full of services that communicate with each other by means of ACE network commands and send out periodic notifications. All these communications take place over the network. Securing these communications is the next step in resolving the security problems in ACE.

Encryption and decryption are the standard and accepted mechanisms to ensure secure communications. The ACE services also exchange data streams (audio and video) apart from the ACE network commands. The difference here between the ACE network commands and the data streams is very fundamental. As a consequence of this, the approach taken towards securing the ACE network commands and the data streams is also drastically different. Any steps taken to secure the ACE network commands will cover all the ACE services and the notifications that they send. The advantage also lies in the fact that any new service in ACE shall inherit these features and shall need to do nothing specific to ensure secure communications. However, the concerns with the data streams are quite different.  Data streams need a different mechanism to encrypt and decrypt them. The same mechanism that is used for the ACE commands cannot be used here. Data streams have a different characteristic in terms of a need for real-time delivery. Their traffic characteristics also vary from those of the ACE network commands. From an implementation point of view, they would probably need a stream cipher suite than block encryption mode. As noted in the previous section, the very act of identifying services and users with PKI based digital structures enables services (and hence the users) to compute session keys for secure communications. ACE shall now have to provide ways for the services to secure their data streams independent of the certificates. An inherent requirement in this “way” is the capability to compute a session key for any cryptographic algorithm with any key strength. This is fundamentally different from key negotiation when viewed in terms of implementation.

Besides these types of communications, there are other means by which the ACE operates which need to have secure communications. The most important is one of securing the users session in the ACE.  Very simply put, this is a remote VNC (Virtual Network Computing) session with the main VNC server running in a secure machine in the heart of the ACE domain. The VNC data stream needs to be encrypted in a strong security sense. The fact is that the VNC session is what the user sees as his workspace and hence, it is the ACE to him. The compromise of the VNC session can effectively compromise the entire ACE domain from the viewpoint of the user. Since a VNC viewer can also request a shared session, it becomes more imperative that the session is properly encrypted or else the compromise is not just in terms of data or passwords. An active attacker can actually see what the user is doing! This fact is true with users inside an ACE domain and outside the ACE domain. Users from outside the ACE domain also need a scheme by which they can connect into the ACE domain. This should appear to the user the same as though logging into the ACE from inside the domain. Hence, the username-password combination or a certificate or any biometric means of authentication employed by ACE as a means to authenticate users inside the domain should also work outside the domain. This necessitates that a security protocol be deployed to authenticate users, establish a session key and secure all further communications between the user and the ACE domain. The user communicating with the ACE domain actually translates to the user communicating with the ACE service that acts as the gateway into the ACE domain.

The difference between being authenticated from within the ACE and from outside the ACE is also to be observed. Any user who is locally authenticated is done so through an ACE service directly. Hence all network communication is through the ACE network commands. They are automatically encrypted through the same mechanism that encrypts all ACE network commands. Remote authentication, on the other hand, requires a standalone application that connects to the ACE service and transmits the authentication parameters through an unprotected network. (Although the network outside the any systems domain is considered unprotected, security in ACE is designed to treat even the traffic from inside the domain as suspicious unless authenticated and encrypted). The standalone application connecting to the ACE is assumed to have zero knowledge about the ACE service and vice versa. Requirements in such a protocol to remotely authenticate the user with zero knowledge about the user and the service are many-fold. The protocol has to ensure perfect forward secrecy, protect itself from offline dictionary attacks and also be immune to the obscure chosen protocol attack [3].

While many standard protocols are readily available off the shelf, the choice of the protocol has to take into account the fact that ACE is all encompassing. The ACE user must be able to work remotely from a normal desktop machine or from a PDA or a Java™ enabled cell phone. The existence of different devices in ACE is a consequence of the very definition of ACE and its commitment to be all-inclusive. The implication of this is that different devices will have different characteristics in terms of computational power, bandwidth accommodation and battery power. Therefore the protocol in use by ACE to allow remote users into the ACE have to satisfy the additional requirements of accommodating devices of varying capabilities. It is evident that no single protocol will be useful for all the devices. A choice of protocols has to be given to the remote connection application. Thus secure communications in the ACE includes securing three broad types of communications, namely the ACE network commands, the data streams in the ACE and the remote user connecting from outside the ACE domain. The next section discusses the security services in ACE that have been deployed to ensure security in the ACE.

    IV.         Security Services

As observed in the section on ACE Architecture, the entire ACE is structured on the basis of the ACE services. It implies that providing security in the ACE should also translate itself into providing services that protect the ACE. The services covered here are the primary services that form the base for other services to identify themselves and secure their communications. The services presented here are used for authenticating the user (locally and remotely) and identifying the user and the service. They constitute the local authentication services, the remote authentication service and the limited PKI services in ACE. A Key Manager service that helps in secure communication by issuing cryptographic keys of varying strengths is also presented.

A.       Authentication Services in ACE

ACE handles user authentication in four ways. The user may identify himself by means of a username-password combination, an IButton™ ID or with his fingerprint. In the case where the user is remotely logging into the ACE domain, he may also choose to log into the ACE domain with his digital X509 certificate. When the user logs into the ACE domain from inside, it is expected that he’ll log in by means of a password, IButton™ or a fingerprint. The user ID presented (fingerprint or IButton™ or password) is trapped by the corresponding service in the local machine. For e.g. a service specific to the IButton™ runs on every host that has an IButton™ receptacle connected to it. It polls the IButton™ receptacle to see if an IButton™ has been depressed into it. A similar service polls the Fingerprint Identification Unit and detects the any fingerprint. These services throw out a notification in the ACE with the relevant information (the fingerprint / IButton™ data). Any service in the ACE that registers for these notifications receives the relevant data and acts on the notifications. Once the relevant ID is captured, it is compared with a database of the previously cached IDs and the user is authenticated. Note here that the entire ACE Network commands are encrypted through SSL (Secure Socket Layer). The advantage of this is that all services that are deployed automatically inherit the feature of secure communications. Furthermore, since the notifications that are sent by any service are in fact sent through the ACE network commands, they are also automatically encrypted. This is how ACE authentication is done from within the ACE domain.

Note also the modular design of the ACE services here. The two services only poll the devices and check if an IButton or a finger is present. The actual authentication is done by some other service that has access to the user database.

In the case of remote authentication, the Remote Connection Manager service manages the network connection to the outside world. The service interacts with a standalone application that transmits the authentication parameters. They both talk over the SPEKE [1] (Simple Password-authenticated Exponential Key Exchange) protocol. This protocol allows the two parties to mutually authenticate each other, establish a session key for encrypting further communications and avoids offline dictionary attacks. It is basically a zero knowledge password proof protocol. It suits the remote authentication scheme very well in our case. The remote connection is assumed to be out of the ACE domain completely. This requires a zero knowledge password proof protocol in place.

Since ACE aims at being ubiquitous and incorporating new technologies as they come by, the user is given the options of authenticating himself by means of certificates, IButtons™, fingerprints and passwords. Unfortunately passwords are the Achilles heel of all security systems. A badly chosen password can be easily cracked in no time. While the administrative solution to this issue is to educate users on choosing a good password, the technical solution lies in not providing the active attacker any text; plain-text, cipher-text or worse still the cipher-text and its corresponding plain-text from which an offline attack may be mounted. Offline password guessing methods such as dictionary attacks against the hash of the password are very common and are to be avoided.

Note that we do not have a shared key between the user and the ACE domain (unless the user happens to have his private key with him). We also need to ensure mutual authentication between the user and the ACE domain. So trying to authenticate to a third party server for recovery of private keys or something similar is not useful, for the very simple fact that the mutual authentication that has to be performed with the server might as well be performed with the ACE service directly. Also, introducing a server introduces the additional annoyance of protecting against replay and timing attacks against the server.

SPEKE is a protocol that satisfies all our requirements. The protocol is a very simple variation of the Diffie-Hellman key exchange protocol. The Diffie-Hellman protocol provides for any two communicating parties to establish a session key without having any prior common secret material. The key exchange revolves around the two publicly known values, a prime number p and a generator g that is smaller than p and has a few restrictions. The two parties, after knowing these two values, commence with the message exchange at the end of which they have a session key that cannot be computed by any eavesdropper. The SPEKE protocol modifies this exchange so that mutual authentication is also achieved. The SPEKE protocol’s modification of the Diffie-Hellman exchange is implemented by publicly exchanging the prime number P, but making the generator the squared hash of the shared secret, which is the password or the IButton™ ID or the fingerprint. The session key is then computed in the same manner as in the Diffie-Hellman protocol. The verification of the Session key in itself provides mutual authentication. SPEKE thus provides strong password protection without a strong password (in principle)! This is of course, illustrative only of the protocol’s strength and is by no means a passport to poorly chosen passwords. The advantage, in particular, is that the same protocol can be used to authenticate the user by means of an IButton™ or a fingerprint. Since it’s just the hash (squared) of the secret that matters, SPEKE can be used to authenticate with almost any shared secret. The relevance of this can be observed in the analysis section, particularly with the usage of IButtons™ and fingerprints. The message exchange in the SPEKE protocol is given in the table below. The notations and the message exchange shown here are exactly the same as that presented in the original paper.

Notation:

S: A small password shared by Alice & Bob

P: A large prime, where (p-1)/2 is also prime 

R_A: The secret random number chosen by Alice

R_B: The secret random number chosen by Bob

H (x): One-way hash of x, like SHA1 (x)

TABLE I.            SPEKE

Ref.: http://www.integritysciences.com/peek.html

The exchange shown above is a minimal 3-pass exchange for establishing the session key. That is a highly desirable feature for wireless systems where bandwidth and CPU/Battery power come at a premium. But it is to be noted that SPEKE is not designed for wireless devices and hence is not deployed for wireless devices in ACE.

B.       PKI based Services

               In its effort to address the issue of user and service identification across multiple ACE domains and to blend with the outside world in terms of accessibility and uniform identification, ACE supports a limited set of PKI services. These services are responsible for generating and issuing users and services alike with digital X509 Certificates. These certificates help identify users and services. They also enable the services to compute dynamic shared keys between themselves when required and communicate securely. The PKI based services in ACE are the CA (Certificate Authority) and the CDS (Certificate Distributions System).

            The ACE CA is responsible for issuing digital X509 certificates to the users and services in ACE. The CA also revokes certificates when required. Certificate revocation is usually done when a private key compromise has been detected or is suspected. Certificates may also be revoked in the ACE when users leave the ACE domain before their certificates expire. The ACE CA is also capable of answering queries regarding the validity of a certificate. In essence, it performs some of the functions that are actually performed by a certificate distribution system in a typical PKI environment. The CA has been designed in this manner since it is unlikely to be under a very heavy load most of the time. When the ACE domain starts up, there are bound to be many incoming requests for a certificate from all the services. After the services, whenever a new user is added to the ACE domain, there is a likely request for a certificate. Apart from these instances, the CA is mostly idle. Hence it has also been designed to answer queries regarding the validity of the certificates. Whenever the CA issues or revokes a certificate, it also throws a corresponding notification with the newly issued certificate or the revoked certificate.

            The CDS listens for these notifications and publishes the information in a publicly available LDAP v3 (Lightweight Directory Access Protocol) server. The CDS also runs a very rudimentary web server with an applet that allows the user to connect to the LDAP server run by ACE and make rudimentary queries. Since the applet can connect to the machine from where it was run from, it mandates that the LDAP server also should be run on the same machine as the web server. Hence the CDS should also be resident on the same machine. This gives us an implicit advantage since the LDAP authentication parameters are not transmitted through the network. The reason why the CA and the CDS have been implemented as two different services despite the fact that the CA performs some of the CDS functions is that the CDS interacts with some of the standard non-ACE components (i.e. the LDAP server). Furthermore the CA functions as the CDS to all the ACE services. The CDS takes care of making that information available to the rest of the non-ACE world. Since the CDS shares a one-way relationship with the LDAP server, any compromise in the LDAP server does not carry itself on to the ACE domain. The CDS is in no way compromised through a compromise in the LDAP server.

            Besides these PKI based services, ACE also has a key manager service that issues keys for a variety of cryptographic algorithms. Any service can request keys of a specified strength for any algorithm. The Key Manager issues the keys and also stores them in a keystore. Observe that this is a situation with the conflicting goals of Perfect Forward Secrecy (PFS) and complete control. In view of maintaining PFS, it is desirable that the key manager not store all issued keys. That decision could be taken at the time of deploying the ACE. The key manager can also be used to issue keys for a conference between large numbers of users in the ACE. This centralized approach works better than the users negotiating a session key among them based on their certificates. The disadvantage however, is that it also becomes a single point of failure. A more distributed form of conference key distribution [6] is required in the ACE.

     V.          Analysis of ACE Security

This section looks objectively at the security schemes implemented in ACE. As observed in the introduction section, ACE is about reinventing the infrastructure so that we can create more sophisticated applications. The security schemes in ACE are about proper choice and proper implementation in the given scenario. The analysis discusses the schemes that were indeed chosen and implemented in ACE.

The analysis proceeds to ask a few simple questions [4], the answers to which reveal the strengths and weaknesses of the ACE security schemes.

The first issue to be addressed relates to the problem statement in the ACE. The security problem in ACE is one of secure communications between the different services. It also concerns itself with user and daemon identification. Authentication problems, which are essentially the same as identification issues, come in two distinct flavors: local and remote.

The second issue now relates to the effectiveness of the proposed solution. The solution for identification has been a set of limited PKI based services. Authentication of users is performed by means of the username-password pair, or an IButton™ or a fingerprint. The X509 Digital Certificates provides a good identification scheme for both users and services, being useful not only inside the ACE, but also in interfacing to other non-ACE systems. All ACE communications are encrypted by SSL. The combination of SSL and identification of services through certificates is potent when it comes to services communicating within an ACE domain and outside. Services of two domains can authenticate and establish session keys with each other through their certificates. Services inside a domain can communicate through SSL with a predefined key from a configuration file. The inclusion of a PKI in ACE also paves the way for a hierarchical authentication scheme with multiple ACE domains while ensuring independent operation of the services in each domain. ACE also has a key manager service that can issue cryptographic keys of the desired strength. Such services could be used for securing conferencing sessions between many users. The fact that the key manager can issue keys of the desired strength implies that any service can choose the level of key strength it needs, depending on the scenario. The choice of key lengths, though debatable, is not a handicap in the ACE. Thus ACE provides the necessary infrastructure needed for any kind of secure communications to be put into place. The solutions offered for the most common security problems in ACE appear good enough and effective too.

In view of this, the third question assumes importance. We discuss here on what new problems have been added in ACE due to these security schemes. The inclusion of PKI in ACE gives us the pain of maintaining a Certificate Authority and the corresponding distribution system. Apart from this are the usual social engineering problems that affect all systems. As regards ACE, their effects are slightly more pronounced than for other systems. Passwords, as mentioned before are the Achilles heel of all security systems. By implementing the SPEKE protocol, ACE can claim to have reduced the problem significantly. But once a compromise in passwords has been detected, they can be easily changed. But as far as the IButton™ is concerned, once the ID is compromised, the buttons have to be replaced. The infrastructure waste in this situation cannot be over-emphasized. The situation is worse when it comes to fingerprints. Not only can they be replaced, it is ridiculously easy to fool fingerprint scanners if recent reports [5] about them are to be believed. The solution in this case only lies in furthering the technology that goes into the making of these scanners. The administrative solution in ACE as regards the IButton™, password and fingerprint hazards are to educate users to choose better passwords and report stolen IButton’s immediately. The technical solution would be to restrict the rights of all users logging into the ACE remotely through an IButton™ or a fingerprint. This would mean placing them in a user group with restricted access control. This definitely is a problem in the ACE. Once again, we tread the fine line between user convenience and strong security.

Other extraneous issues in security issues relate mostly to their implementation. Most of the ACE components are coded in Java™. The object-oriented nature of the language gives us implicit advantage when we want to add new services with more functionality than existing ones. For e.g. this is particularly useful in cases where the existing services address controls to a general class of cameras and we want to add a layer to Pan, Tilt & Zoom cameras. From the security perspective, Java™ scores very well against buffer overflow attacks, which are by far the most common implementation mistakes found in today’s systems. Since ACE services are responsible only for displaying the VNC session to the user, Java™ in no way inhibits us with regard to its limited file operations and inadequate (if none) operations on Access Control Lists (ACL). The SPEKE protocol involves exchanging a prime number for initiating the protocol [2]. Java™ does not produce an exception when numerical overflows and underflows occur. In the ACE, it could lead to security vulnerabilities if any assumptions are made when dealing with numbers of a huge order.

In conclusion, we would like to mention that building a secure system is a process, not a product that can be neatly gift-wrapped. Securing the ACE is also a process, one that assures us that the ACE is “presently secure” and has to be continuously revamped.

Acknowledgment

The authors wish to thank the ACE project sponsors, including DARPA, NSF and Sprint Corporation.

References

[1]      David P. Jablon, “Strong Password-Only Authenticated Key Exchange” Computer Communication Review, Oct 1996, Vol 26, Number 5

[2]      P. MacKenzie, “On the Security of the SPEKE Password-Authenticated Key Exchange Protocol” Bell Laboratories, Lucent Technologies

[3]      Kelsey, Schneier and Wagner “Protocol Interactions and the Chosen Protocol Attack” Security Protocols Workshop ’97, number 1361 in Lecture Notes in Computer Science, pp. 91-103.

[4]      Bruce Schneier, “How to think about Security” Cryptogram Newsletter, April 15 2002. http://www.counterpane.com/crypto-gram-0204.html#1

[5]      Bruce Schneier, “Fun with Fingerprint Readers” Cryptogram Newsletter, May 15 2002. http://www.counterpane.com/crypto-gram-0205.html#5