Roaming PKIs: Harbinger of Virtual VPNs?

About a year ago, I started to use the expression "virtual VPNs" to describe what I see as the eventual future of Internet communication. A private network, of course, allows communication between geographically disperse sites over communications facilities that are reserved for use by the organization that owns or leases the facilities. Since these are private lines, the communication is secure, at least from eavesdropping by outsiders. A virtual private network (VPN) provides private network-like features and security over a public network, such as X.25, frame relay, or the Internet. In most cases, Internet-based VPNs use public key cryptography methods to support authentication and secure communication; certificates provide the basic mechanism with which public keys are shared. VPNs are most typically used to provide access to a corporate network by remote users (access VPN), intra-corporate communication (intranet VPN), and external access to some corporate resources (extranet VPN). In all cases, however, a VPN user is known to the network before access is allowed.

In a slightly different vein, most of us have already used certificates and cryptography, such as when we make an on-line purchase using SSL to protect our credit card number. But while SSL uses certificates, it is the server that is authenticated to the user and not vice versa; if the credit card number is approved for the purchase, the server figures that that is sufficient user authentication. The nice thing with SSL, of course, is that any user with a browser can access any secure site using certificates without pre-establishing an account with the server.

The term virtual VPN is meant to suggest an environment with the best of both worlds: anyone can communicate with anyone else, obtaining VPN-like security and privacy using certificates and cryptography but without requiring the a priori relationship demanded by today's VPNs. And in the latter half of 1999, several companies introduced products that support roaming certificates, which is, in my opinion, a harbinger of this future mode of any-to-any secure communication.

In today's environment, different types of cryptography are used for secure communication. Secret key cryptography (SKC), such as DES and 3DES, is typically used to encrypt messages and other communication, for purposes of privacy and confidentiality. Public key cryptography (PKC), such as RSA, is commonly used for key exchange and authentication. If two parties wish to exchange a secret message, they can merely use an agreed upon SKC scheme and a secret key selected by one of the parties; the secret key is encrypted using the public key of the other party.

But how does the sender know the public key of the other party? The answer is public key certificates, which bind a user name with a public key, key expiration date, and other information that controls the use of the key. The emerging public key infrastructure (PKI) will provide a set of distributed certificate servers that will allow any user anywhere to find the public key of any other user. But the PKI required to support this level of interchange is still in the early stages of development and acceptance, and far from being widely available.

Meanwhile, many companies use certificates internally for intra-corporate communication. Foo Corp., for example, might issue certificates to all of its employees; Foo Corp.'s digital signature confirms the authenticity of the individual users' certificate. In turn, Foo Corp. might turn to a well-known root certificate authority (CA), such as Entrust or VeriSign, to sign Foo Corp.'s public key certificate, authenticating all of Foo Corp.'s users' certificates to the world. This hierarchical chain of trust is consistent with general business organizations.

But let's look at Foo Corp.'s internal communication. While certificates ostensibly bind users to a public key, they are generally implemented so that they are tied to one computer. This works pretty well as long as the individual only uses a single computer and the computer only has a single user.

But it is common today for a user to move amongst multiple computers within an organization or for a single system to be shared by multiple users. Today's way of making certificates mobile is to burn the certificate onto a smart card. Using smart card technology, the certificate and the public key pair are on the card, but only the public key can be read from the card. The limiting factor with smart cards is that they are only usable on systems with a smart card reader, which may not be every system within an organization. Of course, you could carry your own smart card reader with you, but that creates another potential problem - suppose the "foreign" system that you plug your reader into has been tampered with so that your password, certificates, and keys are cached without your knowledge.

