Logistics of Smart Card Deployment

Article
03/24/2009

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

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 https://www.microsoft.com/msf/ Before describing the deployment process, the following overview of smart cards provides a starting point for understanding the technology involved.

Understanding Smart Cards

Although smart cards are often compared to hard drives, they are "secured drives with a brain"—they store and 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 Windows for Smart Cards–compliant third-party vendors to provide enterprise management tools that are compatible with Microsoft Windows 2000. 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.

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.

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: https://www.microsoft.com/msf/.

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) database or Active Directory™? If you want to minimize interaction with your smart card vendor, the vendor can supply you with a few cases of 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.

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; perhaps 100–200.

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.

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.

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
Smart card logon to a Windows 2000–based enterprise
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?
- Combi-card—building access and embedded smart card.
- 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

Microsoft Enterprise Services

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

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

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