Case study: How to build a corporate PKI

By Rolf Oppliger

The corporate Public Key Infrastructure (PKI) described in this article has been designed by the IT Security Group of the Swiss Federal Office of Information Technology and Systems (BFI) to meet the requirements of the federal agencies. Provided the architecture is approved, it will be implemented accordingly. The software to run the Certification Authority (CA) kernel and database is very likely to be standard software, whereas the software to run the CA front-end on top of an SSL-enabled HTTP server will be developed and customized accordingly. The resulting software will be described in a subsequent article.

One may reasonably dispute whether an X.509-based PKI is actually the infrastructure required for the Internet community and Internet-based electronic commerce; but from a corporate point of view, the situation is fundamentally different. Typically, within a corporate environment, a namespace in which each employee is not only identified with a unique name, but is also assigned a unique employee number already exists. Consequently, there exists a global namespace within the corporate environment that can be used to have certificates bind public keys to unique names. Note, however, that the resulting certificates can be mainly used for internal purposes, and other certificates for secure communications with external parties, may exist as well.

Assumptions Following this line of argument, we assumes the existence of an internal namespace within a company, and suggests the building an X.509-based PKI for the corporate environment accordingly. Having an X.509-based PKI in place, it seems to be an easy task to later issue other certificates (i.e. attribute certificates or SPKI certificates). An internal namespace for a corporate environment means that every user has a name that uniquely identifies him within the corporate environment. Where names are ambiguous, additional information (for example, date of birth or employee identification numbers) may be used as well.

It is also assumed that every user is an employee of the company and as such has a relation with the human resources department accordingly. Human resources officers usually hire employees and check their identities and credentials respectively. It seems to be a good idea to have those officers deal with user identification and authentication during the certification process, as well. The procedures described in this article actually make use of this idea and have human resources officers serve as certification agents or delegates who remotely control the certification process. This allows us to actually minimize the CA infrastructure. It is also assumed that all users and certification agents or delegates work with SSL-enabled WWW browsers or HTTP clients, such as the Netscape Navigator or Microsoft Internet Explorer. As a consequence of this, additional software must be developed only for the CA components introduced in the following section.

Components
A corporate PKI typically consists of one or several CAs that issue and revoke certificates. From a technical point of view, those CAs can be seen as replicas of a CA that consists of three components:

• CA kernel
• CA front-end
• CA database

The CA kernel is an off-line component that communicates only with the CA database. What this basically means is that it takes its input from the CA database and also deposits its output there. There is no interaction with users and certification agents or delegates. Contrary to the behavior of the CA kernel, the CA front-end is an on-line component that directly interacts with users and certification agents or delegates. For example, it takes certification requests from users and lets certification agents or delegates confirm the authenticity of the corresponding users. Interactive communications with the CA front-end is always protected through SSL. Finally, the CA database is the interface between the on-line CA front-end and the off-line CA kernel. As described in the following section, a user can contact the CA front-end to request a certificate. The CA front-end deposits the certificate request in the CA database, where it can be confirmed by an authorized CA agent or delegate. From time to time, the CA kernel issues certificates for the confirmed certification requests that he finds in the CA database. This step can be automated accordingly. To implement a corporate PKI as proposed in this article, an SSL-enabled ÒsecureÓ HTTP server is required for the CA front-end, a database management system (DBMS) for the CA database, and a commercial CA software for the CA kernel. If the CA is replicated, one of each components is used for each replication.

Five steps for certification The figure above illustrates the basic steps of the certification process. Note that the users on the bottom left side and the certification agents or delegates on the bottom right only communicate with the CA front-end. In general, there are five steps for a legitimate user to receive a certificate.

