If you’re concerned about weak passwords serving as a hacker’s haven on your network, smart card logon may be the answer.

Smart Card Education

If you’re concerned about weak passwords serving as a hacker’s haven on your network, smart card logon may be the answer.

Smart cards won’t make you smarter. However, they can be used as a part of your infrastructure authentication design to better control who gains entry to your network. A smart card is a credit-card-sized device that sports a computer chip. The chip can hold information about the user such as credentials for logging to a Windows 2000 network. The user inserts the smart card into a special reader and, instead of a password, enters a pin number. If the smart card holds valid credentials and the pin number is correct, the user is logged on. If the credentials are invalid, the pin is incorrect, or the card reader malfunctions, the user is denied access.

Third-party companies offer smart cards for Window NT 4.0 and Windows 9x, and Win2K comes with built-in support for smart cards. In my session at a recent MCP TechMentor event for this magazine, I introduced smart card operations in Win2K. Many of you have asked for explicit instructions on how to do this in your network. So this month and next, I’ll show you how to create a simple smart card test lab. If you’re not familiar with public key infrastructure, here’s a little background.

What Is PKI?

A public key infrastructure, or PKI, is the sum of all the hardware and software and its configuration within your network. This list defines the components.

  • CA—Certification Authority. The CA issues certificates with which a user can authenticate to the system.
  • CA roles—Win2K CAs can be enterprise (integrated with Active Directory) or stand-alone (not integrated with AD). Both enterprise and stand-alone CAs can be either root (the source from which all trust flows) or subordinate (issued a server certificate from a root CA).
  • Certificate—A collection of information about the owner, the CA that issued it, what it can be used for, and a copy of the public key.
  • Certificate revocation list (CRL)—Certificates are issued with expiration dates and must be renewed periodically. If a certificate needs to be invalidated before its expiration date (say, because it was compromised or the user quit), then the certificate is posted to the CRL. In Win2K, the CRL is always checked before a user is authenticated.
  • Enrollment—The process by which a user or computer is assigned a certificate.
  • Private key—Half of the key pair. In the email encryption scenario above, the private key is used to decrypt the email. Only the owner of the private key has access to it. In authentication schemes, the private key is used during logon to encrypt a challenge. It can be verified because the public key is available to the operating system.
  • Public key—One half of a key pair issued for each authorized user or computer. One use of the public key is in email encryption. Other users can use the public key to encrypt an email message to the certificate holder. The public key is made available to other people.
CA and CA Hierarchy

In a Win2K network, a combination of stand-alone and enterprise Certification Authorities (CAs) can be hierarchically arranged in order to scale the PKI. Using a hierarchy also allows the root CA to be taken offline for protection. On the top level a stand-alone root CA is used only to issue CA certificates for the stand-alone subordinate CAs in the next level. When a root CA is installed, it grants itself a root certificate. This certificate is used to sign the certificates of the subordinate CA. The root CA is never placed on the network and is kept locked in a vault.

When a subordinate CA certificate is required, an administrator must enter the vault and request a certificate file. The file, which includes the certificate and the private key for the new CA, can be placed on a 3.5-inch disk. The disk is used during the installation of the subordinate CA. The subordinate CAs can be located at different physical locations on the network. This layer of the hierarchy is used only to issue server certificates for the bottom layer, which consists of enterprise subordinate CAs. These CAs are used to issue computer and user certificates for many purposes. Each server can be dedicated to one type of certificate (for easy delegation of authority and ease in administration) or used to issue many types of certificates.

It’s unnecessary to create a CA hierarchy. However, multiple CAs can extend trust from the root outward in distributed environments in this manner; it allows for the best protection of the root CA. Remember, since it’s the root CA from which all trust flows, if someone compromises the root CA, your carefully constructed authentication configuration is worthless.

In the simple lab I will outline in next month’s continuation of this column, I won’t set up a hierarchy, but you could easily do so. You’ll need one computer to represent every layer of your proposed hierarchy, and you’ll make different decisions about which certificates a CA can issue. Don’t forget to set up the root first!

—Roberta Bragg

Working with PKI

Although having a PKI is an obvious choice in order to use certificates for authentication, Win2K has other uses for PKI. IPSec can use Kerberos, a shared key, or certificates for authentication, but with Win2K, there are several situations that require a PKI:

  • To implement L2TP over IPSec for VPN, the computers involved must have a computer certificate in order to authenticate with the network on the other side of the tunnel.
  • In order to centralize management and control file recovery agents for the encrypting file system.

