10.2 Using Smart Cards

Smart cards can have a variety of uses on your network aside from user logons. They can be used for secure logons, application access, general purpose cryptography, and more. Regardless of how you choose to use smart cards, you'll need to make sure you keep track of them and keep them secure. In the next few sections, I'll give you some tips for effectively using smart cards.

10.2.1 Secure Logon

Smart cards are an effective means of user identification, but as a physical factor, they can be lost or damaged. Deciding to use smart cards in your organization means committing to physical management of those cards. Here are some tips for making smart card management easier:

  • Make sure your users have an easy, fast way of reporting lost or damaged smart cards.

  • Provide your helpdesk or other organization with the means to quickly disable lost cards by revoking their certificates in your PKI. Exactly how you accomplish this depends on what PKI solution you're using. With a Windows Server 2003 certification authority (CA), you simply open the Certification Authority MMC snap-in from any authorized client, right-click a certificate to revoke it, and then publish an updated certificate revocation list. For detailed instructions on how to complete this task, see the "Revoking Issued Certificates" section in Chapter 9.

  • Ensure that your users can quickly obtain replacement cards. Keeping a supply of cards on hand in each of your company's offices, for example, provides faster service than shipping them all from a central location whenever a user needs one.

10.2.2 General Purpose Cryptography

Remember that smart cards never transmit their encryption keys to the host computer. Instead, the computer transmits data to the smart card, which encrypts it and sends it back. This behavior provides increased security for encryption keys, which are tied to the physical card rather than to a specific computer.

However, the increased security of smart cards comes at a price. Because the private key is created on and never leaves the smart card, it cannot be archived. This means that when a smart card is lost, stolen, or damaged, the private key is gone forever. This is compounded by the smart card's portability, which encourages users and administrators to carry them around until they're damaged well before their expected lifetime is up. This can be a drawback if large amounts of data or critical data is protected by this key. Care should be taken to use smart cards in appropriate situations and ensure that backup plans exist in case of smart card key loss. Users should also be cautioned about the proper care of smart cards, which includes the following basic guidelines:

  • Do not store the smart card in an eel-skin wallet. Actually, this is a joke: eel-skin wallets damaging magnetic stripe and smart cards is purely a myth.

  • Do not use a smart card for any "ancillary" use that you might use a regular credit card for, such as unlocking a door or scraping cheese off the inside of a microwave oven. Smart cards are somewhat flexible, but even a minor scratch or overextension of the chip's circuitry can render it inoperative.

  • Carry the card in a protective sleeve. These are available from smart card manufacturers at a nominal cost.

  • Remove the smart card when it is not in use or under direct observation. This rule can be used in conjunction with the computer-locking group policy mentioned earlier to lock unused workstations and ensure the smart card is not stolen.

The design of smart cards makes them ideal for all forms of cryptography. In addition to the private key used for logging on, smart cards can contain a general purpose private encryption key. The additional key allows the smart card to be used for all a user's cryptography needs, including conducting e-commerce, digitally signing email, and so forth. Smart cards can actually make cryptography more accessible to your users, since they can use their smart cards on any computer equipped with a reader. Normally, cryptography keys are stored on a computer, making it difficult for users to carry their keys around with them. By storing keys on a smart card, users can carry their keys around with them, making them more likely to use cryptography in appropriate situations.

10.2.3 Distributing Smart Cards

No matter how you choose to use smart cards, remember that they represent your users' identities. You need to ensure that smart cards make it to the correct users and that the users receive the correct PINs for their smart cards. Smart cards should be physically distributed by a person who recognizes each employee. PINs should be communicated via voice or a separate piece of paper, in much the same way that your bank gives you the PIN for a new ATM card. By visually verifying that the correct user has the correct smart card and PIN, you can be assured of the smart card's security.

