1. What is a Certificate Authority (CA)?

A Certificate Authority (CA) is a combination of software and hardware that can issue digital certificates and that is run by a human entity – an organization or group. Digital certificates are credentials that "bind" public keys to the holder of a digital certificate.

Certificate authorities, the software and hardware, must be managed securely to ensure that trust. It is particularly important for CAs to protect the private key of the CA. The CA uses its private key to digitally sign the certificates. Applications that use digital certificates trust that digital certificates are from the CA that issued the digital certificates.

A CA is responsible for the full cycle of certificate management from the certificate request, certificate issuance, and certificate acceptance to certificate revocation, expiration and renewal.

Certificate requests are processed by a Registration Authority (RA), which is the identity validation function of a CA. The RA ensures that requests for digital certificates are approved only for valid members of the CA community. There may be many trusted RAs for one CA carrying out the role of authenticating users in some fashion.

Well known Certificate Authorities include VeriSign and Entrust.

2. Why would I want to run a campus CA?

You may want to run your own campus CA to support a wide range of applications more securely than the security provided by user name and password. Security is best managed if it is assumed that the network cannot be secure.

If you establish a CA on your campus, you can use it to manage student, faculty, and staff access to virtually any campus resource – from logging on to computer networks, to verifying when email was sent and from whom, to even controlling access to buildings or rooms with a digital certificate embedded in a token (like an access card). Holders of digital certificates can also use these certificates to sign email, providing more secure campus communications.

3. What kind of resources will I need to setup and run a campus CA?

Here are the resources you will want to have on hand to set up a campus CA.

For hardware you should have the following:

• One dedicated server that will be your "CA Box." This is where you will load your CA software. This is where your CA software will reside.
• An optional Hardware Security Module (HSM) to hold the private key of your CA. This is optional, but a highly recommended component of a CA. It is not an absolute requirement for PKI-Lite. A separate Q&A; later in this section describes an HSM and why it is so highly recommended.
• A second computer or adequate computer resources for the Registration Authority software.

For software you should have the following:

• CA software and RA software. The RA software generally comes as part of the CA software bundle if it is applicable.

Another key component of an operational CA is the database or directory of people/objects to whom certificates will be issued. You should have the following:

• A network connection between the server that hold a campus directory/database/etc. and the server on which the RA software resides.

Last but not least, you should have

• A secured physical area in which to store the CA server with controlled and monitored access. Some campuses use a section of their existing machine rooms.

None of this software/hardware runs or operates itself. CA robots are still in the future. In addition to these physical resources, people are needed. You should have the following:

• At least a portion of two staff members time will be needed for setup to select, install and configure the hardware and software over a period of 2 - 4 months.

4. Can I load the RA software on to the same computer where my database/directory resides?

The question of where a campus manages its database /repository/directory is a good one. It is possible to load the RA software on to the same machine as the repository or directory. This may or may not be recommended depending on the particular campus scenario. The pilot work will provide examples in this area.

5. What about network access to the CA? Is this a good practice?

If your directory server has two (2) network cards built in, then you can set up a firewall setup between your directory server and your CA. This may require the purchase of a router or similar device.

6. Why do I need this high level of security?

This set-up helps to prevent network attacks on the CA server itself. Also, the processes of issuing and requesting certificates are separated so that the physical machines may be secured separately, keeping the CA safe from intruders and yet accessible when needed. It is also a good idea to use a hardware security module (HSM) to keep the campus private key physically secure.

7. How are you planning to set up the CREN Net CA?

We are planning to set up a separate machine for the Registration Authority (RA) part of the CREN Net CA. This machine will be set up as a router with two network cards, one connected to the CA issuing machine and the second connected to the network.

With this configuration, the CA machine remains safely behind the router on its own subnet while users (clients) can have uninterrupted access to the RA and the directory over the network. In this configuration, users access the Registration Authority though the network card attached to the LAN and the Registration Authority processes requests for certificates from the CA, attached to the other network card. The diagram below shows the set up:

8. What if our campus doesn’t have a directory set up as yet?

