Public key smart cards are most often found in public key infrastructures (PKIs) and typically are associated with authentication (i.e., with the certified identification of an individual). A lot of conferences have been held and a lot of venture capital burned pursuing the commercial viability of authentication services based on PKIs with, to date, relatively little net effect. Stefan Brand and Bruce Schneier and Carl Ellison have raised a number of cautions and concerns regarding the use of public key smart cards as identity tokens. At the same time, events have stimulated the consideration of public keys, along with biometric smart cards, as more general identity tokens.
Interestingly enough, public key smart cards are not limited to a supporting role in PKIs. In fact, when you strip away all the servers, software, and certificates, you are left with what is really valuable about public key cryptography on a smart card: a tamper-resistant binding between the single copy of some useful cryptographic material (the private key) and a physical thing (the smart card). In effect, you have a software equivalent of a physical key, such as a key to a safe or key to a drawer.
At first blush, a tamper-resistant binding between a unique digital object and a unique physical object doesn't seem like a very big deal. There are two direct consequences of this binding that are quite useful in IT architectures, however. First, the card must be present for the key to be used. Second, if there is evidence that the key was used, then the card must have been present. In addition, there is the rather nice effect that the key can act “at a distance”; it can be presented at one point in a network and act up a lock at some widely separated other point within the network.
In this chapter, we will explore through examples the use of a public key smart card as a bearer instrument in use as an authorization token rather than as an authentication or identity token.
To bring into sharp focus the difference between a card used for authorization and a card used for authentication, let's start with a personal example: access to your medical records. Suppose that the database holding your medical records only provides access to those records from a network address that demonstrates that your medical records access card is present. You could keep your card under your pillow at home and access your records whenever you wanted to via your DSL line. Or, you could carry your card with you so that emergency medical personnel could access your records from the ambulance if they found you unconscious. Or, you could leave it with your doctor to study your medical history if you came down with a strange affliction. Or, you could give it to the hospital when you checked in.
Your medical records card authorizes access to your records. It does not identify either you or the person accessing the records. It is a bearer instrument. Anyone possessing it can access your records anonymously. The only thing that is authenticated is the card itself.
The authorization protocol executed by the medical records database to authenticate the card is straightforward. As a matter of fact, it looks very much like the standard smart card security commands for identity authentication. The public key associated with the private key in the card is filed away with your medical records. When a request for access comes in, a random number is sent back to the card for encryption by the private key. The encrypted random number is sent back to the access point and if it decrypts with the public key in your records, the IP address, cell phone number, or whatever communication channel the request came in on is noted and access is granted to that channel.
The right to access to your medical records is hard-wired to possession of the smart card. Anyone possessing the card gets in. Anyone without the card doesn't. When you have it in your possession, no one else can access your records. You can give someone else permission to access your records by giving him or her the card. And, you can rescind this permission by taking back the card. This probably seems incredibly intuitive to us because this is the way that we use a key to the front door of our houses or the key to our automobiles.
Anyway, it is this latter property of an authorization card that differentiates it from a password and makes it more like a key (not a cryptographic key, but a physical key). A password can't be rescinded. In order to rescind the right that went with the password, the right has to be disconnected from the password and attached to a new password. You have to change, not the person to whom you loaned the right.
Another difference is that passwords can be easily duplicated. Sometimes this is not a problem. But in situations where you want to control the total number of people exercising a right or the number of people exercising the right simultaneously, the ease with which passwords can be passed along makes administering the right more difficult and more expensive. The ease with which passwords can be duplicated also makes selectively rescinding them more difficult.
The tight binding of a right to a physical object is something that is familiar and is something everyone can understand. As we shall see, it also makes managing the right more certain and less expensive and, in the end, makes the right itself more useful. From the point of view of the grantor of the right, it means the right can't be cloned and that it can be rescinded with certainty. From the point of view of the user of the right, it means that his or her identity is not associated with the use of the right and that he or she can, pending other rules, transfer use of the right to others.
In a climate of heightened sensitivity about personal privacy and the use of individual identities, it makes sense to resort to authentication when it is absolutely necessary and to not use it needlessly when only authorization is required.
The next four sections describe IT situations where public key smart card authorization could be employed. The settings are all different, but the role of the card is the same—namely, a binding of a private key to a physical object. We follow these four scenarios with two detailed practical examples of building and using an authorization card based on public key cryptography.
Suppose that your employer wants to provide access to an online service to the employees of your company. Because not all employees will be using the service at the same time, it makes no sense to buy a subscription for each employee. Rather, your employer works out a deal with the service that allows no more than ten employees to access the service at any one time.
Both the service and your employer want to make certain—with a minimum of administrative overhead—that their agreement is enforced. What they have done is create ten public key smart cards and given them to the librarian or the receptionist, or they've just hung them on the wall in the kitchen. In order to access the service, an employee gets a card, sticks it in the card reader on his or her desktop, and surfs away. When done, he or she returns the card so that other employees can use the service.
At the service, a list is kept of all the public keys that are authorized to use the service. When a request comes in, a random number is sent back out to the origin of the request. What is expected back is an encryption of the random number with the private key on the access card along with the public key stored on the card that goes with the private key on the card. If the returned public key is on the approved list and if the random number decrypts with the public key, then access to the service is granted. This protocol is rerun every five or ten minutes to make sure the card is still there.
The service access card is a bearer token. A right to access the service is bound to the key and the key is bound to the card. If you possess the card, you possess the right. You can't clone the card, so you can't clone the key or the right.
You can be identified as being a member of a group without revealing your individual identity. Suppose, for example, that all the engineers assigned to a particular project are allowed to access the project's files, but engineers in other projects are not. If access is administered on the basis of individual authentication, then as engineers come and go, there has to be constant administration of the access control lists for the project files.
If, on the other hand, the project manager creates a batch of public key cards that permit access to the project files—just like the online service or medical record card previously—the manager can give an access card to project engineers when they are assigned to the project and collect them back when they leave the project.
In this case, because the number of cards is small, we are essentially performing a remote INTERNAL AUTHENTICATION command on the card when we verify it. An advantage of the use of public key cryptography over secret key INTERNAL AUTHENTICATION is that there is no sensitive key material in the computer room. There is only the list of public keys that can access the project files. It does no good to steal this list, and making unauthorized additions to it are easily detected.
A digital right—the right to listen to a song or to view a video—is an everyday case of authorization without authentication. The possession of a CD carries with it the right to listen to the songs that the CD contains. In the rapidly fading era where intellectual property was tightly bound to one physical media or another—songs to vinyl, words to paper, video to cellulose, pictures to silver halide or color emulsions—it rarely occurred to people that the right and the media were separable. That is probably why we never talked much about analog rights.
A public key smart card can play the role of the CD in the post-Napster era (i.e., a physical object whose presence is necessary in order for a right to be exercised). In fact, the digital rights management smart card may not only have to be present, but it will probably contain rules or policies for the digital rights it is managing (e.g., “can only be exercised ten times” or “can only be exercised when an allied right is present” or “when right manifested by this card is exercised increment a frequent listener counter on the card by one”).
Digital rights are not just about Britney Spears or The Academy of Ancient Music. Digital rights management also applies to corporate communications and personal correspondence. The number of start-ups that have failed trying to provide DRM to bit streams other than songs and video is roughly equal to the number of start-ups that thought they had a way to defeat the digital pirates in Hong Kong.
A subject that always comes up in talking about the use of smart cards for DRM is difficulty of running an entire book, record, or film through a smart card. Of course, you can't—and you don't need to. The seminal paper showing how to use a smart card for DRM is Matt Blaze's “High-Bandwidth Encryption for Low-Bandwidth Smartcards” [Cambridge Workshop on Fast Software Encryption, February 1996]. There is a lot of additional published and patented work in this area, almost all of which cite Matt's paper as their wellspring.
The bits generated by the card can be used to simply demonstrate possession of the card as in the preceding cases or they can cause something to happen at a remote location. Suppose, for example, that you want to send a Short Message Storage (SMS) message from your mobile phone to reset a printer queue at work. You send the reset message to the remote control gateway server, it verifies your authorization to reset the queue, and forwards a reset SNMP message to the printer. This is all standard stuff except for the authorization step.
The authorization gateway can use the telephone number on the incoming SMS message as an authorizer, but this has a number of shortcomings. First, you have to use a different authorizer for each mode of communication with the gateway. Some will provide good assurance and some will provide less-than-good assurance, but they will certainly all be different, which adds complexity to the gateway. Second, there is the issue of liability and due diligence. Using the telephone number as an authenticator to reset the printer queue essentially means you are using the telephone company's key infrastructure to control access to your company's computer center. This is definitely not the intended use of these keys and, if something goes wrong, you won't have much of a case against the telecom.
An approach that addresses both of these shortcomings is to use a public key smart card. (You may have seen that coming.) The authorization gateway sends a random number back down the same line that the message came in on and waits for the return of an encrypted version along with a public key. When the encrypted random number and the public key come back, the gateway makes sure the provided key decrypts the provided encryption and also checks to see if the public key is allowed to perform the operation in the message. If so, it fires off the SNMP message to the printer or to the network management system that will, in turn, send it to the printer.
If the number of remote sysops is small, it doesn't even need the public key. It can decrypt the random number with each key on the authorized list until it finds one that works.
Figure 9.1 is a general diagram of using a public key smart card for remote control.
Whether or not you need to use an authorization gateway depends on a number of factors, including the complexity of the cryptography used, the capabilities of the actuators, and the number of people sending commands. There are situations in which the actuator itself can perform the authorization function.
Authentication is too often used as a proxy for authorization. Not only does this introduce additional costs that provide no benefit, but it involves handling information that is more sensitive than is necessary for the task at hand. All you get for the higher price is more risk and more liability exposure.
Public key smart cards used as authorization tokens (i.e., without a PKI) can be tailored to the authorization task or tasks at hand. The tight binding of the authorization (the private key) to a physical object (the smart card) is easy to understand and easy to manage.
We will conclude this chapter with two programming examples. The first, the WCLA Auction Card, uses the Schlumberger Cryptoflex public key smart card and a simple Windows program to create a card that can be used for anonymous bidding. The second programming example uses a Wireless Application Protocol (WAP) phone, a simple WML script, and an ISO 7816-8 WIM card to do remote control authorization.
The local classical radio station, WCLA, gives an auction to raise money once every year. Some listeners have expressed some reluctance to bid on the high-ticket items on privacy grounds. For a number of reasons, they don't want to identify themselves to unknown WCLA auction volunteers as either being interested in such items or able to pay for such items.
The IT manager of WCLA understands this reluctance and is highly motivated to address these concerns so that these preferred bidders won't abandon the auction. So, she has created the WCLA Auction Card. Here's how it works.
Bidders can drop by the radio station and pick up an auction card from a great big bowl full of Auction Cards—no questions asked. Or, if the bidder has a mustard seed's worth of trust in WCLA, he can call and ask to have someone draw a card out for him and have an Auction Card Kit sent to him.
In either case, what he gets is a Schlumberger Cryptoflex card—the WCLA Auction Card—and a CD-ROM containing the WCLA Auction Advisor program that we will discuss at length in the next few sections. The Auction Card had been pre-personalized to contain a public key pair and nothing else. In other words, there is no association between the bidder and the card. The card is a bearer instrument.
When an item comes up for bid on which the listener wants to bid, he once again fires up the Auction Advisor, enters the item number and bid into the appropriate windows, has these two numbers encrypted by the freshly generated private key, and cuts-and-pastes the text blob that appears in the output window into a bid form on the WCLA Web site. The text blob contains the item number, the bid amount, the encrypted item number and bid, and the public key that goes with the private key that does the encrypting.
The WCLA Web server decrypts the encrypted item number and bid using the public key and checks them against the plain-text item number and bid. If they are the same, the server enters the bid on the item on behalf of the cardholder.
At the end of the auction, the winning public keys that match the items won are posted on the WCLA Web site. In order to claim an item, an anonymous someone with the card containing the private key that goes with a posted public key goes to the WCLA studios. WCLA gives the presented card the item number and the winning bid for the item that is being claimed. If the card produces the same text blob that was the original bid sent into the Web site, WCLA accepts the satchel of unmarked $20s and the anonymous someone walks away with the Ming vase.
Of course, at this point, the bidder is no longer dealing with auction volunteers but with WCLA staff, so he might be willing to actually write a check—but you get the idea.
As obtained from WCLA, the Auction Card contains the files in Table 9.1. This is the simplest of all possible public key cards.
The PIN for the card is the PIN that is found in the majority of smart cards in use: 1234. The bidder doesn't really need a PIN for this use of a public key card, but the Schlumberger Cryptoflex card requires that there be one.
Table 9.1. Files on the WCLA Auction Card
Directory | File | Contents |
|---|---|---|
0x3F00 | 0x0000 | User PIN |
0x0002 | Card Identifier | |
0x0011 | Administration Keys | |
0x4F01 | 0x0012 | Private Key |
0x1012 | Public Key |
Figure 9.2 is a screenshot of the Auction Advisor in action. The bidder now just cuts the text in the Cut-and-Paste Window into the WCLA Bid Form and he has entered his bid.
When the program is started, the WCLA Auction Card is initialized and the public key is extracted:
hResult = SCardEstablishContext(
SCARD_SCOPE_SYSTEM, NULL, NULL, &hContext);
hResult = SCardListReaders(hContext, NULL, Reader,
&ReaderLength);
hResult = SCardConnect(hContext, Reader, SCARD_SHARE_EXCLUSIVE,
SCARD_PROTOCOL_T0, &hCard, &dwActiveProtocol);
cbAtrLen = sizeof(Atr);
hResult = SCardState(hCard, &dwState, &dwProtocol, Atr,
&cbAtrLen);
DO(select_mf);
DO(verify_pin);
DO(select_4F01);
DO(select_1012);
DO(get_public_key);
memcpy(PublicKey, bpRecvBuffer, sizeof(PublicKey));
The DO macro just sends an APDU to the card and retrieves the response
#define DO(command)
cbRecvLength=sizeof(bpRecvBuffer);
memset(bpRecvBuffer, 0, sizeof(bpRecvBuffer));
hResult = SCardTransmit(hCard, SCARD_PCI_T0, command,
sizeof(command), NULL, bpRecvBuffer, &cbRecvLength);
where, for example, select_mf is just
BYTE select_mf[] = {0xC0, 0xA4, 0x00, 0x00, 0x02, 0x3F, 0x00};
The code for the Sign It! Button, in the grimmest detail, looks like this:
void CWcla1Dlg::OnSignIt()
{
int i, j;
m_ItemNumber.GetWindowText(ItemNumber, sizeof(ItemNumber));
m_BidAmount.GetWindowText(BidAmount, sizeof(BidAmount));
memset(&sign_data[5], ' ', sizeof(sign_data)-5);
memcpy(&sign_data[5], ItemNumber, strlen(ItemNumber));
memcpy(&sign_data[10], BidAmount, strlen(BidAmount));
DO(sign_data);
DO(get_signature);
memcpy(Signature, bpRecvBuffer, sizeof(Signature));
sprintf(CutAndPasteBuffer, "Item=%s Bid=$%s
Public Key
",
ItemNumber, BidAmount);
for(i=3, j=strlen(CutAndPasteBuffer); i < sizeof(PublicKey); i++)
{
sprintf(&CutAndPasteBuffer[j], "%02x", PublicKey[i]);
j += 2;
if(((i-3)+1)%36 == 0) {
CutAndPasteBuffer[j++] = '
';
CutAndPasteBuffer[j++] = '
';
CutAndPasteBuffer[j] = ' ';
}
}
sprintf(&CutAndPasteBuffer[j], "
Signature
");
for(i=0, j=strlen(CutAndPasteBuffer); i < sizeof(Signature); i++)
{
sprintf(&CutAndPasteBuffer[j], "%02x", Signature[i]);
j += 2;
if((i+1)%36 == 0) {
CutAndPasteBuffer[j++] = '
';
CutAndPasteBuffer[j++] = '
';
CutAndPasteBuffer[j] = ' ';
}
}
m_CutAndPaste.SetWindowText(CutAndPasteBuffer);
}
In Chapter 8, we described the SIM smart card and the SIM Application Toolkit. SIM is an acronym for subscriber identification module and it is the smart card that is in GSM and 3G mobile telephones. The SIM is an authorization smart card, just like a public key smart card except that it uses symmetric (secret) key cryptography rather than the asymmetric (public) key cryptography. When you get a new account with a GSM mobile operator, you are given a SIM that contains the secret key associated with your account. A copy of the key is in the operator's network operations center.
What a SIM authorizes the bearer to do is use a mobile network. The network operator performs a slightly more complicated version of the authorization protocol we have seen previously with the SIM when you turn on the phone. The operator doesn't know or care who is actually using the phone. All the operator really cares about is who is going to pay for the usage. It is the contract you signed when you opened the account that links the key on the SIM to a payment obligation. This contractual binding to pay for network use is over and above the binding of the secret key in the SIM and the physical SIM itself. This latter binding makes it hard for you to claim that it wasn't your SIM that made the call, but it also lets you argue that the call that was made in Eastern Slovenia wasn't you. The binding of a physical object and a digital object cuts both ways.
There is another smart card that is used in mobile applications called the WIM. WIM is an acronym for WAP identification module. Details of the WIM and the application programming interfaces (APIs) to it can be found on the WAP Forum Web site at www.wapforum.org.
The WIM is a public key smart card just like the ones we've been describing. Originally, it was designed to be part of a PKI; this may still happen some day. In the meantime, we can use it for mobile authorization without a PKI.
Figure 9.3 shows the flow of the authorization protocol to the WIM and back to the mobile authorization gateway.
The WML script that the mobile authorization gatewaysends to the WAP phone to ask for an authorization might look like this:
<wml>
<card id="Query"
<select name="YESorNO" title="Reset BLUE Printer?">
<option value="YES">YES</option>
<option value="NO">NO</option>
</select>
<do type="Accept">
<go href="SignIt.wmls#signIt($(YESorNO))"/
</go>
</do>
</card>
<card id="Return"
<do type="Accept" title="Send authorization?">
<go href="http://www.sguthery.com/gateway.asp" method="post">
<postfield name="Signature" value="$(Signature)"/>
</go>
</do>
</card>
</wml>
The WMLScript function signIt looks like this:
extern function signIt(data)
{
WMLBrowser.setVar("Signature", Crypto.signText(data, 1, 0, "x00"));
WMLBrowser.go("WMLScriptExample.wml#Return");
};
The Crypto.signText function is an element of the WMLScript Crypto library. The execution of the signIt function by the WAP browser on the handset causes five ISO 7816-8 APDUs to be sent to the WIM smart card. The first one is a Manage Security Environment command that establishes the WIM security environment on the card:
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
8016 | 2216 | F316 | 0616 | 0116 | 0016 |
The second one is a VERIFY PIN APDU that provides access to the private key:
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
8016 | 2016 | 0016 | 0116 | 0416 | 3116 3216 3316 3416 |
The third one is another MANAGE SECURITY ENVIRONMENT command that says what private key file and what key in that file to use:
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
8016 | 2216 | 4116 | B616 | 0716 | 8116 0216 0016 1216 8416 0116 01 |
In our case, we are using key #1 in the file 0x0012.
The fourth APDU is the PERFORM SECURITY OPERATION APDU that actually sends the data into the WIM for signing:
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
8016 | 2A16 | 9E16 | 9A16 | 0316 | 'Y' 'E' 'S' |
And the final APDU is a GET RESPONSE APDU that retrieves the 64-byte signature:
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
0016 | C016 | 0016 | 0016 | 4016 |
As fate would have it, WAP has not been one of the world's great successes. Not only are there few WAP handsets out there, there were even fewer WIM cards. Nevertheless, the idea of adding additional keys and the ISO 7816-8 APDUs to the mobile environment is compelling. Thus was born the SWIM card. A SWIM card is a SIM with WIM capabilities; namely, it supports the ISO 7816-8 needed to implement the WIM signing and verification protocols. To be sure, network operators aren't thrilled by having keys other than their own on the SIM, but the alternative of having a second smart card on the scene is even more distasteful. At least with the SWIM, they still own the platform.
Additional keys are fine, but what about the WMLScript and interacting with the mobile cardholder? How do we accomplish this without a WAP phone? The answer is to install a nanobrowser on the SIM itself.
This was first accomplished by Across Wireless in 1998. The SIM-based browser was called the Wireless Internet Browser, or WIB for short. The Across Wireless (now SmartTrust) WIB was very well received in the GSM and 3G marketplace and has proved to be a more manageable and less costly way to roll out mobile applications than downloading Java applets to the SIM. The Across Wireless WIB supports a public key cryptography plug-in, just like the browser on your desktop; this plug-in can be used for mobile authorization just like the WML Crypto library was previously. The WML that you send to the Across Wireless WIB is almost identical to the WML that you would have sent to a WAP handset.
Telecom operators are adamant about standardization and while, they liked the approach of the Across WIB, they were uncomfortable with installing essentially proprietary technology on their SIMs. In early 2000, they launched an effort in 3GPP to standardize the SIM-based microbrowser. The result is the USAT (for UICC SIM Application Toolkit) Interpreter that we discussed in Chapter 8.
A public key smart card creates a tamper-resistant binding between a digital object (a private key) and a physical object (the smart card). In order to use the key, the card must be present. If the key is used, then the card is present. If the key is a right, then the right is bound to the card and can be transferred by transferring possession of the card. The act of encrypting a piece of data with a private key generated on a smart card associates the piece of data bound to the possession of the card. It does not associate the data with any particular person.