Nuclear Instruments and Methods in Physics Research A 502 (2003) 430–432
Secure automated request processing software for DataGrid certification authorities L. Shamardina,*, N. Kruglova, P. Martuccib a
Skobeltsyn Institute of Nuclear Physics, Moscow State University, 119992 Moscow, Russia b G22100, CERN, CH-1211, Geneve 23, Switzerland
Abstract Typical Public Key Infrastructure (Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, IETF Network Working Group, RFC 2527, 1999) includes a Certification Authority (CA) and several Registration Authorities (RA). In this report we present our solution for building the CA. Our goal was to make it secure, robust and as automated as possible. In our solution the message exchange between CAs and RAs uses signed e-mail. Supported features include issuing and revocation of certificates, information services and certificate renewal. All operations requiring a private key of the CA are held on the separate offline signing host and are fully controlled by an operator, making the CA attack proof. r 2003 Published by Elsevier Science B.V. PACS: 07.05.Bx Keywords: Certification; Authority; Grids; DataGrid; X.509; PKI
1. Authenticity and security issues In general, the requirements to the Certification Authority (CA) are quite conflicting [1]. From the first side, the CA should publish online the most latest information possible about the certificates. At the same time a CA cannot be fully automatic and online to be secure. For the best security the authenticity control of all the requests coming to the CA is required. This can be done contacting the certificate request author directly using the phone call for example. Large amount of incoming requests will cause *Corresponding author. E-mail address:
[email protected] (L. Shamardin).
extremely high load of the CA because of the large number of checks. One of the solutions is setting up the Registration Authorities (RA). An RA is the point where the authenticity of the request is checked. But the RA does not issue certificates, it approves and digitally signs the request, and then transfers it to the CA, where it is considered to be authentic if it has a valid signature from the RA. Secure CA must be offline to be as hack-proof as possible. On the other side, information about certificates and CRLs must be published in the Internet as soon as possible. The simple solution to keep the CA signing key offline is not secure enough because a hacker could wait until the key is connected to the CA host for singing. Thus we have to split the CA into two hosts, one of them is
0168-9002/03/$ - see front matter r 2003 Published by Elsevier Science B.V. doi:10.1016/S0168-9002(03)00460-1
L. Shamardin et al. / Nuclear Instruments and Methods in Physics Research A 502 (2003) 430–432
used for signing and kept offline, another publishes the information and implements other online CA services, but does not contain CA signing key.
2. CA architecture All requests are coming to the CA online host. Secure e-mail (S/MIME) was chosen as the transport protocol for the certificates and requests exchange between the CA and RAs. End users send their requests to the RAs. The RA checks the authenticity of the request and signs it. Signed requests are archived on the CA online host and once a day are transferred to the offline CA signing host. RA can also create certificate revocation requests for the certificates which requests were signed by this RA. The signing host processes all the requests, issues and revokes certificates and updates the CRL. Then the data is transferred back to the online host. Private key of the Certification Authority is stored on the removable media (CD in our case), but it can be also stored on any special hardware which is supported by OpenSSL library [2]. All information about issued certificates, etc. is stored in the database. Stored data includes information about certificate owners with their contact details, all information about the requests including which RA signed the request and the original request itself. All CA operations can be logged to the local or remote syslog facility.
3. Implementation details The software package installed on the CA online host includes an automated e-mail processing software and CGI scripts for the web server. Web scripts implement part of the information services and e-mail robot processes the incoming requests. The e-mail robot is started automatically every time when e-mail arrives to the CA. First, it checks the signature on the e-mail message. Certificate issue and revocation requests must contain a valid signature from the RA, otherwise they are rejected.
431
Information requests may contain no signature at all. The special case is certificate renew requests, which do not have to be signed by the RA. All requests which require access to the CA’s private key are placed in the queue and request details are added to the database. For the revocation requests there is an access check. Currently only the RA which signed the certificate request may ask for revocation, but later this check may be replaced with ACLs. The special case is the certificates renew requests. We have implemented the renewal scheme proposed in the Globus Toolkit [3]. When the certificate is going to expire soon, the CA sends an e-mail to the certificate owner with a notification about certificate expiration and a challenge string. In reply, the certificate owner should send to the CA the new certificate request with the Distinguished Name equal the old DN and ‘‘=CN ¼ proxy’’ appended to the end, a certificate for this request signed with an old (going to expire) certificate and the challenge string from the notification signed with an old certificate. The last part is required to prevent frequent renewal of the certificates by the users. If all the signatures on the renewal request are valid, then the CA places the renewal request to the queue. The RA is not involved in the certificate renewal process. After this the CA operator runs the queue processing script which creates an exchange packet which is transferred to the offline host using a floppy disk for example. On the offline signing host all requests are processed, signed, etc. with the CA signing key. Then the signing host creates another exchange packet which is processed on the CA online host. After this new CRL, certificates and other information is automatically published to the Web and CA automatically sends all the required e-mail notifications. Another component automatically checks certificate expiration dates and sends notifications with challenges to the certificate owners. All actions on both online and offline hosts are logged to the database for auditing and other purposes. All information about the Certification Authority, the CRL, issued certificates, CP/CPS and other is published on the CA web page.
432
L. Shamardin et al. / Nuclear Instruments and Methods in Physics Research A 502 (2003) 430–432
4. Conclusions
References
The created system is secure enough from both hack-proof and certificate authenticity sides, and it allows fast online information updates. It was tested on the Russian DataGrid Certification Authority.
[1] S. Chokhani, Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, IETF Network Working Group, RFC 2527, 1999. [2] J. Viega, M. Messier, P. Chandra, Network Security with OpenSSL, O’Reily & Associates, 1st edn. (June 15, 2002), 384 pp.; ISBN 059600270X. [3] http://www.globus.org/
Acknowledgements The work was partially supported by CERNINTAS grant 00-0440.
