Research activity in 1997
The Department of Computer Science has established an internal public key certification service, to allow users to exchange signed and encrypted mail using Netscape Communicator or Internet Explorer. An SSL secure WWW server has also been installed, and user authentication with internally certified client keys is also available. The services are to be proposed for the whole University after a testing phase in the first quarter of 1998.
Public key certification is the most critical aspect of communication privacy and authentication, especially when digital signatures are involved. Wrong associations of public keys to users can lead to serious and long-lasting damages. A certification authority (CA) is normally used to publish reliable user to public key correspondences, under the form of a public key certificate. Our CA distributes certificates under the X.509 standard, including user data such as name and affiliation, user public key, a serial number, and the CA’s digital signature. Certificates can then be exchanged by users without further communications with the CA, in order to determine public key ownership when exchanging encrypted and/or signed data. This is useful for electronic mail, for access to secure WWW servers, and for the offline verification of digital signatures.
The department CA offers a service distributing X.509 (version 3) certificates that may be used in popular mail and browsing tools such as Netscape Communicator and Microsoft’s Internet Explorer. The used public key cryptosystem is based on the RSA asymmetric encryption with the MD5 message digest, as available in the international SSLeay implementation (version 0.8.1). The implementation is not subject to US export restrictions and is compatible with standard mail tools and browsers. For Netscape Communicator, certificates must then be combined with the user’s private key in the PKCS12 format, so that they may be loaded in the browser. This is also available from the SSLeay package.
Two distinct CA services are available.
The first is to be used only as a demo, and relies on the user’s browser to generate 512 bit RSA keys. The public key is then sent to the CA, a few automatic checks are performed, a certificate is generated and made available to the user via HTTP. The user will then request the certificate from the relevant CA address. The browser will automatically install the certificate, combined with the private key, that was kept on the client. This first service is weak from a security perspective, especially due to the 512 bit keys, but also because the browser is used for key generation, and because key ownership tests are deliberately simple and automatic. However, the service may be useful for training our users in performing private and authenticated communications, and for making them at ease with digital signatures.
The second certification service we offer is stronger, and requires face-to-face or voice/telephone identity verification. A Windows 95 package has been implemented and made available with its source code to our users. The Sun Solaris implementation is under way. The package includes the needed SSLeay functions, and runs on the client host. It allows the user to: (1) generate a 1024 bit asymmetric key pair (2) view and store the key fingerprint (3) prepare a certificate request and send it to our CA address (4) receive the certificate when it becomes available, combine it with the local public key and load it in the browser. On the CA side, the certificate request will be stored in a temporary directory. Periodically, we move the certificate requests to an offline computer, and generate certificate requests, after verifying user identity and fingerprints over the telephone, or with the physical presence of the owner. Then, certificates are made available over the network, so that the client Windows 95 program may load them.
Finally, certificates are distributed publicly via the LDAP protocol, that is accessed by commercial browsers as a standard directory service over TCP/IP. The publication of a certificate revocation list over the WEB is also planned, together with the implementation of an online revocation service, separate from the CA. Users must be contacted for revocation when the private key has been lost, but even non-signed certificate revocation requests are stored and made known on a separate list. Time is critical in certificate revocation.
The department has also installed a secure WWW server (with the SSL protocol, under the SSLeay implementation). This server distributes authenticated information to internal users. The information is restricted to the Department personnel, and users are authenticated via asymmetric cryptography, if they have a public key pair certified by our CA. If not, HTTP user authentication is performed, with a userid/password. Because client to server information is in any case encrypted, the password may not be read over the local area network. Strong 128 bit symmetric encryption is made available to users as distributed through the "FORTIFY" modifier of the standard Netscape Communicator browser.
