Smart Access: Strong Authentication on the Web
Ton VERSCHUREN <email@example.com>
Today's Internet is moving away from its original academic credo: free access to everything for all. Popular mechanisms to protect a (or part of a) Web site from public access are filters on the IP address or username/password combinations. The first prevents the identification of a single individual from any PC on the Internet. The latter suffers from sniffing (the passwords travel unencrypted) and from publication; lists with usernames and passwords are popular. In short, there's a strong need for better identification (tell me who you are) of individuals and for better authentication (prove to me who you are). One solution to this problem is the use of public key cryptography, whereby both a Web server and a client possess a private/public key pair that is used to create an encrypted communication path. An example is Netscape's Secure Sockets Layer (SSL). Although the technology has been available for quite some time now, the use of client certificates is minimal. Main reasons for this are the US crypto export regulations (export of 40-bits instead of 128-bits keys makes the communication vulnerable to attacks) and the fact that Certificate Authorities (the issuers of the certificates) are not yet deployed on a large scale and do not interwork well. Therefore, another approach was chosen. In the Netherlands more and more college and university passes are being implemented on a multifunctional smartcard, the Student Smart Card, "Studentenchipkaart" (SCK). Multifunctionality here means the combination of several logical functions, both physical (the print on the card) and electronic (the data on the card): visual pass for identification, access, library; electronic purse, electronic identification, telephone card, etc. Could this smartcard also be used as a means in a strong authentication process for online services? The answer is yes. With the help of a team of students under supervision of IBM staff, a protocol was developed and implemented, whereby a user with a smartcard, a smartcard reader, a PC, and a Web browser can authenticate himself to a Web server serving sensitive (i.e., nonpublic) data. The main advantage of this approach over the one based on public key cryptography is the fact that no separate registration process is necessary to obtain, say, a key. All necessary data are already on the card when it reaches the student. The applications above use a so-called two-party authentication mechanism, whereby the client talks directly to the server for its authentication. Consequently, every server needs a copy of the secret (triple DES) key on the smartcard. Obviously, this approach will not scale in a secure way. Therefore, a three-party authentication service is currently under development. SURFnet will act as the Trusted Third Party (TTP) for its customers who want to authenticate their users before they access their data.
One of the main obstacles to using the World Wide Web to publish confidential information, or information that has a commercial value, is the weakness of the authentication mechanisms that can be employed: restrictions based on network address or username/password combinations that are transmitted in the clear and can easily be intercepted. The DESIRE project (Ref. 1) is investigating alternatives, initially taking advantage of the plan to provide smartcards to all students in the Netherlands (serving not only as student identification, but with electronic purse functionality which allows it to be used as a phone card and for other payment applications). The project has produced a system which gives students and researchers access to secured information, using their smartcards as identification.
Together with IBM Smartcard Solutions, we have built an architecture and a protocol implementation. This paper explains what smartcard we use, why we wanted to create the system, the underlying principles, some of the problems encountered, and what will be the next phase in our development.
In the Netherlands, a dedicated smartcard for educational institutes, especially higher education and vocational institutes, is available. This smartcard is called "Studentenchipkaart" (student smartcard), SCK. The smartcard used for the SCK is the IBM Multi-Function Card (MFC, Ref. 2), which conforms with the ETSI TE9 and ISO 7816-1/4 standards -- standards specified by the telecommunications industry. Many telephone cards, for example, adhere to the same standard. The chip has its own operating system -- in our case, MFC 3.5. The smartcard's data storage facilities have an architecture equivalent to an MS-DOS diskette. The card has over 20 security levels, each with its own (set of) corresponding keys. This enables the use of different applications independent of one another -- hence the name multi-function card. Different keys can be issued to different vendors which makes the card also a multi-vendor card. The keys are being used to ensure privacy, data integrity, encryption of the communication, and authentication. The encryption used is full DES, which means symmetric encryption: The keys are shared by the card and the external application. Certain fields on the card may only be read by external applications after the user has given his consent by providing his Card Holder Verification (CHV) code (a sort of PIN code), a four-digit code. Current functions on the SCK card are student card, public transportation pass, library pass, (chargeable) telephone card, identification for communication with the organization that issues the student grants, and payments for copiers, vending machines, and products from the canteen. For the latter, a number of so-called Closed Electronic Purses (CEP) exist on the card. These CEPs simply contain a counter that can be decreased and increased. The term "closed" refers to the fact that the purse is under full control of a single application (or vendor), i.e., in a closed environment. Next to closed purses, an open purse is implemented on the card: the Chipper (Ref. 3) purse. This purse allows for use of the card in all public telephone cells in the Netherlands and it will be accepted by most retail stores in the course of this year as an alternative for cash. Furthermore, online payments with this Chipper purse, called CyberChipper, are under development.
What makes this smartcard attractive in an online process to provide selective access to information? In general, a sound way to identify or authenticate someone is based on one or both of the following:
For example, the most common scheme used on the Web for restricting access to certain information is based on the basic authentication scheme, consisting of a username and password (the secret) transmitted in the clear over the Internet. A common scheme based on possession is, for example, the token-based access through firewalls using a SecurId card (a physical device).
The Student Smartcard combines both the knowledge (the CHV or PIN code) and the possession (the card itself). As this card has many functions and may contain real money, the temptation to lend it out to a colleague or friend is minimal, unlike the common username/password combinations. This makes the card very attractive for online identification ("just tell me who you are") and authentication ("prove to me who you are").
How can we maximally use the security functions of the smartcard? Let's introduce the concept of Implicit Dynamically Secured Application Protocols (IDSAP, Ref. 4). Using the access conditions (e.g., always, never, after CHV, etc.) defined for every operation (e.g., read, write, delete, compare, increase, decrease, etc.) on every field in the smartcard, we want the smartcard to have a number of complete operations built in, in which all that is needed for a complete, safe, and interruption-insensible processing by the card is performed by the card itself without any dependence on the (unsafe) external world. The operation generally involves more than one command. These commands are connected to each other and together form a complete protocol. IDSAPs make it possible to make smartcards which can be put in different kinds of equipment without real security risks. Indeed, there is total independence of the equipment. A promiscuous cardreader or PC will be of no effect.
So, how does this work in practice? Suppose we want to read the value of a certain field on the card (e.g., card number) in an implicitly safe way. This field has access conditions such that it can only be read after the user has entered his CHV. The IDSAP that we now want is the following: The external application that needs the data sends a random number with a request to read the field. The card first asks the user to provide the CHV, thus ensuring the card and user belong to each other (authentication of the user to the card). Next, the random number is used to calculate a stamp over the field, based on a key that is associated with this field. This stamp is called a Message Authentication Code (MAC). The MAC together with the value of the field is then sent to the external application. This application then calculates the stamp itself, based on the random number and the key (remember, we're speaking DES here), and compares the result with what was received from the card. If the two MACs are identical, the value of the data (in our case, the card number) can be trusted. In short, all crypto is done inside the card and inside the Web server. No keys cross the Internet!
The Web browser is the window to the online world. Its ease-of-use has boosted the exponential growth of information on the Internet and on intranets. So, we want to hide all the cryptographic complexities of the previous section and keep the browser as the interface to the information protected by the smartcard: Just point and click! And what do we mean by "protect"? It means we only give access to a certain (part of a) Web server after we know for sure that the user issuing the request for access has the proper access rights, maintained in a database co-located on the Web server. And how do we know for sure that the user is who he or she claims to be? That's of course where the smartcard and the IBM Smartcard Identification (ISI) protocol come in.
As mentioned above, we want to use HTTP between the client (browser) and the (Web) server. Furthermore, we want a solution as generic as possible. It should support
The latter condition made us turn to Java; i.e., the Web browser downloads Java applets from the Web server. On the Web server itself, cgi scripts are used, which ensures daemon independence. It was not as easy as this, however. Due to security considerations, the Java versions of Netscape Navigator up to v3.x and Microsoft Internet Explorer up to v3.x do not allow for communication with the serial ports on the PC. The solution was found in installing Java local classes (Java Smartcard API) as a first and only step in the installation process on the user's PC. These local classes essentially contain the support for the cardreader drivers. The driver represents the actual RS232 serial communication port of the computer that transmits and receives data to/from the smartcard reader. This driver will be kept as small as possible because of its platform dependence. Because Java does not support serial communication ports, this can be implemented in C++. But every platform needs its own driver. The communication between these local classes and the server can now be handled by applets, served by the Web server: The local classes are called by the applet. Adding support for another smartcard reader means a simple addition to the local classes. Support for a different smartcard means serving a modified applet specific to that card.
Figure 1 shows a schematic view of the ISI model.
The steps in the dataflow are as follows:
As can be seen from this figure (step 2), the communication between browser and server may be encrypted using Secure Sockets Layer (SSL). This is not part of the ISI model, but an optional implementation detail. Refer to Ref. 5 and 6 for more information about the ISI protocol and architecture.
The previous sections described how the Student Smartcard functions, roughly how the crypto works, and how these fit into the ISI model. In this section, all ingredients and their roles will be summarized.
This section describes the applications that have been built using the ISI technology. The current applications include
A careful reader will have learned from the description of the applications that there's a problem with the current model: It is a two-party model. Such a model, with symmetric encryption, will not scale without the secret key being compromised. Indeed, since every information provider that wants to authenticate based on the same data fields on the smartcard will need a copy of the secret key that protects these fields, in the long run the key will no longer be a secret.
To overcome these problems, an entirely new architecture has been drafted based on three-party authentication. A Trusted Third Party (TTP) will authenticate clients on behalf of the information provider who runs a Web server. In this process, TTP and Web server may perform a mutual authentication process using either separate symmetric keys or asymmetric (e.g., RSA) keys. This model is of particular importance for electronic commerce. The TTP might be a bank-related organization, which makes the step towards online payments using the purse on the smartcard a small one. On the other hand, the TTP may be part of the card management organization's services, which allows for online updates of any field on the card. Alternatively, SURFnet could, in its role as National Research Network, authenticate its customers (students and staff) on behalf of information providers belonging to its constituency. The aim of the current project is to develop such an authentication service.
A complicating factor for the development of a TTP is the fast-changing environment, technically (e.g., for public key schemes like PGP or S/MIME and the rapid smartcard developments), policy-related (e.g., Certificate Authorities), and legally (governments are becoming increasingly interested in these kind of issues, boosted by the electronic commerce hype).
Another issue in the model is the use, or more particularly, the stability and uniformity, of Java. Support for several browsers has proven to be difficult due to differences in the Java implementations, even when the same version of JDK was used. From JDK 1.1.x, used in the v4.x versions of the Netscape and Microsoft browsers, the need for locally installed software has become obsolete. Now applets are allowed to use the serial port, provided they are signed by the developer. This allows for a stricter version control: The applet may check if there is a more recent version available and if so, install it on the PC. Whether Java is the way to go for the TTP implementation is an issue currently under investigation.
A legitimate question is where the DES-based smartcard fits into a world that seems to head for asymmetric encryption schemes. One of the justifications for the use of smartcards is that most people will possess one or more in the near future: Not only will students have a smartcard, but virtually everyone will get one now that bank cards are getting smart. Another reason to use smartcards is that due to the export restrictions of the USA, asymmetric crypto implementations suffer from the low-grade security caused by the rather short key length (40 bits in general or 56 in special cases). The triple DES keys used in the smartcard are 64 to 128 bits long. Therefore, it provides one of the highest-grade security solutions outside the USA.
The coupling of the TTP service to the Public Key Infrastructure (PKI) that is currently being developed for the Dutch R&E users is an item for future research.
Despite the aforementioned "features," the ISI architecture and current implementations allow for one of the most secure ways to protect information from the eyes of unauthorized people. The fact that all complex cryptographic details are hidden behind the familiar Web interface -- only a PIN code has to be provided in addition to the usual point-and-click -- makes this solution a very attractive one. In the short period that the technology has been available, it has already attracted the attention of banks, insurance companies, and publishers. Some implementations in these sectors have already started. No doubt, the availability of a Trusted Third Party implementation, expected this year, will boost the use of this smartcard-based authentication technology.
Part of this work is sponsored by the European Union in the Telematics Application Programme and by the SURF Foundation in the SURF-ACE Programme. Many organizations participate in the Home Office project to make it successful. Special thanks to Rita Groothuizen and Frans Veltkamp (computer center of Groningen University) and to Piet Maclaine Pont (IBM) and his ISCIT team for their contribution to the project.