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.
- By Roberta Bragg
- 09/01/2000
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.
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.