INET Conferences


Conferences


INET


NDSS

Other Conferences


[INET'98] [ Up ][Prev][Next]

Smart Access: Strong Authentication on the Web

Ton VERSCHUREN <ton.verschuren@surfnet.nl>
SURFnet
Netherlands

Abstract

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.

Contents

Initializing...

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.

Let's look at the smartcard

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:

  • Knowledge (of a secret, say)
  • Possession (of something physical)

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").

Implicit Dynamically Secured Application Protocols (IDSAP)

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!

K.I.S.S.

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.

The model is ISI

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

  • Various smartcards (not only the SCK);
  • Various cardreaders;
  • The most popular Web browsers;
  • No dependence on the type of Web server; and
  • Various platforms and operating systems.

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.


Figure 1. The ISI model

The steps in the dataflow are as follows:

  1. First, the client uses the browser to select and load the proper start page, which contains general information. On this page the client first selects a type of card (e.g., SCK 96/97) and then a button to request access to the protected data. This button selects the first CGI script on the server.
  2. Next, this script starts an (optional) procedure to set up a SSL connection. When the SSL connection has been set up, the appropriate Java applet will be selected and loaded from the server into the browser on the client side. The applet will be stored in the "dynamic part" of the browser.
  3. The applet will automatically start running. It first gets a random number from the server. This number is needed for the authentication.
  4. When the applet has received this random number, it will give some commands to the Java Chipcard API. The applet will check and initialize the connection with the smartcard by activating the Java Chipcard API. There are several things the applet will do. The applet carries all the information about the command it has sent to the smartcard. It also carries functions to handle the information that will come from the server to carry out the ISI protocol. The random number is sent to the smartcard, and the data (with MAC) are sent to the applet by the smartcard.
  5. When all the commands are executed, the applet will construct a URL and tell the browser to load this URL. The server will get the request and send this URL to the browser. But before this URL will be sent, the server checks if the parameters, which were sent together with the URL, are correct. For verifying the MAC, a cryptographic process is started.
  6. If the key on the server is the same one as the key on the card, and if the data and/or the MAC is not changed during the transfer, the calculated MAC and the received MAC are the same. This means that the authentication is successful, so that the cardholder gets access to the requested data.

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.

What does it take to be smart?

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.

The smartcard
Any smartcard that is able to accept random numbers and calculate MACs over fields (i.e., handles IDSAPs) can be used. In practice we use two different smartcards: the SCK '96/97 and the SCK '97/98. Depending on the architecture of the smartcard, it may have to undergo an initialization process prior to the use of the ISI technology. This step may be necessary to put the required information into certain fields on the card with the desired access functions. This initialization may well be carried out over the Internet.
What data is being read from the smartcard? Of course, this may differ for each application, but all current applications read the card number, the identifying number of the educational institute, and the student number. Each of these numbers may act as handles in the access database on the Web server. With these numbers, access may be granted based on a group characteristic (such as the university of the student) or an individual characteristic (such as the student number). The application can thus be tailored to serve data for a specific group or for an individual.
The cardreader
Support for yet another cardreader means adding a new DLL to the locally installed part of the ISI software. Currently, the homemade Dr.Chip, the IBM 5948, and the range of Towitoko readers, like ChipDrive (internal and external), Kartenzwerg, and Smarty (in the form of a floppy disk that goes in the diskette station), are options. In real life, problems were sometimes encountered with PCs with a modem and a mouse and no more free serial ports. Also, problems with interrupts have occurred. These problems seem to be common on Windows platforms with many devices installed.
The platform
Although the goal was to be platform independent, practice turns out to be more complicated. There are hardly any affordable cardreaders for Apple or Unix platforms and hence these operating systems are not supported in the ISI client software. That means we only support Windows 3.x, 95, and (soon) NT.
The browser
Browser support is totally determined by the Java implementation of the browser. First, only Netscape Navigator 3.01 (with JDK 1.0.x) was supported. Although MS Internet Explorer 3.x used the same Java version, their implementation was incompatible. With the availability of JDK 1.1.x in Communicator 4.x and Explorer 4.x, both browsers are supported.
The server
Any Web server will do. We use Netscape and Apache for the different applications. On one server, the access database is an Oracle 7 database. To connect the database to the Web server we use Oracle Web Agent. The communication from the Java applet to the Web server is handled by cgi scripts in perl. The random number generator is written in C. The DES key used to verify on the server the MAC sent by the smartcard can be stored in software or in hardware (e.g., an IBM Transaction Security System Card).
The client-server communication
As an option, the path between browser and server may be encrypted using Secure Sockets Layers (SSL). Also as an option, the server may wish to set a cookie. The advantage of this approach is that after the initial authentication, the client can send a cookie instead of having to redo the authentication process for every consecutive Web page. This means a trade-off between security and ease of use, however.

And this is what it looks like...

This section describes the applications that have been built using the ISI technology. The current applications include

The smart server
The downloading of commercial software for which a campus license has been concluded. The access is based on the university the student belongs to. See figure 2 for a screen dump of the application. After the provision of the CHV, a window with two frames appears: The top frame lists the organization the student belongs to and the left frame gives a list of licenses. Clicking one of those makes a third frame appear with the products that belong to the particular license. Selecting a product shows a fourth frame with the file(s) to download. Large programs have been split into 15 MB chunks. An extensive description can be found in Ref. 7.
A grades database
Access to the results of examinations on an individual basis. It replaces the usual paper lists on the walls.
Electronic registration for courses
Individual registration for computer courses provided by a computing center has been developed. The smartcard authentication module replaces an "authentication" process that was based on an e-mail loop. In fact, this application does not perform an authentication step, but only an identification process. Unlike the other applications, this one is not running on the server that has a copy of the DES key used on the card. Therefore, it cannot verify the MAC it receives from the smartcard. The application just accepts the data "as is," thereby reducing the authentication to identification only.
Student grants system
In the Netherlands every student receives a student grant and optionally a loan, issued by the IBG organization. The student may now change his address and/or height of his loan online using his smartcard. This application replaces a rather cumbersome process of filling out forms and long delays before the changes have been processed. A screen dump is shown in figure 3.


Figure 2. The smart server: download commercial software


Figure 3. Viewing and modifying of student grant/loan data.

Bug or feature: what about the future?

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.

Thanks!

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.

References

  1. The DESIRE Project, 1996-1997, http://www.desire.org/
  2. IBM Boeblingen Smartcard Solutions, IBM Multi-Function Card, Functional Description Supporting Card Version 1.0, First Edition July 1993.
  3. The Chipper Card, http://www.chipper.com/
  4. Piet Maclaine Pont, Chipcards & Internet, 1997, http://www.iscit.surfnet.nl/team/George/enib.htm
  5. Arjan Koetsier, The ISI-protocol v3.0, 1997, http://www.iscit.surfnet.nl/team/Arjan/homepage/doc7.htm
  6. Arnout Hannink and Michael Lipman, ISI-3, Towards an open chipcard authentication protocol, 1997, http://www.iscit.surfnet.nl/team/George/isi3ref1.htm
  7. Bas Cordewener et al., The Smart Server Download Service, DESIRE Technical Report D10.2, http://www.surfnet.nl/surfnet/projects/home-office/deliver/d10-2.html

[INET'98] [ Up ][Prev][Next]