Abstract
Keywords: smartcard, security, educational licenses
SURFdiensten, a subsidiary of the SURF Foundation, is an intermediair between ICT-providers and Dutch (higher) education and research providing them with ICT-licenses covering a wide range of license levels like the single-copy license and the site-license. Authentication based on smartcard technology is used for access control and tailor made information. When a client requests the application server for information, the application server asks a third party, the authentication server, for authentication of the client. If the client has a valid smartcard for this authentication protocol, access is permitted to the application server which controls the application on data stored in the chip. SURFnet, also a subsidiary of the SURF Foundation, is now developing the authentication service.
Introduction
SURFdiensten is a subsidiary company of the SURF Foundation (1), and deals with concluding license agreements with suppliers of software, information services, courseware, hardware, lifeware and other ICT-services. As it presents for this purpose the entire sector (higher) education and research in the Netherlands, it can obtain exceptionally favorable terms. Organizations can then individually choose from the assortment that SURFdiensten has put together. In this way it is possible, for example, for all staff members and students of an educational establishment to obtain user rights for popular software at minimal prices. Partners involved in carrying out the license program are SLBdiensten covering the secondary educational segment and APS IT-diensten for the primary segment.
Slice (3), SURFdiensten Licences Information by Chipcard-available Extranet, is part of the Home Office (2) project and was funded by SURFnet in the SURF-ACE program. In march 1999, 400 cards were unrolled to participating universities and schools to open up tailor made information on their contracts. The cards are based on the regular Dutch student smartcard, the IBM Multi Function Card (4). A pilot was defined to develop an authentication service using this type of smartcard.
Smartcard
The Dutch student smartcard called ‘Studentchipkaart’ (SCK) conforms with the ISO 7816-1/4 and the ETSI TE9 standards specified by the telecommunications industry. The operating system on the chip is MFC 3.5 with an architecture similar to the architecture of an MS-DOS diskette. This multi-function card is equipped with over 20 security levels, which enables the use of different independent applications. The encryption used is full DES where the keys are shared by the external application and the card. A Card Holder Verification (CHV), a four digit number similar to a Personal Identification Number (PIN) opens up information for external applications. Current functions on the card besides the student card are library pass, (re-chargeable) telephone card, public transportation pass, payments for copying and canteen products and identification for communication with the central organization issuing students grants.
The way the card is used for authentication is done by Implicit Dynamically Secured Application Protocols (IDSAP) (5). If a value of a certain field of the card has to be read in an implicit save way, the field should only be read after CHV control. This can be done in a few steps:
The application, which calls for the data, sends a random number together with the read request. First the card then asks the user for the CHV to ensure the card and the user belongs together. Next a stamp, a Message Authentication Check (MAC) is calculated based on the random number and a key on the field which should be read. The application receives the MAC and the field value, recalculates the stamp and compares with the received values. The data can be trusted if the two MAC’s are identical. The keys are not sent across the net and all cryptographic actions are done inside the card and inside the web server!
ISI
The ISI protocol(6) based on the described IDSAP is developed
for the Home Office project by IBM and SURFnet. This protocol consists
of a Java applet on the client and a Java applet on the server combined
with CGI scripts. Figure 1 shows the equipment necessary for the ISI-protocol.
| Processor | Platform | Additional hardware | |
| Client | Intel | Win95, WIN98 | Reader:
Towitoko, Dr. Chip, IBM 5948 |
| Server | Intel | NT | Crypto card |
The client applet is available for Netscape 4.x and Microsoft Internet Explorer 4.x. The server applet runs on NT 4 servicepack 4 with the Microsoft Internet Server. But the Netscape Fasttrack server works fine too. The server is also provided with Secure Sockets Layer (SSL). The key is the restriction in using the ISI-protocol because only cards equipped with the same key can be used. In the Netherlands each institution has its own key, therefore the server can handle only ‘own’ smartcards.
Three Party Authentication (TPA)
In the case of an authentication server this server can be provided
with a general key in stead of a particular, private key. If the application
server can ask an authentication server if the client can be trusted as
a secure client, the communication will be handled by three party’s. The
first one is the client asking for some restricted information. The second
is the secured application server (SAS) providing the restricted information.
The third party is the authentication server (AS) providing authentication
information on the client to the SAS.
| Client | PC equipped with browser and reader |
| SAS | Server with secured application and one authentication key to authenticate itself to the AS |
| AS | Server, guarding own authentication key, the key of the SAS and the keys of the smartcards |
In Figure 2 the key distribution is shown on the three parties.
The client needs to start a local installed TPA daemon before running a browser. Asking for restricted information starts with providing the CHV in a TPA session sending this information to the SAS. The SAS sends this information with its own key to the AS for authentication control based on additional information read from the smartcard. The AS first checks the key information of the smartcard followed by checking the card information on a ‘black list’, a list of invalid or unreliable cards. If all checks return ok, the AS sends this signal back to the SAS together with the additional card information. If or the MAC control or the black list control returns not ok the TPA session is aborted. If the SAS receives the authenticated data back another black list control is done there. Again the TPA session will be aborted when the card information is related with a card listed as invalid or unreliable. If both the AS and the SAS return ok, the application is started.
Environment:
| OS | TPA installation | Additional hardware | |
| Client PC | PC
WIN95, WIN98 |
Java Runtime Environment 1.1.6, TPA client software | Towitoko,
Dr. Chip
Specific reader software |
| SAS | Pentium
II
Win NT4, Service pack 4 |
Java Runtime
Environment 1.1.6, TPA SAS software,
HTTP daemon |
Crypto adapter
IBM 4758 PCI Cryptographic Coprocessor |
| AS | IBM RS/6000
43P-240
AIX 4.3.1 |
Java Runtime Environment 1.1.6, TPA AS software | Crypto adapter
IBM 4758 PCI Cryptographic Coprocessor |
The entry to the SURFdiensten database is restricted by the value of the field that holds the card number and the one that holds the BRIN-code, an official code for an educational institution in the Netherlands. The 400 so-called relation cards are checked by the ISI-protocol based on the specific, private SURFdiensten key. To handle requests from clients equipped with non-relation cards but regular student cards the TPA-protocol is necessary to authenticate the client. Extending these regular cards with a purse function each request for restricted information can be followed by a request for payment. If the payment is successful the requested information is sent to the client.
The information is stored in an Oracle database. Based on the card information the application is started. Contract information is shown to institutions on their own participations. Via CGI-BIN scripts the card parameters are passed to an Oracle agent running a specific procedure providing the requested information.
Available topics:
During 1999 the Slice server (SAS) will be connected to the Authentication
Server. The information stored in the SURFdiensten database will become
‘available’ to cardholders using other student cards provided with a foreign
key. A pilot will be run with the payment function enabled on the card.
Ackowledgements
Connecting all these components caused a lot of struggle and needed
a lot of invention. Thanks to Ali Odaci, Arnout Hannink, Marco Buys (all
IBM), Rita Groothuizen and Frans Velthuis(RUG), Ester van Heuven and Audrey
Visscher (SURFdiensten(7)), they all struggled and invented
to get the solution.
References:
Jan Bakker, Ineke Scholten
SURFdiensten
Muntkade 8
3531 AK Utrecht
The Netherlands
Email:Scholten@surfdiensten.nl