Many organizations deploying smart cards find it useful to allow the smart card recipient to set her own PIN. Similar to when you activate a new credit card, you provide the card to the individual with reasonable authentication and then require her to further prove her identity before first use. This can be done by creating a custom application that asks the user for some personally identifying piece of information (such as her social security number) and then authenticates that against a database before allowing her to choose an initial PIN. This helps keep management and operation costs down by automating part of the deployment process, which as I mentioned can get quite expensive. For more information on developing this type of custom application, a great reference is The Smart Card Cryptographic Service Provider Cookbook at http://msdn.microsoft.com/library/en-us/dnscard/html/msdn_smart_card.asp.

10.2.4 Implementing Smart Cards in Your Organization

Actually implementing, distributing, and using smart cards for the first time can be a daunting process. With that in mind, here's a complete, step-by-step outline of what you'll need to do to implement smart cards in your own organization.

A great online resource for smart card deployment is Microsoft's Smart Card Deployment Cookbook, available at www.microsoft.com/technet/security/topics/smrtcard/smrtcdcb/default.mspx. PKI first

Before you can begin using smart cards, you need to have PKI deployed in your environment. I've covered how to do that in Chapter 9. As I've mentioned earlier, your PKI can be an extension of a commercial certification authority, or you can deploy your own root CA. Whichever method you choose, get your PKI up and running, and thoroughly tested, prior to starting your smart card deployment. Enrolling users

Smart cards show up from the factory without much in the way of "smarts" on board. Specifically, they're lacking the digital certificates that make them useful. During the enrollment process, you'll encode certificates on the cards and issue them to specific users in your organization.

Typically, enrollment is done in person, meaning the smart card recipient actually has to show up and get his card. This can be very inconvenient for users and difficult to schedule, but it's a security requirement. If you simply mailed completed cards out in interoffice memo pouches, you'd have no assurance that the correct users received the correct cards, compromising your entire deployment. The questions surrounding enrollment processes are explored in depth in Chapter 9.

Most organizations like to set up a centralized enrollment station, complete with a dedicated certificate-issuing server and the necessary card readers and burners. If necessary, you can make this station mobile and move it from office to office as you deploy smart cards throughout your organization.

You'll also need to provide users with smart card readers. Typically, these are USB-connected devices, although laptop users may prefer PC Card-based readers. These readers should be deployed and operational before users show up to claim their new smart cards from your central station. Preparing to issue cards

You'll need to do some prep work in order to issue a card, and then a simple set of steps will serve to issue all the cards your organization needs. Here's an example of what to do (I'm assuming you're using a Windows Server 2003 certification authority to issue cards; if you're not, you'll need to alter these steps to fit your PKI solution):

  1. In the Certification Authority console, ensure that the Enrollment Agent template is present in the Policy Settings folder.

  2. Create a new domain user group, named something like Smart Card. Give the group Read and Enroll permissions to the EnrollmentAgent policy template.

  3. Open Active Directory Sites and Services, and open the Certificate Templates folder (located under Services Public Key Services). Locate the Enrollment Agent template's properties, and add the Smart Card group.

  4. On the computer you'll be using to issue certificates, open Internet Explorer. From the Tools menu, select Internet Options. In the Trusted Sites category, ensure that the certificate service web page is in the Trusted Sites list.

  5. Open the certificate service web page in Internet Explorer, and select Request a Certificate and click Next.

  6. Select Advanced Request, and then click Next.

  7. Select "Submit a certificate request to this CA using a form," and then click Next.

  8. For the Certificate Template, select Enrollment Agent. Then, select Microsoft Enhanced Cryptographic Provider for the CSP. Select a key size?1024 is a common one?and click Next.

  9. Click Install This Certificate.

You can also select the Mark Keys as Exportable option to enable the private keys to be exported for backup purposes. Your organization should have policies regarding key backup and recovery, and those policies must dictate how this option is used.

That's it! You're now an enrollment officer for your organization and can request certificates on behalf of other users and then install those certificates onto blank smart cards. Issuing cards to users

