The Hay Buv Toys Environment

  • Article

This paper is part of a series of white papers known as " The Smart Card Deployment Cookbook. "

On This Page

The Hay Buv Toys PKI Building Blocks
The Hay Buv Toys CA Hierarchy
Hay Buv Toys Registration Authorities
The Hay Buv Toys Pilot Project

The Hay Buv Toys PKI Building Blocks

An important factor in developing a functional Public Key Infrastructure (PKI) is establishing well-defined policies and organizational procedures prior to implementing technologies. Hay Buv Toys (HBT) PKI planning consists of developing procedures and technology. In the first stage, HBT identifies the PKI requirements after specifying the common building blocks for a PKI.

A PKI technology solution must supply PKI back-end and front-end services. Major components of PKI architecture include Certification Authority, Key Generation Center, a Directory Service in the back-end site, and PKI-enabled applications and users in the front-end site. In addition, organizational procedures, such as establishing Registration Authorities, are considered.

The following figure provides an overview of the PKI solution for HBT.

Dd277381.smar0701(en-us,TechNet.10).gif

PKI Back-End Service

The PKI back-end service can be divided into three sub-parts:

  • Registration Authority (RA)

  • Key Generation (KG)

  • Certification Authority (CA)

The main task of the Registration Authority (RA) is to prove the identity of the certificate requestor. This is an organizational process that has to be defined and established by HBT before any certificates are distributed to the employees. All RAs follow the appropriate set of certificate policies. For example, face-to-face registration requires individuals to present photo ID. These policies are defined in a Certification Practice Statement (CPS). A CPS is a comprehensive published document that establishes a legal infrastructure and operational procedures for a Certification Authority (CA).

Key Generation (KG) occurs after the identity of the certificate requestor is successfully proven. A key pair (public key and private key) is generated centrally on behalf of the requestor. The public key is sent to the CA for certification issuance. Private keys are backed up for key recovery purposes.

A CA issues or renews certificates to the requestor, which is either a user or an application. A certificate is a document that is digitally signed by a CA and that ties a particular entity to a specific public key. Other tasks of the CA include backup and restore operations and publishing or revoking certificates.

The KG process for smart cards is similar to the CA process. A smart card can hold more than one key pair, such as a key pair for signing and another one for encryption and authentication. A Signature Lawcompliant smart card contains three different key pairs. The signing key pair is generated on the smart card, whereas encryption and authentication key pairs are generated outside the smart card to support key recovery. Signing key pairs should never become recoverable. After all required key pairs have been generated, the CA issues certificates for the smart cards. Finally, smart cards are personalized with an additional personal identification number (PIN).

PKI Entities

PKI entities are users and machines. These certificates are typically used for authentication, such as in e-mail or e-commerce solutions. These types of certificates belong to the user and contain user-specific attributes, such as e-mail address or user name.

Machine-specific certificates are used for authentication processes in which no user intervention is needed. In Internet Protocol security (IPSec), the tunnel end-points must authenticate one another (mutual authentication) through machine certificates, or domain controller certificates that can enforce and encrypt replication traffic with domain controller (DC) certificates. Machine certificates contain machine specific information, such as machine DNS name. Distribution of certificates to PKI entities can be organized automatically, for instance through Group Policies in a Microsoft Windows 2000 PKI.

Active Directory Service

Certificate and certificate revocation lists are published in Active Directory. This way, HBT users and applications can access and verify the certificates of their counterparts.

The Hay Buv Toys CA Hierarchy

Single CA Model

HBT initially examined a single CA model in respect to simplified administrative tasks. However, the single CA model did not match the current Active Directory design for HBT, and had serious disadvantages and limitations, including:

  • CA key compromise. All BM users are affected in case of a CA compromise. This requires re-enrollment of all certificates and smart cards for every HBT user worldwide.

  • CA availability. If a CA is not available due to a system failure, or prevented as a result of scheduled maintenance tasks, certificates cannot be issued. If additional CAs are made available, the impact is reduced.

  • In a typical centralized model, each RA (established in major HBT locations) has the ability to submit or approve certificate requests to the central CA. This could become a security threat if the RA is compromised. A better approach is to establish a particular CA for each RA, in which case only users of the particular CA are affected.

  • If this model is extended by PKI trust relationships to an external CA, all BM users will automatically trust the external CA.

In conclusion, it is important for HBT to establish a CA hierarchy that better fits its requirements, such as the hierarchy shown in the following illustration.

HierarchyCA Model

Dd277381.smar0702(en-us,TechNet.10).gif

The root of the CA hierarchy is the stand-alone/offline root CA with a self-signed certificate. The entire CA hierarchy is based on Microsoft Certificate Server and Windows 2000.

The main task of the root CA during its lifetime is the certification of the lower-level, or subordinate, CAs. Another task is to renew its self-signed certificate or sub-CA certificates prior to certificate expiration and publishing of revoked CA certificates. The lifetime for the self-signed root CA certificate is 10 years. The lifetime for the sub-CA certificate is four years.

The root CA represents the highest assurance level because all subordinate CAs and certificates depend on the root CA. If the root CA is compromised, all subordinate CAs and issued certificates lose their validity. Therefore, it is crucial that the root CA be secured. One of the first barriers is offline usage that limits any system failures or attacks from the network. Furthermore, additional procedures are required to secure a root CA and other CAs.

