Planning Your Smart Card Deployment: The Importance of Policy and Process

  • Article

By Brian Komar

See other Security MVP Article of the Month columns.

Many organizations are considering the deployment of smart cards in their networks. The key to a successful smart card deployment is to ensure that you get your policies defined before you start the smart card issuance process. The steps for a successful smart card implementation are as follows:

  1. Define the certificate policies that are enforced during the issuance of the smart card certificates.

  2. Choose a registration model that enforces the certificate policies selected.

  3. Configure a registration authority to define a workflow used for the issuance and management of the smart card certificates through the life cycle of the certificates.

This article focuses on the policies and processes that help ensure that a smart card certificate can be used for the assurance level stated in the certificate. The article also introduces Microsoft Certificate Lifecycle Manager, a new product that allows management of certificates and smart cards in a Microsoft Certificate Services environment.

Why are organizations moving to smart cards?

Although each case is unique, some of the more common reasons for deploying smart cards include:

  • Allowing portable certificate credentials. Users can use any computer (as long as it has a smart card reader and middleware installed) with their smart card, and can access their certificates at that computer.

  • Securing administrator credentials. Many organizations are looking at smart cards for administrators to remove all password use by administrators. Administrators must use their smart cards to authenticate when performing administrative actions.

  • Creating high assurance credentials. A smart card is a two-factor authentication device. This means that to authenticate, two factors must be known or met. For a smart card, the two factors are: something you have (the smart card) and something you know (the personal identification number or PIN).

Assurance levels—not all smart card certificates are created equally

The measures taken to ensure that the owner of the smart card is the same person referenced in the subject of the certificates on the smart card help determine what the assurance level is of the certificates on the smart card. This information is recorded in each issued certificate in the certificate policy extension.

Note
Certificate Policies are defined in RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework.

A project in the United States—the Federal Bridge Certification Authority (FBCA)—has defined different assurance levels for the certificates used in the bridge CA framework. These assurance levels define:

  • When it is required to use a certificate with a specific assurance level.

  • What measures must be taken at enrollment to meet the specific assurance level.

  • What measures must be taken at renewal to meet the specific assurance level.

FBCA Assurance Levels

The FBCA has defined five different assurance levels for use within the FBCA framework. The five assurance levels are:

  • Test. This level is used only for interoperability testing between the FBCA and Principal CAs.

  • Rudimentary. This level is typically used to provide data integrity to the information being signed, for example, protecting an e-mail message from modification. The level is not intended for transactions requiring authentication, and is generally insufficient for transactions requiring confidentiality.

  • Basic. This level provides a basic level of assurance relevant to environments where there are risks and consequences of data compromise, but they are not considered to be of major significance. This may include access to private information where the likelihood of malicious access is not high. It is assumed at this security level that users are not likely to be malicious.

  • Medium. This level is relevant to environments where risks and consequences of data compromise are moderate. This may include transactions having substantial monetary value or risk of fraud, or involving access to private information where the likelihood of malicious access is substantial.

  • High. This level is appropriate for use where the threats to data are high, or the consequences of the failure of security services are high. This may include very high-value transactions or high levels of fraud risk.

Note
This article will focus on the basic, medium, and high assurance levels.

FBCA Enrollment Requirements

The enrollment requirements that an organization defines help ensure the assurance level of the smart card certificates. Some of the common measures taken to validate the identity of the smart card subscriber include:

  • Recording the identity of the person performing the validation process.

  • Having the smart card subscriber present identification to prove their identity. For example, the FBCA medium and high assurance certificate policies require presentation of photo identification. Credentials required are either one Federal Government-issued photo ID, or two Non-Federal Government IDs, one of which shall be a photo ID.

  • Recording a unique identifying number from the presented identification.

  • Recording the date and time of the identity validation.

  • The requirements for renewal will also differ based on the assurance level of the certificate. In most cases, proof of ownership of the current certificate's private key is sufficient for certificate renewal. In other words, if I have the smart card and know its PIN, I can sign my renewal request with the existing smart card to prove my identity. The FBCA still does require that the identity of the smart card holder be reviewed at period intervals:

  • Basic - Identity must be reestablished every 15 years through the initial identity validation process.

  • Medium - Identity must be reestablished every 9 years through the initial identity validation process.

  • High - Identity must be reestablished every 3 years through the initial identity validation process.

Asserting Assurance Levels in Certificates

When you issue a certificate, you can state its assurance level by inserting an object identifier (OID) into the certificate policy extension of the certificate. The OID represents the assurance level implemented when the certificate was issued to the smart card subscriber.

For example, the FBCA defines the following OIDs for their basic, medium, and high assurance certificate policies:

  • Basic = 2.16.840.1.101.3.2.1.2

  • Medium = 2.16.840.1.101.3.2.1.3

  • High = 2.16.840.1.101.3.2.1.4

Note
You do not have to use the specific FBCA OIDs in the certificates issued by your organization. You can assign OIDs from your organization's arc to represent the assurance levels implemented by your organization. The process of cross-certification allows you to map your organization's OIDs to another organization's OIDs when certificates are used between organizations. For more information on cross-certification, see my Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003 white paper. And for more information on modifying certificate templates, see my Implementing and Administering Certificate Templates in Windows Server 2003 white paper.

Applying Process to Policy