If you do not already have a directory you can use the directory software that comes bundled with the CA software. You may want to give some thought about the information that you will want to capture in your CA directory and how your users will authenticate. More about directories is available on the web at the CREN CA FAQ material and the internet Middleware sites. The goal of a directory, database, or repository for this pilot is simply to know who the people are to whom digital certificates will be issued.

9. Why do I need more than one person involved in the CA?

Selection and installation of the software and hardware is actually pretty easy. For security reasons, however, it is very important that more than one individual be required to access and activate the software and the hardware. Also, if there is an HSM attached to the CA then it is best to require at least 2 of 3 individuals to be present in order to access the information stored on the HSM.

10. Why should my CA be secured in a separate room?

Statistics show that the highest percentage of security breaches come from within one’s own institution. Thus, it is important to secure the physical device. It does not have to be in its very own room which would be ideal but having a room that has very limited access for only employees with a certain security level is recommended.

1. Can I use existing computers for setting up the CA service?

For many of the CA functions, existing equipment can be used. For example, the Registration Authority (RA) may be installed on whatever machine already runs your LDAP compatible directory or repository/database of people.

The machine running the RA is the one that will have the most demand put on it by those making request for certificates. The Certificate Authority (CA) really should be run on a separate physical device from the RA and placed in a secure location. The CA is recommended to be on a dedicated machine.

2. Will I need to purchase any special hardware?

In addition to any computers that you will be assigning to your CA service, you may also choose to purchase a hardware security module (HSM). Although this is not required, it is considered good practice for operational CAs to have one. Basically, an HSM is used with a CA to store and secure the private key of the CA.

3. Where do I need to locate the equipment for my CA?

Any machine that has an operational CA running on it should be secure from uncontrolled access. The CA is the most vulnerable machine and if compromised will need to have its private key revoked along with all previously issued digital certificates.

4. What kind of network access does my CA need?

The CA should not be accessible to the network if at all possible except through the RA. The RA is the machine/software that submits a request to the CA to issue a certificate for a user.

5. What kind of network access does my RA need?

The RA can be accessed by as many users on the network as you decide are necessary. It is referred to as the ‘front end‘ to the CA.

6. What hardware do I need to setup to run my campus Certification Authority?

There are three basic scenarios. There are many other more sophisticated network designs but these three scenarios serve as a starting point for planning.

• Option A: Certificate Authority and Registration Authority with the database/ directory on the same physical device. This means that the CA private key is stored on the hard drive. In this scenario the CA is only activated for issuance of digital certificates and is off line.

• Option B: Certificate Authority and Registration Authority with the database/ directory on the same physical device but with the CA private key stored on a hardware security device.

• Option C: Certificate Authority on one physical device with a hardware security device to store the CA private key and the Registration Authority with the database/ directory on a separate physical device.

8. Option B: Certificate Authority and Registration Authority with the database/ directory on the same physical device but with the CA private key stored on a hardware security device.

This scenario does not provide the recommended level of security as the CA itself may be on the network. The security problem is somewhat lessened with the private key stored in a hardware security module.

The encrypting of the certificate by the CA will slow down access to your directory by other applications.

9. Option C: Certificate Authority on one physical device with a hardware security device to store the CA private key and the Registration Authority with the database/ directory on a separate physical device This is the most secure scenario and the most efficient. The simplest solution to securing the CA is to dedicate a server to this purpose and secure it in a locked area.

If the RA server is configured with two network cards, the RA can be linked to the CA with one network card and linked to the outside world with the other network card.

With this scenario, the RA is accessible to request certificate of the CA for those individuals accessing it from the outside world. Adding a hardware security device to this configuration, which is attached to the CA, would doubly protect the private key of the CA.

1. What is a Hardware Security Module (HSM)? How does it fit into my campus Certification Authority?

A Hardware Security Module is a hardware-based security device that generates, stores and protects cryptographic keys. It provides the foundation for a high-level secure campus certification authority. Certification modules are also available in software, but a hardware device provides a higher level of security.

2. How do I know if a Hardware Security Module is secure enough for my applications? Are there any universal criteria for rating these devices?

