Previous | Table of Contents | Next |
With this approach, each card would need to know two keys: one to be used to authenticate the terminal-side application and one to use in authenticating itself to the terminal side application. The terminal-side application, however, would need to know a large number of keys: the one it uses to authenticate itself to all the various cards and one for each card it uses when each card authenticates itself to the terminal-side application. From the standpoint of the cardholder, this is a less-than-optimal situation in that the secret key used to authenticate the identity of the card is known outside the card. Similarly, the secret key used to authenticate the identity of the terminal-side application is known to every card that can access this application. If this key can be retrieved from the card, then perhaps an attacker could use it to gain access to the application.
A shared secret approach is typically used by a smart card to authenticate the cardholder to the card. This is done through a cardholder verification (CHV) command set, listed among the inter-industry commands defined in the ISO/IEC 7816-4 specification (see Chapter 4, Smart Card Commands). This verification process is often referred to as PIN entry or PIN checking. In this process, a file is written within the file structure of a smart card. A PIN value is then written in this file. When a cardholder inserts a card into a terminal, the terminal-side application requests the bearer to enter a PIN through a terminal keypad. The number sequence then entered is passed through an APDU command to the card which then compares the value supplied by the terminal (which was entered by the cardholder) to the value in the CHV file. If they match, the cardholder is then identified (as far as the card is concerned) as the person for whom the card will act.
This CHV process can be significantly more complex than depicted here; multiple PINs can be required or supported by a single card. In addition, multiple steps can be required for the cardholder finally to be authenticated to the card.
Asymmetric Key Authentication
A second approach that is widely used for identity authentication makes use of an encryption process called asymmetric key encryption, commonly called public-key cryptography. As the name implies, the technique makes use of different keys for the encryption operation and the decryption operation. This is illustrated in Figure 9.3.
Figure 9.3. Asymmetric key encryption.
With this technique, one key is used to encrypt information and the other is used to decrypt the cyphertext to get back the original plain text. There is actually a shared secret between the encryption and decryption keys; that is, the keys are generated as different components of a common algorithm. Whats so interesting about this approach, as opposed to the symmetric key approach, is that the proliferation of keys alluded to in the symmetric key discussion can be greatly reduced.
Of the two keys used in the asymmetric key mechanism, one can be held as a closely guarded secret (and indeed should be held as a closely guarded secret) by the entity which will subsequently use this key for identity authentication. This key is termed the private key. The other key can now be distributed to anyone; hence, its referred to as the public key. The public/private key pair can be used to establish authenticated identity, as illustrated in Figure 9.4.
Figure 9.4. Asymmetric key authentication.
Whats shown in Figure 9.4 is actually just authentication in one direction; that is, the terminal-side application can authenticate its identity to the smart card-side application. To do this, the terminal-side application keeps secret the private key, which essentially represents its identity. The public key corresponding to this private key can be freely distributed; hence, it can be stored on every smart card that might want to access the terminal-side application. So the card can use this public key to encrypt some type of challenge text string; that is, some arbitrary string that the card knows and wants to see if the terminal can find out. It then sends the cyphertext generated from this challenge text to the terminal-side application. If the terminal-side application really possesses the identity (private key) corresponding to the public key possessed by the card, it can decrypt the challenge and return the plain text to the card for validation.
Obviously, the inverse of this procedure can be used to allow the card to authenticate its identity to the terminal-side application. In this case, the terminal-side application needs to know only the public-key component related to each cards identity. If it is to be able to authenticate a large number of cards, it needs to keep a list of, or at least be able to obtain, the public keys of the cards it wants to authenticate. This is considerably better from a security standpoint than the symmetric key situation described in the previous section.
Of course, theres never a free lunch. Computationally, a public-key encryption or decryption algorithm is much more intensive than a symmetric key algorithm. Therefore, it is unrealistic to think about encrypting or decrypting large amounts of information on a smart card processor in a short time. However, the challenge text noted previously does not have to be too voluminous. So for establishing authenticated identity, public-key mechanisms can be used effectively, even given the limited processor capacity of a smart card.
The mechanisms described in this chapter are useful for authenticating identities among a variety of parties to a transaction. Although it may not always be thought of as a transaction, the same mechanisms are useful for establishing identities related to documents or procedures; that is, performing the function of allowing an identity to sign a document or a process. This identity authentication procedure can form part of what can be referred to as a digital signature. The other aspect of a digital signature is the confirmation that the information which has been digitally signed has not been modified from the time that it is signed until it is read (and the signatures identity is authenticated). This, then, is a means of addressing another of the concepts of securityintegrity.
Previous | Table of Contents | Next |