Smart Card Deployment Cookbook

My Collection
This document is provided "as-is". Information and views expressed in this document, including URL and other Internet Web site references, may change without
notice. This document does not provide you with any legal rights to any intellectual property in any Microsoft product or product name. You may copy and use
this document for your internal, reference purposes. You may modify this document for your internal, reference purposes. 2012 Microsoft. All rights reserved.
Terms of Use (http://technet.microsoft.com/cc300389.aspx) | Trademarks (http://www.microsoft.com/library/toolbar/3.0/trademarks/en-us.mspx)
Table Of Contents
Chapter 1
Overview
Introduction to Windows for Smart Cards
Smart Card Concepts
Smart Cards and the Windows 2000 PKI
Running a Windows 2000 PKI Project
Logistics of Smart Card Deployment
Welcome to Hay Buv Toys
The Hay Buv Toys Environment
Deploying the PKI
Deploying Smart Cards
Deploying PKI-Enabled Applications for Smart Cards
Developing Applications for Windows for Smart Cards
Chapter 1
Overview
Typically, a cookbook is a collection of recipes, or instructions, that explain how to do something and what you need to do it. This "cookbook" is a set of
"recipes" for deploying smart cards in an enterprise that is deploying Microsoft Windows 2000 Active Directory. The white papers in this series will help
you understand the principal smart card concepts and guide you through the planning tasks.
The cookbook is divided into three sections:
On This Page
About This Cookbook
Who Should Read This Series
Section 1: Smart Card Backgrounder
Section 2: Smart Card Deployment Planning Considerations
Section 3: Smart Card Deployment Scenario
Related Materials
About This Cookbook
The papers in this section are designed to provide you with a foundation for your understanding of smart cards. It covers such topics as how smart
cards have been used in organizations, smart card architecture in Microsoft Windows 2000, smart card application development, and public key
infrastructure (PKI) requirements for deploying smart cards, for example, for smart card logon. By the end of this section you will be able to build a case
for deploying smart cards in your organization based on:
An understanding of the ways in which the initial investment in deploying cards and readers can be leveraged to deploy a range of useful smart
card applications.
An understanding of the smart card features shipped "in the box" with Windows 2000.
An understanding of the infrastructure components necessary to deploy smart cards for smart card logon.
Section 2: Smart Card Deployment Planning Considerations.
The papers in this section provide you with the building blocks that allow you to start planning your smart card deployment, by setting out the kind of
considerations to bear in mind. This includes factors such as:
Your network infrastructure and administration model
The basic considerations for planning a PKI
The details of planning the actual deployment
Section 3: Smart Card Deployment Scenarios.
The papers in this section describe a detailed deployment scenario that uses a fictitious company, Hay Buv Toys, as an example of an organization
planning smart card deployment. The section begins with a description of Hay Buv's current environment and its smart card deployment goals, then sets
out their desired deployment environment. This section takes you through processes such as:
Deploying the PKI
Deploying smart cards
Deploying PKI-enabled applications for smart cards
Developing applications for Windows for Smart Cards
Top Of Page
Who Should Read This Series
This deployment cookbook addresses the concepts behind deploying smart cards, the steps that are necessary to plan a successful deployment, and
some of the tools that deployment requires. Therefore, it will be of use to the following people:
Network engineers
System architects
Consultants
Top Of Page
1
This white paper covers the add-on value of using smart cards in the enterprise.
Business opportunities
Higher level of security
Legal aspects and how smart cards will adopt digital signature laws
Smart Card Concepts
2
This white paper covers basic smart card information, such as the following:
What is a smart card? This covers the different form factors, etc.
What can you do with a smart card? This covers some examples of uses for smart cards, i.e., stored value, credential storage, etc.
Windows Smart Card Subsystem:
PC/SC v1.0: what it is and why it's relevant.
ISO 7816: what it is and why it's relevant.
Why do cards differ from each other, e.g., GemPlus, Schlumberger?
Descriptions of the components in the architecture, i.e., readers, drivers, resource manager.
Support in Windows platforms, i.e., the files shipped in the box or downloaded, driver and card coverage in all Windows platforms.
3
This white paper begins tying the concepts together.
What are the requirements for using smart cards to log on, sign e-mail, etc.?This includes discussion of the need to deploy a CA infrastructure.
What is enrollment? This covers what is involved in enrollment from a software perspective, i.e., the necessary templates, the enrollment station,
how it interacts with the CSP, etc.
What is smart card logon? This covers what is involved in logging on to the domain, how Winlogon and GINA interact, how Kerberos authentication
fits in, UPNs, etc.
What is e-mail signing/encryption? This covers what is involved in signing/encrypting e-mail.
Top Of Page
Section 2: Smart Card Deployment Planning Considerations
4
This white paper covers the typical considerations involved in planning a PKI:
Hierarchy
External root CA or self-signed
What's online and what's off-line
Enterprise CAs
Interoperability with non-Microsoft CAs
The kinds of tools you might use
5
This white paper covers the typical considerations involved in planning a smart card deployment.
The kinds of card management tools you might need
Logistical processes, i.e., the kinds of steps you might want to have in place to verify identity for enrolment
The enrollment station vs. other approaches
Tracking cards throughout their lifecycle
Multi-application cards, i.e., logo n plus an application
Escrow issues
Smart card-related issues wrt interop, i.e., non-Microsoft CAs
Top Of Page
Section 3: Smart Card Deployment Scenario
6
This white paper outlines the existing Hay Buv Toys Windows NT infrastructure and describes some of the issues being faced by this fictitious company in
this scenario.
7
This white paper describes the PKI that is planned, based on the factors described in thefirst white paper in this section, together with an outline of the
procedures that will be adopted to deploy smart cards. This paper covers the stages of the project and what is involved at each stage:
Pilot
Early adopter deployment
Phased mass deployment
Deploying the PKI
8
This white paper is a walkthrough that describs deploying the PKI step-by-step, describing the test requirements at each stage.
9
This white paper is a walkthrough that describes the steps and highlevel processes that are necessary for deploying smart cards, starting with a pilot,
etc., and describing the test requirements at each stage.
10
This white paper is a walkthrough that describes the steps for developing PKI applications such as S/MIME, VPN, SSL, or Windows Logon and how to
enforce them with smart cards.
11
This white paper is a walkthrough that describes the steps for developing applications that are based on Windows for Smart Cards by using Visual Basic.
Sample Visual Basic source code is provided for the Hay Buv Toys scenario.
2012Microsoft.Allrightsreserved.
Top Of Page
Related Materials
The following document provides additional information about migration:
Microsoft Windows 2000 Deployment Planning Guide (available at
http://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp
12
)
Top Of Page
Links Table
1
http://www.microsoft.com/technet/security/guidance/identitymanagement/smrtcdcb/sec1/smartc01.mspx
2
3
4
5
6
7
8
9
10
11
12
http://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp
This paper is part of a series of white papers known as " The Smart Card Deployment Cookbook
1
."
On This Page
Introduction
Advantages of Windows for Smart Cards
Protection
Productivity
Profit
Promotion
Smart Card Deployment
Introduction
In the past few years, telecommuting, the Internet, and electronic commerce have developed from an alternative means of doing business to become
increasingly mainstream consumer activities. Several years ago, a Web address on a business card was comparable to a secret handshake that gains you
admittance to an exclusive club. Now, advances in software functionality and hardware speed, along with the power of word of mouth, have made the
Internet and all its offshoots the "next big thing" for commerce, communication, and entertainment. Unfortunately, growing in lock step with the boom in
network and communication technology are the proliferation of multiple user IDs and passwords, the proficiency of computer hackers, and the occurrence
of credit card fraud and identity theft.
The family of Microsoft Windows operating systems is designed for the emerging world of connected commerce and far-flung networks. By incorporating
the same widely used software development tools from the desktop and the back office, Windows scales from the smallest networks - the smart card -
to the largest enterprise network, enabling customers to run their businesses complete with multiple networks, remote users, electronic commerce, credit
card payments, and Web sites. The newest member of the Windows operating system family, Windows for Smart Cards extends the benefits of the
Windows environment to the smart card industry.
Top Of Page
Advantages of Windows for Smart Cards
A Windows Powered Smart Card is a microcomputer without a graphical user interface. According to Gemplus, a leading smart card manufacturer,
companies have reduced their technical support calls by 40 percent by implementing smart cards that perform automatic authentication, previously an
error-prone manual process. , Microsoft is working closely with smart card industry leaders such as Gemplus to developing its smart card technology to
the highest performance and security standards in the enterprise. At the same time, Microsoft is integrating smart card technology with Windows-based
architectures to facilitate ease of application development."
At a price of approximately $20 per card reader and a maximum of $5 per card, Windows Powered Smart Cards are an inexpensive way to strengthen
your corporate security. Even when the cards are implemented only for security reasons, your business still benefits from the multitude of other functions
that Smart Card facilitates. These services include payment functionality and storage of loyalty information, medical and citizen information, and personal
contacts.
The Windows Powered Smart Card can enhance your existing corporate network; there is no need to replace the existing system infrastructure. Windows
for Smart Cards works with the Microsoft Windows 95, Windows 98, and Windows NT 4.0 operating systems, and will be optimized for Windows 2000.
Windows Powered Smart Cards can be customized for each user, And they can be programmed with multiple keys. The cards can be used to log on to a
PC or to one or more networks and to perform remote logons. By storing all of a user's authentication information, one Windows Powered Smart Card can
gain for a user admittance to all of his or her accounts - on the corporate network, within Internet chat rooms, or within financial institutions.
Therefore, Windows for Smart Cards used with one or more of the Microsoft Windows operating systems can enhance protection, improve productivity,
increase profit, and facilitate promotion.
Top Of Page
Protection
Corporate computers generally are configured to require a form of authentication for logon purposes. Password authentication, the most widely used
logon security mechanism, is only as infallible as its users. Users often share their personal passwords with friends and spouses. Even the most reliable
user may write a password on a slip of paper where another user might later discover it. If a user does not safeguard a password, the network may be
subject to concurrent usage of a user account or worse, may be unprotected against malicious break-ins.
A Windows Powered Smart Card can be used by only one person at a time, which makes concurrent account usage impossible. Because the card is
required to access the network, users are inclined to carry the card with them wherever they go, preventing malicious break-ins. Windows for Smart
Cards supports multiple authentication mechanisms, such as PIN, fingerprint, or retina recognition. Your company can determine the method or methods
that work best for you.
If the card is lost, no one else can use it to access the network because only the owner knows the PIN or has the fingerprint or retina to match the
authentication account. Information and account balances are not lost if the card is lost because a user's information is replicated on each card
partner's server. When a replacement card is activated and inserted into the card partner's network, the information is transferred to the new card.
Like a bank or credit card, if a Windows Powered Smart Card is lost or stolen, an 800 number can be used to turn off the card and activate the issuance
of a new card. Unlike a bank or credit card, a Windows-powered smart card can be produced at a branch office for quicker turnaround.
By using the most secure crypto-algorithms, such as RSA, DES, 3DES and SHA and by being built on the most reliable chips, Windows Powered Smart
Cards are virtually inviolable.
Top Of Page
Productivity
Windows for Smart Cards ensures a consistent experience for application developers and end users. Application developers can use development and
debugging tools with which they are already proficient, such as Microsoft Visual Studio, to create applications for Windows Powered Smart Cards.
Additionally, developers save time by using the Microsoft Windows Smart Card Toolkit to write applications. Unlike tools that differ from vendor to vendor,
Windows for Smart Cards is a logical extension of the Windows operating systems and provides a consistent development and run-time environment. By
using the Windows Smart Cards Toolkit with the Windows operating systems, developers can write and debug many diverse applications in the same
amount of time it would have taken to port one application to many diverse operating environments.
Windows Powered Smart Cards can be used with the Windows operating systems to store personal contact information. By using the cards as a
companion to the Microsoft Outlook messaging and collaboration client, you can transfer the names, e-mail addresses and phone numbers of business
associates from a PC or network to the card. You can slip the card into your pocket or wallet; then, miles and time zones away, you can insert it into
another computer running a Windows operating system. Instantly, your Outlook information is accessible.
With the appropriate hardware, Windows Powered Smart Cards can be used to call a contact at the touch of a button, obtain a street address while
driving, or exchange contact information with another user of Outlook. And, unlike e-mail attachments or floppy disks, the smart cards are tamper-
resistant, making them resistant to viruses, physical modification, or any other type of unauthorized access.
In fact, physical defenses are built into the hardware of a Windows Powered Smart Card. It uses the software protection strategy of the access control
list (ACL), enabling information to be retrieved from the card only if certain known principles (requester's identification, computer identification, time of
day) match information stored in the ACL. In addition, these smart cards utilize an MS-DOS-type file system so that applications from different vendors
are stored separately. Vendors, therefore, cannot obtain information that does not pertain directly to their application from a card. ACL and file
partitioning, together with security libraries and mathematical algorithms, work in tandem to protect these smart cards from unauthorized users and the
most invasive tampering. If the card is tampered with in any way (consecutive incorrect PIN entries, electron microscope, sawing open), it implodes,
rendering it useless.
Windows Powered Smart Cards can be used to store medical information and citizen accounts. Pharmacies can check a patient's card to verify that the
patient isn't taking medication that may interact negatively with a new prescription. By using Windows Powered Smart Cards, a doctor's office can bill
insurance companies at the time of treatment, eliminating copious paperwork and speeding the payment of charges. Furthermore, Windows Powered
Smart Cards also can be used to help distribute food stamps, store traffic violations, and verify a consumer's age for tobacco and alcohol purchases.
Vendors of Windows Powered Smart Cards can use standard Windows-based APIs to customize the amount and type of information stored on a card. For
those loath to store their personal information on a card that could be lost, the card can be configured as an identification mechanism only. In this case,
medical and citizen information resides on an agency's server, and the user's Windows Powered Smart Card acts as the identity key.
Top Of Page
Profit
With the adoption of e-commerce by the masses, fraud activity has increased dramatically. Stolen credit card numbers are used to purchase goods and
services on the Internet, where signatures are not required to prove identity. Underage users can access information and entertainment that is intended
for more mature audiences. With Windows for Smart Cards, a Web site administrator can ascertain the identity of a user signing in to a chat room to
ensure the safety of patrons. In addition, administrators of Web sites that contain adult content can ensure that only the intended audience views the
material.
Internet merchants can implement Windows Powered Smart Cards to obtain a digital signature when goods and services are purchased. Such a digital
signature would protect financial institutions as well, ensuring that only a card's owner can make purchases with the card. Windows Powered Smart
Cards can be used in lieu of a bank or credit card in traditional purchasing scenarios as well. By writing a financial application and storing it on the card, a
vendor can determine the payment method. Financial institutions can write applications for Windows Powered Smart Cards that store a prepaid value,
deducting from it as purchases are made. Alternatively, applications for Windows Powered Smart Cards can be written with the same Windows-based
APIs developers already use to interact with a server-side automatic billing program.
Top Of Page
Promotion
Windows Powered Smart Cards can be used much like a credit card to advertise your business and your corporate partners. You can also store loyalty
information, such as airline miles and past purchase amounts, directly on the card. Or you can issue Windows Powered Smart Cards to your customers
and sell advertising space on them.
Unlike a credit card, however, Windows Powered Smart Cards are read-writable. When your company's strategic alliances change, you don't need to
manufacture more cards; instead, you can change the advertisements and loyalty information on the cards you have already issued.
Top Of Page
Smart Card Deployment
How to deploy Windows for Smart Cards is discussed in the remainder of this series of white papers. One group of these papers sets up a "real-world"
scenario that illustrates the planning and deployment process.
Microsoft Enterprise Services
Mike Dusche, Program Manager, Microsoft Windows Powered Smart Cards
March 2001
For information about Enterprise Services, see http://www.microsoft.com/es/
2
.
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.
Top Of Page
Links Table
1
http://www.microsoft.com/technet/security/guidance/identitymanagement/smrtcdcb/default.mspx
2
http://www.microsoft.com/es/
Smart Card Concepts
1
."
On This Page
Introduction
What Is a Smart Card?
Strategy for Supporting Smart Cards
Smart Card Support in Microsoft Products
Introduction
This paper covers the key technical concepts of smart cards. The purpose is to provide readers with a foundation for understanding the aspects of
planning and deployment that are covered in later papers.
After reading this paper, you should be able to answer the following questions:
What is a smart card?
What is Microsoft's strategy for supporting smart cards?
How do Microsoft products support smart cards?
Top Of Page
What Is a Smart Card?
Most people have an image of smart cards as rectangular pieces of plastic that resemble credit cards. Although this is often the case, smart cards can
take several forms, including:
Credit cards
Key-shaped tokens
SIM chips in GSM cellular phones
Smart cards contain a built-in processor and are programmable. Smart cards have secure storage for data, including private keys and public key
certificates.
Smart Card Processing Capabilities
Today's smart cards contain 8-bit micro controllers and hold a minimum of 4KB of information. While the card has processing capability, it must be
connected to a PC device to be useful for purposes such as smart card logon to a Microsoft Windows 2000 domain. This connection is achieved by
placing the card in a smart card reader that is connected to the computer. There is another type of smart card, called a contactless card, that transfers
data over radio waves. At this time, however, this type of card is not covered by the PC/SC specification that defines smart cards and readers
integrated with Windows.
Smart Card Programmability
Smart cards run embedded operating systems, such as Microsoft Windows for Smart Cards, and in many cases a form of file system in which data can be
stored. For features such as Windows 2000 smart card logon, the smart card must be programmable so that it can:
Store a user's key pair.
Store an associated public key certificate.
Retrieve the public key certificate.
Complete private key operations on behalf of the user.
Increasingly, smart cards are generating the key pairs automatically.
Secure Storage
A key feature of smart cards is that they provide secure storage for data. Smart cards must support authentication and authorization: the card holder is
authenticated through a Personal Identification Number (PIN) or other mechanism, and can be authorized to access only particular data on the card, or
carry out a particular range of activities with the card.
Top Of Page
Strategy for Supporting Smart Cards
Microsoft views smart cards as a key component of its Public Key Infrastructure (PKI) support. Smart cards enhance software-only solutions, such as
client authentication, interactive logon, and secure e-mail. Smart cards are a point of convergence for public-key certificates and associated keys
because they:
Provide tamper-resistant storage for protecting private keys and other forms of personal information.
Isolate security-critical computations involving authentication, digital signatures, and key exchanges from other parts of the system.
Enable portability of credentials and other private information between computers at work, at home, or for mobile users.
Smart cards will be increasingly integrated with the Windows operating system for future releases. Ultimately, any operation that currently requires a
password can be enabled to use a smart card.
Approach to Supporting Smart Cards
Microsoft encourages the adoption and use of smart cards for several reasons, including:
Hardware interoperabilityEncourageastandardmodelforinterfacingsmartcardreadersandcardswithcomputers.
Application interoperabilityProvidereaderandcardindependentAPIsforenablingapplicationsthatsupportsmartcards.
Developer supportProvidefamiliartoolsforsoftwaredevelopment.
Universal support for WindowsProvidesmartcardsupportforallWindowsoperatingsystems.
Hardware Interoperability
The emergence of a standard model that determines the way in which readers and cards interface with a computer enforces interoperability among cards
and readers from different manufacturers. In the past, lack of interoperability has been a major reason for the slow adoption of smart cards outside of
Europe.
The main standard in the area of smart card and reader interoperability is the International Standards Organization (ISO) 7816 standards for integrated
circuit cards with contacts. These specifications focus on interoperability at the physical, electrical, and data-link protocol levels. These standards have
been incorporated into the following key initiatives:
Europay, MasterCard, and VISA (EMV)In1996,EMVdefinedanISO7816basedsmartcardspecificationwithafocusonthefinancialservices
industry.
Global System for Mobile Communications (GSM)TheEuropeantelecommunicationsindustryadoptedtheISO7816standardsfortheirsmart
card specification to enable identification and authentication for mobile phone users.
Although these specifications were a step in the right direction, each was either too low-level or application-specific to gain widespread support, and
failed to address application interoperability issues. The PC/SC Workgroup was formed in 1996 by computer and smart card companies including Microsoft,
Hewlett-Packard, Schlumberger, and Gemplus, to develop specifications that address these issues.
Version 1.0 of the specification was released in December of 1997 and has gained broad industry support. Microsoft assisted by releasing the smart card
base components for free Web download for Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Millennium Edition (Me) and Microsoft
Windows NT 4.0. The smart card components are included with Windows 2000.
Application Interoperability
Device-independent APIs insulate application developers from differences between current and future implementations. From the perspective of the
application developer, there are three possible mechanisms for programming to smart cards:
The Microsoft Win32 API
CryptoAPI
SCard COM
The mechanism chosen depends on the type of application and the capabilities of a specific smart card.
Win32
Win32 APIs are the base-level APIs for accessing smart cards. Effective use of Win32 APIs requires a thorough understanding of the Windows operating
system and smart cards. These APIs provide the most flexibility for the application to control readers, cards, and other related components. For
developers that require maximum control over the way in which an application uses smart cards, this extension to the base Win32 API provides the
necessary interfaces for managing interactions with smart card devices.
CryptoAPI
CryptoAPI is the Microsoft cryptographic API. CryptoAPI is designed to abstract the details of cryptographic functionality, such as encryption algorithms,
so that applications can utilize "pluggable" cryptography. This is achieved by layering the APIs above replaceable cryptographic modules called
Cryptographic Service Providers (CSPs). CSPs can be software-only or they can be part of a hardware-based solution in which the cryptographic engine
resides on a smart card, or another piece of hardware that is attached to the computer.
In the Microsoft model for accessing smart cards, a smart card CSP is associated with a specific type of smart card, providing the mapping between
cryptographic functions exposed through CryptoAPI and the low-level commands accessible through the Win32 smart card APIs. Therefore, the smart
card CSP can instruct the smart card to complete specific cryptographic operations. In Windows 2000, Microsoft provides two smart card CSPs to
support a variety of Gemplus and Schlumberger smart cards. Other vendors have developed smart cards CSPs for their own smart cards.
SCard COM
SCard COM is a non-cryptographic interface implementation provided by Microsoft for accessing generic smart card-based services from applications that
are written in different languages, such as C, Microsoft Visual C++, Java, and Microsoft Visual Basic.
SCard COM exposes the non-cryptographic services of a smart card to an application through service providers that support specific interfaces. A smart
card interface consists of a predefined set of services, the protocols necessary to invoke the services, and any assumptions regarding the context of
the services. This is similar in concept to the ISO 7816-5 Application Identifier, but differs in scope.
A smart card can register support for an interface through association with the interface's globally unique identifier (GUID). This binding between a card
and an interface is done when the card is first introduced to the system, typically when the service provider is installed. After the card is introduced to
the system, applications can search for smart cards based on a specific interface or GUID. For example, a cash card could be available to Windows-
based applications by registering interfaces to access its purse scheme.
As part of the Smart Card Base Components 1.0 release, Microsoft shipped several base-level service providers for performing generic operations, such
as card location, command and reply APDU (Application Protocol Data Unit) management, and card file system access. The service providers supplied by
Microsoft are implemented as COM interface objects to enable software developers and card providers to develop higher-level service providers and
applications.
The software developer can use standard development tools, such as Visual C++ and Visual Basic, to develop applications and service providers that are
enabled for smart cards.
Developer Support
Support for CryptoAPI, Win32, and especially SCard COM enables the development of smart card and reader-independent applications and service
providers. These applications and service providers are enabled for smart cards by using standard development tools, such as Visual C++ and Visual
Basic.
Universal Support for Windows
As previously mentioned, Microsoft Smart Card Base Components 1.0 is available for free Web download for Windows 95, Windows 98, Windows Me, and
Windows NT 4.0. Support is also available in Microsoft Windows CE 3.0. Integration of the base components in the Windows 2000 operating system
enables support for public-key services, such as logon.
Top Of Page
Smart Card Support in Microsoft Products
This section covers the architecture of the smart card subsystem, and smart card features in Windows 2000.
Smart Card Subsystem Architecture
The smart card subsystem consists of the following components:
ServiceProvidersSmartcardCSPsandSCardCOMserviceproviders
Resource Manager
Device Drivers
Reader Driver Library
Service Providers
All smart cards must have at least one service provider in order for Windows-based applications to access card-based services. There can be multiple
service providers depending on the type of card and the card issuer. In general, there are two categories of service providers: cryptographic and non-
cryptographic.
Resource Manager
The smart card Resource Manager runs as a trusted service in a single process. All requests for smart card access are routed through the Resource
Manager and then to the smart card reader that contains the requested card. Therefore, the Resource Manager is responsible for managing and
controlling all application access to any smart card inserted into any reader that is attached to a Windows-based computer. The Resource Manager
provides a given application with a virtual direct connection to the requested smart card.
The Resource Manager performs three basic tasks in managing access to multiple readers and cards. First, it identifies and tracks resources. Second, it
controls the allocation of readers and resources across multiple applications. Finally, it supports transaction primitives for accessing services available on
a specific card. This is important because current cards are single-threaded devices that often require execution of multiple commands to complete a
single function. Transaction control allows multiple commands to be executed without interruption, ensuring that intermediate state information is not
corrupted.
Device Drivers
A device driver for a specific reader maps the functionality of the reader to the native services provided by the Windows operating system and the smart
card infrastructure. The reader device driver communicates card insertion and removal events to the Resource Manager and provides data
communications capabilities to and from the card by either the T=0 or the T=1 protocols.
Reader Driver Library
A common driver library is included with Smart Card Base Components 1.0 for use by developers to simplify device driver development. This shared library
supports ISO 7816 and common system functions required for data communication between a smart card and a reader. This is a significant improvement
over how smart card reader device drivers were developed in the past because there are now standard interfaces for developers to rely upon. These
common interfaces enable a smart card reader device driver to be developed in a uniform manner and be accessible to all Windows applications, as
opposed to only a select few applications that know how to communicate with a specific reader.
Smart Card Features in Windows 2000
By enhancing software-only solutions such as client authentication and secure messaging, smart cards in Windows 2000 enable applications for future
opportunities in the emerging global digital economy. Smart cards offer application developers a secure mechanism for enhancing solutions for enterprise
and the consumer.
Client Authentication
Client authentication involves identification and validation of a client to a server to establish a secure communications channel. A secure protocol, such
as Secure Sockets Layer (SSL) or Transport Layer Security (TLS), is typically used in conjunction with a trusted public-key certificate that is provided
by the client. This certificate identifies the client to the server. For example, the client could be Microsoft Internet Explorer running on a Windows
operating system, and the server could be Internet Information Server or another Web server that supports SSL/TLS.
The secure session is established by using public-key authentication with key exchange to derive a unique session key that can then be used to ensure
data integrity and confidentiality throughout the session. Additional authentication can be achieved by mapping the certificate to a user or group
account with previously established access-control privileges. The smart card enhances the public-key authentication process by serving as a secure
store for the private-key material, and as a cryptographic engine for performing a digital signature or key-exchange operation.
Public Key Interactive Logon
In the past, interactive logon meant the ability to authenticate a user to a network by using a form of shared credential, such as a hashed password.
Windows 2000 supports public-key interactive logon by using a X.509 version 3 certificate stored on a smart card with the private key. Instead of a
password, the user types a Personal Identification Number (PIN) to the Graphical Identification and Authentication (GINA), and the PIN authenticates the
user to the card.
The user's public-key certificate is retrieved from the card through a secure process and verified to be valid and from a trusted issuer. During the
authentication process, a challenge based on the public key contained in the certificate is issued to the card. This challenge verifies that the card in
possession of and can successfully use the corresponding private key.
After successful verification of the public-private key pair, the user's identity contained in the certificate is used to reference the user object stored in
the Active Directory to build a token and return a Ticket-Granting Ticket (TGT) to the client. Public key logon has been integrated with the Microsoft
implementation of Kerberos version 5 that is compatible with the public-key extension specified in the IETF draft RFC-1510.
Secure E-mail
Secure e-mail is one of the more exciting public-key-enabled applications because it allows users to share information confidentially and to trust that the
integrity of the information was maintained during transit. By using Microsoft Outlook Express or Microsoft Outlook, a user can select a public-key
certificate issued by a trusted certificate authority to use for digitally signing and decrypting secure messages. By publishing the user's certificate to a
public directory in the enterprise or on the Internet, other users in a company or on the Internet can send encrypted e-mail to the user, and visa-versa.
A smart card adds a level of integrity to secure e-mail applications because it stores the private key on the card, protected by a PIN. To compromise the
private key and send signed e-mail as someone else, the user would have to obtain the smart card and PIN.
Glenn Pittaway: Program Manager, Microsoft Security
March 2001
2
.
Java is a registered trademark of Sun Microsystems.
Top Of Page
Links Table
1
2
1
."
On This Page
Introduction
Enhanced Security with Smart Cards
Smart Card Logon Requirements
Smart Card Logon and Authentication
E-mail Signing and Encryption
Sending Encrypted E-Mail with Smart Cards
Introduction
This paper covers security related issues with respect to deploying smart cards in a Windows 2000 environment.
After reading this chapter, you should have a clear understanding of the following topics:
Hardware and software requirements for smart card deployment
Enrollment processes for smart card users
Client authentication and logon with smart cards
E-mail signing and encryption
Top Of Page
Enhanced Security with Smart Cards
In a secure network environment, data cannot be accessed or modified by people who do not have rights to the information. Unfortunately, options for
securing an enterprise network until now have been limited. Typically, organizations have relied on a password authentication system to protect their
digital assets. The weaknesses of such a system are numerous: users choose simple passwords that are easy to hack; administrators engage in
password fraud; passwords are shared and then stolen, and so on.
Now, in a Windows 2000 environment, you can use smart card technology to protect your network, instead of relying on password protection. Smart
cards provide tamper-proof storage for a user's key pair and an associated public key certificate. These symmetric and asymmetric keys are protected
through a PIN (Personal Identification Number) that the user has to type in when a key or a certificate on the smart card is required.
Furthermore, when you deploy smart cards in a Windows 2000 environment, you can leverage operating system features such as Kerberos and S/MIME to
increase security in relation to authentication, e-mail encryption, and key exchanges.
Top Of Page
Smart Card Logon Requirements
Before implementing a smart card logon in your enterprise, make sure your network meets the following system requirements.
Required Hardware
The PC/SC Workgroup has developed specifications for interoperability between readers and smart cards. Microsoft Windows 2000 supports any smart
card reader that is PC/SC compatible. For a complete list of supported smart card readers, see the hardware compatibility list at
http://www.microsoft.com/hcl
2
.
Note: Every smart card reader and/or coupler is usually a smart card writer. With this functionality, you can use a generic smart card reader to write
certificates to a smart card.
Required Software
In a Windows 2000 environment, you must have a Windows 2000 Server product with the following software components installed:
The Certificate Authentication Service. With this service, Windows 2000 can create certificates that can be installed on the smart card. A
Windows 2000 server running this service is called a Certificate Authority (CA).
MicrosoftActiveDirectory.ThisistheWindows2000LDAPV3compliantdirectoryservicewherethecertificatesarestored.
A Cryptography Service Provider (CSP). This facilitates communication between the device and the smart card. The CSP must be signed by
Microsoft,oritwillnotworkonWindows2000.Typically,aCSPisprovidedbythemanufactureroftheSmartCardReaderforexample,aGemPlus
reader would use a GemPlus CSP, a Schlumberger CSP would use the Schlumberger CSP, and so on.
You also must have Windows 2000 installed on the client because only Windows 2000 uses a PC/SC-compliant smart card reader with Kerberos as the
authentication protocol.
Required Enrollment Processes
In the enrollment process, a certificate is issued on a smart card. In Windows 2000, Smart Card Enrollment Control enables administrators to obtain
certificates for smart card users, rather than each user enrolling for smart card certificate. Enrollment is independent from the PKI design.
During a typical enrollment process, the enrollment agent writes the certificate on a user's smart card. The enrollment agent then becomes a member of
the Certificate Requester Group in Windows. The following conditions must be met for successful enrollment:
The enrollment agent must have an enrollment agent certificate.
The CA has to be online while the user is enrolled.
The CA needs to be trusted in the CA hierarchy.
The appropriate CA needs to be configured to issue certificates for smart card logon and for the smart card user if the user will be encrypting and
signing e-mail.
Top Of Page
Smart Card Logon and Authentication
This section describes the recommended authentication protocol for smart card logon and the logon process.
Kerberos Authentication Protocol
The Kerberos protocol is the primary authentication mechanism in the Microsoft Windows 2000 operating system. At the heart of the protocol is a trusted
server called a Key Distribution Center (KDC). When the user logs on to the network, the KDC verifies the user's identity and provides credentials called
"tickets", one for each network service that the user wants to use. Each ticket introduces the user to the appropriate service, and optionally carries
information that indicates the user's privileges for the service.
Microsoft's implementation of the protocol uses extensions to enable smart card logon. This provides the twin advantages of strengthening the
authentication process and providing seamless entry into the public key infrastructure. Smart card logon only works with Kerberos; you cannot use
NTLM, the authentication method of Windows NT 4.0 and earlier versions of Windows NT, for smart card logon.
Typically, Kerberos uses Symmetric Key encryption. The certificate on the smart card, however, is based on asymmetric public key encryption.
For more information about using Kerberos in the Windows 2000 environment, see: http://www.microsoft.com/windows2000/
3
Smart Card Logon
Windows 2000 uses a layered approach for local and domain logon as illustrated in the following diagram.
4
The smart card logon process includes the following steps:
1. After the user inserts his or her smart card, Windows Logon Service (WINLOGON) dispatches this event to MSGINA. The window below displays.
2. The user is prompted to enter a PIN (rather than a user name and password).
3. MSGINA sends the PIN to Local Security Authority (LSA).
Note: There is no logon domain information required, because the user is logged on with a Unified Principal Name (UPN).
4. The LSA uses the PIN to access the smart card and extract the certificate with the user's public key.
5. The Kerberos security service provider sends the signed user's certificate with the user's private key to the Key Distribution Center (KDC).
6. The KDC compares the UPN (user principal name) in the certificate with the UPN on the user object in the directory. The KDC also verifies the
signature on the certificate to ensure that it was issued by a Certificate Authority that is trusted in the Active Directory forest such as an
Enterprise CA.
7. The KDC encrypts the logon session key and the Ticket Granting (TGT) for the Ticket Granting Service with the Public Key from the client
certificate. This ensures that only the client with the appropriate private key can decrypt the logon session key.
8. The client decrypts the logon session key and presents the TGT to the ticket granting service. After this process is complete, all other
communication in Kerberos uses symmetric encryption.
5
Top Of Page
E-mail Signing and Encryption
This section describes message encryption using secured multipurpose Internet mail extension (S/MIME) and explains how Smart Card Enrollment Station
utilizes S/MIME to encrypt messages.
Message Encryption
S/MIME is a popular protocol used for message encryption and signing. Microsoft e-mail clients (Microsoft Outlook 98, Outlook 2000, and Outlook Express)
and Microsoft Exchange support S/MIME. This security option provides for a completely opaque message body and signature. It generates a one-time
symmetric key and encrypts it in the recipient's public key, so that only that specific key owner can decrypt it, and then sends the message. On the
recipient end, the private key is used to decrypt the symmetric key, which is then used to decrypt the message. This process is transparent to the user.
It is performed with no interaction between client and additional network services except for a directory query to obtain the recipient's public key. The
following diagram shows the encryption and decryption process.
6
Digital signatures
When a digital signature is added to a message, the message contents are used to compute a hash value that identifies the sender and serves as a
"digital fingerprint" that verifies the message has not been altered in transit. A message digest algorithm, the message contents, and the sender's private
key are used to generate the hash value. The recipient decrypts the original hash value with the sender public key, which is readily obtainable from a
trusted directory, such as the Active Directory, or may optionally be sent with the signed message. The message is decrypted, and then a new hash
value is computed from the received text and compared to original hash value. If they match, the contents and the sender's identity are verified. The
following diagram illustrates this process.
7
Smart Card Enrollment Station
The Smart Card Enrollment Station is a Web-based application that provides smart card enrollment for S/MIME. The station is part of the Web client that
will be installed during setup of the Window 2000 Certificate Service. By default, the Web client is installed on every CA. (A separate Web client exists
for the Enterprise and standalone CAs.) Alternatively, the Web client can be installed on a separate Windows 2000 server with Internet Information
Services (IIS)..
Smart card enrollment is more complex than the Key Management Service enrollment in Exchange 5.5. The client initiates the enrollment process. All key
pairs are generated by the smart card, in contrast to the Exchange 2000 KMS enrollment process, where encryption key pairs are generated within Key
Managementserverandsigningkeypairsaregeneratedinthemailclientsite.Therefore,keyrecoveryisnotprovidedwithsmartcardsprivatekeysare
never revealed in smart cards.
Before enrolling users, appropriate rights must be set for the smart card enrollment operator to IIS/Certificate Services and also to the Certificate
Templates in Windows 2000. The smart card user needs logon, client authentication and secure mail access, and the SC enrollment operator needs
access to the Enrolment Agent Template.
Smart Card S/MIME Enrollment Process
Following is a description of the smart card enrollment process:
1. The smart card operator accesses the Web enrollment page http://hostname/certsrv/ and opens the Smart Card Enrollment Station.
2. The smart card operator requests a smart card user certificate for a specific user.
3. A key-generating request for a key pair is sent to the hardware CSP (Smart Card CSP) and the smart card is accessed with a PIN.
4. The smart card generates the key pair (multiple key pairs, if the signing and encryption process is separated with different key pairs).
5. After the key pair is generated, the public key is retrieved from the smart card.
6. The smart card enrollment station sends the public key along with the certificate request message format (PKCS #10) to certificate service. IIS
passes this request to the certificate service.
7. Certificate Service (CS) generates the requested certificates.
8. If certificate service is configured as an Enterprise CA, the generated certificates will be published to Active Directory. If CS is configured as a
stand-alone CA, then certificates are published in the file system by default.
9. CS sends the certificates to IIS. IIS will pass the certificates to the smart card enrollment station.
10. The certificate is stored in EEPROM of the inserted smart card. The smart card is now ready for distribution to the specific user.
11. The user registers the smart card on his or her local workstation with the smart card registration tool (provided by smart card vendors). If the
smart card is used for logon, the smart card is automatically registered at first logon. In registration a copy of the smart card user certificate is
stored in the local certificate store of the user's machine.
12. Finally, Outlook or Outlook Express is configured for S/MIME by retrieving the smart card user certificate from the local certificate store.
8
Top Of Page
Sending Encrypted E-Mail with Smart Cards
S/MIME client deployment with smart cards and the common S/MIME deployment based on soft tokens (certificates and keys) are very similar. Both use
S/MIME certificates and keys for mail encryption and signing. The main difference is where private keys are stored.
In a smart card deployment, private keys are stored on the smart card and can only be accessed through the smart card PIN. In S/MIME deployments
based on soft tokens, private keys are stored in the protected store of the local machine and can be accessed through the user logon password or an
administrator password.
The following diagram illustrates e-mail encryption and decryption using smart cards. A detailed description of the process follows the diagram.
9
Encrypting and Signing E-mail with a smart card
Alice wants to send Bob a signed and encrypted message.
In the mail encryption process, Bob's certificate is retrieved from the corporate directory. A session key is generated and used for the message
(bulk) encryption. Bob's public key, located in Bob's S/MIME certificate, encrypts the session key.
To generate a digital signature, Alice inserts her smart card into the reader. A hash function produces a message digest of the original mail. Alice
enters her smart card PIN to gain access to her private key. The signing operation is now processed inside the smart card by encrypting the
message digest with Alice' private key.
Decrypting and Verifying the Signature of the E-mail
Bob receives the encrypted and signed e-mail from Alice.
To decrypt the e-mail, Bob inserts his smart card into the reader and enters his PIN. The encrypted session key is decrypted with Bob's private
key, which is stored in his smart card. Then, the session key is used to decrypt the e-mail.
To decrypt the digital signature, Alice's public key is retrieved from the corporate directory where her certificate is published. (Alice's public key
may also be sent with the e-mail message, depending on the security configuration of the S/MIME client.) The same hash algorithm generated
when Alice inserted her smart card into the reader is used to produce a message digest locally. If the received message digest and the locally
generated message digest match, the mail has not been altered during transport and Alice is authenticated as the author of the e-mail message.
Roland Zeitler: MCS Germany
Jung-Uh Yang: MCS Germany
March 2001
For information about Enterprise Services, see
http://www.microsoft.com/services/microsoftservices/default.mspx
10
.
Top Of Page
Links Table
1
2
http://www.microsoft.com/hcl
3
http://www.microsoft.com/windows2000/
4
http://technet.microsoft.com/en-us/library/Dd277377.smar0301_big(l=en-us).gif
5
6
7
8
9
10
http://www.microsoft.com/services/microsoftservices/default.mspx
1
."
On This Page
Introduction
Assessing the Organizational Needs for a PKI
Designing, Planning, and Implementing a Windows 2000 PKI
Parameters Set Before or During CA Installation
Parameters Set During CA configuration
Automated Certificate Requests
Trusted Root Certification Authorities
Enterprise Trust
Encrypted Data Recovery Agents
Introduction
Just like any other IT project, a Microsoft Windows 2000 Public Key Infrastructure (PKI) project can be subdivided into four key phases: assessment,
design, implementation, and management.
During the assessment phase, the current and future security requirements of an organization are analyzed. This can be done by running a security audit
or by performing a penetration test. The assessment phase also includes a business requirements analysis.
The design phase deals with the technological design of the PKI solution, in addition to some non-technological design topics, such as the creation of a
Certificate Practice Statements (CPS).
The implementation phase takes care of the deployment of the PKI solution, its integration with the existing IT environment and, prior to the rollout, the
development of customized PKI applications or modules.
After the PKI is installed and deployed across your enterprise, you need to manage and maintain it. In the management phase, you deal with the support
model for the PKI (Helpdesk, Emergency Response, and so on), administrator and end-user training, and the management of the PKI components.
Top Of Page
Assessing the Organizational Needs for a PKI
During an assessment for a PKI project, you analyze your organization's actual and future security needs. Prior to the assessment, you may need to
gather some extra information by organizing a security audit or a penetration test.
The paragraphs that follow discuss three key areas that you should focus on during the assessment phase: the analysis of business requirements, the
analysis of applications that benefit from PKI-based security, and the decision on whether to insource or outsource.
Analyzing Business Requirements
The deployment of a PKI in a corporate environment is driven by core business needs, such as advanced security requirements for information storage
and network communication. The business reason behind a corporate PKI deployment has an impact on every step of your PKI planning and design. For
example, the size of the investment that a company makes in a PKI depends on the criticality of the business problem it wants to resolve, or the
importance of the business processes it wants to improve by installing a PKI will be prepared to spend much more money on a PKI solution.
Some business security requirements do not need a certificate-based security solution and can be resolved with simpler arrangements. Because not
every certificate-based solution requires rolling out an enterprise PKI, companies often decide to outsource the job or simply buy a limited set of
certificates from a commercial certification authority (CA).
Your organization might require some extra specifications on the level of:
Availability. What sort of availability does the PKI need within the organization? This affects the CAs, the CA databases, and the directories used in
the PKI solution.
Scalability. Does the PKI have to be scalable? Will it need to cope with rapid or enormous growth of the number of required certificates? Must
planning take into account possible future mergers? Will many more PKI-based applications be deployed in the near future?
Performance. Public key cryptography operations place load and performance demands on client and server systems. Is it acceptable? Should
hardware be upgraded? Should you buy and install hardware that will speed up PKI functions?
Cost. PKI products are available with different features and in different price classes.
Analyzing the Applications That Benefit from PKI-Based Security
Many Windows 2000 applications (built-in and otherwise) can take advantage of a PKI to provide strong security: networking systems, virtual private
network(VPN)systems,EnterpriseResourcePlanning(ERP)software,documentsigning,andsmartcardbasedapplications.Thetypesofcertificates
that will be needed and the entities to which certificates will be issued (computers or users) depend on the applications you want to support in your
corporate environment.
You can build these types of Windows 2000 applications on top of a Windows 2000 PKI:
Secure Web. In a corporate intranet or extranet environment, you can use certificates for strong authentication, which uses the Secure Sockets
Layer (SSL) or Transport Layer Security (TLS) protocols to provide client authentication, server authentication, and data confidentiality. Each
authenticated entity requires a certificate. If you host Web sites and directories on Internet Information Services (IIS), you can map a certificate-
based account to a Microsoft Windows NT account so that users who authenticate through certificates are treated just like any other user in
post-authentication processes, such as access control. On the IIS level, you can define one-to-one mapping or a many-to-one mapping, which
maps certificates of the same type (for example, issued by the same CA) to the same Windows NT account. Mapping definitions are contained in
theIISmetabaseorinActiveDirectory.AnewfeatureofIIS5.0runningontopofWindows2000isthepossibilitytopointaWebservertothe
Active Directory database to check for certificate mappings.
Secure mail. Signing and sealing electronic mail messages by using Secure/Multipurpose Internet Mail Extensions (S/MIME) is also based on public
key cryptography and certificates. Signing uses the sender's private key; encryption uses the recipient's public key. Microsoft Exchange, Microsoft
Outlook, and Microsoft Outlook Express all can provide secure mail. Most secure mail applications use a dual-key pair system to provide non-
repudiation of signed mail messages and recovery of encrypted mail messages.
File system encryption. Windows 2000 comes with the Encrypting File System (EFS) extension to the NTFS version 5 file system. It provides file-
system-level encryption. A built-in feature provides recovery of encrypted data by a person other than the one who originally encrypted the data.
Because it performs encryption and decryption transparently, it is also easy to use. You can use Windows 2000 to encrypt files or folders through
a graphical user interface (GUI) or a command-prompt interface.
Code signing. This helps protect against downloads of altered (hacker) code from Web sites. Using a private key, the original code developer signs
the code, and the user downloading a piece of it can use the developer's public key to verify the code's origin. The Microsoft code-signing
technology is known as Microsoft Authenticode.
Smart card logon. This provides strong two-factor authentication (based on knowledge of a personal identification number [PIN] code and
possession of a smart card) in a Windows 2000 domain environment. Logging on to Windows NT version 4.0 by using a user ID and password
provided one-factor authentication (based on knowledge only). Smart card logon in Windows 2000 is implemented as an extension to the Kerberos
protocol; it is called PKINIT because it uses public key cryptography only for initial authentication. The smart card logon process replaces all
occurrences of the user's password with the user's public key credentials. Active Directory contains a mapping between a user's certificate and a
Windows 2000 account. There is a security gain in using PINs instead of using passwords: unlike passwords, PINs are never sent over the network,
and thus greatly reduce the possibility of security attacks.
Secure Web and secure mail using Fortezza crypto cards (United States only). The Fortezza crypto card standard is a smart card standard
developed by the U.S. National Security Agency (NSA). A Fortezza crypto card can be used like any other smart card for secure storage of public
key credentials. Fortezza also enables secure Web and secure mail applications that use public key technology.
Virtual private networking. Windows 2000 supports the Internet Protocol security (IPSec) tunneling protocol, which can use certificates to
authenticate between two IPSec tunnel endpoints. This is an ideal solution for strong authentication between two tunnel endpoints that are part
of different domains that do not have a trust relationship set up. Untrusted domains cannot rely on the standard Windows 2000 authentication
protocols, such as Kerberos and NTLM.
Remote access authentication. Windows 2000 remote access supports the Extensible Authentication Protocol (EAP) authentication protocol, which
uses (among other methods) Transport Layer Security authentication. The IETF successor to SSL, TLS uses certificates for client and server
authentication.
Authentication of Simple Mail Transfer Protocol (SMTP) site connections. You can connect Windows 2000 sites with asynchronous SMTP
connections, in which case the bridgehead domain controllers at both ends authenticate one another by using certificates.
Any custom PKI-enabled application that uses CryptoAPI version 2. The Windows 2000 CryptoAPI that is deals with PKI-related operations is fully
documented in the Windows 2000 software development kit (SDK) and can be used to build many other PKI-enabled applications on top of
Windows 2000.
Not all of these applications require the presence of a corporate PKI or CA infrastructure. For example, you can use EFS on laptops, even if no CA is
present.
Deciding Whether to Insource or Outsource
You have three choices to implement and manage an enterprise PKI: insource, outsource, or a hybrid approach.
Insourced solutions are solutions that your organization installs, implements, administers, and maintains. Your IT department must take the lead in
implementing all related PKI technologies: CA hardware, the CA database, PKI directories, and the communication links between all participating entities.
Your organization can create its own liability rules and security policies, and can decide how to implement, administer, and maintain the PKI. It also has
complete control over who gets a certificate.
Outsourced solutions give most of these responsibilities to another company. The degree of outsourcing can range from small (generating some server
certificates) to large (outsourcing multiple CA services that are dedicated to your organization). An important consideration with outsourcing is that you
must select a company that you can trust with sensitive security issues. However, outsourcing is often necessary for smaller companies or for those
without the resources required to install and maintain a PKI.
Hybrid solutions combine insourcing and outsourcing: Your organization maintains part of the CAs in the hierarchy, while another organization maintains
others. This model is probably the best choice for most companies. For example, a company might have different security needs for different
applications. In this case, applications with high security needs can be managed and implemented by the company itself; the implementation and
management of applications with weaker security needs can be outsourced.
The topics outlined in the following table can help you choose between an insourced, outsourced, or hybrid approach.
Insourcing Outsourcing
Pros
Morecontrolovercertificatepolicydefinitionandmanagement,
certificate and key management, issuance, archiving, and recovery
Tighterintegrationoptions:integrationwithenterprisedirectoryand
in-house applications
Certificatepolicycontrolcanencouragestrongertrustrelationships
with partners
Pros
LeverageonexpertiseofPKIleaders
Lesseffortforplanning,design,administration,andmaintenance
Canbemorecosteffectiveforasmallenterprisethebusinesswiththe
external partner can be extended as need for PKI-enabled applications grows
Canbeoperationalinashortperiodoftime
Requireslessinhouseexpertise
Cons
Morecostlytoplan,design,administer,andmaintain,particularlyfor
a small enterprise
Moretimeconsumingtoplan,design,anddeploy
Requiresmoreinhouseexpertise
Integrationanddeploymentcanbecomplicated
Cons
Fewerpolicycontrolandenforcementcapabilities
Fewerintegrationoptions
Canbemorecostlyforalargeenterprise
Top Of Page
Designing, Planning, and Implementing a Windows 2000 PKI
This section focuses on the different steps you need to consider when designing, planning, and implementing a Windows 2000 PKI.
Defining Your Topology
When designing your Windows 2000 PKI topology, you need to consider possible future extensions of your organization, and then make decisions about
the following topics:
Decide on the number of CAs you want. Your organization may require multiple CAs for reasons of scalability, business, geography, CA policy, or
politics.
Choose a trust model. The primary trust model of Windows 2000 is hierarchical. Windows also supports the distributed and browser trust models.
When designing a hierarchical trust model, you need to decide on the number of hierarchical levels you will need and on what those levels will be
based (such as geography, business organization, and so on). In a distributed model, you must also decide on the number of hierarchies that your
organization needs.
In PKI projects of limited scope, you might choose a stand-alone CA solution. Given the growing interest in PKI, however, this is not a good idea.
You should always consider the possibility of linking your CA trust model with others and provide ways to scale your CA trust model.
Map the trust model to the Windows 2000 domain and site model. Because the trust model established between CAs is totally independent of the
trust model existing between Windows 2000 domains, one CA can span multiple domains and a domain can contain multiple CAs.
With Windows 2000, it is good practice to increase availability by installing one Windows 2000 domain controller or global catalog server in each site. In a
PKI environment, the availability of the CA services is much less important than the availability of the directory that holds the certificates and the
certificate revocation lists (CRLs). If you integrate the certificate server with Active Directory, the certificates and CRLs are automatically published to
the configuration container of the active directory and then replicated throughout the forest.
In some environments, such as the one illustrated below, it might be a good idea to have one CA per group of sites. The example below illustrates a
multiple hub-and-spoke site model; in this case, it's a good idea to deploy one CA per core site, simply for availability and performance reasons.
Define relationships with external CAs or PKIs. When the PKI topology design is done, you should have a clear view of the trust relationships
between your organization's CAs. To provide PKI interoperability between different CA domains, Windows uses a special type of browser trust,
based on the concept of Certificate Trust Lists (CTLs). You also need to decide on how you will link your PKI domain with other external PKI
domains and whether there is a need to do this. If you are planning to use CTLs, think about the following elements: Which CA certificates will be
containedintheCTLs?Willthetrustbeunidirectionalorbidirectional?WhatwillbethelimitationsontheCTLswhichcertificatetypeswillthey
support? What will their lifetime be? Remember that setting up a link between different PKIs requires more than just a technology solution. You will
also need to think about policy agreements.
Specifications of the Individual CAs
Certification authorities are your key PKI components, so you need to spend enough time and effort to create detailed designs of the individual CAs. The
sections that follow discuss the parameters that you set for the installation and configuration phases of a CA.
Top Of Page
Parameters Set Before or During CA Installation
Before or during the installation of a CA, you need to think about its architecture, its role, the specification of its keys and certificates, its naming
conventions, the inclusion of a pointer to the CPS or to a short notice text in the certificates, and its database specifications.
CA Architecture Design
When setting the CA architecture, you must decide factors such as whether your organization needs CAs with a customized exit or a policy module.
CA Role
You can choose among the following roles for the CA:
Stand-alone or enterprise CA
Root or subordinate CA
Intermediate or issuing CA (if it is a subordinate CA)
Offline CA (if it is a root or intermediate CA)
Within a certificate hierarchy, it is advisable to take the non-issuing CAs (root CAs and intermediate CAs) offline. This minimizes the risk of the CA private
key being compromised.
Taking a CA offline can mean different things. You can:
Take it off the network
Shut down the CA service
Shut down the CA machine
Install it on a stand-alone Windows 2000 server and thus set it up as a stand-alone CA.
Installing an offline CA on a member server that is a member of a domain can lead to secure channel problems when you bring the CA online again after a
long offline period (by default, the machine account password is changed every seven days). Installing it as an enterprise CA would lead to Active
Directory updating problems, when you decide to disconnect the server from the network.
A best practice for an offline CA, is to respect all of the above.
If an offline CA needs to issue new certificates (for example, for a new subordinate CA) or generate a new CRL, you need to bring it online. If it is not
connected to the network, you can use the following procedure to obtain a certificate for the new subordinate CA:
1. During the installation of the subordinate CA, click Save the request to a file. The Certificate Services feature informs you that the installation is
incomplete.
2. Put the request file (*.req) on a floppy disk and transport the disk to the offline CA.
3. Open the subordinate CA's request file from the offline CA, and copy the text between the Begin New Certificate Request and End New Certificate
Request lines.
4. Paste this text into the Submit a saved request window (Advanced certificate request) of the offline CA's Web enrollment interface. Submit the
request, and then save the newly generated certificate to the floppy disk.
5. Transport the disk to the subordinate CA. From the CA Microsoft Management Console (MMC) snap-in, right-click the CA object, and then click
Install CA certificate. The CA certificate is installed and the subordinate CA service starts.
Even though a CA is offline, the users of the certificates it issued must be able to access its CRLs and CA certificate. Even though a CA is offline, you
can publish its certificate and CRL in Active Directory: Export them from the offline CA to a floppy disk; bring the disk to a machine that has access to
Active Directory, and publish them in Active Directory by using the Dsstore resource kit tool. You must also change the CRL distribution point and
authority information access parameters in the CA's certificate (by using the Capolicy.inf file), and in the CA's policy module; the last change should be
made before any certificate is issued. In addition, even though a CA is offline, it must be brought online at regular intervals to generate a new CRL (it
does not matter if the CRL is empty, as long as it is available). Otherwise, the certificates that have been issued will not be valid after the existing CRL
has expired.
CA Keys and Certificates
When you set up a CA, you must choose the key length, the cryptographic service provider (CSP), and the hash functions that the CA will use for
cryptographic operations. When installing a root CA, you can also set the lifetime of its certificate. Remember that the CA is the heart of your security
systemifitsprivatekeyiscompromised,soistheentirePKI.Protectagainstattacksbychoosingthelongestkeypossibleatleast1,024bitsandby
storing the CA private key in a secure place.
The place where the private key is stored depends on the CSP selected during the installation of the CA. A CSP can be software based; for CA private
key storage, it should be, preferably, hardware-based. The safest way to store the CA's private key is on a specialized hardware device, a Hardware
Security Module (HSM), but these are very expensive. A cheaper alternative is a smart card. Windows 2000 supports different types of smart cards and
smart card readers.
Regardless of the choice you make, you need to make sure that the device on which you store the CA's private key is physically secured. Put it in a
highly secured area of your organization's computer room, or lock it in a safe. If you're not planning to use any special hardware protection on your root
CAs and intermediate CAs, remember that it is a best practice to keep these servers offline. Keeping the offline CA servers in a secured area also offers
private key protection.
CA Naming Conventions
During CA installation, you are prompted to enter the CA's identification information: the CA name, organization, organizational unit, city, state or
province, country/region, e-mail, and CA description. Be sure to agree on the naming conventions before you start the installation. The naming choices
made during installation affect not only the CA; they will also be the CA's Common Name in Active Directory and will be reflected in every certificate the
CA issues.
Windows 2000 generates a sanitized CA name, which is the truncated CA name without any non-ASCII characters and ASCII punctuation characters. It
is needed for file names, key container names, and Active Directory object names that cannot handle a CA name that includes special characters. Active
Directory object names are limited to 64 characters; if a CA's name is longer than 64 characters, it is truncated and appended with a hash calculated
over the truncated part.
To look at all CA-related Active Directory names (including the CA sanitized names), run Certutil with the -v -ds switches. All CA-related Active Directory
content was explained in the previous chapter.
After you install the CA, you cannot change the server's name. If you need to do this, you must uninstall the CA, change the server's name, and then
re-install the CA.
CA Database
The location of the database and its log files can be specified during CA installation. During installation, you are also asked whether you want to store
the CA's configuration information on the file system. Doing this copies the CA's naming information and the CA's certificate to the file system (the
configuration directory will automatically be shared as "certconfig").
The Windows 2000 CA database is a JET database. It uses the same database engine, the Extensible Storage Engine (esent.dll), that is used in
Exchange and Active Directory. Just as for any other JET database, a good practice is to split the database and its log files across different physical disk
drives. By default, all of its files are located in the "certlog" subdirectory of the system directory. To determine the location of your CA database files,
type certutil -database locations at the command prompt. The CA database consists of the files listed in the following table.
Database file Purpose
CA name.edb CA store
edb.log Transaction log file for the CA store
res1.log Reservation log file to store transactions if disk space is exhausted
res2.log Reservation log file to store transactions if disk space is exhausted
edb.chk Database checkpoint file
tmp.edb Temporary CA store
The Windows 2000 CA database is designed to support up to 1 million certificates; if every user has an average of four certificates, the database can
support approximately 250,000 users. Because there is no limit on the number of CAs that can be supported in a single domain, the number of supported
users and certificates in the Windows 2000 PKI is practically unlimited.
The CA database format used in Certificate Services for Windows 2000 is different from the format used in the version of Certificate Server for Windows
NT 4.0. When Windows NT 4.0 is upgraded to Windows 2000, the database is converted automatically. To upgrade your CA database from the earlier
version to the later version, stop the CA service, use certutil -convertMDB to do the conversion, restart the CA service, and force the publication of a
new CRL. To look at the new schema layout of the Windows 2000 CA database, type certutil -schema at the command prompt.
Other Installation-Time CA Configurations
During enterprise or stand-alone CA installation or certificate renewal, you can add several custom extensions to the CA certificate:
A custom Issuer Statement
A custom certificate policies field, pointing to all certificate policies that the CA adheres to
Custom CRL distribution points
Custom authority information access points
Custom enhanced key usage settings
Custom certificate renewal settings
The last four extensions are used only when installing or renewing a root CA certificate. For CRL distribution points for subordinate CAs, authority
information access points and key lifetime settings are set by configuring the parent CA's policy settings.
To customize the CA certificate, you must create a policy statement file, Capolicy.inf, and store it in the system directory (C:\winnt) prior to CA
installation. The following code represents a sample Capolicy.inf file:
[Version]
Signature="$Windows NT$"
[CAPolicy]
Policies=CompaqPolicy
[CompaqPolicy]
OID=1.1.1.1.1.2.3.4.5
URL = "http://www.compaq.com/certsvc/cp.asp"
URL = "ftp://ftp.compaq.com/certsvc/cp.asp"
URL = "ldap://ldap.compaq.com/certsvc/cp.asp"
Notice = "Compaq Certificate Policy"
[CRLDistributionPoint]
URL="http:://www.compaq.com/Public/CompaqCA.crl"
[AuthorityInformationAccess]
URL="http::// www.compaq.com/Public/CompaqCA.crt"
[EnhancedKeyUsage]
OID=1.2.3.2.110
OID=1.2.3.2.111
[certsrv_server]
RenewalKeyLength=4096
RenewalValidityPeriod=4
RenewalValidityPeriodUnits=Years
The settings in the "[CompaqPolicy]" part of the code will embed the following in the CA's certificate policies extension:
[1] CertificatePolicy:
PolicyIdentifier=1.1.1.1.1.2.3.4.5
[1,1]Policy Qualifier info:
Policy Qualifier ID= CPS
Qualifier: http://www.compaq.com/certsvc/cp.asp
Qualifier: ftp://ftp.compaq.com/certsvc/cp.asp
Qualifier: ldap://ldap.compaq.com/ certsvc/cp.asp
Policy Qualifier ID= User Notice
Qualifier: Notice Text= Compaq Certificate Policy
Top Of Page
Parameters Set During CA configuration
After you install the CA, you must configure the CA and all the entities related to the operation of your PKI environment. This includes configuring CRL
preferences, policy and exit module settings, loading the appropriate certificate templates, delegating administrative control, setting identification
options, setting up additional certificate request interfaces, and hardening the CA server.
CRL Settings
In the planning for a PKI, you should consider how CRLs will be generated, distributed, and checked. You need to think about the following CRL-related
parameters: the period allowed between key compromise and certificate revocation, the CRL lifetime and publication interval, and the number and type of
CRL distribution points.
The period allowed between key compromise and certificate revocation is a parameter that should be agreed upon in the certificate policies and
mentioned in the certification practice statement (CPS).
When setting the CRL lifetime and publication interval parameters, keep the following in mind:
In Windows 2000, the CRL lifetime and publication interval are, though closely related, not the same. The CRL lifetime is deducted from the
publication interval and is by default 10 percent longer than its publication schedule. This enables Windows 2000 to deal with the replication delay
of CRLs that are published in Active Directory. The CRL overlap can be set in the registry by using the CRLOverlapPeriod, CRLOverlapUnits, and
Clockskewminutes parameters, which are located in the HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \CertSvc \Configuration<CA
Name>\ registry hive.
For example, imagine you have to deal with a replication delay of four hours. In this case, it would be wise to set the overlap period to five hours.
The CRL lifetime resulting from the registry settings (in the list that follows) would be one week, five hours, and 10 minutes, because it is the sum
of CRLPeriod, CRLOverlapPeriod, and Clockskewminutes.
CRLPeriod REG_SZ = Weeks
CRLPeriodUnits REG_DWORD = 1
CRLOverlapPeriod REG_SZ = Hours
CRLOverlapUnits REG_DWORD = 5
ClockSkewMinutes REG_DWORD = a
Setting the CRLOverlapUnits parameter in the registry to 0 activates the default algorithm for the calculation of the CRL overlap, mentioned
previously.
The shorter the CRL lifetime, the faster the user is apprised of a revoked certificate. Setting CRL publication (and thus CRL lifetimes) too short can
burden the network with numerous CRL downloads.
Windows 2000 supports both automated and manual CRL publishing. To disable automatic CRL publishing, check the disable publication schedule
box or set the CRLPeriodUnits parameter in the registry to 0. Automatic CRL publication cannot be set to less than one hour. It is set on the CA
level, in the properties of the revoked certificates container available from the MMC Certification Authority snap-in.
If some of your PKI-enabled applications have different CRL publication requirements, you will need to install multiple CAs. For example, you might
install one CA with a short publication schedule that is used for an application with high security requirements, and another CA with a longer
schedule for an application with lower security requirements.
Windows 2000 supports four types of CRL distribution points: Lightweight Directory Access Protocol (LDAP), file system, Hypertext Transfer Protocol
(HTTP)based,andFileTransferProtocol(FTP)based.ForCRLdownloadswithinyourWindows2000basedorganization,ActiveDirectoryisanobvious
storage location; in this case, you use LDAP CRL distribution points. Because Active Directory provides automatic replication of the CRLs throughout your
Windows 2000 forest, LDAP CRL distribution points pointing to the CRL in Active Directory will always be fault tolerant (unless you have only one domain
controller in your Windows 2000 forest). Remember, however, that the way you set up intersite and intrasite Active Directory replication can affect the
availability of the CRLs. If you use certificates to communicate with entities outside your organization, you'll need to consider alternative CRL distribution
point locations, such as FTP sites or Web pages.
CRL distribution points for certificates issued by a CA are configured in the X.509 extensions tab of the Policy Module configuration dialog box,
available from the properties of the CA object container in the MMC Certification Authorities snap-in. To define CRL distribution points, use the text string
variables (also known as the replaceable parameter syntax) defined in the table that follows. In the registry, the text string variables are translated into
numbered variables. Remember that the CRL distribution point settings for the certificate of a root CA are configured during CA installation by using the
Capolicy.inf file, as explained earlier in this chapter.
Text string variable Numbered variable Value
%SERVER_DNS_NAME% %1 DNS name of the CA
%SERVER_SHORT_NAME%%2 Network basic input/output system (NetBIOS) name of the CA
%CA_NAME% %3 Name of the CA
%CERT_SUFFIX% %4 Renewal extension of the CA
%5 Location of domain root in Active Directory
%CONFIG_NAME% %6 Location of the Configuration container in Active Directory
%CA_NAME_HASH% %7 Sanitized name of the CA
%CRL_SUFFIX% %8 CRL base file name and renewal extension for the CA
The renewal extension is the extension that is added to the CRL name when the CA's key pair has been changed, and thus when a CRL is generated. The
%5 and %6 variables both point to the PKI entries in Active Directory.
To use the replaceable parameter syntax for CRL distribution point and authority information access specifications in the Capolicy.inf file, you need to
add an extra % before every parameter; for example, instead of %8, you specify %%8. To specify a space in the CRL distribution point or authority
information access, you need to add three extra % to the %20, so it becomes %%%%20.
The table that follows lists some sample file, Active Directory, and Web CRL distribution points.
File CRL distribution point:
File://\\%SERVER_DNS_NAME%\CertEnroll\%CA_NAME%%CRL_SUFFIX%.crl
Active Directory CRL distribution point:
ldap:///CN=%CA_NAME_HASH%%CRL_SUFFIX%,CN=%SERVER_SHORT_NAME%,CN=CDP,CN=Public Key Services, CN=Services,%CONFIG_NAME%?
certificateRevocationList?base?objectclass=cRLDistributionPoint
Web CRL distribution point:
Http://%SERVER_DNS_NAME%/CertEnroll/%CA_NAME%%CRL_SUFFIX%.crl
Certificate Characteristics
The administrator of a Windows 2000 CA can set the following certificate properties: the certificate lifetime, the CRL distribution points, and the
authorityinformationaccesspoints.TheCAadministratorcaninfluencetheuserskeypairlifetime.Thecertificatelifetimeisalwaystheminimumofthe
following:
The registry validity period setting on the CA, as defined in the following registry key on the CA:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA Name>\ValidityPeriodUnits
The certificate template validity period ( Validity Period on the General tab of Properties for the specific Certificate Template)
The lifetime of the CA certificate
The CA administrator has full control to modify these settings.
Remember that machine certificates, resulting from an autoenrollment, will renew their key pair automatically together and at each automatic certificate
renewal.
To set authority information access points, you can use the same procedure and variables as the ones outlined for CRL distribution points.
The default certificate lifetimes and the way you can change the defaults were explained in the previous chapter. When planning for certificate lifetimes,
you must consider the following:
The longer the lifetime of public and private key, the more packets will be secured with the same key pair, giving a hacker more opportunities to
break the mathematical problem behind an asymmetric cipher. Hence, it's a good practice to renew the key pair at each certificate renewal.
Certificate lifetime is also related to key length. Because it takes less time to resolve the mathematical problem behind an asymmetric cipher by
using short keys, Certificates certifying short public keys should have a shorter lifetime than the ones certifying long public keys.
The storage of public key credentials on a dedicated hardware device (such as a smart card), and consequently, the usage of a hardware CSP,
lower the risk for private key compromise. This is a reason to lengthen the key pair and certificate lifetimes.
Moresecurestorageautomaticallylowerstheriskforattacksonpublickeycredentialsanotherreasontoconsiderlongercertificatelifetimes.The
risk for attacks is also influenced by other organizational and IT environmental factors, such as the cryptographic knowledge of your employees.
Certificatelifetimeaffectsthenumberofcertificaterenewalrequestssentacrossyournetwork.Inenvironmentswithscarcebandwidthfor
example,usersinremotesiteconnectingtoaCAacrossaslowwideareanetwork(WAN)thiscanbeareasontolengthencertificatelifetimes.
If you issue certificates to users of your corporate extranet, the certificate lifetime might be shorter than when you issue certificates to users of
your corporate intranet. Generally, the level of trust that an organization has in its internal users is higher than the level of trust it has in the
external users of the corporate IT infrastructure.
CA Administration Delegation
Administration of the Windows 2000 CA can be delegated to different administrators by setting the appropriate access control lists (ACLs) on the CA
object. The CA permissions and CA administration delegation can be divided into three basic categories:
The CA Manage permission is for administrators who manage the CA configuration. This permission allows for fine-grain delegation. For example, CA
management can be delegated for certificate revocation or certificate request approval.
The CA Read permission is for administrators who need to look at, but do not need to alter, the CA configuration.
The CA Enroll permission is for PKI clients that need to request certificates to the CA.
To view the CA permissions, right-click the CA object in the MMC Certification Authority snap-in, and then click Properties.
The following table shows the permissions that can be set in Basic View and Advanced View.
Meaning Default membership
Basic View
Manage (1)
Accounts and groups that can manage the CA by using the MMC snap-in
or from a command line
Administrators (local); Domain Admins; Enterprise Admins
Enroll Accounts and groups that can request certificates
Administrators (local); Domain Admins; Enterprise Admins;
Authenticated Users
Read (2) Accounts and groups that can read CA configuration information
Administrators (local); Domain Admins; Enterprise Admins;
Authenticated Users
Advanced
View