Yes, there are universal criteria for rating these devices. The criteria are documented in a Federal Information Processing Standard (FIPS) called FIPS 140-1 – Security for Cryptographic Modules.

This FIPS standard provides criteria for evaluating security modules – whether hardware, software, or some combination of hardware and software. The FIPS standard was developed collaboratively by the following agencies: the US National Institute of Standards and Technology (NIST), the US National Security Agency (NSA), and the Canadian Communications Security Establishment (CSE). Security devices are currently rated from FIPS 140-1 Level 1 to FIPS 140-1 Level 4. Higher standards may be developed in the future. The Level 4 standard is for the most rigorous security environments.

3. What is a FIPS 140-1 Level 3 Hardware Security Module?

A FIPS 140-1 Level 3 Hardware Security Module Device meets the FIPS 140-1 Level 3 or higher standard by supporting cryptographic key generation and storage within a hardware environment.

At this time, most institutional certificate authorities use a FIPS 140-Level 3 Hardware security module that cannot be physically accessed by unauthorized personnel.

4. Are there any advantages to using a FIPS 140-1 Level 3 Hardware Security Module rather than a software only security module?

A FIPS 140-1 Level 3 validated cryptographic module has a number of significant security and operational advantages over an equivalent software-based cryptographic implementation. The most useful advantage is the more secure environment. The principal value of these hardware modules is that keys can be generated and stored in these boxes, and provide strong protection against removal from the box.

By using hardware root-key protection from the beginning of deployment, an organization can achieve FIPS 140-1 Level 3 security at the outset. The inherent risks associated with software are mitigated because the root key will be and will always have been stored in protected hardware.

For additional information see:
https://www.cren.net/crenca/onepagers/additionalhsm.html

5. Why should a campus have a Hardware Security Module?

The security and performance benefits offered by a hardware security device provide a critical component in the management and storage of private keys within a security infrastructure. HSMs also supply the infrastructure needed by the finance, government and healthcare sectors to conform to industry and regulatory standards.

6. What does the Hardware Security Module protect and secure?

The heart of trust in a public key infrastructure is the certificate authority (CA) that holds the root cryptographic signing key of the certificate authority. This signing key is used to sign the public keys of certificate holders, and even more importantly, signs its own public key. If this key is compromised, all certificates signed by the certificate authority are suspect, and the CA’s credibility is destroyed.

7. What are some of the additional protections of using a Hardware Security Module as part of a CA?

The security of a certificate authority depends on the right tools and the processes or policies using those tools. Here are some of the specific protections that can be achieved when combining a hardware security module with effective institutional practices and processes.

Hardware may be less susceptible to system failures and corruptions, such as viruses.

The content of the hardware module can be backed up to other hardware devices. If one set of hardware is destroyed, a backup set remains either on a duplicate hardware device or in a spare token or card set dependant upon your HSM model. Protecting the content is achieved with the combination of the hardware protections and good operational practices.

Hardware can protect against internal and external intruders by using two-factor authentication: both the hardware device and a password can be required activate the root key.

Hardware provides a higher level of security than non-secure media such as backup tapes, floppy diskettes, or smart cards, since the latter can be easily removed or copied.

Hardware enables you to keep track of the number and locations of copies of root keys that exist.

Hardware can enable an institution to support controlled access to the activation and use of root keys. Access codes can be distributed among several people who must cooperate to gain access to the root key.

8. What are some of the specific disadvantages of a software module or a combination of software and physical barriers to protect a CA?

Software or a combination of software and physical barriers to protect the root key has the following disadvantages.

Software alone is vulnerable to viruses, inadvertent erasing, hackers, and complications from system failures.

Physical barriers, such as vaults, and secured entrances are cost-prohibitive due to the expense of the initial investment and the on-going maintenance costs and do not adequately protect against insider attacks.

Database backups of the certificate authority’s directory may contain a copy of the root key on each backup media, which are not secure and easily copied. This results in multiple copies of root keys existing at any one time with no assurance that additional copies have not been made and removed.

9. What are some of the best practices for an HSM architecture?

