This documentation is archived and is not being maintained.
Post Mortem Securing a Government Agency with Smart Cards
John Morello is a Senior Consultant with Microsoft, specializing in network security and public key cryptography. He's pretty sure, though not entirely certain, that no one was watching him while writing this article. Read John's blog at blogs.technet.com/morello.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Homeland Security Presidential Directive 12 (HSPD12) requires Federal government agencies to begin utilizing strong, two-factor authentication for physical and logical access to Federal buildings and computer systems. I recently led a project to support HSPD12 for a key Federal agency. It involved the implementation of a smart card issuance and management system, as well as the public key infrastructure (PKI) foundation it leverages. While this solution was initially targeted at Federal agencies, it provides a compelling cost-effective solution for organizations in all markets that want to increase the security of their technological and physical assets.
- The Office of Management and Budget (OMB) has mandated that all Federal agencies must use approved Shared Service Providers (SSPs) for hosting and managing PKI services. In other words, the Certificate Authorities (CAs) must be operated in a secure, offsite datacenter managed by a third party.
- The Federal Information Processing Standard (FIPS) 201 standard that outlines the technical and procedural requirements for complying with HSPD12 is new. No implementations had been performed before and much of the technology required was in development during the project.
- The solution needed to support employees, contractors, and non-governmental employees in multiple agency branches, each with its own requirements and constraints.
- The solution had to support offline and remote users, provide centralized card management and auditing, and integrate with existing systems. The certificates had to be broadly interoperable within the Federal government and beyond.
A solution was designed based on the Certificate Services component of Windows Server™ 2003, in addition to products and services from key Microsoft partners. Following Microsoft® Operations Framework (MOF) and Microsoft Solutions Framework (MSF) best practices, the architecture was built in a lab environment, then moved to a micro-pilot deployment of about 10 users, then to a broader pilot of approximately 250 users. After vetting the technical design and working out new operational processes for the organization, the solution was moved into a full-production deployment and all staff members received smart cards.
Microsoft Consulting Services (MCS) worked with several key partners, using the strengths of each to provide a complete solution. Alacris provided the registration authority (RA) software, idNexus, which interfaces with the Windows® CA platform and handles card issuance, management, and auditing. Gemplus provided the smart card hardware. Cybertrust, an OMB-approved SSP, provided a secure, managed hosting solution for the components operated under the Federal Common Policy. nCipher provided the hardware security modules (HSMs) used to protect the key material on the CAs.
The organization’s existing Active Directory® architecture was a single forest with two domains: an empty root and a single domain used for all users and computers. The forest and domain functional levels both used Windows Server 2003. Another separate Windows 2000-based forest, used solely for Exchange Server, was being migrated into this Active Directory during the project. Microsoft Identity Integration Server (MIIS) 2003 was used to provision and manage all accounts. This polled the organization’s human resources database as its authoritative information store. The solution we put into place also needed to integrate with MIIS to automate as many tasks as possible.
Prior to this smart card project, I implemented an internal PKI for the organization that was used to issue all certificates that did not require extra-organizational interoperability. Its primary uses included IPsec, secure sockets layer (SSL) for internal Web sites, and 802.1X. This PKI has continued to operate after the smart card project as it allows the organization to is sue certificates with no incremental costs and to take advantage of the automatic certificate provisioning and maintenance capabilities in Windows.
The length, approach, and execution of a smart card deployment can vary greatly depending on the needs and goals of a particular client. Thus, it’s important to understand the goals for this specific project before discussing how they were satisfied.
From a certificate and cryptography standpoint, each card stores two certificates and key pairs. The authentication certificate uses a 1K key and facilitates logon to Active Directory, IIS, and any other public key-enabled applications the organization chooses to deploy. The signing certificate uses a 2K key (to conform to guidance set forth by FIPS 201 about key sizes for signing keys) and is used for digitally signing e-mail, Microsoft Office documents, and Adobe documents.
Due to records retention requirements, the organization chose not to enable encryption certificates (known as key management certificates in FIPS 201 parlance) in the initial deployment, although this may be revisited at some future time as new technologies make archival operations more feasible for encrypted messages and documents.
Though the deployed cards can be integrated with virtually any existing physical security access systems (such as magnetic strip or contactless radio frequency (RF) readers), I’m not going to discuss that here. Typically, physical access integration is more a matter of understanding what technologies are currently used, then making sure the card bodies used for the smart cards include appropriate hardware to support those technologies. While certificate-based physical access systems are being developed, they are not yet mature enough to spawn widespread adoption, though I expect that to change in the next few years.
From a CA and PKI support standpoint, the solution needed to be reliable, particularly for certificate revocation list (CRL) publication. Also, though the solution would be hosted by an SSP, connectivity between the SSP’s network and the organization’s network should be kept to an absolute minimum. Thus, simply parking a CA joined to the organization’s domain at the SSP’s datacenter was not a viable option.
Finally, the card issuance process, as well as the physical cards themselves, had to be compliant with the Personal Identity Verification (PIV) standard outlined in FIPS 201. The PIV standard details the specific physical and data requirements of the smart cards, the way they are issued, and their validity periods. Again, though many of these choices are defined by the standard, the fact that the project was occurring in parallel with the development of the standard and the products that support it introduced greater risk into the project.
The project’s architecture was divided into three major components: the hosting solution, the registration solution, and the infrastructure solution. Cybertrust provided the hosting solution by running CAs in a dedicated environment that fulfilled the organization’s needs and were compliant with Federal guidelines for securely operating CAs. Alacris provided the registration solution with its idNexus product that allowed the agency to have a full-featured management solution for card issuance and lifecycle management. Microsoft provided the infrastructure solution, including the CA software, user authentication store, and card logon capabilities within Windows. When combined, these solutions offer a method for the agency to satisfy its requirements without a dedicated PKI staff or rigid outsourced solutions.
Figure 1 Hierarchy
A number of Microsoft products were involved in the overall solution. The organization had already standardized on Windows XP Professional SP2 as its client operating system and Outlook®2003 for its e-mail application. Active Directory was already deployed and was upgraded to the Windows Server 2003 schema (though some Domain Controllers were running Windows 2000 Server). Windows Server 2003, Enterprise Edition SP1 was used to run the CAs, and SQL Server™ 2000 SP4 was used to run the database employed by idNexus. By utilizing Windows XP, Outlook 2003, and Active Directory, the organization did not need to deploy new software to facilitate smart card logon to Windows or to enable digital signing of e-mail.
At the root of trust, common to all Federal agencies, is the Federal root CA. The Federal root has signed the certificates of CAs run by SSPs like Cybertrust, who are vetted by the Federal PKI Policy Authority and have demonstrated compliance with the Federal Common Policy Framework. As one of these SSPs, Cybertrust can then sign the certificates of CAs it operates in compliance with the Common Policy on behalf of its customers. Figure 1 illustrates the relationships between these CAs.
Between an end entity certificate and the Federal root CA, there are two additional layers of CAs. Directly subordinate to the Federal root is the Cybertrust root CA, which forms the top of the CA infrastructure Cybertrust runs for various Federal customers. The Cybertrust CA is then used to sign the keys of the client agency’s CA, which is ultimately responsible for signing the certificates of its staff members. This issuing CA is the only one that is online and available on the network. The agency can add capacity to the hierarchy by commissioning new enterprise CAs following the same process used to build the original CA.
Note that even in the hosted solution that Cybertrust provides, the certificates issued to agency staff members are still branded with agency-specific information. In other words, the Issued by field on the certificate will show the name of the organization’s CA rather than that of Cybertrust or any other external party. Figure 2 gives you an idea of what a Windows user would see if they were to examine a certificate issued in this architecture.
The interesting and unique part of the solution is not really the CA hierarchy, but the mechanism for providing the CA with the information needed to create certificates (usernames, e-mail addresses, and so on). The Windows CA service was designed primarily for use on an organization’s internal network. As such, by default, it assumes that it will have connectivity to Domain Controllers and that end users will be able to communicate directly with it using remote procedure calls (RPC) and DCOM. In a hosted scenario, though, this approach is not desirable, as few customers want to extend their internal network into an external organization’s datacenter. Thus, the key to the entire architecture of this project is the way in which this connectivity requirement is avoided (see Figure 3).
Figure 2 Certification Path
Figure 3 The Architecture
I used the concept of a shadow forest to eliminate the domain connectivity requirements of a classical Windows CA deployment and required that only a few protocols be allowed between the hosting organization and the client agency. A shadow forest is simply a standalone forest (no trust relationship to the internal forest) run at the hosting provider that contains a duplicate of a subset of the organization’s internal forest. In this case, the subset contains only those user objects and attributes required to create certificates. Data is synchronized from the internal forest to the shadow forest using MIIS with Kerberos and Lightweight Directory Access Protocol (LDAP), and no passwords or other sensitive information traverse the link between the two networks.
The RA component (idNexus) was also deployed at the SSP datacenter and pointed to the shadow forest for its authoritative database. Card issuers can simply access idNexus through normal Web protocols (HTTP and HTTPS) to create cards for users. The result is a solution that allows the agency to utilize the SSP for hosting the CAs, while maintaining local control of the issuance process and greatly limiting connectivity between the two environments.
Because the solution utilizes a shadow Active Directory as the authoritative database for PIV data, only two changes were required in the current directory: the expansion of the use of MIIS to push selected user objects and attributes from the production directory to the shadow directory, and the publishing of the new CA’s certificate into the NTAuthCertificates container. No trust relationships were created between the two directories and no connectivity was allowed from the SSP network into the organization’s network.
MIIS is a centralized service that stores and integrates identity information for organizations with multiple directories, and it was already in use within the client’s environment. In this case, the existing MIIS installation has been extended to enable the capability for synchronizing objects into the new shadow domain. For agencies that do not currently have MIIS deployed, other directory synchronization tools that support Active Directory can perform the same function. The Identity Integration Feature Pack for Windows Server 2003 can also be downloaded and used. This includes a version of MIIS that is capable of synchronizing data between Active Directories, which is all that’s required for this design.
Any user account for which a PIV card will be created is synchronized, along with a subset of the attributes required to create a PIV certificate. These attributes are: cn, displayName, distinguishedName, givenName, initials, mail, name, sn, and userPrincipalName. Other user data, such as passwords and group memberships, are not necessary for issuing certificates and are not synchronized.
The NTAuthCertificates container in the internal Active Directory (CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=domain,DC=agency,DC=gov) has been updated to include the certificate of the CA that is being run by Cybertrust on behalf of the agency. This update was required in order to facilitate smart card logon within the internal agency environment.
Integrating Smart Cards
At this point, you may be wondering how smart card logon would work in a scenario where the issuing CAs are not members of the same forest as the users themselves. This is the most commonly asked question about the design, so it’s useful to reexamine the mechanism by which Windows supports logon with smart cards. The process can be condensed into the eight steps that are listed in the sidebar Windows Logon with Smart Cards.
Windows Logon with Smart Cards
1 Interactive logon using a smart card begins when a user inserts a smart card into a smart card reader; this action signals Windows to prompt for a PIN.
2 The logon request first goes to the Local Security Authority (LSA), which it subsequently forwards to the Kerberos authentication package running on the client.
3 The client-side Kerberos package includes the user’s x.509 version 3 certificate, retrieved from the smart card and an authenticator that is digitally signed by the user’s private key.
4 The Kerberos package sends an authentication service request to the KDC service running on a Domain Controller to request authentication and a Ticket Granting Ticket (TGT).
5 The KDC verifies the certification path of the user’s certificate to ensure that it can be trusted. The KDC uses CryptoAPI to build a certification path from the user’s certificate to a root CA certificate residing in the system root store. The KDC then uses CryptoAPI to verify the digital signature on the authenticator that was included as signed data in the pre-authentication data fields. The signature verification is done using the public key from the user’s certificate to prove that the request originated from the owner of the corresponding private key.
6 The KDC service queries the Active Directory for account information. The KDC service retrieves user account information from Active Directory based on the UPN specified in the Subject Alternative Name field in the user’s public key certificate. The account information that the KDC retrieves from the directory is used to construct a TGT, which will include the user’s Security ID (SID), the SIDs for any domain groups to which the user belongs, and potentially the SIDs for any universal groups in which the user is a member (in a multi-domain environment). The list of SIDs is included in the TGT’s authorization data fields.
7 The client decrypts the TGT using its private key to get the KDC secret key.
8 The client validates the reply from the trusted KDC. It verifies the KDC’s signature by building a certification path from the KDC’s certificate to a trusted root CA and then using the KDC’s public key to verify the reply signature.
So, how does the Key Distribution Center (KDC) know that a certificate is trustworthy—in other words, that the User Principal Name (UPN) is validly representing the account holder? This is the purpose of the NTAuthCertificates container. So long as the signer of a given certificate is included in NTAuthCertificates and the chain validates properly (no certificates appear on CRLs and all CRLs are available), the KDC will authenticate the user as whatever is specified in the UPN included in the Subject Alternate Name field in the certificate. This mechanism truly is the cornerstone of the entire architecture, as it allows us to separate the Active Directory where issuance takes place from the Active Directory where the cards are actually used.
Once cards that can be used for smart card logon have been deployed to users, the organization can begin to enforce two-factor authentication in the logon process. This is where the security value of the cards first becomes truly tangible. Most security professionals are painfully aware of the shortcomings of passwords in today’s threat environment, so I won’t rehash them here. Suffice to say, the capability to require users to log on with their cards provides a much stronger barrier to account compromise than passwords of lengths useable by most humans. Unfortunately, technical and procedural barriers exist today that complicate the enforcement of smart card logon and make it impossible for some types of users.
These barriers are mostly in the form of applications that do not support smart card authentication. For example, in Windows XP, an administrator cannot add a computer to a domain using smart card authentication. Microsoft is working to eliminate these barriers in Windows Vista™, but a phased approach to smart card logon enforcement is a recommended until Windows Vista is widely deployed in your organization.
There are two ways to force users to use smart cards for Windows domain logon: user-based enforcement and machine-based enforcement. When utilizing user-based smart card enforcement, Active-Directory sets the user password to a 127-character random value unknown to the user and administrator. This setting is enabled from Active Directory user account attributes and requires the user to log on with a smart card, regardless of what computer or service they attempt to access. Machine-based enforcement, on the other hand, is based on a new Group Policy setting that is valid in Windows XP SP2. The setting is named "Interactive logon: Require smart card" and is a computer Group Policy that can be configured from Active Directory.
I developed the following phased approach for my client to begin enforcing card logon. It’s the same approach I’d recommend for most any other organization looking to do the same.
Phase 1: Machine-based enforcement on standard workstations Because machine-based enforcement is the least disruptive mechanism for forcing smart card authentication, it should be implemented first. The Group Policy setting to force smart card logon to a computer will be enabled on a Group Policy Object (GPO), and that GPO will be linked to an Organizational Unit (OU) containing standard agency workstations. Standard workstations are those used for general knowledge-worker tasks, such as creating and viewing documents, collaboration, and line-of-business applications. Workstations used in more specialized scenarios, such as those used by administrators, will not have this setting enforced. The net result of the setting will be that all workstations that are members of this OU will only allow users to log on with their smart cards.
Phase 2: User-based enforcement on structured task workers Staff members who use their workstations to perform a relatively small number of well- known tasks, such as running a specific line-of-business application or using Outlook, have their accounts configured to require smart cards for logon. Once this setting is enabled on these user accounts, the users will no longer know the password for the account and will only be able to authenticate with their smart cards. Thus, in this phase, the agency will identify those users who fall into the structured task category, and then enforce smart card logon only on those user accounts.
Phase 3: User-based enforcement on non-IT staff All non-IT staff within the organization will have their primary Windows user accounts changed to require smart card logon. This phase can only be implemented after the agency has ensured that all applications that authenticate users against Active Directory are capable of supporting smart card logon. Thus, the organization may not be able to implement this phase until future versions of the software it uses are available. In this phase, domain administrative accounts will be excluded from the requirement, as it is more likely that administrative applications (such as domain joins) will require user name and password combinations.
Phase 4: User-based enforcement on all accounts This phase requires all Active Directory accounts used for interactive logon, including administrative accounts, to use smart cards for logon. This is the most far reaching and potentially disruptive phase, but also the one that represents the greatest relative security gain. Because of limitations in current operating systems and applications, the agency will not be able to implement this phase until some systems are upgraded to Windows Vista.
The most important thing I learned from this exercise is that FIPS 201 compliance is within reach, using many of the same Microsoft products you’re already familiar with. Though costs and implementation times vary from organization to organization, you can lay down the initial infrastructure to begin issuing cards very quickly. Also, since this project has taught me many lessons, future deployments will be much faster and smoother. I made some important observations during the course of this project that I hope will be useful to others working on FIPS 201 solutions.
Never underestimate the importance of certificate revocation lists. The great majority of smart card logon failures (as well as other general failures with certificate usage) are the result of stale or inaccessible CRLs. Ensure that CRLs are published on time and are available to clients, Domain Controllers, and any other systems that utilize certificates. I strongly recommend listing an HTTP path first in the CRL distribution point (CDP) extension, as load balancing and availability solutions are much more prevalent for Web servers than for LDAP servers.
Invest significant time during the course of a smart card project to education and evangelism. If your organization uses cards only for authentication to Active Directory, then you won’t be close to tapping the great potential smart cards provide in other authentication scenarios. You should work with application development teams to educate them on the capabilities and benefits of the cards and encourage them to support smart cards for authentication.
Automate as much of the build process of the solution as possible. I had a collection of 12 scripts to automate everything from directory setup to CA configuration. This reduces the chances of making minor errors during implementation and is a great aid during testing. Ideally, your deployment documentation should consist primarily of "Run script X, then run script Y" instructions. By scripting the deployment, you make it faster and more consistent.
Because of the amount of lab testing you’ll be doing, you’ll want the ability to quickly roll out ideas and roll back configurations of your environment. Virtualization software like Microsoft Virtual PC is a great asset for this. In the course of this project, I was able to condense the entire solution down to two virtual machines running on my laptop. With these two virtual systems, I could almost instantly test any aspect of the system from wherever I happened to be at the moment.
"Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure" Microsoft Corporation
"FIPS 201 Personal Identity Verification (PIV) of Federal Employees and Contractors" NIST. 25 Feb 2005
"Homeland Security Presidential Directive/Hspd-12" Office of the Press Secretary. 27 Aug 2004
"Windows Server 2003 PKI Operations Guide" Microsoft Corporation
Aim to standardize user components as much as possible. In other words, evaluate, test, and then decide on a single card chipset and the associated software. Choose a few different form factors of readers, all of which should be WHQL certified for different user needs. For example, this project uses three standard reader types: a standalone USB reader, a PC Card reader for laptops, and a keyboard integrated reader for space-constrained environments. Standardizing on hardware and software allows you to push out a standard set of drivers and card software to all users. It also makes subsequent support easier for an organization as user components are known quantities and help desk staff can be trained on each type of component.
As with any large technical project, collaboration between key stakeholders is critical. IT security, physical security, human resources, legal departments, and many other factors played a role in this project.