When a user shows up for her new smart card, follow these steps:

  1. Sign on to your enrollment computer as the enrollment agent, and open the certificate services web page on your certificate-issuing server.

  2. Select Request a Certificate and click Next.

  3. Select Advanced Request and click Next.

  4. Select "Request a certificate on behalf of another user using the Smart Card Enrollment" and click Next. You can perform this step only because you already received an enrollment agent certificate in the previous section.

  5. You may be prompted to install a new ActiveX control; allow Internet Explorer to do so. The Enrollment Station Control is required to proceed.

  6. Select Standard Logon as the certificate template, select the appropriate certification authority, and select the appropriate cryptographic service provider that corresponds with the smart card hardware you are using. Click Next.

  7. In the dialog box that appears, select the issued certificate and click OK. This corresponds to the user's identity.

  8. When prompted, insert the user's smart card into the smart card burner, and click OK.

  9. When prompted, select the option to change the default PIN (which is usually 1234 but will vary depending on the manufacturer?you should verify this information with the smart card manufacturer in advance). Have the user type her new PIN if possible, or immediately communicate it to her if not. You should record the PIN for backup in accordance with your company's policies (perhaps your company stores a list of PINs in a safe for emergency purposes).

You're done! Your user has a new smart card, and you can move on to the next user.

When the user inserts her card at her own workstation, Windows prompts for her PIN (her identity is already stored in the certificate on the card) and uses this information to send an authentication request to a domain controller. The user experience is very simple and the public key-based Active Directory authentication all happens in the background.

Security Showdown: Passwords Versus Smart Cards and Biometrics

Passwords have been used since the beginning of computer security. It's hard to imagine a system that uses anything else to prove identity. Movies and books show us a future in which computers identify people in a variety of ways. And that future is nearly upon us. In this Security Showdown, we argue about using passwords versus other authentication means in today's technology.

Don: I like complex passwords. Everyone understands how to use them, they work in just about any circumstances, and they're simple. Passwords have no moving parts to break, no circuits to fry, and can't be left on the coffee table at home when you leave for work in the morning. A proper complex password is incredibly hard to guess?so hard, in fact, that it's usually not feasible to even try. And complex passwords don't have to be impossible to remember, either. "L0ves5teak!" is plenty complex, nice and long, and is easy to remember. Heck, coming up with complex passwords can even be fun, like coming up with a cute custom license plate combination.

Mike: Sure, I agree that passwords have their place. But having something other than a password to prove a user's identity is very important. Passwords are far too easy to guess, as even the most complex will have patterns and rules it must conform with. Passwords must be memorized by people, which provides a weak link in that the person must be considered reliable. And passwords that are held by people are susceptible to a specific form of attack we haven't mentioned yet: the "rubber hose" attack, in which the knowledge is simply beaten out of the individual. Plain and simple, there are too many ways to beat a system that relies only on passwords.

Sure, creating complexity by requiring a user to memorize a PIN for a smart card adds difficulty to the security experience. But the more factors that are required to prove a user's identity, the safer the network resources will remain. Even if he uses a simple PIN or reuses one he's already memorized for another purpose, it's far better to require that PIN than a password. The PIN is useless without the smart card and vice versa, providing two-factor authentication. The PIN will almost certainly not be guessed with brute force attacks, and the card cannot be reproduced. A wonderful benefit of this two-factor authentication is that the factors can be split: one administrator can retain the smart card while a second knows the PIN. This allows virtually any company adopting this well-established and inexpensive solution to require multiple parties to agree to perform critical functions.

Advanced biometrics provide even more assurance that a user is who he claims to be. New technologies that measure everything from the classic fingerprint or retina scan to thermal imaging and bone placement recognition are evolving every day. These technologies have their drawbacks at the moment, including false negatives and cost. But they're getting more reliable and cheaper every day.

Don: You make a good argument for embracing the next phase of technology. However, I still say that, for backward compatibility and because of human nature, passwords will be with us for a while. Perhaps in the near future all these gadgets will replace passwords and change our perception of computer security, but for now, people will still need to compose and memorize complex passwords or migrate to a simple smart card solution. And passwords will certainly remain with us until technical glitches?such as successfully logging on with a fingerprint reader by using gummy bears (http://cryptome.org/gummy.htm)?are worked out.

Ultimately, I think we'll bypass smart cards completely and rely on biometric devices like retinal or fingerprint scanners, which combine the security of a smart card with the ease of use of a password.