Best practices are methods or strategies that are used by leading organizations to improve their security posture. See the following for a set of Best Practices on security assurance:
https://www.chrysalis-its.com/news/library/industry_white_papers/dt_best_practices.pdf

Acknowledgements: Thanks to Tina Bennett at Chrysalis for the foundation piece from which this FAQ was developed and to the reviewers, especially Ed Feustel at the Dartmouth College PKI lab.

1. Does the certificate authority software run on a system that I am familiar with?

Each CA software package lists the system requirements for that package. Some CA software vendors specialize in certain operating systems while others make an effort to cover a variety of the more common platforms. For example, Entrust does not run on Linux but runs nicely on Windows 2000. On the other hand, iPlanet runs on Sun Solaris and Windows NT 4.0 but has not been thoroughly tested on newer Windows systems.

2. What other software should be compatible with the certificate authority software?

Compatibility with other software on your campus can be an important consideration in your purchase of certificate authority software. It is sometimes possible to purchase CA software from the same family of software. For example, if you are already running RSA’s Web Sentry to protect your web servers, it is possible that you may want to choose the RSA Keon CA to be your CA server and Keon RA for your registration authority.

3. Do I already own some certificate authority software?

It is possible you already have certificate authority software with which you can experiment. If you bought a suite of software like the Microsoft Server it is possible that some certificate authority software was included. Some times vendors will sell a license to a group of individual software packages. It is possible that the CA software was included in that license or could be included for a nominal fee.

4. Does the certificate authority software have a user interface for the RA?

Most certificate authority software packages include a web interface for the user to request a certificate. This interface is sometimes referred to as the Registration Authority. RSA has individual modules that can be purchased and installed separately so that you have a choice to either purchase or create your own. iPlanet and Microsoft provide options during the certificate authority software installation process as to whether to install the RA software or CA software from the same install screen.

5. What directory does the certificate authority software use?

Knowing your users is very important from a technical standpoint. If there is a way in which users currently are identified electronically, then take some time to document the process that is used for this purpose. It will be useful later for you to know what attributes your directory currently holds. Ultimately you will have a directory for your users, however, if you don’t currently have one the software that you choose will usually create on for you as you issue certificates. Otherwise some software packages will allow you to connect to your current directory if it is LDAP compatible. It is important to examine the directory linking capabilities of the CA software that you select. Some CA packages would prefer to user a proprietary directory structure and have some difficulties with linking to the standard X.509 LDAP compatible structure.

6. Can certificates be accessed remotely?

Some certificate authority vendors have software features that enable a CA to "manage" certificates by escrowing the private keys of certificates as certificates are issued. Vendors have a variety of strategies to protect a private key once it is escrowed, including double or triple encryption.

7. Can the certificate authority be remotely administered?

Many of the certificate authority software offer a remote administration option using a web browser interface. This feature emphasizes the need for the best practice of connecting the CA to only one machine with network access. The more users that have access to the CAs physical device, the higher the probability that the device will be compromised.

8. What about operating a CA? How much support will be needed over time?

Knowledge is one of the most costly items to obtain and/or replace. Open source software or locally developed software can be difficult to support in the event of staff turnover or advancement.

9. What certificate authority software is available?

There are almost as many vendors of certificate authority software as there are purchasing options for certificates. The vendor specifications chart later in this section provides an overview of some of the certificate authority software choices currently in the marketplace.

There is information on the Java-based CA (JSCA) by Jeff Schiller, a version of which is used by the CREN CA. Other software that is lightly profiled include Entrust’s Entrust Authority, iPlanet’s CMS and RSA’s Keon CA. Other choices to be examined in the future include Open CA from the Open Source community, Baltimore Technology’s CA, and Microsoft’s CA in the Windows 2000 and NT 4.0 server software packages.

10. What certificate authority software packages are recommended to the pilot institutions?

This is another important question for this pilot. It is hoped that some positive business relationships can be developed with these vendors for the benefit of the higher education community. Each package has its own set of attributes and should be examined closely to match those attributes with the needs of the institution. This is an area of opportunity for collaboration among institutions — to learn about and pilot this software.