Smartcard Service
Smartcard service is an important component in Microsoft's PKI in Win2K. A
smartcard is a password-protected, credit card-sized device that consists of an embedded 8-bit microprocessor, cryptographic coprocessor, and local storage. The card runs a special purpose card-operating system that resides in a 6KB to 24KB ROM chip. A 1KB to 16KB erasable programmable ROM (EPROM) chip can store limited
user data, such as certificates and private keys. EPROM chips have only 128
bytes to 512 bytes of RAM for run-time data.
You can store a Certificate Server-issued certificate in a smartcard. Then,
if you have a smartcard reader attached to your computer--whether in the
office, at home, or on the road--you can access the certificate. The
smartcard's portability lets you use a certificate on any computer with a
smartcard reader. To ensure compatibility and interoperability between
smartcards and smartcard readers, the International Organization for
Standardization (ISO) developed the ISO 7860 standard for smartcard hardware.
ISO 7860, however, doesn't address interoperability between smartcards and PCs.
Microsoft and other vendors formed a Personal Computer/Smart Card (PC/SC)
workgroup and developed a PC/SC specification based on ISO 7860 to standardize
smartcards and smartcard readers that interface with PCs. Microsoft also
delivered a device-independent smartcard SDK for developers to use to write
smartcard-enabled applications in the Windows environment. Win2K includes a
Microsoft-based smartcard cryptographic service provider to support PC/SC- and
ISO 7860-compliant smartcards and smartcard readers.
An important use of smartcards in Win2K is for public key logon. You can use the certificate in your smartcard to log on to a Win2K domain instead of going through the regular NT logon process. Figure 3 depicts the smartcard logon process. When you insert your smartcard into the smartcard reader on your
computer, Win2K prompts you to enter your personal identification number (PIN)
in a smartcard logon window. If NT authenticates you as the owner of the card,
the Local Security Authority (LSA) in your computer retrieves the certificate
from the smartcard and sends it to the Kerberos Key Distribution Center (KDC),
which is a Win2K domain controller. After the KDC verifies your certificate's
validation and issuer (i.e., CA), the KDC uses the subject name in the
certificate as a reference to look up your user object in AD. When the KDC finds
the object, it builds a Kerberos ticket-granting ticket (TGT), which contains
your user account and access control information. The KDC encrypts the TGT with
a session key, which your public key then encrypts, and returns the TGT to your
computer. Your smartcard decrypts the session key with your private key, which
the smartcard contains, and uses the session key to decrypt the TGT. Finally,
the KDC lets the LSA log you on to the Win2K domain. (To learn more about
Kerberos user authentication in Win2K, see Michael E. Chacon, "Kerberos Is
on Guard in Windows NT 5.0," October 1997.)
In addition to smartcard logon, you can use Win2K's smartcard service for
other PKI operations, such as client and server authentication in Secure Sockets
Layer (SSL). To fully leverage your smartcard, you can integrate other security
functions, such as your company ID information and bank automatic teller card
authorization, into the smartcard containing your digital certificate.
Secure Channel
Win2K incorporates a secure channel that supports SSL protocol, which many
companies use to secure Web communications over the Internet. The Internet
Engineering Task Force (IETF) has ratified SSL as an Internet standard and
renamed it Transport Layer Security (TLS). Microsoft's secure channel also
includes Server Gated Cryptography (SGC), an extension to SSL 3.0 using 128-bit encryption to secure online banking sessions. IE 3.0 and earlier, and IIS 3.0 support SSL/TLS; IE 4.0, IIS 4.0 and later, and Money 98 support SGC.
Compared with SGC, SSL/TLS is a general-purpose protocol. You can use SSL/TLS for any kind of Web site. Because of US export limitations on powerful cryptography, SSL/TLS implements two versions of IE: One version has 128-bit encryption for North America, and the other version has 40-bit encryption for international use. However, banks and financial institutions require powerful cryptography to protect customers using online access over the Web. The US government lets international financial organizations use SGC between the United States and almost every other country. Microsoft has built SGC into 40-bit and 128-bit IE 4.0 and 5.0 browsers. Only when the Web server that the browser communicates with is equipped with an SGC server certificate can the browser use the SGC function for 128-bit encryption.
Let's look at how SSL/TLS and SGC use certificates and public keys to
establish a secure channel between a client and a server. In SSL/TLS, the client
first sends a hello message to the server, and the server greets the client by
sending its server certificate to the client. The client authenticates the
server by using the CA's public key, which the client extracts from the CA
certificate stored in the client, to check the CA's signature in the server's
certificate. The server can optionally authenticate the client by asking for and
checking the client's certificate (in IIS 3.0 and later versions, administrators
can choose the option of having the server authenticate the client). After the
client authenticates the server, the client generates a 40-bit or 128-bit
session key, according to security restrictions. The client then encrypts the
session key with the server's public key (extracted from the server's
certificate) and sends the encrypted session key to the server. The server
decrypts the received session key using its private key. Now the server and
client can exchange data encrypted with this session key.
You can use certificates Win2K's Certificate Server or other CAs issue for
SSL/TLS. To use SGC, however, you must request an SGC server certificate from an authorized CA, such as VeriSign, that will examine your eligibility. SGC uses a handshake sequence similar to the sequence that SSL/TLS uses to set up a secure session, but SGC differs from SSL/TLS in two ways. First, in SGC, the client resets and restarts the handshake sequence when it determines that the server certificate is an SGC certificate after the first hello exchange. Second, in SGC, the client always generates a 128-bit session key after resetting the handshake sequence and server authentication.
Register
