Case study: How I implemented PKI

Terry L. Beavers, head of technology assessment and application at the University of South Florida, explains how his division rolled out a PKI pilot project from start to finish.

By Terry L. Beavers

The University of South Florida needed a Web-based secure payroll certification system. It involved two components:
  1. Preparation of biweekly payroll for each employee by authorized preparers
  2. Certification of payroll by authorized certifier upon completion of preparation

We were a couple of years away from implementation of our campus-wide NetID system, but we needed a secure way for Web-based certification, so we opted to develop a PKI infrastructure that would integrate with future systems.

Our requirements
This was a pilot project, and we are a public agency, so we had a list of requirements our PKI system had to meet.

First, we needed to keep total costs and per-user costs low. We also wanted a system that was easily modifiable and customizable. It needed x.509v3 compliance for extensibility and browser compatibility, and we needed to ensure integration with our IIS4.0 Web servers.

Further, we had to ensure the system would eventually work with:
  • Lightweight Directory Access Protocol (LDAP)-based campus directory.
  • Outlook secure mail (s/mime).
  • Active Directory.

Finally, we had to have total control of the certification project, which meant we couldn’t simply outsource that component. Because the University of South Florida is a public agency, we must be able to meet certain legal and audit requirements. We decided to go with the Microsoft Certificate Server.

About Microsoft Certificate Server
Microsoft Certificate Server generates standard x.509v3 certificates, so we’ve had no compatibility issues with the various browsers used. It is also an inexpensive yet powerful and flexible solution.

Via the ActiveX API, we quickly developed our own Web-based registration process using active server pages and one-step certificate download and installation for Internet Explorer users. Both Netscape and Internet Explorer browsers automatically install the Certificate Authority certificate the first time, so that was largely a nonissue.

But to make things slightly smoother for IE users, we were able to preinstall our CA certificate in a copy of IE available as a free download from our Web site. This makes the process seamless to IE users because they don’t even see a warning message. Netscape users, however, still receive a warning the first time they get a certificate.
Would you like to share your project story? Good or bad, TechRepublic is always looking for first-person accounts of projects and policy implementations. If you think you’ve got a project other IT executives would like to hear about, e-mail us a brief description of it.
The biggest negative aspect of the Microsoft Certificate server was the lack of a revocation list standard. So we used more efficient direct certificate database queries instead.

And although this was not part of the project, we were disappointed in the lack of a public key LDAP directory. This issue was resolved in the current version of the server.

Obtaining user buy-in
We first met with administrators to explain the concept and how it would work. Next, we met with various campus officers and committees to obtain buy-in from the user base.

There were two key issues we had to address to gain user buy-in:
  • Security concerns. I would venture to say that addressing security concerns was the largest obstacle to overcome. I approached this by conducting basic security concepts presentations to user groups and various committees throughout the organization, as well as conducting in depth meetings with the process owners, information technology support staff, and internal auditors.
  • Making users comfortable with PKI. The next issue of significance was dealing with the complexity of the process. I addressed this issue in the meetings with user groups. To allay first-time jitters, the IT support staff conducted training sessions throughout campus in venues near the users and prepared online, graphical, step-by-step instructions.
    The entire process was automated to be as simple as possible within the scope of the security concerns. I also developed an online help system for problem resolution and held Q&A sessions with the computing support staffs. Still, the first couple of weeks required a lot of user handholding.

Another way we eased concerns was by carefully conducting a pilot period during which the certificate process and payroll certification process were used in parallel with the paper process. During this time, we introduced the payroll staff and selected user representatives to the system.

Following this successful month-long test, we rolled out the PKI system to a broad segment of about 500 users. Gradually, as new people have come into the process, it has expanded to about 750 active users.

The actual implementation
We developed our own Web-based authentication and acquisition process for users of the system. To obtain certification, the user:
  1. Goes to the University of South Florida card center and gets identified, photographed, and entered into a user database.
  2. Goes to the certificate site and provides identification, which is confirmed by our databases.
  3. Receives e-mail at an official USF address. He or she must respond to the e-mail within 48 hours.
  4. Goes to a user-unique Web site, as directed by the e-mail, and reenters identification.
  5. Downloads and installs a certificate.

The procedure users go through to obtain a certificate.

We also developed a session-based payroll certification system that grabs the certificate information. This requires a password from the user. The certificate validity is checked for authorizations at that time. The following section explains how we developed that system.

Developing the session-based payroll certification system
We easily created the session-based certification system by exposing the certificate information to the application via the Web server API.

Using Internet Information Server 4.0, we used the server management software to require and read client certificate data by checking two boxes for this Web application. In the application itself, we then created a “client-certificate object” that exposed that server-side data to the application.

Since this all occurs within the Web server, there was no security exposure with this approach. To accomplish the latter step, we created a module using VBScript in an active server page to perform the authentication operation and verify certificates against the certificate database. (We used active data objects for the database operation—essentially a SQL query based on that certificate.)

Shocking as it may be, this was the easiest part of the coding and took no more than an hour or two to fully code and debug.

We used this authentication operation because our tests indicated it was considerably more efficient and functional for our purposes than using native Web server certificate authentication. We basically let the Web server handle certificate decrypting (SSL) and basic verification and then performed our application-specific verification via code.

What about scalability?
Early tests indicated adequate scalability for our application, since we would never have more than a couple of thousand users during this project. However, scalability certainly would have been an issue with the entire user population (50,000). As it is, we have issued over 2,500 certificates without any issues or load problems.

We intend to upgrade to an Active Directory-based MS Certificate Server 2.0 before implementing certificate-based services for the entire user community. Early tests indicate no scalability issues for us with this version.

What’s next?
As I mentioned earlier, the University of South Florida is developing a campus-wide NetID system in-house. The basic NetID generation system is currently in open test using Netscape Directory Server and LDAP. We intend to move the core authentication directory to MS Active Directory in the next phase.

The system itself was fully written in-house and is Web-based. We are working now with external vendors to integrate our NetID repository with their authentication systems.

The goal is to provide a single “netid” for each user that can be used to identify the user and provide access to the various applications and Web servers currently in use. Our first application will be student e-mail. We hope to then move to the same approach for faculty/staff e-mail and Windows applications, such as Office.

The greater challenge will be integrating the NetIDs with the currently independent authentication systems of our business application vendors. This is one reason we are working with the external vendors to address such integration and will very likely outsource parts of that development, especially the authorization integration pieces.

The future of PKI is still up in the air. The Electronic Signatures in Global and National Commerce, which went into effect Oct. 1, has raised questions among some IT security experts about whether PKI is really necessary for most business operations.

Taking a cue from the experiences of the Access America PKI participants, we will very likely look toward a smart card-based environment that will include a user’s digital certificate and private key. This will allow the use of embedded PKI for many more operations, including e-mail encryption, online document signing, and resource logon access.

Toward that end, we are investigating smart card vendors now for a possible replacement for our current multi-stripe USFCard. If the university does this, we’ll probably make an investment in an upgrade to Certificate Server 2.0, using Active Directory as the NetID repository.
If you’ve implemented PKI, did you encounter similar issues? Send us an e-mail or begin a discussion below.

Editor's Picks