- Email: [email protected]
Smart access: strong authentication on the web
Computer Networks and ISDN Systems 30 (1998) 1511–1519
Smart access: strong authentication on the Web Ton Verschuren Ł SURFnet bv, P.O. Box 19035, 3501 DA Utrecht, Netherlands
Abstract This paper describes a field project that extends the ‘Studentenchipkaart’ for client/server authentication on the web. No separate registration process on the Internet is used besides the delivery of the smartcard itself. The encryption and authentication are based on symmetric keys that are shared between smartcards and applications. A three-party authentication service, where a trusted third party takes care of the authentication, is currently under development. 1998 Elsevier Science B.V. All rights reserved.
Keywords: Smartcard; Authentication; Security; Electronic commerce
1. Initialising Today’s Internet is moving away from its original academic credo: free access to everything for all. Popular mechanisms to protect a (part of a) web site from public access are filters on IP address or username/ passwords 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 is 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 is available for Ł Tel.: C31 302 305305; Fax: C31 302 305329; E-mail: Ton.Ver [email protected]
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, the DESIRE project [1] developed and implemented a protocol, whereby a user with a smartcard, a smartcard reader, a PC and a web browser can
0169-7552/98/$ – see front matter 1998 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 9 - 7 5 5 2 ( 9 8 ) 0 0 2 0 1 - 3
1512
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
authenticate himself to a web server, serving sensitive (i.e., non-public) data. 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 is already on the card when it reaches the student. The applications use a so-called two-party authentication mechanism, where 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 that want to authenticate their users before they access their data.
2. Let us 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 [2]), which is conform 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 MSDOS 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 transporta-
tion pass, library pass, (chargeable) telephone card, identification for communication with the organisation that issues the student grants, and payments for copiers, vending machines and in the canteen. For the latter a number of so called Closed Electronic Purses (CEP) exists 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 [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, on-line payments with this Chipper purse, called CyberChipper, are under development. What makes this smartcard attractive in an on-line process to provide selective access to information, then? 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 on-line identification (‘just tell me who you are’) and authentication (‘prove to me who you are’). 2.1. Implicit dynamically secured application protocols (IDSAP) How can we maximally use the security functions of the smartcard? Let us introduce the concept of Implicit Dynamically Secured Application Proto-
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
cols (IDSAP [4]). Using the access conditions (e.g. always, never, after CHV, etc.) defined for every operation (e.g. read, write, delete, compare, increase, decrease,: : :) on every field in the smartcard, we want the smartcard to have a number of complete operations built in, in which all what 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 involves generally 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 card reader or PC will be of no effect. So, how does this work in practise? 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 (used for ‘salting’ the encryption) 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 are 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. Both share the same secret key. No keys cross the Internet!
3. K.I.S.S. The web browser is the window to the on-line world. Its ease-of-use has boosted the exponential
1513
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 give only 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 s/he claims to be? That is of course where the smartcard comes in, and the IBM Smartcard Identification (ISI) protocol.
4. 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 card readers; ž the most popular web browsers; ž no dependence on the type of web server; ž 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 version of Netscape Navigator up to v3.x and Microsoft Internet Explorer up to v3.x does 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 card reader drivers. The driver represents the actual RS232 serial communication port of the computer that transmits and receives data to the smartcard reader. This driver (written in CCC) will be kept as small as possible, because of its platform dependence. The communication between the 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 an-
1514
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
Fig. 1. The ISI model.
other smartcard reader means a simple addition to the local classes. Support for a different smartcard means serving a modified applet specific for that card. Fig. 1 shows a schematic view of the ISI model. The steps in the data flow 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 97/98) 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.
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
(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 initialise 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 are 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 Refs. [5,6] for more information about the ISI protocol and architecture.
5. 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 summarised. The Smartcard Any smartcard that is able to accept random numbers and calculate MACs over fields (i.e. handles
1515
IDSAPs) can be used. In practise 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 initialisation 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 initialisation 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 number access may be granted based on a group characteristic: the university of the student, or based on an individual characteristic, e.g. the student number. The application can thus be tailored to serve data for a specific group or for an individual! The Card Reader Support for yet another card reader 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). In real life sometimes problems were 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, practise turns out to be more complicated. There are hardly any affordable card readers 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
1516
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
Fig. 2. The Smart Server: download commercial software.
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 the security and ease-of-use, however.
6. And this is how 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 Fig. 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 organisation the student belongs to, and the left frame gives a list of licenses. Clicking of one of those a third frame appears with the products that belong to the particular license. Selecting a product shows a fourth frame with the file(s) to download. Large programmes have been split into 15 MB chunks. An extensive description of this application and its underlying technology can be found in [7]. In the first month the service was available to some 20 students in a well-connected (ethernet)
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
1517
Fig. 3. Viewing and modifying of student grant/loan data.
student dormitory 1.3 GB was downloaded by 10 different users. 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 centre has been developed. The smartcard authentication module replaces an ‘authentication’ process that was based on an email 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 organisation. The student may now change his address and/or height of his loan on-line 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 Fig. 3.
7. Bug or feature: what about the future? A careful reader will have learnt from the description of the applications that there is 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 organisation, which makes the step towards on-line payments using the purse on the smartcard a small one. On the other hand, the
1518
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
TTP may be part of the card management organisation’s services, which allows for on-line 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. Complicating factor for the development of a TTP is the fast changing environment, both technically (e.g. for public key schemes like PGP or S/MIME, and the rapid smartcard developments), as well as 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 Student 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 56 to 112 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 Research and Education users is an item for future research. Despite the aforementioned ‘features’, the ISI architecture and current implementations allows for one of the most secure ways to protect information from the eyes of unauthorised 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 is available now, 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!
Acknowledgements 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 organisations participate in the Home Office project [8] to make it successful. Special thanks to Rita Groothuizen and Frans Veltkamp (computer centre 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] P. Maclaine Pont, Chipcards and Internet, 1997, http://www. iscit.surfnet.nl/team/George/enib.htm. [5] A. Koetsier, The ISI-protocol v3.0, 1997, http://www.iscit.su rfnet.nl/team/Arjan/homepage/doc7.htm. [6] A. Hannink, M. Lipman, ISI-3, Towards an open chipcard authentication protocol, 1997, http://www.iscit.surfnet.nl/tea m/George/isi3ref1.htm. [7] B. Cordewener et al., The Smart Server Download Service, DESIRE Technical Report D10.2, 1997, http://www.surfnet. nl/surfnet/projects/home-office/deliver/d10-2.html. [8] Home Office Project, 1996–1998, http://www.surfnet.nl/proj ecten/surf-ace/homeoffice/.
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519 Ton Verschuren is working as manager of Communication Services at SURFnet bv since 1991. SURFnet runs the Dutch Academic and Research computer network. In his current function, he is responsible for the communication and information services (web, news, e-mail, directory services) that SURFnet provides to its customers, and for development projects in the same areas. In the past, Ton has been working on projects in areas such as data communication over cable TV networks, X.400, X.500, and information services (ftp, gopher, archie, web). Current development projects involve web caching, application of smart card technology on the web, and several other activities aimed at enhancing access to information on the net. Ton received his Ph.D. in High Energy Physics at Nijmegen University, The Netherlands in 1991.
1519
Smart access: strong authentication on the Web Ton Verschuren Ł SURFnet bv, P.O. Box 19035, 3501 DA Utrecht, Netherlands
Abstract This paper describes a field project that extends the ‘Studentenchipkaart’ for client/server authentication on the web. No separate registration process on the Internet is used besides the delivery of the smartcard itself. The encryption and authentication are based on symmetric keys that are shared between smartcards and applications. A three-party authentication service, where a trusted third party takes care of the authentication, is currently under development. 1998 Elsevier Science B.V. All rights reserved.
Keywords: Smartcard; Authentication; Security; Electronic commerce
1. Initialising Today’s Internet is moving away from its original academic credo: free access to everything for all. Popular mechanisms to protect a (part of a) web site from public access are filters on IP address or username/ passwords 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 is 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 is available for Ł Tel.: C31 302 305305; Fax: C31 302 305329; E-mail: Ton.Ver [email protected]
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, the DESIRE project [1] developed and implemented a protocol, whereby a user with a smartcard, a smartcard reader, a PC and a web browser can
0169-7552/98/$ – see front matter 1998 Elsevier Science B.V. All rights reserved. PII: S 0 1 6 9 - 7 5 5 2 ( 9 8 ) 0 0 2 0 1 - 3
1512
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
authenticate himself to a web server, serving sensitive (i.e., non-public) data. 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 is already on the card when it reaches the student. The applications use a so-called two-party authentication mechanism, where 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 that want to authenticate their users before they access their data.
2. Let us 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 [2]), which is conform 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 MSDOS 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 transporta-
tion pass, library pass, (chargeable) telephone card, identification for communication with the organisation that issues the student grants, and payments for copiers, vending machines and in the canteen. For the latter a number of so called Closed Electronic Purses (CEP) exists 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 [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, on-line payments with this Chipper purse, called CyberChipper, are under development. What makes this smartcard attractive in an on-line process to provide selective access to information, then? 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 on-line identification (‘just tell me who you are’) and authentication (‘prove to me who you are’). 2.1. Implicit dynamically secured application protocols (IDSAP) How can we maximally use the security functions of the smartcard? Let us introduce the concept of Implicit Dynamically Secured Application Proto-
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
cols (IDSAP [4]). Using the access conditions (e.g. always, never, after CHV, etc.) defined for every operation (e.g. read, write, delete, compare, increase, decrease,: : :) on every field in the smartcard, we want the smartcard to have a number of complete operations built in, in which all what 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 involves generally 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 card reader or PC will be of no effect. So, how does this work in practise? 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 (used for ‘salting’ the encryption) 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 are 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. Both share the same secret key. No keys cross the Internet!
3. K.I.S.S. The web browser is the window to the on-line world. Its ease-of-use has boosted the exponential
1513
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 give only 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 s/he claims to be? That is of course where the smartcard comes in, and the IBM Smartcard Identification (ISI) protocol.
4. 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 card readers; ž the most popular web browsers; ž no dependence on the type of web server; ž 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 version of Netscape Navigator up to v3.x and Microsoft Internet Explorer up to v3.x does 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 card reader drivers. The driver represents the actual RS232 serial communication port of the computer that transmits and receives data to the smartcard reader. This driver (written in CCC) will be kept as small as possible, because of its platform dependence. The communication between the 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 an-
1514
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
Fig. 1. The ISI model.
other smartcard reader means a simple addition to the local classes. Support for a different smartcard means serving a modified applet specific for that card. Fig. 1 shows a schematic view of the ISI model. The steps in the data flow 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 97/98) 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.
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
(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 initialise 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 are 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 Refs. [5,6] for more information about the ISI protocol and architecture.
5. 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 summarised. The Smartcard Any smartcard that is able to accept random numbers and calculate MACs over fields (i.e. handles
1515
IDSAPs) can be used. In practise 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 initialisation 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 initialisation 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 number access may be granted based on a group characteristic: the university of the student, or based on an individual characteristic, e.g. the student number. The application can thus be tailored to serve data for a specific group or for an individual! The Card Reader Support for yet another card reader 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). In real life sometimes problems were 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, practise turns out to be more complicated. There are hardly any affordable card readers 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
1516
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
Fig. 2. The Smart Server: download commercial software.
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 the security and ease-of-use, however.
6. And this is how 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 Fig. 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 organisation the student belongs to, and the left frame gives a list of licenses. Clicking of one of those a third frame appears with the products that belong to the particular license. Selecting a product shows a fourth frame with the file(s) to download. Large programmes have been split into 15 MB chunks. An extensive description of this application and its underlying technology can be found in [7]. In the first month the service was available to some 20 students in a well-connected (ethernet)
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
1517
Fig. 3. Viewing and modifying of student grant/loan data.
student dormitory 1.3 GB was downloaded by 10 different users. 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 centre has been developed. The smartcard authentication module replaces an ‘authentication’ process that was based on an email 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 organisation. The student may now change his address and/or height of his loan on-line 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 Fig. 3.
7. Bug or feature: what about the future? A careful reader will have learnt from the description of the applications that there is 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 organisation, which makes the step towards on-line payments using the purse on the smartcard a small one. On the other hand, the
1518
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519
TTP may be part of the card management organisation’s services, which allows for on-line 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. Complicating factor for the development of a TTP is the fast changing environment, both technically (e.g. for public key schemes like PGP or S/MIME, and the rapid smartcard developments), as well as 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 Student 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 56 to 112 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 Research and Education users is an item for future research. Despite the aforementioned ‘features’, the ISI architecture and current implementations allows for one of the most secure ways to protect information from the eyes of unauthorised 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 is available now, 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!
Acknowledgements 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 organisations participate in the Home Office project [8] to make it successful. Special thanks to Rita Groothuizen and Frans Veltkamp (computer centre 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] P. Maclaine Pont, Chipcards and Internet, 1997, http://www. iscit.surfnet.nl/team/George/enib.htm. [5] A. Koetsier, The ISI-protocol v3.0, 1997, http://www.iscit.su rfnet.nl/team/Arjan/homepage/doc7.htm. [6] A. Hannink, M. Lipman, ISI-3, Towards an open chipcard authentication protocol, 1997, http://www.iscit.surfnet.nl/tea m/George/isi3ref1.htm. [7] B. Cordewener et al., The Smart Server Download Service, DESIRE Technical Report D10.2, 1997, http://www.surfnet. nl/surfnet/projects/home-office/deliver/d10-2.html. [8] Home Office Project, 1996–1998, http://www.surfnet.nl/proj ecten/surf-ace/homeoffice/.
T. Verschuren / Computer Networks and ISDN Systems 30 (1998) 1511–1519 Ton Verschuren is working as manager of Communication Services at SURFnet bv since 1991. SURFnet runs the Dutch Academic and Research computer network. In his current function, he is responsible for the communication and information services (web, news, e-mail, directory services) that SURFnet provides to its customers, and for development projects in the same areas. In the past, Ton has been working on projects in areas such as data communication over cable TV networks, X.400, X.500, and information services (ftp, gopher, archie, web). Current development projects involve web caching, application of smart card technology on the web, and several other activities aimed at enhancing access to information on the net. Ton received his Ph.D. in High Energy Physics at Nijmegen University, The Netherlands in 1991.
1519