Active Directory integration is not required for the stand-alone/offline root CA because of the limited number of issued certificates and CRL renewals (weekly) and operational aspects. The root CA is installed on an isolated computer running Windows 2000 that is not connected to the network. This ensures the independence of the root CA operator from other Windows 2000 administrators and from the enterprise administrator. In the root CA scenario, additional processes have been specified, such as the way in which sub-CA certificates are requested or enrolled on the root CA.

In respect to the current HBT Active Directory design by region, the sub-level CAs are also organized per sales region. The root CA certifies the Policy Certificate Authorities (PCAs) as subordinate CAs. For each HBT region (USWest, USEast, Europe, East Asia, and Partner Customer CA), one PCA is assigned. In summary, four PCA second-level instances exist.

The PCAs are integrated in Active Directory and assigned by the Active Directory domain, as defined in the HBT Active Directory design. By default, users will enumerate the Enrollment Services object in the configuration container of the active directory to locate a CA. It will then select any CA that issues the certificate template that the client is requesting. This could be any CA in the Enterprise. The only way to control this behavior in Windows 2000 would be to not give the users rights to request certificates from the CA. Furthermore, automatic certificate publishing is carried out on a per-domain base. The Regional PCA role is the certification of third-level CAs inside the Active Directory domain. The Regional PCA gives local autonomy to each HBT subsidiary. Therefore, each HBT region is able to determine how many additional CA services should be established below its PCA level.

Below the PCAs, two additional CAs are required for each Active Directory domain. The two CAs are configured depending on the applications they support. A smart card user CA and another CA for user and machine certificates is established. The smart card CA will issue certificates to smart card users. The user/machine CA will issue certificates to users or machines for other PKI applications. Both CAs are responsible for publishing certificates and CRLs in their directories.

Note: Not all applications provide smart card support. For this reason, the user/machine CA will also issue certificates, or soft tokens. For example, Encrypting File System (EFS) or Microsoft Exchange Key Management Server (KMS) are not supported by smart cards.

Partner/Customer User CA

For HBT partners and customers, a separate user CA is planned as a subordinate CA of the root CA, resulting in an integration into the internal CA hierarchy. HBT has plans in the future to provide value-added services to its partners and customers, which is one of the reasons for establishing a separate customer CA. For the purpose of enabling customers and partners to use secured online payment, HBT will provide smart cards with a payment solution on the card. Therefore, an additional project has been initiated to develop a payment application based on Microsoft Windows for Smart Cards.

Hay Buv Toys Registration Authorities

For each HBT sales region related to Active Directory design (USWest, USEast, Europe, and East Asia), at least one RA is established. HBT defined an RA practice to authenticate user identity and acquire all information (user name, e-mail address, organization, and so on) that is needed to issue the certificate.

HBT requires face-to-face registration. HBT's Human Resources department, or any department that issues corporate ID cards, provides RA operations.

Dd277381.smar0703(en-us,TechNet.10).gif

Face-to-face registration in one RA is not suitable because of the geographic size of the HBT regions. Therefore, sub-RAs are introduced that trust and report to the central RA in each region, as shown in the following illustration. Central RAs are established in the regional headquarters (Seattle, New York, London, and Tokyo) in addition to the HBT sales region.

Sub-RAs can register and approve user identity, but are not allowed to submit registration information directly to enrollment or CA operations. All registration information must be submitted only by the central RA. This will limit the trust relationship of enrollment operations to only one RA per region.

Each HBT region contains three different CA types and three different enrollment processes, as shown in the following illustration. The central RA submits registration information to the appropriate CA and enrollment process, depending on the PKI application that will be used and the level of security required by the requestor. For instance, KMS enrollment and the user/machine CA provide Secure/Multipurpose Internet Mail Extensions (S/MIME) enrollment. However, smart card enrollment and the smart card user CA cover a highly secured S/MIME environment.

Dd277381.smar0704(en-us,TechNet.10).gif

The Hay Buv Toys Pilot Project

The Hay Buv Toys pilot project will be addressed in four stages:

  1. Organization

    • Define organizational processes and roles

    • Establish RAs

    • Document a Certification Practice Statement

  2. Pilot in DomainUSWest

    • Identify pilot users and applications

    • Deploy the root CA

    • Deploy the CA hierarchy for the USWest domain

    • Deploy PKI applications for pilot users

    • Evaluate different enrollment strategies for certificates (soft tokens) and smart cards (hard tokens) in relation to mass deployment

    • Review different smart card management tools, such as standard Microsoft smart card tools or enterprise smart card tools from third-party vendors

    • Develop a payment application for customer cards

  3. Early adopter deployment

    • Deploy PKI in the USWest domain

    • Manage smart cards by using standard smart card management tools

  4. Mass deployment

    • Deploy PKI for Hay Buv Toys

    • Manage smart cards by using enterprise smart card management tools from third party vendors, such as GemPlus or Schlumberger

The HBT pilot environment is shown in the following illustration.

Dd277381.smar0705(en-us,TechNet.10).gif

Microsoft Enterprise Services

Jung-Uh Yang: MCS Germany

March 2001

For information about Enterprise Services, see https://www.microsoft.com/es/.

Companies, organizations, products, people, and events depicted in examples in this paper are fictitious. No association with any real company, organization, product, person, or event is intended or should be inferred.