Another way to move a certificate is to copy it onto a floppy disk using the Personal Information Exchange Syntax Standard (PKCS #12). The certificate, of course, needs to be encrypted and that requires another key, which is probably based upon a shared secret such as a weak password.

There is more than meets the eye to this scenario. The certificate provides user and public key information. But since messages and files are encrypted using secret keys that are exchanged using PKC, there must also be a store with the entire SKC history. You don't want this information to have to be managed by end users! And, in addition, the user that copies the certificate to the new system is responsible for removing it; if it is not manually removed, the certificate stays on the computer where a nefarious person can appropriate it.

FIGURE. Sample scenario where a certificate is bound to a user's PC, but the user can go to any other appropriately-configured computer anywhere on the Internet to access the certificate server and network resources.

This is where roaming certificate technology comes in. Roaming certificates allow a user to go to any appropriately-configured system and access their public key credentials (see figure). While the concept is almost obvious, the implementation requires strong cryptographic protection ideally coupled with a simple-to-remember password. While everyone agrees that passwords are the weakest form of protecting secrets, the reality is that they are, and will remain, the prevalent security tool for many years to come. Even when users have smart cards and tokens, passwords are somewhere in the security chain.

A number of companies support a roaming certificate model that obviates the need for removable storage such as smartcards, and the paragraphs below will examine two such products. Both address issues of scalability, ease of use, and the fact that today's browsers are just about the only client software that natively knows how to use certificates.

Entrust (http://www.entrust.com) has built roaming certificate capability into their PKI 5.0 product. They built this product to provide a "flexible, secure, easy to use, and low cost" roaming capability, combining specialized client software with a secure, central certificate server and a Lightweight Directory Access Protocol (LDAP) server. The general idea is that I would create my digital identity - i.e., a certificate and public-private key pair - locally, where it is secured with my password and a Profile Server password. The Profile Server is a broker that gets users and their certificates together; the Profile Server publishes the certificate information to an LDAP directory server.

If I now go to another computer that has the PKI client software, I can connect to the Profile Server and supply my password. The SPEKE algorithm is used for the password-based authentication. My profile is now downloaded into the memory of the local system, decrypted using the Profile Server's password, and then decrypted using my password. At that point, my credentials are known to the local computer and used by any application needing them.

If I do all of my secure transactions in one sitting, I will also only have to login once. For example, if I surf to a secure Web site, the computer will automatically contact the Profile Server, prompt me for my password, and obtain my certificate from the Profile Server. If I now want to send a secure e-mail, no further action is necessary; once my credentials are downloaded, I can do all of the secure (and/or unsecure) communication that I want. When I logout, the certificate information is scrubbed from memory; logout can be defined in a number of ways, such as going for N seconds without any security-related activity. This prevents one user from being able to use another user's credentials that have been "left in memory."

The PKI client software is essentially an operating system plug-in, forming a secure sublayer that enables roaming for all applications. While individual application plug-ins are available for Eudora, Outlook, Exchange, Notes, and other products, GroupWise ships natively with a PKI plug-in. Entrust's PKI toolkit also allows plug-ins for other products to be developed. The key advantage is that certificates can be incorporated into the way an organization does its business without changing applications nor the old processes.

The Entrust product also provides a mechanism for the auto-recovery of passwords; about 25% of all users forget their password at least once in any given year so it is important that users' certificates, and their secret key history, can be retrieved. This feature also allows an organization to recover a key in the case that an employee leaves the organization.

VASCO Data Security (http://www.vasco.com), through their acquisition of IntelliSoft (http://www.isoft.com) in October of last year, makes a roaming certificate product using their SnareWorks software. Like the Entrust product, their roaming scheme requires an on-line service, replicated directories, and high availability of servers and communications.

The major issue here is the protection of the "crypto bundle" which contains the public key certificate and the private key. A strong 3DES secret key is used for this purpose. This key may be stored physically on a DigiPass, VASCO's family of hardware devices designed to provide security and access control for computers. Alternatively, the SnareWorks client can access the 3DES key at the server via the Private Key Access (PKA) scheme. PKA employs VASCO's Challenge Response algorithm (also used by the DigiPass products) to access the 3DES key stored on the server, which is in turn used to unlock the "crypto bundle"; the key is never transferred to the user's computer.

The VASCO solution is designed to work with the most common certificate caches in use today, namely, Entrust (which uses a proprietary exchange scheme), Microsoft (using their Cryptographic API), and Netscape (using PKCS). If a user wishes to download their certificate when using a "foreign" system, they have to ensure that SnareWorks client software is installed; it is responsible for the certificate import/export function with the specified certificate server. The certificate is stored on the system in a either memory or on the hard drive, depending upon the requirements of the API used to access the certificate cache. The software provides a transparent security infrastructure for all applications.

One model for the use of the VASCO solution is as follows. A new employee could be directed to access a particular Web page, where they employ a secure protocol such as SSL or a VPN client to register themselves. The registration server obtains certain usage and privilege information from an administrator and then creates a user account, passwords, etc. The server will also generate a public/private key pair and contact an appropriate CA to generate a certificate. If the certificate is marked as "roaming," then it can be made available to any application that the user uses on any system running SnareWorks.

The SnareWorks Integrated Login software at a client is linked with the computer's operating system so that it knows when a user logs in and out. Upon login, the user's crypto bundle is downloaded and installed on the local system, along with network credentials that carry additional information about the user, such as security attributes, user policies, and access control groups; while certificates can be used for authentication and digital signatures, network credentials control what a user can do in a protected environment. When the user logs out, SnareWorks is responsible for removing the crypto bundle from the system.

One can argue that the only organizations that should seriously consider roaming certificates are those that are currently using or considering static certificates. The most common applications for a roaming PKI seem to be to expand common intranet applications and supports the notion of location-independent network access. If a user, for example, has to travel to another corporate location, the user can logon from any system, access the certificate server, be authenticated, and obtain their certificate; at that point, actual geographic location becomes irrelevant.

Alternatively, consider an organization that provides a pool of terminals for employees on a shop floor, manufacturing line, or "hotelling" office space, where no user has an assigned system. As above, the user merely logs on and is granted their certificate and access.

But a roaming PKI applications might not be limited to today's intranet/VPN and, indeed, it allows the potential for a new service to be offered by public Internet kiosks. Consider the public Internet terminals that are becoming increasingly available at airports, hotels, business centers, and industry conferences. If such a system implemented the same roaming certificate technology as a particular user's organization, that user could access corporate resources while in a public place which could be quite beneficial; in some cases, it might even obviate the need for traveling with a laptop.

PKIs are still in their infancy and roaming PKIs even more so. But this new addition to PKI technology is pointing in the right direction.

The Simple Password-authenticated Exponential Key Exchange (SPEKE) algorithm, invented by cryptographer David Jablon of Integrity Sciences, Inc. (http://www.integritysciences.com), has been licensed to Entrust for use in its PKI products. SPEKE is a type of zero-knowledge proof (ZKP), where two parties prove to each other that they both know the same secret but neither party reveals the secret. In this way, the two parties can mutually authenticate and an eavesdropper learns nothing useful.

From a cryptographic perspective, SPEKE is special because it is a ZKP applied to a small secret. Most of the ZKP research prior to the early part of the 1990s was devoted to ZKP of large secrets because secure cryptography requires large numbers, such as 512-bit passwords that only computers can memorize. Conversely, a small secret might be an 8-byte password, easily memorized by a person. Small secrets were not viewed as cryptographically important because high-speed computers made an attack on small secrets too easy.

Most password-based authentication schemes, such as Kerberos and Challenge-Handshake Authentication Protocol (CHAP), use relatively weak authentication in favor of greater user convenience and are susceptible to off-line dictionary attacks. In addition, both share a fundamental flaw because the user's password is exposed. If a user with multiple passwords uses the wrong one when logging onto a site, or if a user accidentally attempts to login to the wrong server, the password is potentially revealed.

In any case, these schemes use the password as the key. Small keys or keys with a small amount of randomness ("low entropy") are just inadequate for common encryption schemes, which is why minimum safe key sizes have continued to grow. But the flaw in the thinking was that strong password authentication required strong passwords. In fact, by obtaining strong authentication with short passwords, we have a system where users are more prone to correctly memorize their password and less prone to write it down and/or lose it.

SPEKE uses a modification of standard Diffie-Hellman public-key cryptography, where the secret password is used to form the base for the key exchange rather than the base be given by a fixed value. The steps below show the general SPEKE algorithm, and are similar to a normal Diffie-Hellman exchange:

In this scenario, Alice and Bob want to mutually prove that they both know the password, S. They each select a random number, R_A and R_B, from which they derive Q_A and Q_B, respectively (all exponentiation is performed modulo p, where p is a large prime number and (p-1)/2 is also prime). By exchanging these two values, Alice and Bob can independently derive K (which is S^4R_AR_B). By then exchanging the hashes of K (e.g., applying MD5 or SHA-1), Alice and Bob now have a mutually authenticated session key. And the best part of this, mathematically, is that a small S can generate a very large K.

Acknowledgements: I would like to thank Jonathan Chinitz (Vasco), David Jablon (Integrity Sciences), and Chris Voice (Entrust) for their time and input as I was researching and writing this article.

About the Author: Gary C. Kessler is a senior network security analyst at SymQuest Group (http://www.symquest.com), a network integration consulting company in South Burlington, VT. His e-mail addresses is kumquat@sover.net.