Write
Configuration
Accounts and groups that can change CA configuration information Manage members (1)
Read Control Accounts and groups that can view the CA configuration information Read members (2)
Modify
Permissions
Accounts and groups that can change CA security permissions Manage members (1)
Modify Owner Accounts and groups that can change ownership of a CA object Manage members (1)
Revoke
Certificates
Accounts and groups that can revoke certificates Manage members (1)
Approve
Certificates
Accounts and groups that can approve certificate requests Manage members (1)
Read Database Accounts and groups that can access and read the CA database Manage members (1)
Although Windows 2000 offers plenty of flexibility for the definition of CA-related administrative tasks, it offers no or very little flexibility for the
delegation of CA-related installations in a Windows 2000 forest. For example, in a forest, only a root domain or an enterprise administrator can install an
enterprise CA, because installation of an enterprise CA requires read/write permission to the Active Directory configuration naming context.
Consequently, an enterprise administrator cannot delegate the installation of an enterprise subordinate CA to an administrator of a child domain.
Hardening the CA Server
A CA's private key is the most critical element of PKI security. If a root or intermediate CA's private key is compromised, part or all of your PKI-trust
infrastructure is ruined. The level of security provided by a CA on the level of private key storage will also have an significant impact on the amount of
trust people have in the CA. This is why it is so important to securely store the CA's private key securely, and to keep root and intermediate CAs offline.
It is also important to "harden" your CA server by boosting the following types of security:
Physical security. Install Certificate Servers on computers in secure areas where physical access is controlled and where there is protection
against fire, power loss, and other disasters.
Logical security. Implement software access control systems on the computer to prevent unauthorized access to computer systems. In a
Windows 2000 environment, logical security depends on the quality of the operating system's authentication and access control system.
You can provide high-quality authentication by equipping all servers with smart-card readers, which provide two-factor authentication.
You can provide high-quality access control by checking the ACLs on all the server's resources at regular intervals. Remember, in Windows
2000, you need to check ACLs on file system objects and on Active Directory objects.
YoucanusetheSecurityConfigurationandAnalysistool(SCAitcomeswithWindows2000)toauditthesecuritysettingsonWindows
2000basedservers.YoucanautomatetheSCAandrunitatregularintervalsinbatchmode(byusingSecedit.exe).
Communications security. To provide communications security for the CAs (issuing CAs or other online CAs) that are connected to your
production network, you can install them on a separate subnet, behind a dedicated firewall or router that is filtering out all non-PKI-related traffic.
Organizational security. Make sure the administrators of the CA and the operators of the computer room where the CA server is located are
aware of the importance of the CA. Convince them that this is not an ordinary file and print server but a server used to secure your corporate IT
environment.
Defining Public Key Policy Settings
Windows 2000 Group Policy object (GPO) objects include some PKI-related entries: Automated Certificate Request Settings, Trusted Root Certification
Authorities, Enterprise Trust, and Encrypted Data Recovery Agents. The table that follows shows the mapping between the PKI-related GPO settings, the
GPO levels (domain, site, organizational unit [OU], or local), and the GPO portions (user or machine). Notice that the same settings occur on the site,
domain, and OU levels. Settings that are defined on the machine level are shared with all users logging on to the machine and all services running on the
machine. Settings defined on the user level are valid only on the user level.
GPO level User Machine
Automated Certificate Request Domain X
Site X
OU X
Local
Trusted Root CAs Domain X
Site X
OU X
Local
Enterprise Trust Domain X X
Site X X
OU X X
Local
Encrypted Data Recovery Agents Domain X
Site X
OU X
Local X
Top Of Page
Automated Certificate Requests
The Automated Certificate Request GPO setting refers to automated certificate enrollment and renewal. Windows 2000 administrators can set machine
accounts to enroll automatically for a certificate when they boot up or the next time their GPO settings are enforced. For example, you can use this
feature to autoenroll all machines located in one of your Windows 2000 sites. Automatic renewal starts automatically at a moment that is defined in the
renewal overlap parameter of a certificate template, before the expiration of the certificate.
The following machine-related certificate types can be automatically requested: computer, domain controller, Internet Protocol security (IPsec), and
enrollment agent. Automated enrollment can be very useful for IPsec or SSL certificate-based machine authentication. In the Automatic Certificate
Request Setup Wizard, you can select multiple enterprise CAs that may service the request. This feature can provide some level of fault tolerance; if the
first CA in the list is unavailable, the next one can be tried.
Every time the GPO settings are applied to the machine, an autoenrollment event occurs. This event triggers more than just autoenrollment:
The status of the current available machine certificates is checked against the autoenrollment object. This means not only that the machine will
automatically enroll for a certificate, but also that it will reenroll in case of certificate revocation, certificate expiry, or even when the CAs that can
issue the autoenroll certificate have been changed in the GPO setting.
CertificatesofenterpriserootCAsaredownloadedfromthedirectoryservicebasedenterpriserootstoretothemachine'slocalTrustedRoot
Certification Authorities certificate store.
DownloadofenterpriseCAcertificatesfromtheActiveDirectorybasedNTAuthstoretolocalmachineNTAuthstore.
The autoenrollment event can occur when the GPO is pulsed; this happens automatically at machine startup or every eight hours, and this can happen
manually by using the resource kit tool Dsstore with the pulse switch.
Independently of this setting, every Windows 2000 domain controller that is part of a Windows 2000 forest containing an enterprise CA automatically
enrolls for a domain controller certificate.
Top Of Page
Trusted Root Certification Authorities
The Trusted Root Certification Authorities GPO setting contains a list of trusted CA certificates. The name of the container is rather misleading; it can
containcertificatesofrootandsubordinateCAs,andcertificatesofCAsinternalandexternaltoyourWindows2000basedorganization.Unlikethe
Enterprise Trust setting explained later in this paper, you cannot limit the trust of CA certificates in this container based on time or application
(certificate template). The certificates that are part of this GPO setting are downloaded to the Trusted Root Certification Authorities container of your
Windows2000basedclients.
Besides the use of this GPO setting, there are two other ways to automatically download CA certificates to users' Trusted Root Certification Authorities
certificatestorecontainer.ThecertificateentriesinthedirectoryservicebasedenterpriserootstoreandNTAuthstorearedownloadedtotheTrusted
Root Certification Authorities certificate store when the autoenrollment event occurs.
Directory ServiceBased Enterprise Root Store
If a root domain administrator or an enterprise administrator installs an enterprise or stand-alone root CA in Windows 2000 domain, a CA object is
automaticallyaddedtotheActiveDirectorybasedenterpriserootstore.ThemultivaluedCacertificate attribute of the CA object contains the CA's
certificate or certificates. This store is located in CN=< CA NAME >, CN=Certification Authorities,CN=Public Key
Services,CN=Services,CN=Configuration,DC=<rootdomaininenterprise>,DC=com.Todisplayormodify(adddelete)thecontentofthedirectoryservice
based enterprise root store, you can use: dsstore <DN of root domain (required) > [-display | -del | -addroot].
The NTAuth Store
If a root domain administrator or an enterprise administrator installs an enterprise CA in a Windows 2000 domain, its certificate is automatically added to
the NTAuth store. This Active Directory store contains the certificates of enterprise CAs that are capable of issuing smart card logon and enrolment
agent certificates. The certificates are added as fields in the multi-valued Cacertificate attribute of the following Active Directory object:
CN=NTAuthTemplates,CN=Public Key Services,CN=Services,CN=Configuration,DC=<root domain in enterprise>,DC=com.
Top Of Page
Enterprise Trust
The Enterprise Trust GPO setting contains a signed list of certificates of CAs that are internal or external to your organization, and that need to be
trusted by your internal Windows 2000 entities. The setting is referred to as a Certificate Trust List (CTL). The concept of CTLs was also used in
Microsoft Exchange version 5.5 Advanced Security to enable S/MIME-based security interoperability between two organizations. To create a CTL, an
administrator needs a "CTL signing" or "administrator" certificate. By default, members of the Enterprise Admins and Domain Admins groups can enroll for
these certificate types.
Using the Enterprise Trust GPO setting, the trust definition can be fine-tuned based on certificate type and validity period. This is very different from the
Trusted Root Certification Authorities GPO setting: a CA that is trusted using this setting is, by default, trusted for all purposes and for its entire lifetime.
Youcanfinetunethetrustbyaccessingthefollowingcomponentsofthedialogbox:
Use Certificate type to specify that certificates coming from a particular CA are trusted only for some uses or purposes (such as secure e-mail).
Besides the certificate purposes available by default, you can also add your own purposes by adding the appropriate object identifier (also known
as OID) in the User defined purposes dialog box. These purposes are listed in the subject usage extension of the CTL.
Use Validity period to specify that certificates coming from a particular CA are trusted only if they are used within a certain time limit. If the
administrator doesn't specify a lifetime, the CTL expires when the "CTL signing" certificate expires. The CTL validity period can be specified in
months and days; it is listed in the effective date and next update extensions of the CTL.
Besides the subject usage, effective date, and next update fields, the CTL format used by Microsoft also contains a version number, a list identifier,
the subject algorithm, the thumbprint algorithm, a thumbprint, and a friendly name. A CTL's properties are displayed in the CTL dialog box that opens
when you double-click a CTL. The same dialog box can be used to view the CTL signature.
Top Of Page
Encrypted Data Recovery Agents
The Encrypted Data Recovery Agents GPO setting is used to define accounts that have the ability to recover encrypted Encrypting File System (EFS)
data. A Windows 2000 domain administrator can grant this privilege to a limited number of Windows 2000 accounts. Only accounts that have an "EFS
recovery" certificate can be added to this setting. You can add accounts by pointing to their recovery certificates stored in Active Directory or on the
file system.
Jan De Clercq: Senior Consultant, Compaq Global Services
March 2001
2
.
Top Of Page
Links Table
1
2
1
."
On This Page
Introduction
Understanding Smart Cards
The Envisioning Phase
The Development Phase
Suggested Links
Appendix A
Introduction
This paper details the process for deploying smart card technology in a large enterprise setting. Because the adoption of smart card technology is still
limited, it is not possible to offer a detailed "cookbook" for successful deployment. However, this paper will offer recommendations and identify risks
specific to smart card technology integrated with a process based on the Microsoft Solutions Framework (MSF) principles of infrastructure deployment.
MSF specifies best practices and principles for managing software development and deployment distilled from internal practices at Microsoft.
The deployment process is organized into three phases:
Envisioning Stage
Planning Stage
Development Stage
Each stage includes milestones that help your organization track progress and ensure that the deployment addresses your organization's needs. For more
information about MSF infrastructure deployment, see http://www.microsoft.com/msf/
2
Before describing the deployment process, the following overview
of smart cards provides a starting point for understanding the technology involved.
Top Of Page
Understanding Smart Cards
Althoughsmartcardsareoftencomparedtoharddrives,theyare"secureddriveswithabrain"theystoreand process information. Smart cards are
storage devices with the core mechanics to facilitate communication with a reader or coupler. They have file system configurations and the ability to be
partitioned into public and private spaces that can be made available or locked. They also have segregated areas for protected information, such as
certificates, e-purses, and entire operating systems. In addition to traditional data storage states, such as read-only and read/write, some vendors are
working with sub-states best described as "add only" and "update only."
Smart cards currently come in two forms, contact and contactless. Contact cards require a reader to facilitate the bidirectional connection. The card
must be inserted into a device that touches the contact points on the card, which facilitate communication with the card's chip. Contact cards come in
3-volt and 5-volt models, as do current desktop CPUs. Contact card readers are commonly built into company or vendor-owned buildings and assets,
cellular phones, handheld devices, stand-alone devices that connect to a computer desktop's serial or universal serial bus (USB) port, laptop card slots,
and keyboards.
Contactless cards use proximity couplers to get information to and from the card's chip. An antenna is wound around the circumference of the card, and
activated when the card is radiated in a specific distance of the coupler. The configuration of the card's antenna and the coupler facilitate connected
states from a couple of centimeters to a couple of feet. The bidirectional transmission is encoded, and can be encrypted by using a combination of a
card vendor's hard-coded chip algorithms, randomly generated session numbers; and the card holder's certificate, secret key or personal identification
number (PIN). The sophistication of the connection can facilitate separate and discrete connections with multiple cards should they be within range of
the coupler. Because contactless cards do not require physical contact with a reader, the usability range is expanded tremendously.
The physical characteristics of smart cards are governed by international standards. For example, the size of a card is covered by ISO-7810. ISO-7816
and subsequent standards cover manufacturing parameters, physical and electrical characteristics, location of the contact points, communication
protocols, data storage, and more. Data layout and format, however, can vary from vendor to vendor.
In addition to physical and manufacturing standards, an increasing number of standards exist for specific vendor applications. Credit card vendors,
cellular phone vendors, US and European banks, credit agencies, and debit agencies are examples of organizations that are tailoring smart card
applications and procedures geared exclusively to the services they offer, and the companies with which they do business.
The two largest vendors of operating systems for smart cards are MAOSCO (an industry consortium) and Microsoft. The Microsoft Windows for Smart
Cards operating system is a component-based architecture that supports multiple card chips and platforms. It is extensible and supported by a growing
number of card manufacturers and vendors. The application programming interfaces (APIs) and the associated toolkit can be integrated into
environments that are already familiar to developers. Cards that are compliant with Windows for Smart Cards can be obtained from a variety of sources.
Smart card applications can be developed by using systems such as Microsoft Visual Basic and Microsoft Visual C++. Internally, Microsoft is working with
WindowsforSmartCardscompliantthirdpartyvendorstoprovideenterprisemanagementtoolsthatarecompatiblewithMicrosoftWindows2000.
These will provide administrative features, such as the ability to remotely reset PINs.
A number of vendors are providing support and other standards for Windows for Smart Cards. Sun Microsystems has published and currently maintains
specifications for both Windows for Smart Cards and a "Java Card." Vendors GemPlus and Schlumberger also support Windows for Smart Cards, in addition
to their own card operating system, the "Java Card" specification.
Top Of Page
The Envisioning Phase
Some of the most common reasons for project failure include a lack of shared project goals and a lack of executive sponsorship. Therefore, before
detailed planning starts, it is critical to ensure that a clear vision exists for how smart card technology will be implemented. It is also important to involve
executive management. This is the goal of the envisioning phase.
Gather the Requirements
Frequently, organizations make the mistake of moving right into development without performing a thorough business requirements analysis. Anticipating
the applications that the card must support in its lifetime is critical to good design. After the chips for the card are manufactured, the number and size of
applications that can later be added to the card are set. Some applications might not be ready until months later, after the cards are already deployed in
the organization.
For this reason, it is important to identify and meet with the key stakeholders in the smart card deployment in the early development stage. Stakeholders
include groups that intend to build smart card applications, and groups that can approve (or block) the smart card deployment.
From these discussions, you can compile the requirements into a requirements document. Most organizations are initially interested in smart cards for
security reasons. Other common requirements for smart cards include:
Enhancing the security of user logons to the corporate network from the desktop
Providing selective access to data, resources, and Web sites
Providing employees enhanced security when remotely accessing the corporate network
Enabling legally binding digital signatures
Providing internal payment systems (or e-purse) within the organization
Migrating toward elimination of passwords
Enhancing asset tracking; who is doing what, with what, and for how long?
Ensuring access for employees with disabilities
After you compile a list of business requirements, consider the administrative tools that will be necessary to manage large numbers of smart cards, such
as:
Resetting a user's PIN remotely.
Viewing a user's card profile. What applications are on the card? How much memory is available?
Performing first-time diagnostics on a card as it is being issued.
Allowing full access for security officers.
Flashing new chips.
Document the Operating Environment
Identify the platform, network/server configuration, and hardware with which the smart card solution must integrate. A functioning Public Key
Infrastructure (PKI) must be in production in the enterprise before smart card technology can be deployed.
In addition, be sure to document the user's physical environment. Will users be swiping cards at doorways, next to cashiers, or at workstations? Will they
be using cards with mobile devices? What accommodations must be made for people with disabilities?
Prioritize Requirements and Create a Version Strategy
The initial deployment should focus on a few top-priority features and establish the one-time elements of the system (cards, card readers, issuance
process). If designed properly, additional applications and features can be added later to the same card over the course of its lifecycle. It is
recommended that the overall list of features in the requirements document be implemented in phases.
Build the Team
Getting the right resources on the project takes a long time, so this must begin early. Complete a skills assessment based on the technologies that will
be needed. For example, if your company uses Windows 2000 for its server architecture, at least one developer on your team must have knowledge of
PKI. During this time, you can interview and select a card vendor that will participate on the team. For further information about building a team based
on the MSF team model, see the white paper Team Model for Application Development
3
.
Prepare a Vision/Scope Document
This document will identify the goals, value proposition, high-level features, and risks of the smart card deployment. Circulate this to key decision-
makers, IT managers, and managers of user groups that will be most affected. The vision/scope document must reduce the ideal list to a manageable list
of features that can be implemented in a single project or series of projects.
Conduct a High-Level Vision/Scope Review
Present the vision/scope document to the key decision-makers and stakeholders. The review should include a rough cost estimate (not a fixed budget),
approximate project time frame (not exact dates), and a preliminary risk assessment. It should also be clear that there are two choices available to the
key decision-makers. They can approve and commit resources to proceed to the next milestone, or disapprove and send the document back for revision.
The Planning Phase
After the vision/scope approved milestone has been passed, detailed planning and specifications can begin.
Write Functional Specifications
The functional specifications must describe the architecture, design, and implementation details of the core system and custom applications that will use
smart card technology. Several key points should be considered when preparing design and specifications.
Chip Design
Chip design should anticipate adding new applications during the 18- to 24-month lifecycle of the card. Assume that interest in taking advantage of the
smart cards for new applications will grow after people begin to use them. When planning file allocation tables (FATs) and storage space on the chip,
allot space for applications that are still in the early phase of planning. Good communication is critical; for example, if an application requires 4 kilobytes
(KB) of storage space on the chip, the space is reserved and reconciled against the storage needs of other applications.
Graphics
The chip can be screen printed directly on a card or applied as a sticker, or "skin." By using a skin, existing corporate cardkeys or badges can be
leveraged. Enterprises with existing card issuance processes, and issuing stations and policies can save money by "piggybacking" these. Avoid issuing
employees multiple cards and readers because this involves considerable cost.
Note: There is a risk of damaging the chips with the solvent). For some organizations, such as the military, skins might be viewed as less secure than
screen printing. This is because skins can also be peeled off and placed on a different card.
Cards and Readers
Some organizations have found that if the card-to-reader interface is too tight or abrasive, the cards deteriorate more rapidly. This can occur if the
cards are too thick. Discuss this issue with your card and reader vendor or vendors. Include physical thickness of cards in your specifications. This is
important when selecting vendors for manufacturing skins, because the material thickness for skins varies.
Also, some readers use USB ports. Some users might have all USB ports on their workstation occupied, and therefore need special accommodations to
use the readers. You may need to obtain a mix of card reader connector types. In some companies, it is appropriate to give users the option to choose
the connector type.
Some personal computer vendors provide alternative options that do not occupy the USB port. Both Siemens and Compaq offer corporate desktop
computers with built-in card readers. Compaq and Cherry Systems make a keyboard that includes a smart card contact reader at a reasonable cost.
Prepare Schedule and Budget
After the functional specifications are sufficiently detailed, developers and infrastructure IT personnel can prepare detailed task lists and time/cost
estimates. The task lists and estimates can then be added to the project schedule and budget estimates.
It is sometimes helpful to create a master plan document that describes the overall strategy for completing the project.
Prepare Risk Assessment
Brainstorm the risks specific to the smart card deployment and document them in a spreadsheet. For each risk, make a determination regarding its
probability and impact, and decide what the response will be. Response options include avoiding the risk entirely (by doing something to eliminate its
cause), mitigating the consequences of the risk, creating contingency plans should the risk occur, or accepting the consequences of the risk. For more
information about MSF risk management, see the white paper The Risk Management Model, available at: http://www.microsoft.com/msf/
2
.
The following pages contain examples of the risks involved with smart card deployments. Topics include:
Risk Inefficient card production.
Result Deployment is delayed.
Response Will your organization perform card preparation on its own, or work with a partnered vendor in a temporary or permanent hybrid solution?
If you work with a partner, to what extent will the engagement be, and what liabilities are acceptable to your organization? A partner may be
willing to do some or all of the preparatory work for you on site or at the manufacturing plant. If you need smart cards with employee information,
the card operating system, a default PIN, and a pre-printed photograph, do you need to send out your Security Accounts Manager (SAM)
databaseorActiveDirectory?Ifyouwanttominimizeinteractionwithyoursmartcardvendor,thevendorcansupplyyouwithafewcasesof
pre-formatted cards.
If the card will be recycled, you may need to prepare and print a decal that is fixed to the card. The decal has the cardholder's picture, employee ID,
and so on. The decal adds 4 to 10 millimeters to the thickness of the card. Does this make the card "sticky" in a contacted reader? Do your employees
apply decals such as transit passes to the cards they currently use? Generally speaking, the thicker the card, the more awkward it is to use in a
contacted reader scenario.
Risk We cannot deploy across multiple server types.
Result Service will be inconsistent and inefficient.
Response You can use multiple card vendors and servers if the cards are International Organization for Standardization (ISO) compatible and the
certificates are recognizable throughout the installation process. The Windows for Smart Cards operating system is used by an increasing number
of smart card vendors. Any vendor that uses Windows for Smart Cards can supply cards that you can prepare and deploy. You can also employ
third-party management tools that are compliant with Windows for Smart Cards and compatible with Windows 2000.
Risk Aggregate domain/card password overhead and maintenance becomes excessive.
Result You risk work stoppage and an overall increase in support overhead.
Response The level of security agreed to in the vision/scope document sets the tone for card support and maintenance, which will be an added
layer for the support organization. Smart cards do not directly affect domain passwords. Smart cards add an extra layer that results in a more
secure domain. The card has its own password.
Risk Uncertain of certificate types to put on the card.
Result Security goals are not met.
Response You can put Verisign, Microsoft Windows NT Certificate Server, and Microsoft Exchange Key Manager certificates on a smart card. You
must determine how much space you will need and locate a vendor that can supply you with cards of the necessary capacity.
Risk Lost, forgotten, or locked card. Lack of consistency throughout the company.
Result You risk losing secured data.
Response The response will vary depending on what the reader already has in place with respect to corporate identification and building and asset
access, compared with the level of security declared in the vision/scope document. In a strong environment, the user may need to visit the
enrollment center. If the card is lost in a very strong environment, and the certificates are not available from a central repository, data secured by
the card will be lost, and a new card is needed. In a more casual scenario, receptionists, group assistants, and managers may have the ability to
recover the card or grant a temporary card.
Risk Managing multiple card types will not be coordinated.
Result Security will be diluted to the extent that you grant control to a greater number of people.
Response In general, three types of cards are used during deployment: a master card, an enrollment card, and a user card. The user card can be
further divided into two categories: permanent and temporary.
The master card is at the highest level. Card certificates and PIN administration and recovery roles are assigned to this card. If your company contracts
with a vendor for 5,000 cards, a small number of master cards is generated and supplied with the shipment. These cards are critical and can be unique to
the delivered shipment. If all master cards are lost, they are not recoverable. Some vendors enable you to duplicate master cards if two or more are
used to generate additional cards. You will want to keep master cards in a safe, stored off site, and in the possession of only those individuals who must
have them.
The enrollment card is used as a proxy to enter users into the system. Enrollment cards have a special enrollment agent certificate, and are issued only
to enrollment personnel. The relationship between the enrollment card and the enrollment agents should be highly secure because the agents are access
issuers.
The permanent user card is the card that your employees carry. It contains the credentials, certificates, data, and applications for each cardholder. It
may also have photographic information printed on the card or on a decal applied to the card. In a Windows 2000 environment, the card is directed to a
permanent certificate server. If you prefer, the card can have a designated lifespan.
The temporary user card is a limited-use card that is issued to guests, temporary employees, and users who have forgotten their permanent cards. It is
pointed to a temporary certificate server, and can also have a lifespan that reflects the short-term nature of the card.
You might want to create a roles and responsibilities document for each user type, and develop a checklist that each department signs off on before
moving forward to a pilot.
Plan Phase Deliverables
The deliverables of the planning phase are a set of planning documents, primarily consisting of the functional specifications, master schedule, budget
estimate, risk assessment, and perhaps others. You can disseminate these deliverables to the key decision-makers for comments and input.
Conduct a Project Plan Review
Like the vision/scope review, the project plan review provides a checkpoint at which key decision-makers have an opportunity to evaluate the smart
card deployment before committing further resources. However, this review includes much more specific information about how it will work, the cost, and
how long it will take. As before, the review meeting should end with yes or no decisions about committing resources to the deployment. If the plan is
approved, the deployment continues on to the development phase.
Top Of Page
The Development Phase
Most smart card deployments require a phase of solution development as custom features, application integration, and installation scripts are developed.
Although the specifics depend entirely on the nature of your smart card solution, the following checklist contains some development best practices to
ensure quality.
Proof of Concept
Build a proof of concept to test the smart card solution in a lab simulation setting.
Pre-production Test
Use a version control tool, such as Microsoft Visual SourceSafe, for all custom components being developed.
Set up a test environment that reflects the production environment as much as possible.
Devise test cases and compile them into a test plan.
Use issue tracking software to track bugs.
Take an iterative approach to testing, and retest bugs that have been fixed before closing them.
Establish acceptance criteria for implementing a pilot with input from key stakeholders, such as IT management, security, and department leads of
affected user groups.
Pilot Deployment
The purpose of the pilot deployment is to stress the card technology in addition to the processes for issuance, management, and support of the card.
Decide on the size and the composition of individuals that will participate in the pilot. The number of participants determines how many cards and readers
to order from the manufacturers. There should be enough participants to stress the deployment and support processes, in addition to the technology;
perhaps100200.
In most cases, participants should be volunteers. Consider creating an internal Web page to explain what the pilot is about. This way, you can solicit
additional volunteers and provide updates.
Consider using special programs and incentives to encourage the use of the cards during the pilot, because it is unlikely that they will be required to use
them at this stage to perform tasks such as logging on to the network.
Prepare for Production Deployment
While the pilot program is in progress, you can prepare and refine training materials for the production deployment process.
Draft Policies and Procedures
Policies and procedures for various user situations must be drafted and reviewed. Many of these will need to be approved by the Human Resources,
Legal, and Corporate Security departments. Allow enough time for generating, reviewing, and updating these policies and procedures as needed.
An example of a policy issue is that of lost or stolen cards. The appropriate policy will depend on the nature of the company, the manner in which smart
cards are being used, and the access level of the employee involved.
In some cases, if a user forgets his or her card, the environment may allow a user to revert to standard domain network logon. The user can also report
to the receptionist, group assistant, manager, or another person who has a special certificate on his or her card. This special certificate is not the same
as that of the enrollment officer. The receptionist can use a personal card to issue a temporary card that is valid for 24 hours.
Some questions to consider for production deployment include:
What is the escalation path for user problems?
What is the procedure if a user has a lost or stolen card?
What is the procedure if a user forgets his or her card at home and cannot log on?
What level of access must an administrator have to reset PINs and complete other sensitive management tasks?
What policies and procedures apply to special categories of employees, such as senior executives and other critical personnel?
Prepare the Card Issuance Process
To prepare for card issuance, you can map out the issuance process. Be sure to include physical variables, such as locations of issuance stations, and
the equipment required at each station.
The flow chart in the following illustration shows an example of a card issuance process.
4
The employee signs an agreement to accept the roles and responsibilities associated with a company-issued asset, and goes to the enrollment center to
obtain a new smart card. The employee provides proof of ID, (sometimes two pieces of ID are required, depending on the card options and the
appropriate level of security). The enrollment officer uses the enrollment card to create the card to be issued. The card is then flashed, the user's smart
card profile is purged, the tracking logs are updated, and the ID decal is applied, if applicable. Then, a simple card password, such as "12Fish34" is
flashed on the card and is good for a short period of time; for example, 12 hours. The new cardholder must change the PIN to a permanent personal PIN
within that time. You can supply a private terminal located in the enrollment office for this task.
Train Technical Support and Issuance Staff
After policies and the issuance process have been thoroughly reviewed and nearly finalized, you can begin writing training materials for staff involved in
card issuance and technical support staff. Depending on the size of the deployment, you might consider a "train the trainer" document and training
event.
Determine the Number of Cards and Readers Needed
In calculating the number of cards and readers to be ordered from the vendors, consider the following factors:
Employees have more than one workstation.
Computers may not be associated with specific individuals, such as in computer labs, training rooms, shop floors, and workstations used by
temporary workers.
Remote access workstations may be used by employees at home or in mobile environments.
Other Preparation Tasks
Additional preparation tasks include creating an issue tracking system and developing a readiness communications plan for the appropriate division leads.
Contingency plans for security breaches and employee downtime would also be prepared, possibly with the assistance of your card vendor.
Set Up Intranet Site for Information and Downloads
For large deployments, it is recommended that you set up an internal site on the corporate intranet for communicating with users and providing
downloadable components that will be used with smart card deployments. Coordinating this with your corporate IT department is critical.
Conduct a Ready-for-Release Milestone Review
During the pre-release milestone review, pilot and test results are presented and assessed. The goal of the review is to evaluate the fitness of the
solution before proceeding to full production deployment.
The following key deliverables should be ready at this milestone:
Results of the completed pilot
Training materials
Communications plan (to users, technical support staff, trainers)
Installation procedures and scripts
Checklists and templates
Operational procedures
Deployment documentation
Support and troubleshooting documentation
Updated schedules
Deploy Core Technology
The technology that is centrally operated and managed should be deployed first. Again, the PKI servers are assumed to be operational. Production
manufacturing of cards or skins takes place at this time. Arrange for secure delivery and storage throughout the distribution process for receiving from
the vendor and sending cards or skins to the various issuance stations.
Deploy Readers and Begin Issuance Process
During this phase, users receive their cards and readers, and then install the necessary drivers and components from the internal site. You can anticipate
and plan for a heavy load of troubleshooting and escalation calls to your technical support staff.
The issuance process should be organized into phases by organizational or geographic units. Users of a given unit are notified that they can obtain their
cards and receive instructions within a designated period of time. The implementation schedule should accommodate travel and setup time for security
officers and issuance teams who are traveling from site to site.
Complete the Stabilization Process
The development team must work closely with IT personnel to track and resolve issues that are escalated from technical support staff. The development
team and the operations staff must agree on the point at which the smart card deployment is considered stable enough to be completely transitioned to
operations.
Top Of Page
Suggested Links
For more information on Smart Cards, visit the following links:
http://www.smartcardalliance.org/
5
http://www.microsoft.com/whdc/whql/device/smartcard.mspx
6
http://msdn2.microsoft.com/en-us/library/ms834348
7
http://www.smartcardcentral.com/
8
http://www.gemplus.com/
9
http://www.ipccards.com/
10
http://www.dawar.com
11
http://www.cardlogix.com/
12
Top Of Page
Appendix A
Smart Card Deployment Checklist
The following checklist is simply a list of things to consider when you apply smart card logistics. Because each environment is different, some of these
suggestions may not apply to you.
Determine Smart Card Usage Within Your Environment (Usage Scenarios)
RAS (Remote Access Services) into the company network
SmartcardlogontoaWindows2000basedenterprise
Client Web authentication (Secure Sockets Layer [SSL] and TLS)
Application usage (e-purse, kiosk, Human Resources benefits)
Secure/Multipurpose Internet Mail Extensions (S/MIME)
Outline or map each scenario, test and pilot Proof of concept
Determine the risks, roadblocks, end user impact, support model, and so on.
Complete a Cost Analysis on Smart Card Infrastructure
What is the business value proposition of each card usage deployed, such as cost, risk (impact), and benefits?
Do you have an existing employee badge process so you can incorporate smart card infrastructure?
Do you have staff to manage issuance and administration?
Do you have the correct number of cards and readers for the number of users?
Have you factored in travel (remote locations) and training new security officers?
Have you considered the costs associated with in-house vs. outsourced card management (Cryptographic Message Syntax (CMS), card
management system, or software)?
Have you forecasted yearly operational expenses and maintenance for cards, readers, printers, skins, and issuance hardware?
Card Logistics
Outline Smart card requirements and submit an RFQ to several card and reader manufacturers.
Determine what you need in a CMS; in-house vs. outsourced to a Service Bureau.
Tracking and auditing for card issuance, serial number, key escrow, certificates (PKI), application version, card version, and chip size.
Integrate and track next operating system, card serial version.
Use multi-functional (one card) or multiple cards for many functions?
Combicardbuildingaccessandembeddedsmartcard.
Can the exiting environment incorporate a smart card?
Determine smart card chip size (8 KB, 32 KB, 64 KB)
What is the life expectance of the smart card before replacing or upgrading?
What future growth should be considered from deployment to 18 months or longer?
What is the allocation of space on the card (file allocation table)? Number of certificates (1.5 KB per certificate)? Number of applications (2
KB to 5 KB per small applet)? Is there open space for user data?
Consider costs if you have to re-flash cards to expand space for future business usage.
What applet could be deployed after the initial deployment? What are your deployment phases (see Determine Smart Card Usage)?
Recycle smart cards? Clean certificates, applets, data, and graphics from cards for re-use in your environment.
Permanent graphics, such as return postage
Removal graphics, such as employee ID.
Develop a Smart Card Infrastructure
Definition of the operation model
Central issuance, revocation, reissuing of cards
Tools to manage remote card operations, such as blocking, unblocking, card diagnostic, and delegate enrollment of certificate (remote issuance)
Issuance of temporary cards (delegated enrollment model)
Audit and reporting tools
Candy Stark: Manager, Microsoft Security
Enzo Paschino: Program Manager, Microsoft Solutions Framework
Markus Vilcinskas: Program Manager, Microsoft Solutions Framework
Steven Seim: Technical Writer, Microsoft Solutions Framework
March 2001
13
.
Top Of Page
Links Table
1
2
http://www.microsoft.com/msf/
3
http://www.microsoft.com/trainingandservices/default.asp?pageid=enterprise&subsite=whitepapers&pagecall=msf
4
5
http://www.smartcardalliance.org/
6
http://www.microsoft.com/whdc/whql/device/smartcard.mspx
7
http://msdn2.microsoft.com/en-us/library/ms834348
8
http://www.smartcardcentral.com/
9
http://www.gemplus.com/
10
http://www.ipccards.com/
11
http://www.dawar.com/
12
http://www.cardlogix.com/
13
1
. "
On This Page
Introduction
The Hay Buv Toys IT Infrastructure
Security Issues
Introduction
Hay Buv Toys (HBT) is one of the leading toy companies in the United States and Europe. HBT uses cutting-edge technology to develop the latest in
techno toys. HBT has its headquarters and also a major subsidiary in Seattle, with other major subsidiaries in New York, London, and Tokyo. Hay Buv
Toys stores are worldwide, and the expansion rate is tremendous. HBT plans to extend its infrastructure to South America in the near future.
Top Of Page
The Hay Buv Toys IT Infrastructure
The HBT information technology (IT) infrastructure is centralized in the major subsidiaries. Most of the server systems and Line of Business (LOB)
applications are located in Seattle, New York, London, and Tokyo. These servers and applications represent the USWest, USEast, Europe, and East Asia
sales regions, as shown in the following figure. All business data is replicated in the hubs.
2
All data is accessed from the corresponding IT hub in a sales region. Only the larger HBT toy stores have their own domain controllers and file servers.
Other stores use the IT services provided by HBT headquarters. All HBT toy stores, subsidiaries, and headquarters are connected through a wide area
network (WAN). HBT sales representatives build dial-up connections from remote access servers to the major IT hubs.
HBT is currently migrating from a Microsoft Windows NT environment to a Microsoft Windows 2000 environment. The Active Directory HBT design is
shown in the following illustration.
3
HBT developed an Active Directory design based on its sales regions, so the domain architecture follows a geographic design model. A root domain and
child domains for the major sales regionsUSWest, USEast, Europe, and East Asiahave been established. The HBT organizational areasSales, Finance, and
Marketingare covered in each child domain by organizational units.
Top Of Page
Security Issues
Many of the core business processes of HBT are already handled electronically. Exchanging e-mails, signing contracts, and accessing electronic data and
information are minor parts of this process. External communication and electronic transactions with business partners are critical. New and improved
business relations will be generated from technologies such as e-commerce. Therefore, security is an important issue for HBT. Potential security issues
exist in the following scenarios:
Communication between regional headquarters and the individual toy stores is not secured. width="75%" although some information is highly
confidential, the WAN is not owned by HBT.
Internal and external e-mail communication must be kept confidential. Also, the integrity of orders that are sent and received by HBT partners must
be maintained.
HBT has deployed new macros for Microsoft Office 2000 to ensure current virus protection.
HBT will eventually connect its sales representatives to the Internet.
Application development is based on COM+ (Message Queuing, also known as MSMQ). HBT is looking for a solution to provide enhanced message
security.
Restrictive password policies require complex passwords.
Web applications with payment functionality are provided to customers. Internal Web applications also exist.
Mobile users work with sensitive data and information, such as contracts.
HBT prefers to use a technology based on public key methods that are well known in the Internet community. This ensures privacy and information
integrity, and allows interoperability with other systems. A Public Key Infrastructure (PKI) is the common framework for this type of technology. The goal
of HBT is to deploy PKI in order to address its business requirements.
March 2001
4
.
Top Of Page
Links Table
1
2
3
4
1
. "
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.
2
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.
Top Of Page
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
3
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.
Top Of Page
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.
4
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.
5
Top Of Page
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.
6
March 2001
7
.
Top Of Page
Links Table
1
2
3
4
5
6
7
Deploying the PKI
1
. "
On This Page
Introduction
Importance of Certificate Server Uptime
Prerequisite Tasks
Installing a Root Certification Authority with Windows 2000 Server
Conclusion
Introduction
This paper provides a step-by-step guide to Microsoft Windows 2000 Public Key Infrastructure (PKI) installation. It identifies crucial points in the
installation process, helps you evaluate your progress, and explains the options available before you continue.
Although you can apply this material to production machines, we recommend using a test or lab environment first for the purpose of skill building and
preparing department representatives who will be affected by the PKI deployment. Before you begin, you should have a core understanding of PKIs, or
work with other personnel who are. If you are not confident regarding your background knowledge, you can pursue the following links as a parallel
activity:
Windows 2000 Deployment Planning Guide
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/DPG.mspx?mfr=true
2
RFC 2527
http://sunsite.dk/RFC/rfc/rfc2527.html
3
RFC 2459
http://sunsite.dk/RFC/rfc/rfc2459.html
4
Microsoft Security home page
http://www.microsoft.com/security/
5
Microsoft Security Bulletin Search
http://www.microsoft.com/technet/security/default.mspx
6
Top Of Page
Importance of Certificate Server Uptime
When the decision was made to deploy a PKI at Hay Buv Toys (HBT), research and discussion revealed the importance of the online Certificate Services
and its function in the business.
The online certification authority (CA) is not treated in the same way as a file, print, Web, or mail server. HBT, like most businesses, can tolerate and
account for some file, print, and service outages on occasion. The same cannot be said for certificate servers, because the servers are critical to
business. The goal and Microsoft recommendation for system uptime and availability is 99.999 percent. In addition, built-in Windows 2000 reporting,
monitoring, and notification processes are continuously running to ensure that operations personnel are updated and informed regarding certificate
service availability.
Although operations and security personnel at HBT are trusted and competent, the potential to compromise the PKI is increased by the number of
personnel who are granted access to the equipment. To address these concerns, the PKI servers are installed in a restricted area, and serviced only by
a limited number of senior administrators.
The pilot environment on which this paper is based uses stand-alone servers in a test lab on an isolated network. The material in this paper targets skill
building for the pilot environment that you build prior to going into full production. When you document your experiences and incorporate them into the
Microsoft Solutions Framework (MSF) best practices, your production deployment will be more streamlined, predictable, and trouble-free.
Top Of Page
Prerequisite Tasks
Prior to PKI deployment, your environment should match that described in the previous section. It is recommended that you review the network diagrams
for your company, so that you can compare and contrast your lab work against possible scenarios during full deployment. Prior to deployment, you can
complete the following tasks:
1. InstallandstabilizeyourWindows2000ServicePack1(SP1)baseddomainserver.
2. InstallandstabilizeasecondWindows2000SP1basedcomputertofunctionasyourcertificateserver.
3. Optional:InstallathirdWindows2000SP1basedcomputerthatcanserveasasubordinatetotherootcertificateserver.
Note:IfyouintendtousemultipleCAsundertheprimaryCA,itisrecommendedthatyouinstalloneWindows2000SP1basedserverforeach.In
addition, Windows 2000 has a Recovery tab associated with its Properties page. If your company uses Microsoft Exchange 2000 Server, you can
use the Run a file option together with utilities such as MAPIsend or MailSend to send an e-mail message to a named user, distribution list, and
pager gateway. Using an Exchange Server monitor is another option that provides a graphic image on the computer against which it is run.
4. Install the High Encryption Pack on each server.
Top Of Page
Installing a Root Certification Authority with Windows 2000 Server
This installation process makes your root Certification Authority server invisible to your organization because it is not part of your corporate network. It
is the subordinate server that will be visible on your network, and to your users and customers. The subordinate server runs your certificate management
processes, including issuance and revocation. The strength of this hierarchy is a result of the preparation and maintenance of the servers that are
dedicated to management tasks.
Install and Configure Microsoft Certificate Services
Beforeyoubegin,youmustsetupandstabilizetheWindows2000SP1basedserverthatwillbeusedasthecertificateserver,andalsoinstalltheHigh
Encryption Pack. After this is complete, locate your installation CD and ensure that share point is ready.
The procedure for installing and configuring Microsoft Certificate Services is as follows:
1. On the Start menu, point to Settings, and then click Control Panel.
2. Double-click Add/Remove Programs, click Certificate Services from the Components list, and then click Next.
7
3. When you are prompted, click Yes to continue. Any changes made to this computer after its services are active affect the entire domain.
8
4. Under Certification Authority types, click Stand-alone root CA, select the Advanced options check box, and then click Next.
9
5. With the High Encryption Pack installed, you have an additional cryptographic service provider (CSP) option, Microsoft Enhanced Cryptographic
Provider version 1.0. Click this provider in the list. In the Key length box, increase the number from the default of 1024 to 4096, and then click
Next.
10
You can now configure the identity of the CA and its expected service lifespan. Unlike a computer name or user name, this should be planned in
advance and considered to be permanent. Configure the CA accordingly, and ensure that the e-mail address is not likely to change during the
declared service life.
You will notice the ability to declare a valid lifespan. The value that you declare affects the serviceability of the certificate server. This is because
the root CA can only issue certificates that have a lifespan less than the root, which is true for the entire hierarchy, if implemented. Therefore, if
your root CA is configured with a 10-year lifespan, and the sub-CAs are configured with a 5-year lifespan, your users can employ the certificate
services for less than 5 years. If your PKI deployment takes two years to deploy fully, users have even less time to use the service.
CAs can be renewed and the lifespan subsequently changed, but this requires administration. You may opt to keep administration to a minimum to
decrease the opportunity of service interruption due to human intervention or accident.
Before completing the next step, you must know how to present your PKI services. You might want a sub-CA to service temporary or guest
accounts, and therefore keep the lifespan short. In a high-security model, you might do the same. For permanent employees who do not have
access to sensitive data, you might configure a sub-CA with a longer lifespan. This decision can be made by your deployment team. It is important
to have your aggregate security needs known, declared, and in writing before putting the service into live production.
6. Type the appropriate information in the text boxes provided, and then click Next.
11
7. Your service configuration and CA are created. The root certificate is self-signed by the root CA. Click Next when the process is finished.
12
You can now configure the location of the certificate database and log file. Backup and restore of the CA is directed against the folder declared in
the Shared folder box.
The CA must be homed on an NTFS file system partition. Because the goal for uptime is 99.999 percent, a redundant array of independent disks
(RAID) 5 array should be considered for production deployment. Disk capacity also needs to be considered. If the service is expected to issue
numerous certificates, you will need to account for database size, optimization, and fault tolerance requirements. For small- to medium-sized
organizations, a reasonable starting estimate is 20 gigabytes (GB). Drives of this capacity are currently reasonably priced when the role the server
plays is considered.
8. On the Data Storage Location page, enter the appropriate information in the Certificate database and Certificate database log boxes, and
then click Next.
13
9. Any Internet Information Services (IIS) services will be halted and restarted as the Windows Components Wizard proceeds. Click OK.
14
10. On the Configuring Components page, click Next to complete the installation process. Your IIS-related services will be updated and appended.
You are now ready to issue certificates and use the services.
15
Configuring the Certification Authority
The CA can now issue certificates to your test lab users. Before proceeding, you need to declare the locations of the Certificate Revocation List (CRL)
and authority information access. Strong PKI applications verify these locations first to check the status of certificate revocation and public key
download. It is recommended that you install these to the subordinate CA computer, which will not be shut down because its uptime is considered a
priority.
The procedure for configuring the CA is as follows:
1. Open the Microsoft Management Console (MMC) associated with the certification authority. The green check mark indicates that the service is
running. Get properties on your root CA.
16
2. Click Policy Module/Configure/X.509 Extensions. Note that the default location pointers are removed. You have the option to cancel or
remove the defaults; the end result is the same.
Because the root CA computer is essentially invisible to the network, the CRL and CRT files are manually copied to the Web server. The name of the Web
server is used in this example. However, a DNS name is preferred for production because a change in the Web server computer name would break the
PKI.
Note: If your root CA server is also your CRL distribution point, and you want to have the location of the CRL distribution point in the self-signed
certificate for the root CA, you need to create the root CA by using a Capolicy.inf file. This is also necessary for setting a certification practice
statement URL in the root CA certificate. Capolicy.inf is placed in the \winnt directory, and looks similar to the following string:
[Version]
Signature= "$Windows NT$"
[CAPolicy]
Policies = LegalPolicy, LimitedUsePolicy, ExtraPolicy, OIDPolicy
[LegalPolicy]
OID = 1.3.6.1.4.1.311.21.43
Notice = "Legal policy statement text."
[LimitedUsePolicy]
OID = 1.3.6.1.4.1.311.21.47
URL = "http://http.site.com/some where/default.asp"
URL = "ftp://ftp.site.com/some where else/default.asp"
Notice = "Limited use policy statement text."
URL = "ldap://ldap.site.com/some where else again/default.asp"
[ExtraPolicy]
OID = 1.3.6.1.4.1.311.21.53
URL = http://extra.site.com/Extra Policy/default.asp
[oidpolicy]
OID = 1.3.6.1.4.1.311.21.55
17
18
YouarenowreadytopublishtherootcertificatetoActiveDirectory.Afterthisstepiscomplete,youwillhavesetthepathtothetopofyour
certificate hierarchy. As discussed previously, system uptime from this point forward is crucial because the trust will be broken if the root CA cannot be
touched.
To publish, you can run Dsstore.exe from the Windows 2000 Server Resource Kit. The following command line is used in the HBT test lab. Note that the
variable identifiers are in uppercase:
dsstore.exeDC=haybuv,DC=comaddrootROOTCA.CRT"HayBuvToysROOTCA"
During full deployment, replication must be complete before the certificate is available across the entire domain. The DSSTOREpulse switch can
accelerate this process.
19
Installing the Subordinate Certification Authority
As mentioned in previous papers, HBT intends to work with multiple subordinate certificate authorities under the root. One will service smart cards, and
another user and computer accounts.
Root authorities differ from subordinate authorities in that subordinates store CRL and authority information access in Active Directory, which enables a
Lightweight Directory Access Protocol (LDAP) query.
The process of installing a subordinate CA is similar to installing the root, and is identical for every subordinate to be created. Online authorities will use
the offline root to sign the certificates they make available to the enterprise.
The procedure for installing subordinate CAs is as follows:
1. Using the sub-CA computer, sign in as an enterprise-level administrator. On the Start menu, point to Settings, and then click Control Panel.
Double-click Add-Remove Programs, click to select the Windows Components sequence, and then click Add/Remove. Select the option to
Install Certificate Services.
2. Click Enterprise subordinate CA, select Advanced options, and then click Next.
20
3. In the CSP list, click Microsoft Enhanced Cryptographic Provider v1.0, and then in the Key length box, increase the number to 2048. Click
Next.
21
Again, the identification should be planned in advance. The lifespan is determined by the root authority, and is one year by default. The
certificates can be renewed, and a one-year default might be appropriate for a high security requirement. If this is not the case, the default
lifespan can be modified by changing the following registry value on the root CA computer. After you have changed the registry value, cycle the
certificate service.
4. Confirm the CA identifying information, and then click Next.
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<name
of the root CA>\ValidityPeriod
22
5. On the Data Storage Location page, enter the appropriate location information in the Certificate database and Certificate database log
boxes, and then click Next.
You have the option to store configuration information in a shared folder, but if you exercise that option, the specific computer should also have a
maximum uptime goal.
23
You have two options to have the subordinate certificate signed by the root. You can send the request directly to the root, or you can create a
file for the root to process. For this exercise, you can create a file for the root to process because the root CA is not available on the network.
6. Click Save the request to a file, and then click Next.
24
7. Follow the on-screen instructions to complete the installation process, and then click OK.
The wizard will then inform you that the installation process is complete and that the service will be available when you process and install the
certificate.
25
8. The Completing the Windows Components Wizard page appears. Click Finish to close the wizard.
26
Getting the Certification Request Signed by the Root Authority
To get the subordinate certificate request signed by the root, you can access the root computer directly by using the following procedure:
1. Start your browser. On the Tools menu, click Internet Options to open the Internet Options dialog box.
2. Click the Security tab, and then click Trusted Sites. Click Sites, and then clear the Require server verification check box. In the Add this Web
site to the zone text box, type localhost, or the name of the Web server, in the following format:
http://localhost/
3. Click Add, and then click OK. Set the appropriate security level to a custom level, or accept the default level. Click Apply, and then click OK to
close the Internet Options dialog box.
4. Call the local host's certificate service from the browser, click Request a certificate from the Select a task list, and then click Next.
27
5. Click Advanced request, and then click Next.
28
6. Click Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file, and
then click Next.
Note: During a full production deployment, if your root CA does not face your corporate network, you can ensure increased security by hand-
delivering the certificate request to the root CA computer. Base 64 files are encoded, not encrypted. Although base 64 files provide a foundation
for encryption, base 64 encoders and decoders are readily available.
29
7. When you receive the following message, click OK to continue.
30
You have the option to paste the base 64 encoded text into the form field if you prefer. When you are ready, submit the request.
31
8. Open the Pending Requests folder for the root MMC, and notice the pending request.
32
9. Right-click the pending request, point to All Tasks, and then click Issue. You can issue or deny the pending request. In a live production
environment, you can run the request against a registration authority to guarantee the authenticity of the request.
33
10. Return to the root's enrollment page to check the status of the request, click Check on a pending certificate, and then click Next.
34
11. Click to select the request that you want to review, and then click Next.
35
The certificate is issued, and you can retrieve it from a downloadable certification path or copy it to a floppy disk. In a live production setting, the
floppy disk can be hand-delivered to remote sites as needed.
36
Install and Activate the Subordinate CA
You are now ready to install and activate the subordinate CA., which you can do through the following procedure:
1. In the Certification Authority (Local) folder, click Hay Buv Toys USWEST SUB CA. Open the MMC, and notice the Stop dot informing you that the
service is not running or is completed.
37
2. Right-click Hay Buy Toys USWEST SUB CA, point to All Tasks, and then click Install CA Certificate.
38
3. Click the Policy Settings folder, and then click Computer.
39
You can now view the subordinate CA in the Policy Settings folder.
40
Installing Additional Subordinate CAs
From this point forward, you can add subordinate CAs under the subordinate of the root. The installation process is identical to installations covered in
this paper thus far. The process is simplified because you can sign certificates from the online certification authority.
The procedure for installing additional Subordinate CAs is as follows:
1. Create a subordinate under the root's subordinate, by typing the appropriate information on the CA Identifying Information page.
41
2. Click Send the request directly to a CA already on the network to send the request directly to the root's sub-CA, and then click Next to finish
the process.
42
Top Of Page
Conclusion
This paper discusses how to set up a certificate hierarchy, and conveys the importance of keeping the online CA running at all times and serviced only
by trusted operations personnel. Although file, print, and Web servers and services are often subject to change, the same should not be true for your
certificate servers. If Certificate Services is interrupted, your ability to trust your certificate hierarchy is compromised. Your advanced preparation tasks
will reduce this risk to a minimum.
March 2001
43
.
Top Of Page
Links Table
1
2
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/DPG.mspx?mfr=true
3
http://sunsite.dk/rfc/rfc/rfc2527.html
4
http://sunsite.dk/rfc/rfc/rfc2459.html
5
http://www.microsoft.com/security/
6
http://www.microsoft.com/technet/security/default.mspx
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
1
."
On This Page
Introduction
Setting Up the Enrollment Station
Requesting a Certificate
Conclusion
Introduction
This paper discusses the installation and configuration of the smart card enrollment station. The enrollment station and security officer work on behalf of
the enrollee to "flash" one or more certificates to the newly issued smart card. The security officer has a unique certificate that allows certificates to be
written to protected areas on the issued card.
The benefits of a smart card enrollment station are extensive. Primarily, the enrollment station can help centralize, organize, and account for issuing
smart cards. The enrollment process is a formal process in which enrollees prove their identity by using one or more forms of identification, and the
company issues the appropriate keys. If practical, a scaled-down enrollment station can be placed at a reception desk and temporary cards can be
issued for visitors and guests.
A centralized enrollment station can also:
Simplify the physical preparation of the card to be issued. In some deployments, decals may be applied to the card at the time of issue.
Reduce the chance for certificate service interruption. Because the certificate servers are isolated, the opportunity for human intervention or
accident is lessened.
Prevent users and managers from validating their own identification and issuing their own certificates, especially for environments in which varying
levels of security and access exist.
It is crucial to implement a security department to reduce the chance for collusion. This means that employees cannot initiate their own enrollment
process; only managers can authorize and issue smart cards. The security department also determines the extent to which the smart card will be used.
However, because the security department is a separate neutral party, it is in the best position to verify that the card is appropriate for the enrollee,
and in alignment with company policy and the department or departments with which the enrollee is associated.
Top Of Page
Setting Up the Enrollment Station
Before a smart card can be used effectively, one or more readers must be available to the enrollment candidate. When your test or lab work moves into
full corporate deployment, a process can be implemented that confirms to the security department that the card reader is installed and ready for use.
The process might be similar to the following pre-enrollment scenario:
1. The enrollment candidate initiates the enrollment process after reporting on the type of card reader required; USB, serial, keyboard, and so on.
2. When the card reader arrives, the enrollee candidate begins installation. After installation is complete, the candidate views the security Web site
and completes the smart card "Terms and conditions for use" agreement. A copy of the confirmation is sent to the manager, who then launches
authorization to the smart card enrollment station.
3. The candidate commutes to the enrollment station to obtain the smart card.
Top Of Page
Requesting a Certificate
You can start the certificate request process by opening the certification authority (CA) for the subordinate CA. Under policy settings, confirm that the
Enrollment Agent template is present in the list. In the following illustration, the Hay Buv Toys (HBT) smart card CA policies are minimized to allow only
smart card enrollment agent, user, and logon certificate functionality.
2
At Hay Buv Toys, a PKI_Admins group was added to the organizational unit. A Security Smart Card group is associated with the PKI_Admins group, and
the permissions are shown in the illustration that follows. The named enrollment agents are homed to this group.
3
1. Return to the named smart card sub-CA. Open AD Sites and Services to view the certificate templates.
2. Open the Security Settings associated with the Enrollment Agent, and add the Security Smart Card group.
4
A Microsoft Windows 2000 SP1 Professional computer is recommended for the enrollment station. The computer can be a laptop that the enrollment
officer commutes with, if required.
After permissions are granted on the enrollment template, you are ready to generate an enrollment agent certificate. You can sign in as a member
of the Security Smart Card group.
3. Open the browser. In the Tools/Internet Options/Trusted Sites category, add the location of the sub CA's certificate service page to the
Trusted Site list.
4. Open the smart card sub CA's certificate service from the browser, click Request a certificate, and then click Next.
5
5. Click Advanced request, and then click Next.
6
6. Click Submit a certificate request to this CA using a form, and then click Next.
7
7. From the Certificate Template menu, select Enrollment Agent. Under Key Options, select Microsoft Enhanced Cryptographic Provider v1.0
as your provider. In the example below, 1024 was selected as the Key Size from the common suggested lengths.
If you need to install the certificate on multiple workstations or for backup and restore during full deployment, activate the Mark keys as
exportable option. During backup, be advised that the private key is also copied; protect your backup media in accordance with the smart card
security policy that you determine for your company.
8
8. The Certificate Issued confirmation page appears. Click Install this certificate.
9
Be sure to review the lifespan or your certificate, and be aware that it can be renewed. A shorter lifespan assists in ensuring that rights and
responsibilities associated with specific administrative roles are adjusted as personnel change positions or leave your company.
10
Enrolling a Certificate on Behalf of Another User
The enrollment computer and agent are now equipped to enroll smart card users. To begin this process, request a certificate from the sub-CA by using
the enrollment machine. Sign in as the enrollment agent.
1. Click Request a certificate, and then click Next.
11
2. Click Advanced request.
12
3. Click Request a certificate for a smart card on behalf of another user using the Smart Card Enrollment Station.
13
4. The first time you complete this process, you will be prompted to install and run the Enrollment Station Control. Click Yes to continue.
14
5. On the Certificate Template menu, click the Smartcard Logon template. If you configured multiple sub-CAs, point the certificate request to the
proper sub-CA. On the Cryptographic Service Provider menu, select the associated service provider, and the user to whom the logon certificate
will be issued. In this example, the enrollee candidate is using a smart card and reader associated with GemPlus.
15
6. You are prompted to select the installed certificate that is authorized to perform the enrollment action. Click to select the certificate, and then
click OK.
16
7. You are then prompted to insert the enrollee's smart card. Click OK.
8. Insert the user's smart card into the reader/coupler, type the default card PIN, and then click OK. Most vendors ship cards with a universal default
PIN. For example, GemPlus uses 1234.
The enrollment officer must know the default PIN. Notice the option to change the PIN. The enrollment officer should create a new default PIN
which is known only to the enrollee or the officer. The officer should observe and confirm a default PIN change that is performed by the enrollee.
When you implement smart cards during full deployment, the new default PIN might have a limited lifespan, such as 24 hours. During this period,
the enrollee must change the PIN to a permanent personal alphanumeric sequence.
The logon certificate is "flashed" to the smart card, and a status summary screen appears.
17
The certificate properties can also be viewed. During full deployment, you can take a screen capture of this banner and send it by using e-mail to
the newly enrolled user's manager as a confirmation that the process completed successfully.
9. After you have reviewed the information on this page, click View Certificate to review the certificate information.
18
Top Of Page
Conclusion
Because of the comprehensive lab and test activities, and the inclusion of representatives from teams affected by the rollout, the smart card deployment
process was smooth and efficient.If you need to service remote sites during full deployment, entire blocks of blank cards can be prepared in advance by
using a PIN that is sent directly to the remote enrollment agent. The cards, enrollment laptop, card reader(s), and the PIN can all be mailed separately.
March 2001
19
.
Top Of Page
Links Table
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Published: March 1, 2001
1
. "
For information on Enterprise Services, see http://www.microsoft.com/es/
On This Page
Introduction
Smart Card Logon
Secured Sockets Layer Configuration
S/MIME
VPN Configuration
The Code Signing Configuration
Introduction
Hay Buv Toys (HBT) recognizes that using smart cards can significantly improve their users' experience, because smart cards are easy to use and can be
seamlessly integrated into their preferred applications. As part of smart card deployment, HBT must enable their core applications for smart cards. This
includes implementing the following processes:
Smart card logon
Client authentication with smart cards for Web applications
Encrypting and signing e-mail with smart cards
Virtual private network (VPN) authentication with smart cards
Digitally signing macros with smart cards
Top Of Page
Smart Card Logon
When a PC/SC-compatible smart card reader has been installed on a computer running Microsoft Windows 2000, the logon dialog box provides the option
for the user to insert a smart card.
Press Ctrl+Alt+Del to display the logon dialog box.
Enter your PIN instead of your user name and password. For example, GemPLUS cards use the default PIN 1234.
The administrator can configure user settings so that a user must log on to the system by using a smart card. HBT administrators decide to implement
strong security by enforcing a mandatory smart card logon to the HBT network. The following procedure describes how to configure user settings for
mandatory smart card logon.
1. Click Active Directory Users and Computers management console. Browse to the user account you want to change settings for, right-click the
account, and then select Properties.
2
2. Click the Account tab, and then under Account options, select Smart card is required for interactive logon.
3
3. Click OK to enforce mandatory logon with a smart card.
System administrators can also configure system response when a user removes the smart card from the reader while logged on to the system.
Administrators can choose from three options for how the system responds when a smart card is removed while a user is logged on:
No Action This is the default setting. When you select this option, nothing happens when the user removes the smart card.
Lock Workstation CTRL + ALT + DEL and then press Lock Workstation.
Force Logoff When you select this option, the user is automatically logged off the system when the smart card is removed. Use this option for
high security.
HBT decides to enforce the highest security for all their users. The following procedure describes how HBT can change the setting to Force Logoff for all
users in a group.
1. Under Active Directory Users and Computers management console, right-click uswest.haybuv.com.
4
2. Select the appropriate Group Policy Object Links, and then click Edit.
5
3. Click Computer Configuration, click Windows Settings, click Security Settings, click Local Policies, click Security Options, and then select
Smart card removal behavior.
6
4. In the Security Policy Setting dialog box, click Force Logoff, and then click OK.
7
The following illustration shows the Group policy after Lock Workstation is selected. After this policy is replicated to the appropriate computers, every
computer with a PC/SC-compatible smart card reader locks the workstation when the smart card is removed from the reader.
8
Top Of Page
Secured Sockets Layer Configuration
Secured Sockets Layer (SSL) encryption is a method for encrypting connections over the network. It is also a mechanism that enables a server to
authenticate to a client computer. SSL is the most frequently used encryption method, because, unlike Internet Protocol security (IPSec), an application
must recognize SSL to use it. Windows 2000 uses Microsoft Internet Information Services (IIS) and Microsoft Internet Explorer because both use SSL.
As part of their network updates, HBT decides to take advantage of the Windows 2000 SSL encryption services. Before HBT can configure an SSL
connection, they must install a certificate on the Web server that can provide the identity to the client. Clients are thus protected from Domain Name
Server (DNS) spoofing, in which somebody changes the IP Address for a computer and acts on behalf of this official server.
Web Server Certificate Enrollment
To complete certificate enrollment, HTB requests a certificate from the USWest user and machine enterprise subordinate authority.
1. Open the IIS management console.
9
2. Right-click Hay Buv Toys USWEST, and then click Properties.
10
3. In the Hay Buv Toys USWEST Properties dialog box, click the Directory Security tab. Under Secure communications, click Server
Certificate, and then click OK. The Web Server Certificate Wizard opens.
11
12
4. Click Create new certificate, and click Next. To obtain the certificate from a floppy disk, click Assign an existing certificate. This is the most
common way to assign an existing certificate, especially when you change the hardware for a Web server and have to import the old certificate.
13
5. If you are using an Enterprise subordinate certificate authority (CA), such as the USWEST Hay Buv Toys Users & Machine CA, click Send the
request immediately to an online certification authority. When you get your certificate from an offline CA, you have to save the request and
import the certificate later. Click Next.
14
6. Type the name for the certificate in the Name box, and set the length in the Bit length box.
7. In countries and regions where encryption restrictions exist, click Server Gated Cryptography (SGC) certificate (for export versions only).
For example, in Germany, United States software was limited to 40-bit/56-bit symmetric key encryption, while in Germany 128-symmetric key
encryption was allowed. Therefore, software vendors in the United States were not allowed to export strong encryption to Germany. Because
these export regulations have been changed, Microsoft offers a high encryption pack for Microsoft Windows NT 4.0 in Service Pack 6.0a and
Windows 2000, in which 128-bit symmetric encryption is provided for the operating systems. If a high encryption pack is installed on the client, you
do not have be concerned with SGC certificates.
15
8. Type the organization information, and click Next.
16
9. Type the Web site's name for the organization in the Common name box. The common name is the name of the computer on which you install
the certificate. Click Next.
17
Clients such as Internet Explorer 5.0 compare the name in the certificate to the URL address. If the name in the URL address does not match the
common name in the certificate, the user receives a warning which states that the certificates are valid but the names do not match.
For example, if you issued a certificate with the common name dcclab31 and then addressed the SSL site dcclab31.uswest.haybuv.com, you will
get following error, even though the site uses the same server.
18
10. Provide the necessary geographic information, and click Next.
19
11. In Certification authorities, select the appropriate CA. With the Active Directory, the wizard will only show certificate authorities that can issue
certificates for the Web server. Click Next.
20
12. The IIS Certificate Wizard provides a summary of the information you have provided on the Certificate Request Submission page. Click Next to
submit your request, and then click Finish to close the wizard.
21
Configure the Web Server for Secure Sockets Layer Communication
Now that the appropriate certificate is installed on the Web server, HBT can configure the SSL connection.
1. In the Hay Buv Toys USWESTProperties dialog box, click the Directory Security tab. Under Secure Communications, click Edit, and then click
OK.
22
2. Select the Require secure channel (SSL) check box if you want this site or virtual directory to be secured with encryption.
3. Click Accept client certificates or Require client certificates to ensure that clients also have to authenticate to the server, and then click OK.
23
Configure the Web Server for Certificate Mapping
In a Windows network environment, authentication is simplified because IIS has several authentication mechanisms. Authentication through certificates
is a popular option for clients that cannot authenticate through NTLM.
The following procedures describes how HBT maps specific certificates to a specific Windows 2000 user account.
1. In the Secure Communications dialog box, select the Enable client certificate mapping check box, and then click Edit.
24
2. In the Account Mappings dialog box, click the 1-to-1 tab if it is not already selected, and then click Add to select a certificate to map to a
specific user. Browse to the certificate to which you want to map to a user account, and then click OK.
25
3. Type the Map Name for the certificate, and then click Browse.
26
4. From the Names box, click the user account that you want to map to the certificate, and click OK.
27
5. Enter the appropriate password, and then click OK. The mapping is activated immediately.
28
Many-to-many mapping is an alternative to mapping one user account to one certificate. In a Many-to-1 relationship, several clients with a certificate
can be mapped to one Windows 2000 user account. This feature is very popular because users with a certificate are more trustworthy than those
without a certificate.
It is possible to map the anonymous user to the anonymous user account that IIS uses (IUSR_machinename), or to a special user account. HBT
1. In the Account Mappings dialog box, click the Many-to-1 tab, and then click Add to select a certificate to map to a specific user.
29
2. Browse to the certificate to which you want to map to a specific user account. Select the Enable this wildcard rule check box, provide a brief
description of the wildcard matching rule, and then click Next.
30
3. In the Edit Rule Element dialog box, select the criteria for the CA. For example, type Hay Buv Toys to look for certificates from the Hay Buv
Toys certificate authority. Click OK.
31
4. In the Mapping dialog box, click Accept this certificate for Logon Authentication, type USWEST\certmap in the Account box to ensure that
this is the account that IIS selects whenever a certificate from the Hay Buv Toys CA is presented to the Web site, and then click Finish.
32
Another option is global mapping of Windows 2000 accounts to Active Directory. With global mapping, each time an anonymous user enters the Web
server over an SSL connection and shows a certificate, the certificate is mapped to the Active Directory. Depending on the certificate template, the
certificate will automatically be published in Active Directory when the enrollment is completed through an enterprise CA. The following procedure
describes how HBT configures their system to enforce global mapping.
1. Run the Administration module for IIS, and then right-click the Web server name and select Properties.
33
2. Under Master Properties, select WWW Service, and then click Edit.
34
3. Under Secure communications, click Enable the Windows directory service mapper, and click OK. When this option is selected, user
accounts are authenticated against the Windows 2000 directory. For more information on this option, see the Windows 2000 documentation.
35
Client Authentification over an SSL-secured http Connection
When an administration sets require a secure channel to a Web site or a virtual directory, users have to communicate through https://. The following
illustration indicates what users see when they log on to an SSL-configured Web site with a smart card. Client authentication is required before users
can view the site. The following procedure describes how a user initiates the authentication process.
36
1. Type the address you are trying to reach, preceded by https://. When the Security Alert dialog box appears, click OK to continue.
2. In the Client Authentication dialog box, select the client certificate that the SSL Web server must authenticate against, and then click OK. This
is only required when the administrator specifies that client authentication is required.
37
3. Insert one of the smart cards from the Open Gemplus GemSAFE smart card dialog box, and then click OK.
38
4. Type your PIN, and then click OK.
When the user provides the PIN and authentication occurs, an SSL connection is established, and the following page appears.
39
The following illustration shows an unencrypted connection with network monitor.
40
This following illustration shows an encrypted connection with network monitor.
41
Top Of Page
S/MIME
One of the most popular applications used at Hay Buv Toys is e-mail. HBT wants to establish a secure communication infrastructure that provides
confidentiality, authentication, and integrity for internal and external e-mail communications. To secure the investment, HBT has already made smart
cards for authentication, e-mail encryption, and signing. HBT deploys a secured Secure/Multipurpose Internet Mail Extensions (S/MIME) infrastructure by
using Microsoft Outlook.
The following section describes how HBT enables Outlook for S/MIME while using smart cards.
Note: Microsoft Outlook 97 and Outlook Web Access (OWA) do not support S/MIME. S/MIME clients can also be enrolled with Key Management Services
in Microsoft Exchange 5.5 or Exchange 2000 or with the CA services Web client.
Outlook Configuration for S/MIME
Before you configure S/MIME in Outlook, be sure to register the smart card. To register smart cards, copy the smart card e-mail certificate to the local
certificate store.
1. Open Microsoft Outlook.
2. Fom the Tools menu, click Options, and then click the Security tab.
3. Under Secure e-mail, click Settings.
42
4. The stored S/MIME certificate is retrieved from the local certificate store and the S/MIME configuration is done automatically.
5. If you are using multiple key sets (dual key pairs), you must specify the certificate for encryption and the certificate for signing. Under Certificate
and Algorithms, next to Signing Certificate, click Choose, and then select the signing certificate you want. Then, next to Encryption
Certificate, click Choose, select the encryption certificate you want, and then click OK.
43
Note: The encryption algorithm used for e-mail privacy may vary. The "strongest" available algorithms of sender and recipient are always
negotiated by PKCS#7, regardless of the algorithm chosen before. Also, the strongest algorithms are determined by the available encryption pack
for Outlook (40-Bit or 128-Bit Outlook Encryption Pack).
In this example, only one key set, and therefore only one corresponding certificate is available for signing and encryption.
44
The following illustration shows the S/MIME certificate issued to user mail1. The certificate is used for e-mail encryption and signing verification.
The corresponding private key to this certificate is stored on the smart card.
45
Sending an encrypted and signed message with smart cards
The following section describes how a user encrypts and signs messages with smart cards. The user tasks are similar with KMS-enrolled S/MIME clients,
but require users to insert a smart card and enter the smart card PIN.
Window 2000 High Encryption Pack is not sufficient to acquire strong e-mail encryption for Outlook. Because Outlook uses its own cryptographic service
provider (CSP), Outlook 98 and Outlook 2000 provide their own High Encryption Packs. Outlook High Encryption Pack CSP (O2KDOM.EXE, O98DOM.EXE) is
available at: http://office.microsoft.com/
46
The following illustration shows an e-mail message that includes signing and encryption buttons on the Standard toolbar.
47
Users can also perform signing and encryption tasks from the Message Options dialog box, as shown in the following illustration.
48
When encrypting or signing an e-mail message, the user is prompted to insert a smart card.
49
After inserting the smart card, the user is prompted to type a PIN to access the private key stored in the smart card.
50
After the user enters the correct PIN, the e-mail message is digitally signed with the private key stored in the user's smart card, and then encrypted
with the public key extracted from the recipient's e-mail certificate, which may be stored in the directory or the Global Address List (GAL).
Decrypting and signature verification with smart cards
The following section describes the user experience when decrypting and verifying a digital signature with smart cards.
When attempting to open a signed and encrypted e-mail message, the recipient is prompted to insert a smart card and then type the smart card PIN.
51
The private key from the recipient's smart card performs decryption of the message. The public key extracted from the sender's certificate performs
signature validation. The Security line and the two icons located in the top right corner of the following illustration indicate that this e-mail message has
been signed and encrypted.
52
Top Of Page
VPN Configuration
HBT plans to connect the HBT USWest sales force through the Internet to corporate resources. HBT decides to use an Internet connection because
Remote Access Service (RAS) services are costly, and do not provide the transport security of select ISPs.
HBT chooses an ISP that provides points of presence (POP) over the Western United States and allows dial-up connections in every location for local call
rates. The selected ISP supports user authentication and accounting Remote Authentication Dial-In User Service (RADIUS). HBT plans to integrate
RADIUS into their environment so they can manage their user accounts rather than rely on the authentication services provided by the ISP.
This means that the HBT Active Directory must validate user access whenever an HBT user initiates authentication after completing a dial-up connection
on the POP or a tunneling connection on a VPN server. Although transport is provided by third parties, all authentication is managed centrally by HBT and
the account database is owned by HBT.
To enforce dial-up and VPN logon, HBT provides customized smart cards to the pilot mobile users. When a user inserts the smart card and types the PIN,
the dial-up or VPN connection is established. No user name or password is required.Dial-up connection is established when the user is authenticated and
authorized by the POP. The ISP POP sends the authentication request in a RADIUS package to the ISP Radius Proxy. ISP Radius Proxy forwards the
authentication request to the HBT Radius server. HBT Radius server then validates the authentication request with the HBT Active Directory account. If
the account is validated and authorized at the HBT site, the mobile user gains access to the ISP POP. This user authentication method is only supported
by Extensible Authentication Protocol; it is not supported by default authentication methods, such as Challenge Handshake Authentication Protocol
(CHAP), MS CHAP, or MS CHAP v2.
HBT corporate network is connected to the Internet through a Microsoft Internet Security and Acceleration Server (ISA) enterprise firewall. Located in
the DMZ are the Microsoft Radius Server (Internet Authentication Service IAS) and also Microsoft VPN Server. The Radius client for the HBT Radius
server is the ISP Radius Proxy, that proxies all HBT authentication requests from the POPs to the HBT Radius server.
For tunneling, HBT uses L2TP/IPSec, which provides additional security during transport. All packages are authenticated and encrypted with triple Data
Encryption Standard (DES). Also, the tunnel endpoints (VPN Server Mobile Laptop) are authenticated with certificates. Building a VPN connection
(tunnel) requires authentication to the corporate VPN server. Alternatively, Point-to-Point Tunneling Protocol (PPTP) and MS-CHAPv2 (User name and
Password Logon) is provided for non-W2K clients. The following illustration shows the HBT corporate network connections.
53
The following section describes the setup, configuration, and smart card logon for the VPN connection. The setup and configuration for dial-up
connections is similar.
VPN Server Setup and Configuration
Routing and Remote Access Services (RRAS) on Windows 2000 provides the HBT VPN service. The setup of Windows 2000 RRAS is installed by default
but not configured.
When you start the RRAS service for the first time, you are prompted to configure the service. Use the RRAS Setup Wizard to configure the RRAS service
as a RAS Server or a network router.
54
Before you configure RRAS as a VPN server, verify that IP is installed on the RRAS server machine and on all VPN clients. VPN service will not start
without the IP protocol installed on the client.
55
56
Be sure to specify which network card is connected to the ISP, and also the network card that is connected to the HBT corporate network.
57
58
VPN tunnels need their own IP addresses for tunnel endpoints. IP addresses can be assigned from the HBT corporate Dynamic Host Configuration Protocol
(DHCP) services or from a specific IP pool. The following illustration shows a specific IP pool with an address range of 10.0.0.51-10.0.0.60 for ten
concurrent VPN connections. If a DHCP for IP assignment is used on a VPN machine acting as a router, a DHCP relay agent must be installed.
59
60
VPN service does not authenticate users by sending authentication requests directly to the domain controller; RADIUS authentication is required, as
indicated by the following illustration.
61
62
The following illustration shows DCCLAB31 with the VPN server implemented and running.
63
RADIUS Server Setup and Configuration
Microsoft RADIUS server or IAS is responsible for granting or denying access to the ISP POPs and to the HBT VPN services. The HBT RADIUS server does
not have an account database. It queries Active Directory for user authentication through LDAP. RADIUS clients consist of the RADIUS proxies and HBT
VPN servers provided by the ISP. RADIUS service is not installed by default.
To install RADIUS service, start the Components Wizard, and then under Subcomponents of Networking Services: select the Internet
Authentication Service (IAS) check box to install IAS.
64
65
After IAS installation is complete, RADIUS server is running. The next step is to specify the RADIUS clients for the RADIUS server. HBT decides to declare
all VPN servers as RADIUS clients to this server. The ISP RADIUS proxy also acts as a RADIUS client.
66
Specify a Shared secret, and then check the Client must always se the signature attribute in the request check box.
67
68
IAS is now configured with the RADIUS clients. In this example, just the VPN servers are operational.
69
VPN Server Configuration for RADIUS and Smart Card Authentication
On the VPN server side, RADIUS must also be enabled. Smart card authentication is not set by default. VPN servers have to support EAP to support
smart cards or certificates (soft tokens). The authentication provider for the VPN server has changed to RADIUS. For configuration information, such as
the RADIUS Server name, a shared secret and the RADIUS authentication port is required.
70
71
EAP configuration can be set with RAS policies. In EAP Methods, smart card or certificate user authentication is selected. Click EAP Methods to configure
authentication types for EAP.
72
73
VPN Client Configuration for VPN and Smart Card Logon
The following section covers the authentication method for smart cards or certificates, and the VPN tunnel type (PPTP or L2TP/IPSec) for VPN client
configuration. For large deployments, Connection Manager Administration Kit is recommended.
1. Open the Network Connection Wizard.
2. Select a VPN connection, and then type the name of the VPN server. A new client connection, Virtual Private Connection, is created on the
machine.
74
75
3. To set the VPN types, click to select the VPN connection, and then click Properties.
4. Click the Networking tab, and then under Type of VPN server I am calling, select PPTP or L2TP/IPSec from the menu.
76
77
5. To configure EAP for the client computer, click the Security tab. HBT requires a server validation certificate from the trusted HBT Certificate
Authority. In addition, VPN clients will only connect to VPN servers from the USWest domain.
78
79
Requesting a Computer Certificate
When you select L2TP/IPSec, additional authentication processes are triggered. Before any user authentication will start, the machines will authenticate
with certificates to each other (mutual authentication). For this reason, machine certificates must be installed for L2TP/IPSec. For large deployments,
automatic enrollment of computer certificates by way of GPOs is recommended. This example illustrates the manual certificate request process. Be sure
to start MMC with the certificate snap-in for computers, not for users. In the following procedure only user-related certificate templates are
offered.Note: Rights to enroll Computer Certificate templates is managed within AD Sites and Services.
1. From the personal folder, start the Certificate Request Wizard, and click Next.
80
2. Select the Computer certificate template, and then click Next.
81
The Computer Certificate is now installed on the local computer, as indicated by the following illustration.
82
VPN Client Logon with Certificates or Smart Cards
Established RADIUS Authentication and VPN Connection
The following section illustrates client-side and server-side impressions of established VPN connections with smart card logon.
83
VPN connection parameters.
84
85
Different VPN tunnel types. On the left, a PPTP connection with MPPE 128-bit (Microsoft Point to Point Encryption similar to RC symmetric encryption
family). On the right, an IPSec connection in Encapsulated Security Payload with 3DES symmetric encryption.
86
87
A successful RADIUS authentication of the administrator, granting access to the VPN Server.
88
89
Unsuccessful RADIUS authentication of the administrator, denying access to the VPN Server. This is a result of a revoked certificate on the smart card.
90
VPN users that are currently logged on.
RADIUS, PPTP, and IPSec Network Traces
91
RADIUS authentication network trace between the VPN server and IAS server.
92
Establishing a PPTP connection between VPN client and VPN server. Smart card user logon is provided with EAP.
93
Establishing an L2TP/IPSec connection between VPN client and VPN server. Smart card user logon is provided with EAP.
Top Of Page
The Code Signing Configuration
Code signing is a popular way to establish additional security. Office 2000 prevents viruses from infesting the system by only letting macros run when
they are digitally signed.
Because macro viruses are common, HBT decided to configure the Microsoft Office 2000 suite to run only macros that were digitally signed.
The following section provides an overview on how to complete the following steps:
Configure Word 2000 to run only signed macros.
Sign Visual Basic for Applications code.
Determine what happens when a Word document is opened.
1. From the Tools menu in Microsoft Word 2000, point to Macro, and then click Security.
94
2. In the Security dialog box, click the security level you want for running macros. By default, the security level for signed macros is set to High,
and click OK.
95
In the following section, HBT enforces signing the Visual Basic for Application Macros.
1. From the open macro, on theTools menu, click Digital Signature.
96
2. In the Digital Signature dialog box, click Choose to select the certificate for macro signing.
97
3. In the Select Certificate dialog box, choose the macro signing certificates or code signing that you want, and then click OK.
98
The current VBA project is signed with the corresponding private key belonging to the code signing certificate, as indicated in the following illustration.
99
The code signing certificate is used to verify the digital signature of the macro, and the macro signature is generated when the VBA project is saved.
The corresponding private key to the code-signing certificate is located on a smart card. Therefore a smart card must be inserted and a PIN must be
typed in to access the private key of the smart card.
Opening an Office 2000 document that contains a macro
Before a signed macro will run automatically in Word, the user has to trust the administrator code-signing certificate. If the user does not trust the
certificate, the macro cannot be enabled.
100
The Administrator certificate is now trusted explicitly, so the macro can be enabled. In all other cases, the macro will not run.
101
The following illustration shows the macro running in Word.
102
The following illustration shows the administrator code-signing certificate is trusted. A list of all trusted certificates can be found in Word: on the Tools
menu, point to Macro, and then click Security. Click the Trusted Source tab.
103
The example companies, organizations, products, people, and events depicted herein are fictitious. No association with any real company, organization,
product, person or event is intended or should be inferred.
Top Of Page
Links Table
1
2
3
4
5
6
7
8
9
10
http://technet.microsoft.com/en-us/library/Dd277384.sma1010a_big(l=en-us).gif
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
http://office.microsoft.com/
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
http://technet.microsoft.com/en-us/library/Dd277384.sma10100_big(l=en-us).gif
101
102
103
1
."
On This Page
Introduction
Deployment Remarks
References
Introduction
This document describes the applications developed for a company called Hay Buv Toys (HBT). HBT, headquartered in Seattle, develops and sells the
latest in technological toys. In addition to operating stores worldwide, the company has a Web site that customers can use to buy merchandise. HBT
customers who shop online receive a personalized smart card to access the Web site and pay for orders.
In this scenario, the following technologies are used:
On card applications
Remote procedure call (RPC) or proxy calls of smart card application programming interfaces (APIs)
Cryptography
Authentication
Automated personalization of the cards
Although there are multiple ways to use Microsoft Windows for Smart Cards, such as with mobile phones, this scenario uses it for a smart card that
connects to a standard PC reader (ISO 7810 form factor).
Architecture
TheHBTonlineorderingsystemisbasedonasmartcardbasedapplication,aclientbasedapplication,andaserversideapplication.Theapplicationhas
a Web-based user interface and server-side request processing.
The HBT control is instantiated by a client-side Microsoft Visual Basic script when a user accesses the Web site. This control can also be used by other
client applications.
The following figure illustrates the client application and smart card.
2
Workflow
On the HBT Web site, the user can choose between charging with the card or buying a product. When the transaction starts, the client application
generates a random transaction ID that is stored on the smart card. The transaction ID is transmitted with all the other information to the server, which
then processes that request. The server component analyzes the encrypted information from the client. If the server accepts this request, it encrypts
the information together with the transaction ID and the result, and sends it back to the client, as shown in the following figure.
3
The client application, realized as an ActiveX control, decrypts the message with the Data Encryption Standard (DES) key from the smart card. The
decrypted information is then used to manipulate the amount that is stored on the card. Whenever a method is called that changes the amount, the
transaction ID on the card is reset. This prevents the user from using the encrypted message more than once.
The user authenticates access to the smart card by using a personal identification number (PIN). The smart card and the server application use the
same DES key to encrypt and decrypt the data. In the future, HBT hopes to improve security by using stronger encryption, such as triple DES and by
using private or public keys.
Checklist
The system requirements for the client are:
Microsoft Windows 2000 Professional (Service Pack 1 or later)
Microsoft Visual Basic 6.0 (Service Pack 5 or later)
Windows Smart Card Toolkit 1.1 (Service Pack 1)
Hay Buv client control (HayBuvControl.ocx)
A smart card reader device
A smart card compatible with Windows for Smart Cards (see http://www.microsoft.com/smartcard/deploy/
4
for vendors)
The system requirements for the server are:
Windows 2000 Server (Service Pack 1 or later)
Internet Information Services (IIS) 5.0
Visual Basic 6.0 (Service Pack 5 or later)
Windows Smart Card Toolkit 1.1 (Service Pack 1 or later)
Hay Buv server component (HayBuvServer.dll)
Installation
To install a new application on the smart card:
1. Load the application on the smart card.
2. Modify the SmartCard.xml file for the deployment tool.
3. Personalize the smart card with the deployment tool.
To test the smart card installation:
Run the test tool.
Setup
The procedures required to set up the client are summarized as follows:
1. Register the HayBuvControl.ocx ActiveX control.
2. Insert the smart card with the payment application on it. The smart card must contain the common DES key as the server and other information.
3. Modify the security settings of Microsoft Internet Explorer to allow running the ActiveX control.
4. Test the installation.
The procedures required to set up the server are summarized as follows:
1. Copy .asp and .dll files to the server.
2. Create a new Component Services application, such as "Hay Buv Payment System."
3. Register the HayBuvServer.dll component.
4. Install this component in the Component Services application.
5. Create a new virtual directory on IIS.
6. Test the installation.
Walkthrough
The following procedure represents a user's experience of using a smart card to make a purchase on the Hay Buv Toys Web site:
1. Start Internet Explorer, and go the HBT Web site.
5
In the initial window of the pilot, the Get balance option can be processed directly on the client. All other actions require a validation from the
server.
2. Click Connect to connect to the smart card reader.
For security reasons, user authentication is required. In this pilot, there are two groups defined with different access rights:
Admin. Members of this group have full access to the file system and can change key files or update the application.
User. Members of this group have restricted access rights.
In the pilot, there are two different users called Known Principals (KP), each with a six-digit PIN:
admin (PIN: 123456). A typical member of the Admin group.
user (PIN: 123456). A typical member of the User group.
These security settings are part of the solution manager of the Windows Smart Card Toolkit and can be found at: \CompiledDiskImage\fsimage.txt
3. In the Login dialog box, type your user name and PIN, and then click OK.
After authentication, a transaction can begin. To do this, you need to select a different action to get a balance or to specify the amount.
4. Clicktype,andthenclickExecute.
6
The Confirm window appears and shows the information that the server received. The cipher text shows the encrypted response from the server.
Cipher text covers the transaction ID, amount, action, and decision to accept the transaction or not. When the Confirm button is clicked, the
balance on the card is processed and the result is sent to the server that can close the transaction.
5. Click Confirm. The ActiveX control generates a random transaction number and stores it on the smart card.
7
HBT developed a test tool for the pilot to simulate the client/server communication.
8
Top Of Page
Deployment Remarks
Deployment of Windows for Smart Cards Applications
For the development phase, you can use special development cards. These cards have a flashable, electrically erasable programmable read-only memory
(EEPROM) to test different operating system configurations and applications. These cards can be used for smaller deployments, but doing so poses a
huge security gap. In larger deployments, production cards should be used. After the application is developed and tested, the manufacturer can install it
on the development cards.
Deploying the developed applications in the enterprise is a big issue. For the pilot phase, it is appropriate to use development cards that are flashed by
the solution manager of the Windows Smart Cart Toolkit. This uploads the Windows for Smart Cards operating system and the file system with the
applet. To simplify deployment, you can use some of the following tools in the Windows Smart Cart Toolkit:
RFlasher.exe to load the operating system.
FSLoader.exe to load the file system image onto the smart card.
FSBuilder.exe to build the file system image.
For the HBT project, an additional tool is implemented to roll out the application together with personalized information on the customer cards. This tool
obtains its information from an .xml file with the following schema:
<?xml version="1.0" encoding="ISO-8859-1"?>
<HayBuv>
<Header>
<DESKey></DESKey>
<ImageFile></ImageFile>
</Header>
<SmartCards>
<SmartCard>
<Firstname></Firstname>
<Lastname></Lastname>
<SerialID></SerialID>
<Amount></Amount>
<Expiredate></Expiredate>
</SmartCard>
...
</SmartCards>
</HayBuv>
During full deployment of the application, the manufacturer may provide the cards. These production cards should carry the most parts of the application
in a non-flashable chip or in ROM. The developer decides how many parts of the system should be stored in ROM. For security reasons, the user should
not be able to manipulate the application and the keys on the card, or even read the keys.
Top Of Page
References
http://www.microsoft.com/windowsce/smartcard/
9
http://msdn.microsoft.com/library/en-us/wcesecur/htm/_wcesdk_windows_ce_smart_card_support.asp
10
http://www.gemplus.fr
11
(You must register at the Gemplus site in order to download this resource).
Bertil Syamken: MCS Germany
March 2001
For information about Enterprise Services, see http://msdn.microsoft.com/library/aa286569.aspx
12
.
Top Of Page
Links Table
1
2
3
4
http://www.microsoft.com/smartcard/deploy/
5
6
7
8
9
http://www.microsoft.com/windowsce/smartcard/
10
http://msdn.microsoft.com/library/en-us/wcesecur/htm/_wcesdk_windows_ce_smart_card_support.asp
11
http://www.gemplus.fr/
12
http://msdn.microsoft.com/library/aa286569.aspx

Smart Card Deployment Cookbook

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Smart Card Deployment Cookbook

Загружено:

Авторское право:

Доступные форматы

My Collection

Вам также может понравиться