In order to use smart card authentication. Plenty of PKI misconceptions exist:

  • You can’t use a PKI in Win2K unless you integrate it with Active Directory.

    The truth: Win2K can be implemented as stand-alone CAs.

  • You can’t integrate Win2K PKI with third-party PKIs.

    The truth: You can import standard v.509 certificates into Win2K and map them to user accounts in the Active Directory. You can use a third-party certificate issued from a root to install a Win2K subordinate CA. Certificates from many third-party CAs can be used in Win2K. Of course, vendors have chosen to implement PKI in many ways, and not all of them may be compatible with Win2K PKI.

  • You must install a CA hierarchy and store the root CA in a vault, thereby making a PKI an expensive proposition for a small business.

    The truth: There are many ways to implement PKI in your network. You may choose to purchase third-party certificates or outsource your PKI infrastructure and administration. In a business, you can implement a single CA that can then be used to issue certificates for your users and computer. You won’t be able to protect this CA as well, however, so you must determine the risk this presents and act accordingly. An alternative might be to use an inexpensive system as the offline root CA; after all, it doesn’t need to be a hefty machine since all it does is issue a subordinate CA certificate and renew it periodically.

  • You can’t use a third-party PKI in Win2K.

    The truth: You’ll have to check with each vendor. Your ability to use these products in Win2K will depend on the use to which you put them. Use of third-party certificates by Win2K systems will depend on the vendor’s use of standard certificates, how trust is established, and several other factors. Using a Win2K server as the platform to host a third-party CA will depend on the compatibility of the third-party product with Win2K. You’ll find an excellent white paper on PKI interoperability at www.microsoft.com/windows2000/library.

  • You must purchase expensive smart card enrollment stations.

    The truth: Smart card readers are capable of both writing smart cards and reading them. You don’t need to purchase any other equipment. You do need a reader for each computer that must be accessed via smart cards. You’ll also need smart cards for each user.

Can Smart Cards Be Compromised?

As long as there are people who think it’s their right to violate your organization’s privacy, or people who will accept payment to do so, there will be enormous efforts made in breaking smart card authentication. This can happen in three ways: through PKI, via the smart card, or through people.

PKI Issues

To examine how smart cards can be compromised, begin by following the trust. The first place of trust in a smart card operation is the issuing CA. If the CA is compromised, all certificates, and thus all smart cards issued with those certificates, may be compromised. Your smart card authentication scheme is based on requiring a certificate signed by a CA whose authority stems from some root CA. If there’s a way to compromise the root CA or any other CA, then it’s possible for someone to issue smart cards that can be used to penetrate your system.

Smart Card Issues

Another area of trust is the smart card itself. We trust that it can’t easily be read by unauthorized users to capture certificates and keys, but we know that sooner or later this will be possible. The redeeming feature of smart cards is that this will require sophisticated equipment, at least currently. While I might lose my smart card or it might be stolen, no one can use it without my PIN. Certainly there are a limited number of PIN combinations, and so someone might try to guess the PIN number or write a dictionary attack that would try all combinations. However, two factors help prevent both dictionary attacks and the capturing of certificates and keys from lost cards:

  • After three invalid attempts to enter the PIN, the card becomes unusable. Even if the correct PIN is then entered, the user will not be authenticated.
  • If someone steals my password, I may not know it. However, if my card is missing, I can’t log on and must report the loss to receive a new card. This allows an administrator to revoke the certificate on the original card so that it can’t be used.

For an analysis of smart cards risks in the real world, read www.counterpane.com/smart-card-threats.pdf.

People Issues

As with any other device and policy, simple user issues can circumvent security. If the PIN is taped to the smart card, or if users share smart cards, all of your work doesn’t stand a chance. Security awareness training must accompany smart card deployment.

Public Key/Private Key Cryptography

In the secret key/symmetric key encryption scheme that you may be more familiar with, if you and I want to share encrypted messages, then you and I each must have a copy of the same key. I use it to encrypt the message and then send it to you. You receive the message and decrypt it using the your copy of the key. No one else has a copy of our private, secret key.

Public key or asymmetric key cryptography uses a different approach. We each have a key pair. If either of the keys in our key pair is used to encrypt, then the opposite key of our key pair must be used to decrypt. To make the system work, we must both make our public keys available to the other. In this scenario, I can then obtain your public key and use it to encrypt a message and send it to you. Since only you have a copy of the private key, only you can decrypt the message. Furthermore, if I use my private key to sign the message, then you can use my public key to decrypt the signature. Since only I have my private key, you can be assured that I sent the message.

In most systems, all public keys are stored in a directory or some other central location, and this is the case with Win2K. The certificates (which each contain a public key) are stored in Active Directory. The certificate binds the key pair to the security principle (user or computer account). The private keys are stored in a private key store only accessible to the owner of the certificate.

—Roberta Bragg

Where to Place Your Readers

The answer is: everywhere. If you’re using smart cards because passwords are a terribly insecure way of granting access, then you’ll want all users to use them. If this is the case, then every workstation in your enterprise needs a reader. If you’re going to set up an enrollment station, that system needs two readers: one for the enroller to use to log on and one for the enroller to make the new smart cards on. Is there any account that shouldn’t use a smart card? Some actions, such as joining computers to a domain, may require an Administrator user ID and password. In this case, a smart card won’t work. So some administrator accounts should also have the ability to log on using a password for these tasks. Control them by setting the computers they can log on from.

Additional Information

The exception to the “smart card reader for every computer” rule is if you’ve decided that only a certain domain requires this special security standard; or perhaps a special circumstance, such as remote logon, warrants the extra protection. Maybe all road warriors should be equipped with readers for their laptops, with their accounts marked to insist on smart card logon (specified in their user account properties), and their laptops forbidden to accept the three-finger salute “Ctrl+Alt+Delete” (this is a security option in Group Policy). Like any security policy, your circumstances may be unique. I’d enjoy hearing about them.

Next month, I’ll show you how to implement a test system.

Featured

Most   Popular