Once your organization has defined the assurance levels required for certificates, you must design certificate issuance processes that will enforce the assurance levels. In most cases, an organization will choose from one of four registration models for requests:

  • Self-service. In a self-service model, the smart card registration process is initiated and completed by the certificate subscriber.

  • Delegated. In a delegated model, the smart card registration process is initiated by a certificate manager and then completed by the certificate subscriber. This allows the collection of data, such as the photo identification details required by FBCA medium and high assurance levels, during the registration process.

  • Centralized. In a centralized model, the smart card registration process is initiated and completed by a certificate manager. The certificate manager acts as an enrollment agent in this model, allow them to request certificates on behalf of other users. In this model, the smart card is typically sent in a blocked state to the certificate subscriber, or the PIN for the smart card is sent separately in a PIN letter printed in a secured fashion.

  • In-person proofing. In an in-person-proofing model, the certificate subscriber will go to the certificate manager’s location to physically meet with the registration authority. The certificate is requested by the certificate manager with the certificate subscriber providing the PIN for the smart card.

Within a certificate's life cycle, different registration models may be used. For example, initial enrollment may implement a centralized model, but self-service may be allowed for renewal of the certificate.

Deploying the Smart Cards

Microsoft has recently acquired Alacris idNexus, a registration authority for the Windows Server 2003 PKI and has rebranded the product as Microsoft Certificate Lifecycle Manager (CLM).

CLM is a policy and workflow drive certificate registration authority that helps an organization manage the life cycle of both software-based and smart card certificates. The workflow options within CLM allow an organization to create a process for each stage of a certificate's life cycle that ensures that the certificate's assurance level is maintained.

The main feature of CLM is the profile template. A profile template consists of:

  • Certificate templates. A profile template can contain one or more certificate templates. The allowance of multiple certificate templates allows common certificate requests to be bundled into a single workflow.

  • Management policies. Each profile template contains multiple management policies. The management policies manage a certificate through its lifetime. For example, separate management policies exist for enrollment, renewal, retirement, and duplication.

  • Profile details. The details of the profile template determine whether certificates included in the profile template are stored in software or on a smart card. The details also include which certification authorities are used for the issuance of certificates.

Note
You can download a beta version of Microsoft Certificate Lifecycle Manager by registering for the beta program at https://www.microsoft.com/clm.

Defining Management Policies

Once you have defined the assurance levels for your smart card certificates, you can then start to define management policies within CLM to enforce the assurance levels. For each stage in the certificate's life cycle, you must decide:

  • What registration model to implement? The registration model will determine how you configure a management policy within a profile template. For example, you may use a centralized registration model for smart card enrollment, a delegated registration model for unblocking the smart card, and self-service for smart card renewal.

  • Who will act as enrollment agents (if required)? The enrollment agent will be able to request certificates on behalf of other users. Typically, this role is assigned to a PKI administrator within the organization.

  • Who will approve requests (if required)? If a request requires approval, who will perform the approval?

  • What data must be collected during the workflow? Depending on the certificate policy used, data may need to be collected. For example, a passport or driver's license number may be recorded during the issuance process.

  • Who will provide the data (certificate manager or certificate subscriber)? Data can be inputted by either the certificate subscriber or by the certificate manager.

Configuring CLM

CLM allows you to configure different workflows for each stage of a certificate life cycle. The goal is to configure CLM so that the workflow matches the policy requirements for your organization.

Creating a Profile Template

A profile template is created by duplicating an existing profile template. As shown in Figure 1, CLM ships with both a sample software certificate and a smart card certificate profile template.

Figure 1. Copying an existing profile template

Figure 1. Copying an existing profile template

Adding Certificate Templates

Once you have created a profile template, the first task is to choose which certificate templates will be issued and managed as part of the profile template. In Figure 2, a custom smart card certificate template, a smart card is added to the profile template.

Figure 2. Defining the certificate templates included in the profile template

Figure 2. Defining the certificate templates included in the profile template

Note
You can add any number of certificate templates to a profile template. The only restriction is that you cannot mix smart card and software certificates within a single profile template.

Configuring Smart Card Properties

CLM must be configured with information regarding the manufacturer and the configuration settings, see Figure 3, for the smart cards you will deploy. Smart card configuration allows you to define which smart card provider is used, initialization and retirement settings, maximum number of certificates, administrator PIN settings, and user PIN settings.

Figure 3. Defining smart card settings

Figure 3. Defining smart card settings

Defining an Enroll Policy

Typically, the first management policy that you define is the enroll policy, to allow the distribution of smart card certificates. It is within the specific management policies where you define your workflow settings.

In the general section, as shown in Figure 4, you configure the general characteristics for the workflow. In this example, a delegated or centralized model is defined where one approval and one enrollment agent is implemented in the workflow.

Figure 4. Defining General Settings for the Enroll policy

Figure 4. Defining General Settings for the Enroll policy

Once the general settings are configured, you must define within the workflow who will initiate, who will approve, and who will act as the enrollment agent for the request as shown in Figure 5.

Figure 5. Defining who will have a role in the enrollment workflow

Figure 5. Defining who will have a role in the enrollment workflow

Note
The role options that must be defined are dependent on the general settings defined for the management policy.

As stated earlier in this article, if you are requiring the presentation of photo identification for the enrollment process, then you must configure data collection. CLM allows you to define what is collected during data collection and who will input the data. As shown in Figure 6, the workflow requires that the certificate manager input the user's driver's license number into the workflow.

Figure 6. Data collection requirements

Figure 6. Data collection requirements

Once you have configured the management policy, the final step is to test the management policy to ensure that the defined workflow matches what your certificate policy requires for enforcement. If there are any issues with the workflow, modify the settings until you meet your requirements.

Conclusion

You cannot rush into a smart card deployment. The policy implications for smart card issuance are huge and must be addressed at the front end of your smart card project. Tools, such as Microsoft Certificate Lifecycle Manager, will greatly assist your deployment by helping enforce the policies that you require for smart card issuance and management.

Note :
This article discusses the initial deployment of smart cards. When you use CLM to deploy smart cards you must also consider workflows for forgotten PINs, lost or forgotten smart cards, the retirement of smart cards, and other events that occur during the lifetime of a smart card certificate.