When a user wants to get a public key certificate from one of the corporate PKI's CAs, he directs his WWW browser to the corresponding CA front-end (typically one specific URL) in step 1. Since the WWW browser is SSL-enabled, it can strongly authenticate the CA front-end, negotiate a session key, and encrypt the entire session accordingly. (Note at this point in time that the user is not authenticated by the CA front-end, since he's not yet provided with a public key certificate.) The SSL connection can now be used by the user to securely deposit a certification request. More precisely, the CA front-end receives a certification request from the user's WWW browser, double-checks whether the browser holds the corresponding private key, and deposits the certification request in the CA database accordingly. In addition to the certification request, the data structure in the CA database has three additional fields for timestamps, as well as a final field to hold the public key certificate. All four additional fields are initialized to zero at this point in time. From time to time, an authorized officer of a human resources department who acts as certification agent or delegate may contact the CA front-end in step 2 to check whether any employees have deposited a certification request meanwhile. (Alternatively, one may also think of a CA front-end that notifies the certification agent instead of having him periodically contact the CA front-end). At this point, it is important to note that the CA agent is equipped with a public key certificate, and can strongly authenticate to the CA front-end accordingly. Consequently, the CA front-end and the certification agent may mutually authenticate each other and encrypt the entire session between them. The certification requests that have not been served so far have all three timestamps set to zero, and can be sorted out accordingly. When the certification agent finds the certification request that the user has deposited previously, the agent checks whether the user has provided his correct name and if the user is authorized to get a certificate. In the positive case, the agent personally contacts the user to authenticate and to see whether the user has requested a certificate. In the normal case, this contact can be established with a telephone call. If the certification agent is convinced that the user is authentic and authorized to get the certificate, he initializes the first timestamp with the current time and date. The initialization of this timestamp actually indicates that the certification request has been confirmed by the appropriate agent. Obviously, the CA front-end should make the entire task transparent to the agent who should only have to mark a specific field. At this point in time, the CA database holds a certification request with the first timestamp not equal to zero, and the two other timestamps equal to zero. When the CA kernel contacts the CA database in step 3, it would search for those records and upload them. The CA kernel would then issue the certificates required and download them to the appropriate database fields. In addition, the second timestamp would also be set to the current time and date. This second timestamp actually indicates that the requested certificate is ready for delivery. Note that the entire process of uploading certification requests, issuing certificates, and downloading them can actually be automated to a certain degree. When the certification agent contacts the CA front-end for the next time in step 4 (through another SSL connection), he would be notified that a requested certificate is ready for delivery. The agent informs the user with an e-mail message or a phone call that he can retrieve the certificate from the CA front-end. The certificate, in turn, is temporarily protected with a password or PIN that the CA front-end and certification agent or delegate agree on. This information is forwarded to the user. So when the user contacts the CA front-end in step 5 to retrieve his certificate, he's prompted for the password or PIN. If he can provide the authentication information, he can download the certificate accordingly. Otherwise, the download is stopped and a corresponding entry is written to the audit log. At this point in time, the third timestamp is initialized with the current time and date. This timestamp actually refers to the time of delivery.

The procedures to create entries in the certification revocation lists (CRLs) of the CAs are similar and not covered in this article. Certificate revocations can be initialized either by the holders of the certificates or the corresponding certification agents or delegates. In either case, they require strong authentication. It is important to note that in the scenario described above, the CA kernel does not have to store a lot of data. All data it is working with is transient by nature and can be deleted after having issued and delivered the corresponding certificates. All data is collected by the CA database. It is assumed that the certification requests that have been served (all timestamps are initialized and the certificate field is not empty) are archived and written out to a read only memory from time to time.

CA costs
The costs of a corporate PKI as proposed in this article seem to be moderately low. Note that from a hardware and software point of view, all that is required is an SSL-enabled HTTP server software to serve as CA front-end, a DBMS to serve as CA database, as well as a CA software package to serve as CA kernel. The most expensive component is the physically secure environment in which the CA software should run. However, one can reasonably expect that this environment already exists in a corporate environment. Note that most companies still have computer centers that can host the corresponding CA software packages. From an operational point of view, the proposed PKI architecture is interesting, as well. Note that the whole CA consists of components that can be automated to a certain degree. The only point where human work is required is for the certification agent to confirm certification requests and to notify the requesting users if the certificates are ready for delivery. It remains to be shown in practice whether these tasks can actually be performed by human resources department officers as proposed in this article. In either case, the task of remotely controlling the certification process requires some basic knowledge in terms of cryptography and public key certificates.

Threats analysis
The corporate PKI proposed in this article assumes the CA (including the CA front-end, database, and kernel) to be run in a physically secure environment without much administration. The only people who have access to the CA are the people who operate the environment. These people, however, are computer professionals that who are used to work in high-security environments. We don't assume them to be a major problem. However, the certification processes are also remotely controlled by certification agents or delegates. These agents are supposed to be human resources officers who are not specially skilled for security. There is some danger that these people can misbehave or willingly cheat. All that can be done about this is to educate them in security and cryptography, and to let each agent only confirm employees he's responsible for. This achieves at least some sort of traceability.

Rolf Oppliger, Ph.D., of Swiss Federal Office of Information Technology and Systems (BFI), IT Security Group can be reached via tel: 41-031 -325 9696, e-mail: rolf.oppliger@bfi.admin.ch or URL: http://iamwww.unibe.ch/~oppliger