Smart cards provide a personal component of applications, whatever the complete purpose of the application might be. The smart card is carried by an individual and is periodically utilized in various equipment configurations to achieve the results or obtain the services provided by those configurations. The most common feature of smart cards in an application is to establish or authenticate the identity of the cardholder and the cardholder's right (permission) to access and use the application in question. In other cases, besides authenticating identity, the smart card may carry additional information needed by the application. For example, in financial debit and credit applications, the smart card may carry an account number (or numbers), which are to be accessed in backend servers involved in the application.
A common aspect to virtually all smart card–enabled applications is that they involve establishing a communication channel between the smart card and some other computer processor acting as the general controller for the application. This translates into a situation of two application-level programs running on peer-level computers needing to communicate with each other. This is exactly the scenario of the International Standards Organization (ISO) Reference Model for communication protocols illustrated in Figure 4.1.
Essentially, all of the layers described in the ISO Reference Model are found in the communication channel between an off-card application and the corresponding application on the smart card. We'll look at a more detailed comparison in Chapter 7 where we'll recognize that the layering in the smart card environment is not quite what was envisioned in the ISO Reference Model, but the sum total of the layers is pretty well there.
The smart card protocols do present some rather eccentric characteristics relative to a true peer-to-peer communication protocol. Most noteworthy, perhaps, is the fact that the host and the smart card actually operate in a master-slave mode. The host requests an operation of the card and the card performs the operation and tells the host the results.
The earliest smart cards were designed from scratch with the larger application in mind and the function of the smart card well established from the beginning. A command set was implemented on the card to provide the necessary functionality for the application. This approach, of course, tended to argue against having multiple smart card (and other equipment) vendors provide components for the application. In an effort to provide some commonality among applications, an interindustry command set was ratified by the ISO organization and published as the ISO/IEC 7816-4 standard.
The ISO 7816 standard makes an assumption for the basic paradigm of smart card–aware applications; that is, the smart card provides information storage in the form of an abbreviated file system, accessed through a command set comparable to that used on a general-purpose computer system. It is further assumed that the smart card provides a relatively secure platform on which to store information. Consequently, a general protocol for authenticating identities and then authorizing operations based on those identities was defined. Finally, because true general transaction operations were extremely difficult to provide, a reduced form of transaction operation was defined that would allow simple operations to be performed on smart card files in a highly secure and reliable fashion.
Deploying a smart card–aware application on a typical PC or workstation system generally requires provision of the complete smart card infrastructure to support the application. That is, the base operating system of the host computer must be upgraded to include a smart card protocol stack, which allows the transfer of information between the host application and the smart card application. In addition, the host computer (hardware) configuration must be enhanced to include a smart card reader, which provides the physical connectivity between the smart card's integrated circuit chip (ICC) and the host computer. We'll look in some detail at this smart card stack in Chapter 7.
Few, if any, computer systems have smart card readers as an integral input/output (I/O) channel of the systems. Rather, a variety of smart card readers have been developed that attach to computer systems through existent I/O ports. The most common such reader attaches through a serial port. Readers that interface in this fashion range from extremely simple devices, which simply serialize the byte streams that convey commands and responses between the PC application and the smart card, to very complex devices, which incorporate personal identification number (PIN) pads, display screens, and hardcopy printers to support the smart card application.
Some variants of smart card readers have been built directly into the standard keyboard of a computer. Some such configurations have further modifications that allow the keyboard to interrupt the transfer of characters to the CPU in the case where the input characters constitute a PIN destined to be sent to the smart card.
Another smart card reader takes the form of a floppy disk plug-in, which conveys the smart card I/O traffic through the floppy disk port. This particular device requires a floppy disk–like module that the card plugs into, and which contains an independent power source for the smart card.
The simple fact that most general computer systems do not, today, contain a smart card reader means that deploying a smart card–aware application immediately runs up against the “infrastructure problem.” That is, a piece of equipment (a smart card reader) must be added to a configuration, but which contributes no other benefit than to allow a smart card to be used. This makes the economics of adding a smart card to an application bend out of shape a bit. For every card that we want to issue, we also must issue a smart card reader. Use of a smart card starts to look like a $50 to $100 option (depending on the cost of the reader) rather than a $2 to $15 option (which looks like the price of just a smart card).
That said, by standardizing smart card components such that they are usable across a wide range of smart card–aware applications, the economics of adding smart cards can be greatly mitigated.
One of the primary reasons smart cards exist is security. The card itself provides a computing platform on which information can be stored securely and computations can be performed securely. The smart card also is highly portable and convenient to carry around on one's person. Consequently, the smart card is ideally suited to function as a token through which the security of other systems can be enhanced.
In financial systems, sensitive information such as bank account numbers can be stored on a smart card. In electronic purse applications (cash cards and the like), the balance of some negotiable currency can be stored on a card and this currency can be credited or debited by external terminals (systems) in a local transaction.
In physical access systems (e.g., opening the door to your office), a smart card can hold the key through which an electronic system can be enticed to unlock the door and allow entry. In network systems or even local computer systems, the smart card can hold the password through which a user is identified to the network or local system and through which privileges are granted by those systems to access information or processing capabilities.
When viewed in the abstract, all these seemingly disjointed systems have very similar needs and operational characteristics, particularly with regard to the security of those systems. On that basis, let's examine some of the general characteristics of systems that collectively are referred to as security.
The term security is often used in a rather loose fashion to refer to a variety of characteristics related to the performance of transactions between two or more parties in such a manner that everyone involved in the transaction trusts the integrity and, perhaps, the privacy of the transaction. With the advent of computer networks and of highly distributed financial transactions, it is often the case that all the necessary parties to a transaction cannot be physically at the same place, or even at the same time, in order to participate in the transaction.
Consider the purchase of an item with a credit card at an airport gift shop while on a trip. This transaction includes a number of distinct steps:
presentation of the consumer's credit card to the vendor
validation by the vendor that the cardholder is really the owner of the card
validation by the vendor that the credit card account represented by the card is valid
validation by the vendor that the account maintains a sufficient credit balance to cover the cost of the item being purchased
debiting the credit account represented by the card by the amount of the item purchased
crediting the account of the vendor with the amount of the item purchased (less any fees due to the bank, etc. related to the credit card transaction)
In the performance of this transaction, the cardholder would also like some assurances that much, if not all, of the information related to the transaction is held private. The credit card name, account number, and validation code should not be obtained by some unscrupulous character bent on making fraudulent purchases with the purloined information.
In the performance of a credit card transaction, there are actually many more components than previously mentioned. However, in just the steps noted, you can see that physical separation of the various parties to the transaction makes it difficult to guarantee that all these parties are satisfied about the integrity and privacy of the transaction.
This section discusses the characteristics of security involved in supporting such a transaction. To facilitate this discussion, the objectives of a security environment are first presented in somewhat abstract terms. After, some of the elements (we'll call them players) of a widely distributed transaction system are examined. Then, some of the mechanisms currently in wide use to provide the desired characteristics through the identified players are examined. Finally, some of the attacks used to thwart these security mechanisms are reviewed.
Security within physical or electronic systems can be viewed as the provision of one or more general characteristics:
authentication
authorization
privacy
integrity
nonrepudiation
When part or all of these characteristics are provided to the extent required to satisfy all the participants of the transaction, the transaction can be said to be secure.
Authentication means establishing an identity within a transaction. Consider a very simple (nonelectronic) transaction such as a student providing homework to a teacher. In general, the teacher wants to confirm that a specific set of homework comes from a specific student. What's involved in establishing identities in such a transaction? Well, when the homework is turned in to the teacher, the teacher will likely just visually recognize the student and accept the homework. In order to identify the homework of a specific student, the teacher may inspect the homework when it is turned in to confirm that the student's name is on it. Then, at some later time after the teacher has reviewed the homework and graded the paper, the grade can be recorded next to the name. In such a transaction, an environment of trust must be established; the teacher can associate (visually) a student, the student's homework, and the student's name on the homework, and the teacher believes this association to be true. Establishing this trust environment for a classroom setting is typically a subtle—and not usually rigorous—procedure.
In general, the rigor applied to establishing trust is commensurate with the value of the transaction. If the transaction does not involve simply homework, but something much more valuable (to one or both parties), such as a final examination or an SAT examination, then establishing the trust environment can be much more involved. Verification of identity may be required at the door of the testing facility; the form of this verification might be a student ID card or a state drivers license. Such forms of authenticated identity suffice to introduce the concept of a trust broker or a trusted third party that both of the parties to the transaction can look to for establishment of a trust environment if they don't know each other. The test monitor might not be able to visually recognize a student, but does know what a valid student ID looks like. So if the student presents such an ID with a picture on it that matches the bearer of the card and a name on it that matches a name on the test list, then the monitor can believe that the bearer of the ID card is really the person authorized to take the examination and hence received the grade derived from taking the examination.
If the transaction in question involves something of even greater value (to one or both parties), then establishing the trust environment can be even more involved. For example, purchasing a house with a mortgage loan may require that a wide variety of information be collected and the validity of that information be attested to in legally binding ways.
The object then of a security system is to provide authentication mechanisms through which a trust environment can be established among all the participants in a transaction even though the participants might not know each other, might not be physically together during the transaction, and might even be participating in the transaction at widely different times (i.e., the transaction requires a significant elapsed time to complete).
Authorization is the establishment of privileges within a transaction. That is, after the identity of a participant in a transaction has been authenticated, what that participant is allowed to do as part of the transaction must be established. In a financial transaction, this authorization might consist of simply confirming that the authenticated individual has enough money to make the desired purchase or enough money to provide the desired loan. In the earlier exam example, authorization might consist of finding a student's name on the class roster; that is, if the student can authenticate that her identity is Jane Doe and the name of Jane Doe is found by the monitor on the class roster, then that student will be allowed to take the final examination.
Just as in establishing identity (authentication), the length to which various parties in the transaction will go to establish authorization is generally related to value ascribed to the transaction by one or more parties. To gain entry to a room containing particularly sensitive information in a high-security facility, your name might have to be on an access list that can be checked by a guard of that room. To enter that room, you must meet at least two criteria. First, you must present the correct identification information to the guard to establish (authenticate) your identity. Then the guard must find your identity on the list of individuals allowed access to the room.
In some situations, the concepts of authentication and authorization might be merged together. In many office buildings, each office has a physical key. The key patterns might be such that a master key can open any office door. In this case, authentication is established by physical possession of the key. From the standpoint of the lock on the door (which is one of the participants in the transaction of unlocking and opening the door), both the authenticated identity of the individual and that individual's authorization to enter the room guarded by the door is satisfied by that individual physically presenting the key.
Privacy is the concept of allowing only the participants in a transaction to know the details of the transaction, and it might even mean that only the participants know that a transaction is occurring.
When a credit card purchase is made, the protocol of presenting the card to the vendor, performing the financial transaction, and returning a receipt of the transaction to the cardholder is set up to minimize the conveyance of sensitive information such as the account name, number, or validation number to those who might be casually observing the transaction. Similarly, when using a telephone calling card at a public telephone, conventional wisdom mandates that one be very cautious to hide the entry of the card number, lest it be seen by someone who will make note of it and use it to make cardholder telephone calls that the cardholder has not authorized.
Integrity is the concept that none of the information involved in a transaction is modified in any manner not known or approved by all the participants in the transaction, either while the transaction is in progress or after the fact. In the previous homework example, when the student turns in the homework, the total transaction may not actually be concluded until the teacher reviews the homework and records a grade. In this simple example, the integrity of the information is maintained by the teacher keeping the homework in controlled possession until it is graded and the grade recorded. The student's integrity facility in this case is to get the homework back from the teacher and to be able to review it to make sure that it's in the same state as when it was submitted.
For the homework example, the integrity of the transaction system is typically not of paramount importance to the student because teachers don't often maliciously modify homework in their possession. The teacher might be more concerned with the integrity of the information: first, in the sense of knowing that the homework hasn't been modified since it was turned in (usually not too likely) and second, in knowing that the homework was actually done by the student.
This latter aspect is often not guaranteed by any stringent mechanism in the case of homework. In the case of examinations, which might be viewed as more valuable, more proactive mechanisms are sometimes used. For example, some universities make use of an “honor code” under which a student might be required to attest to the fact that an examination was completed by the student and that the student neither gave nor received any assistance during the examination proper. Providing mechanisms to facilitate this concept in the highly dispersed environment of electronic transactions across a wide area computer network is a bit more challenging.
Nonrepudiation is establishing the fact of participation in a particular transaction by all the parties to the transaction such that none of the parties can claim after the fact that they did not actually take part in the transaction. Mechanisms to facilitate this concept are typically closely related to the mechanisms used to authenticate identity. In many discussions, the two concepts are viewed as essentially equivalent.
Of these five characteristics of security, it is the concept of privacy that precipitates the greatest concerns on the part of governmental entities. As you will see, encrypting information through mechanisms that allow only the intended participants of a transaction to be able to understand it is often a highly regulated capability. The same encryption mechanisms used to establish privacy can often also be used to authenticate identity. When used for authentication, encryption is viewed much more benignly by governmental entities than when used for privacy.
The previous sections define some of the abstract concepts of security as well as the major components of the systems for which a secure environment is desired. In this section, some of the mechanisms that the various players can use to facilitate the various security concepts are examined.
The field of cryptography is dedicated to the development of mechanisms through which information can be shared in a secure fashion. A variety of mechanisms have thus been developed through which the security concepts discussed earlier can actually be realized. Several different mechanisms have been developed to support the authentication of identity among widely diverse participants in a transaction. A few of the more prevalent of these mechanisms are described in the following sections.
Most, if not all, authentication mechanisms involve the sharing of a secret among all the participants in a transaction. Two such mechanisms involve distinct forms for encryption and decryption of information; the first makes use of a symmetric key encryption algorithm and, the second, a public key encryption algorithm. Both of these mechanisms involve a shared secret; however, the manner in which the secret is shared in each case makes the two mechanisms preferable in different situations. Specifically, symmetric key algorithms are most useful in providing bulk encryption of information because they are less processor intensive than public key algorithms.
Symmetric encryption algorithms make use of a single key for both the encryption and the decryption of information. This is illustrated in Figure 4.2.
In a symmetric key approach, the same key is fed into the encryption algorithm to both encrypt information and decrypt information. Plain text information is passed into the encryption process, where it is modified through the application of the key value. The resulting ciphertext contains all the information present in the original plain text; however, due to the manipulation of the encryption algorithm, the information is in a form not understandable by a reader that does not possess the key. When the ciphertext is passed back through the encryption algorithm with the same key applied (as was used for the encryption process) then the plain text is recovered.
It is apparent that this approach can be used to keep secret the plain text information from anyone who does not have the required key. The approach also can be used, however, to allow each side of a pair-wise transaction to confirm that the other side holds the same key and thereby authenticate a known identity.
This symmetric key identity authentication for a smart card environment is illustrated in Figure 4.3.
In the case shown in Figure 4.3, the application spans both the off-card environment and the on-card environment. In most common instances today, the application is created by the card issuer, who installs the shared secret (the key) in both environments. It should also be pointed out that the case shown in Figure 4.3 could be extended to make use of two distinct authentication operations, each using a different key. This approach would be quite useful if, for many different cards (with different cardholders), all of the cards simply need to authenticate a single identity for the off-card application while the off-card application needs to authenticate the unique identity of each individual card.
With this approach, each card would need to know two keys: one to be used to authenticate the off-card application and one to use in authenticating itself to the off-card application. The off-card 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 off-card 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 off-card 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 typically is 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 interindustry commands defined in the ISO/IEC 7816-4 specification that we'll consider a bit later in this chapter. This verification process often is 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 off-card application requests the bearer to enter a PIN through a terminal keypad. The number sequence then entered is passed through an application protocol data unit (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 (so 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 to finally be authenticated to the card.
A second approach that is widely used for identity authentication makes use of an encryption process called asymmetric key encryption; this technique is 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 4.4.
With this technique, one key is used to encrypt information and the other is used to decrypt the ciphertext 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. What's 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 of the keys can be held as a closely guarded secret (and indeed should be) by the entity that 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, it's referred to as the public key. The public/private key pair can be used to establish authenticated identity, as illustrated in Figure 4.5.
What's shown in Figure 4.5 is actually just authentication in one direction; that is, the off-card application can authenticate its identity to the smart card–side application. To do this, the off-card 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 off-card 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 ciphertext generated from this challenge text to the off-card application. If the off-card application really possesses the identity (private key) corresponding to the public key possessed by the card, then 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 off-card application. In this case, the off-card application needs to know only the public key component related to each card's identity. So 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, there's never a free lunch. Computationally, a public key encryption and/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 previously 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. Thus, 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 that has been digitally signed has not been modified from the time that it is signed until it is read (and the signature's identity is authenticated). This, then, is a means of addressing another of the concepts of security: integrity.
In the case illustrated by Figure 4.5, when the smart card encrypts the challenge text with a public key, the smart card authenticates the identity of the off-card application when it demonstrates possession of the private key, which can decrypt the challenge text. The smart card application knows that only the possessor of the private key can decrypt that message. So if the process is reversed and the off-card application generates some piece of text and encrypts it with its private key, the smart card application knows that the text, when decrypted with the public key (of the off-card application's identity) must have come from the off-card application. Thus, the off-card application has digitally signed the text in question; that is, it has essentially affixed an identifying symbol that conveys the same information that the signature at the bottom of a contract does.
As mentioned previously, public key encryption and decryption can be very processor intensive. Further, the public key encryption and decryption operations being discussed are (for purposes of the current discussion) intended to authenticate identity, not assure privacy. This being the case, it is not actually necessary to encrypt all the information in question in order to digitally sign it and to validate that it hasn't changed (i.e., that the integrity of the information has been preserved). Rather, all that is necessary is to calculate some type of unique checksum over the information in question and then encrypt that checksum. A checksum is the result from a computational algorithm acting on the information in question such that if a single bit of that information changes, the resulting checksum will change.
Generation of such checksums is possible with a family of computational algorithms known as one-way hash functions. Through these functions, you can process a large collection of information and derive a much smaller set of information, referred to as a hash code. You might think of a hash function as a logical, nondestructive meat grinder. When you grind a piece of meat with it, you don't destroy the meat, but you get out a pile of ground round that is unique for every piece of meat you put into it. So, if I put the same piece of meat through the grinder twice, I get two identical batches of ground round.
Some very desirable traits of useful one-way hash functions are the creation of a unique hash code for a unique collection of bits comprising the source document and the inability (or at least great computational difficulty) to predict what hash code will be generated (without passing the information in question through the one-way hash code algorithm) from a given collection of bits. Probably, the most popular one-way hash code in use in the smart card world is the SHA-1 algorithm.
A variant of one-way hash functions has been developed that also requires a key, in addition to the information in question, before a one-way hash code can be computed. These functions are referred to as message authentication codes, or MACs. They are useful for confirming integrity of information as well as authenticating identities associated with the information, but without guaranteeing the privacy of the information. A variant on this theme involves the use of public key cryptography in conjunction with one-way hash functions; this is the mechanism that is most generally called a digital signature as opposed to the definition suggested earlier.
If a one-way hash function is computed on a collection of information and that hash code is not encrypted with the private key of a public/private key pair, the encrypted information that results provides both authentication of the identity of the entity which encrypted the hash code (essentially signed the original information) and the integrity of the original information. This mechanism is illustrated in Figure 4.6.
From Figure 4.6, you can see that if the original document along with the digital signature of that document (i.e., the private key–encrypted hash code calculated from the document) is now passed to a another entity, that entity can validate the digital signature, authenticate the identity of the entity that digitally signed the original document, and confirm the integrity of the original document (i.e., confirm that the same one-way hash code is calculated from the document on receipt as was calculated from the document at signing time).
After the identity of an entity is established through some authentication procedure, what that entity is allowed to do in the context of a given system is the subject of another security concept termed authorization. It is useful to think of authorization in the context of a server that is being accessed by a client—the server provides information or some other abstract service to the client based on what privileges the client has with respect to that server; the model is illustrated in Figure 4.7.
This model indicates that if a client wants to gain some type of access to an object of interest, it must first authenticate its identity to the server. The server can then consult a list of privileges, which that client (identity) has with respect to that object of interest. Figure 4.7 denotes this list of privileges as an access control list (ACL); most such mechanisms can be abstracted back to something that looks like an ACL. This mechanism is widely used within smart cards for access to information (in files or objects) and/or processing capabilities (functions).
ACLs are authorization or privileges lists that link identities, and what those identities are allowed to do, to specific objects of interest. The ACL is typically viewed from the perspective of the object of interest and the server that makes that object of interest accessible to clients. It is the server that interprets the ACL and decides, based on the authorizations it finds there, what access to allow to the object of interest by the client. For a particular object of interest, a well-defined set of authorizations typically can be defined. For a file, for instance, the following privileges typically are defined:
create
delete
read
write
modify
execute
An ACL for such a file might then look as shown in Table 4.1.
Table 4.1. The ACL for the File abc.txt
Identity | Create | Delete | Read | Write | Execute | Control |
|---|---|---|---|---|---|---|
Jane Doe | X | X | X | X | X | X |
Good Person | X | X | X | |||
Iffy Person | X |
This ACL says that the identity Jane Doe can really do anything at all to the file. The identity Good Person can read, write, and execute any code found in the file, while the identity Iffy Person can only read the contents of the file.
A relatively orthogonal way of looking at this same authorization model (i.e., one represented by an ACL) is called a capabilities list. In most instances, the way this variant of the model is implemented, the capabilities list is passed along to the server essentially merged with the identity authentication. That is, there is assumed to be an administration function that decides, external to the actual server, what capabilities (privileges) a specific identity is to have with respect to the object of interest.
In both variants, the security procedures followed are essentially the same. First, authenticate the identity, and then go to an authorization list to determine what privileges that identity has with respect to the object of interest. The most straightforward mechanism for doing this is to include the capabilities list in the digital certificate through which identity is tied to a key that can be used to authenticate that identity.
The final concept of security to be dealt with is privacy, which is keeping the details of a transaction secret from everyone not involved in the transaction. The cryptographic mechanisms previously discussed are adequate to provide transaction privacy. In general, the major design factor (i.e., deciding which mechanism to actually use) is one of performance in the actual operational environment.
As mentioned previously, public key cryptography is significantly more processor intensive than is symmetric key cryptography. Consequently, most systems make use of symmetric key algorithms to actually encrypt the information flow between two disparate points involved in the same transaction. In point of fact, however, public key mechanisms are still quite useful in even this case. Specifically, public key mechanisms are useful in order to exchange the symmetric key needed by both ends of the communication channel. Such shared secrets are well-recognized risk areas in security systems; the longer and more often that the same symmetric key is used, the better the chance for an attacker to figure out what it is and use that knowledge to compromise the privacy of the transaction channel.
If public keys are well known throughout the specific security system, then the mechanisms discussed earlier can be used in which one end of the transaction channel can generate a random symmetric key and send it, under cloak of encryption by the other end's public key knowing that only the other end possesses the private key necessary to decrypt the message containing the secret symmetric key.
If public keys are not well known throughout the system, or actually even if they are, another mechanism exists that is useful specifically for distributing secret symmetric “session” keys (so named because a new key can be generated for each “session” in which a transaction of some type is to occur) among disparate participants in the transaction. The mechanism is known as the Diffie-Helman protocol. It has the very nice feature that, by agreeing in advance to make use of a common algorithm, each end of the channel can calculate a secret key based on information that it can exchange in the clear. The mechanism cannot be used to actually encrypt information, but rather just to exchange a secret symmetric key, which can then be used to encrypt the actual transaction information.
The encryption of transaction information often is referred to as bulk encryption. In general, smart cards are not involved in bulk encryption processes. The data transfer rate across the I/O port from a smart card reader to the card is very low (on the order of 10 Kbps) relative to typical transmission speeds across local area or even wide area networks. Consequently, most cryptographic operations that are actually performed on a smart card are related to establishment of identity.
The dominant algorithms used for bulk data encryption include the DES algorithm, the Triple-DES algorithm, the RC4 algorithm, and the AES algorithm.
The ISO/IEC 7816-4 specification provides a paradigm for identity authentication that is found consistently across most smart card applications. Moreover, it defines an authorization mechanism that builds upon this authentication facility so as to allow the definition of security policies that limit access to information stored in the file systems found on smart cards or to standard computations performed on information found in the file system of a smart card.
In the course of a typical smart card application, there are three distinct actors whose identities need to be authenticated:
host (off-card computer) application
smart card (on-card computer) application
cardholder
The host and the smart card computers need to authenticate themselves to each other. After they do this, they can communicate information and services because each knows that the other belongs to the same security domain. It is possible for these two entities to establish a private (encrypted) channel and thus preclude any eavesdropper from listening in on the proceedings of the transaction. These two computer systems can then participate in the application on behalf of the cardholder, assuming that the cardholder is truly the owner (holder) of the smart card. So, an additional authentication mechanism is needed to authenticate the identity of the cardholder to the smart card. After this is done, the card can participate in the application on behalf of the cardholder.
The method used for authenticating the two computer systems to each other (i.e., the smart card ICC to the host computer) consists of each computer proving to the other that it knows a secret shared between the two machines. To enhance the long-term security of the two systems, it is desirable that this mechanism not involve actually moving the secret between the two systems. So, in the approach used, the shared secret is a key that can be used by a cryptographic algorithm to encrypt information. The approach can use either symmetric key cryptography or asymmetric key cryptography. In the authentication process, a key is used by one side of the operation (either the card or the host computer) to encrypt a random piece of information that has been specified by the other side of the operation. If both sides are using (know) the same key, then the “other” side will be able to decrypt and recover the random piece of information.
When the card has authenticated the off-card computer's identity, the card is then said to be in an AUTH state relative to the key used in the authentication process. Various commands can be tagged such that the on-card system must be in an AUTH state before the command can be executed. Since the off-card computer sends commands to the on-card computer, this mechanism means that the off-card system has to be authenticated to the on-card system in order execute these commands. Since the various commands provide access to information or computational services on the card, this defines an authorization mechanism which limits access to that information of those services.
There can be multiple key files stored on a card and there can be multiple keys in each of those files. This means that, in theory, a very large number of identities can be authenticated by the card and given access to various pieces of information or services.
Another authentication mechanism uses a PIN stored in a file. If an off-card computer can provide a command containing the correct PIN, it can cause the on-card system to enter a state called CHV (cardholder verified). Commands can be predicated upon being in the CHV state just as for the AUTH state. So, by proper design of the information structures on the card, various information and various capabilities (in essence, various applications) can be made available to different off-card identities. In this case, the off-card identities are the “owners” of the application systems in which the on-card components work.
In the following sections, we'll examine the details of the specific commands used to authenticate identities. Plus, we'll see a standard information storage system and the commands that, under authorization control such as we've just discussed, are able to operate on this storage system.
As was mentioned previously, in an effort to provide some standardization among smart cards, an interindustry command set was defined in the ISO/IEC 7816-4 specification. This command set included commands in two distinct areas, as well as several general-purpose, administrative commands. The two specific areas are:
security features
on-card file systems
The commands aimed at security provide mechanisms that allow the authentication of identity among the participants in smart card–based transactions. That is, computers can authenticate to computers and a person (a cardholder) can authenticate to a computer (the smart card). These mechanisms are based in well-established cryptographic operations.
The messages used to support the ISO 7816-4–defined application protocol(s) comprise two structures: one used by the reader side of the channel to send commands to the card and the other used by the card to send responses back to the reader. The former is referred to as the command APDU and the latter as the response APDU.
As illustrated in Figure 4.8, the command APDU comprises a header and a body, each of which is further subdivided into several fields. The header includes CLA, INS, P1, and P2 fields. CLA and INS define an application class and instruction group as described, for example, in ISO 7816-4. The P1 and P2 fields are used to qualify specific instructions and are therefore given specific definitions by each [CLA,INS] instruction. The body of the APDU is a variable size (and form) component that is used to convey information to the card's APDU processor as part of a command or to convey information from the card back to the reader as part of a response to a command. The Lc field specifies the number of bytes to be transferred to the card as part of an instruction; it contains the length of the data field. The data field comprises data that must be conveyed to the card in order to allow its APDU processor to execute the command specified in the APDU. The Le field specifies the number of bytes that will be returned to the reader by the card's APDU processor in the response APDU for this particular command. The body of the APDU can have four different forms:
No data is transferred to or from the card, so the APDU includes only the header component.
No data is transferred to the card but data is returned from the card, so the body of the APDU includes only a non-null Le field.
Data is transferred to the card but no data is returned from the card as a result of the command, so the body of the APDU includes the Lc field and the data field.
Data is transferred to the card and data is returned from the card as a result of the command, so the body of the APDU includes the Lc field, the data field, and the Le field.
Figure 4.9 illustrates the much simpler structure of the response APDU structure. It includes a body and a trailer. The body is either null or includes a data field, depending on the specific command that it is a response to and depending on whether that command was successfully executed by the card's APDU processor. If the response APDU does include a data field, its length is determined by the Le field of the command to which the response corresponds.
The response APDU also includes a trailer field, which can comprise two fields of status information that are referenced as SW1 and SW2. These fields return (from the card's APDU processor) to the reader-side application a status code that, according to ISO 7816-4, has a numbering scheme in which one byte is used to convey an error category and the other byte is used to convey a command-specific status or error indication. This numbering scheme is illustrated in Figure 4.10.
The CLA code that is included in each command APDU has two additional components to be noted:
The two low-order bits of the CLA byte can be used to designate a logical communication channel between the reader-side application and the card's APDU processor.
The next two higher order bits of the CLA byte can be used to indicate that secure messaging is to be used between the reader-side application and the card's APDU processor.
After the link-level protocol is established between the reader-side application and the card's APDU processor, a base-level (command) logical channel is created. This is indicated (in the CLA byte) by both of the low-order bits being 0. Additional logical channels can be created by using the Manage Channel command, which is defined by ISO 7816-4.
ISO 7816-4 also defines a modest secure messaging protocol, which can be used to ensure privacy and integrity of APDUs transferred between the reader-side application and the card's APDU processor.
Associated with each component of the file system is a list of access properties. Through these access properties, a state can be defined such that the smart card system must be put into that state, through the successful execution of a series of commands by the reader, before that component of the file system can be accessed. At the most basic level, the operations to be performed on the file system are to select a specific file and then write information to that file or read information from that file. As shown in the following sections, the access properties may be as simple as requiring the reader to provide a predefined PIN or as complex as the reader proving that it possesses some shared secret (e.g., a key) with the card. These mechanisms will be reviewed in more detail in the following sections.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | 2016 | 0016 | 0016 | 0316 | 5316 6116 5316 |
The Verify command is a command sent by a reader-side application to the security system on the card to allow it to check for a match to password type information stored on the card. This command is used to allow the reader-side application to convince the card that it (the reader-side application) knows a password maintained by the card to restrict access to information on the card.
The password type information may be attached to a specific file on the card or to part or all of the file hierarchy on the card. Successful execution of this command indicates that the reader-side application did know the correct password and it puts the card into a state such that a subsequent access to a file guarded by this password information will succeed.
If the Verify command fails (i.e., the password required by the card is not correctly provided by the reader-side application), then an error status indicator is returned by the card to the reader-side application.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | 8816 | 0016 | 0016 | 0316 | 0216 0116 0316 |
The Internal Authenticate command is a command sent by a reader-side application to the security system on the card to allow the card to prove that it possesses a secret key that is shared with the reader-side application. To prepare this command, the reader-side application creates a set of challenge data (i.e., essentially, the reader-side application generates a random number). This number is then encrypted with some agreed-on algorithm (with the card); this constitutes a challenge to the card.
When given the command, the card then decrypts the challenge with a secret key stored in a file on the card. The information derived from the decryption is then passed back to the reader-side application as a response to the command. If the card really does have the correct secret key, then the information passed back will be the random number generated by the reader-side application prior to issuing the Internal Authenticate command.
This command is used by the reader-side application to authenticate the card's identity. That is, when successfully completed, the reader-side application knows the identity of the card and can give to the card access to information or services within the reader-side application.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | 8216 | 0016 | 0016 | 0316 | 0316 0216 0116 0316 |
The External Authenticate command is used by a reader-side application, in conjunction with the Get Challenge command (described in the next section) to allow the reader-side application to authenticate its identity to the card.
Through the Get Challenge command, the reader-side application receives a set of challenge data from the card (i.e., a random number generated by the card). The reader-side application then encrypts this information with a secret key. This then forms a challenge, which is sent to the card via the External Authenticate command. If the reader-side application knows the same secret key that is stored on the card, then when the card decrypts the challenge, it will find the same random number generated by the last Get Challenge command. Therefore, the card now knows the identity of the reader-side application and can give it (the reader-side application) to data on the card.
The attractive characteristic of this method (from a security standpoint) is that the secret key used to authenticate identity between the reader-side application and the card was never transferred between the reader-side application and the card.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | 8416 | 0016 | 0016 | 0616 | empty |
The Get Challenge command is used by the reader-side application to extract information that can be used to formulate a challenge to the card that can be validated through an External Authenticate command. The result of this command is the generation of a random number by the card, which is then passed back to the reader-side application.
A central application for smart cards defined by the ISO/IEC 7816-4 standard is a file system. The file system is actually applied to the nonvolatile memory on the smart card, generally electrically erasable and programmable read-only memory (EEPROM). The file system defined is a relatively straightforward hierarchical structure comprising three basic elements:
a master file (MF) component
a directory file (DF) component
an elementary file (EF) component
The MF component is the root of the file hierarchy; there is only one MF on a smart card. An MF may contain as elements a DF, or even many DFs, and it may contain none to many EFs. The DF component is essentially a container for EF components; a DF may contain none to many EFs. An EF component may contain only records. This simple hierarchical structure is illustrated in Figure 4.11.
Several characteristics of the smart card file system are significantly different from typical (e.g., disk-based) file systems. These differences are almost exclusively due to the physical characteristics of the EEPROM memory system—specifically, the facts that EEPROM memory can only be subjected to a modest number of erase and write cycles and that it is significantly faster to write to EEPROM memory in a cumulative fashion than in a pure erase and then write fashion. The first of these characteristics resulted in the definition of a rather unique file structure called a cyclic file. The second characteristic resulted in rather unique definitions of the various file write commands.
The cyclic file is actually a ring buffer of physical files that are addressed and accessed as a single file. On successive write operations, the next physical file (in the ring of physical files) is accessed. The net result is that erase and write operations can be spread across a wider selection of EEPROM memory locations. This mitigates somewhat the limit (generally on the order of 100,000 cycles) on the number of times that a specific EEPROM memory location can be erased and rewritten.
EEPROM memory has the additional interesting characteristic that it is significantly faster to set additional bits in a memory location than it is to erase all the currently set bits and then rewrite them. This fact becomes doubly useful in certain operations (e.g., manipulating a purse value on a smart card) where it is required that operations on a file be performed in such a fashion that the values stored in the file are well understood at any point in time, even if power is removed from the smart card in the middle of a file operation. To facilitate the exploitation of these characteristics, the write operations to a smart card file are typically bit-set operations while the update operations are actually erase and rewrite operations, which we generally associate with file-writing operations. These characteristics will be examined in a bit more detail in the following sections.
Each smart card file system has exactly one MF. The MF serves as the root of the hierarchical file structure. In the parlance of general file systems, the MF is a container or a directory; it may contain other dedicated (or directory) files (DFs) or it may contain EFs.
Any file can be identified by a 2-byte file identifier. The file identifier 3F00 is reserved for the MF; that is, there is only one file with a file identifier of 3F00, and the file with that identifier is the MF.
The DF also is a container or a directory file in the same vein as the MF. The DF forms a subdirectory within the file hierarchy rooted in the MF. A DF also can be identified by a file identifier. A DF must be given a unique file identifier within the DF (or MF) that contains it. This allows for the creation of a unique path designation for a file (i.e., a path is simply the concatenation of the file identifiers of the file in question, and of all the DFs between the file in question and its containing DF or MF).
A DF also can be referenced by a name that may be from 1 to 16 byes long. The naming conventions for the DF name are found in the ISO/IEC 7816-5 specification.
The EF is the leaf node of the file hierarchy. It is the file that actually contains data. There are two variants of EFs: an internal EF, which is to be used by applications on the card, and a working EF, which is used as a storage mechanism for information used by an off-card application.
Within a specific DF, an EF may be identified by a short (5-bit) identifier. There are four variants of EFs as illustrated in Figure 4.12:
a transparent file
a linear, fixed-length record file
a linear, variable-length record file
a cyclic, fixed-length record file
A transparent file can be viewed as a string of bytes. When a command is used to read or write information from a transparent file, it is necessary to provide a byte offset (from the start of the file) to the specific byte (within the transparent file) where reading or writing should begin. A command to read or write information from/to a transparent file will also contain a counter or length of the byte string to be read or written to the file.
Fixed- or variable-length record files are, as the name suggests, files that comprise subdivisions called records. Records (within a file) are identified by a sequence number. In a fixed-length record file, all the records contain the same number of bytes. In a variable-length record file, each record in the file can contain a different number of bytes. As might be suspected, a variable-length record file generally has a significantly higher overhead in read/write access time and in the amount of administrative (data storage) overhead required by the file system.
A cyclic file is a rather unique (to smart card file systems) structure. It allows applications to access a file in a consistent, transparent fashion and yet have the file system itself map this access into a variety of different physical files. This allows the limits of erase and rewrite cycles on EEPROM memory to be somewhat mitigated.
A cyclic file is best thought of as a ring of records. Each successive write to the file performs the operation on the next physical record in the ring. Read operations are performed on the last physical record that was actually written to.
To manipulate the smart card file system, an application-level protocol is defined in the form of a collection of functions for selecting, reading, and writing files. These functions are discussed qualitatively in the following sections.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | A416 | 0016 | 0016 | 0216 | 3F16 0016 |
The Select File command is used to establish what may be thought of as a logical pointer to a specific file in the smart card's file system. After a file is selected by this command, any subsequent commands, such as those to read or write information, will operate on the file pointed to by this logical pointer. Access to the smart card's file system is not multithreaded (from the card's viewpoint), but it is possible to have multiple such logical pointers in play at any point in time. This is done by using the Manage Channel command to establish multiple logical channels between the reader-side application and the card. Commands to access different files can then be multiplexed (by the reader-side application) allowing different files on the card to be in various states of access by the reader-side application at the same time.
The primary piece of information the command must convey (from the reader-side application to the smart card's APDU processor) is the identification of the file to which this logical pointer must point. This identification can be provided in three ways (with the specific addressing mechanism being indicated in the data field of the Select File command APDU):
by file identifier (2-byte value)
by DF name (string of bytes identifying the DF)
by path (concatenation of file identifiers)
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | B016 | 0016 | 0016 | 1016 | empty |
The Read Binary command is used by a reader-side application to retrieve some segment of an EF on the card. The EF being accessed must be a transparent file; that is, it cannot be a record-oriented file. If a Read Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned by the card to the reader-side application.
Two parameters are passed from the reader-side application to the card for this command: an offset pointer from the start of the file to initial byte to be read, and the number of bytes to be read and returned to the reader-side application.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | D016 | 0116 | 0116 | 0116 | FF16 |
The Write Binary command is used by a reader-side application to put information into a segment of an EF on the card. The file being accessed must be a transparent file; that is, it cannot be a record-oriented file. If a Write Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned by the card to the reader-side application.
Depending on the attributes passed from the reader-side application to the card in the Write Binary command, the command can be used to set a series of bytes in the EF (i.e., set selected bits within the designated bytes to a value of 1), clear a series of bytes in the EF (i.e., set selected bits within the designated bytes to a value of 0), or do a one-time write of a series of bytes in the EF.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | D616 | 0116 | 0116 | 0116 | FF16 |
The Update Binary command is used by a reader-side application to directly erase and store a set of information (bytes) into a segment of an EF on the card. The file being accessed must be a transparent file; that is, it cannot be a record-oriented file. If an Update Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned by the card to the reader-side application.
The Update Binary command provides the functions that would normally be associated with a file write command. That is, a string of bits provided in the command are actually written into the EF on the card, with those byte positions in the file on the card being erased first. The net result is that the string of bytes found in the designated position within the EF on the card is exactly the string sent by the reader-side application in the Update Binary command.
Input parameters for the command include an offset pointer from the start of the file and a byte count of the total number of bytes to be written.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | 0E16 | 0116 | 0116 | 0116 | 0616 |
The Erase Binary command is used by a reader-side application to erase (set the value to 0) a string of bits within an EF on a card. The file being accessed must be a transparent file; that is, it cannot be a record-oriented file. If an Erase Binary command is attempted on a record-oriented EF, the command will abort with an error indicator being returned by the card to the reader-side application.
Two parameters are specified as part of the command: an offset from the start of the EF to the segment of bytes within the file to be erased and the number of bytes within that segment.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | B216 | 0616 | 0416 | 1416 | empty |
The Read Record command is a command sent by a reader-side application to read and return the contents of one or more records in an EF on a card. This command must be executed against a record-oriented EF. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application.
Depending on the parameters passed through the command, the one designated record is read and returned, or all the records from the beginning of the file to the designated record are read and returned, or all the records from the designated record to the end of the file are read and returned.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | D216 | 0616 | 0416 | 1416 | 5316 6116 6C16 6C16 7916 2016 4716 7216 6516 6516 6E16 0016 0016 0016 0016 0016 0016 0016 0016 0016 |
The Write Record command is a command sent by a reader-side application to write a record into an EF on the card. This command must be executed against a record-oriented EF. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application. In the sample command sequence noted previously, 14 (hexadecimal) characters will be written into the currently selected record beginning at the sixth character position in that record. The characters to be written are contained in the Data field (i.e., the hexadecimal representation for “Sally Green”).
As with the Write Binary command, this command can actually be used to achieve one of three results: a one-time write of a record into the EF, setting of specific bits within a specific record in the EF, or clearing of specific bits within a specific record in the EF.
Several addressing shortcuts may be used in this command to specify the record to be written to, including the first record in the EF, the last record in the EF, the next record in the EF, the previous record in the EF, or a specific record (identified by number) within the EF.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | E216 | 0016 | 0016 | 1416 | 5316 6116 6C16 6C16 7916 2016 4716 7216 6516 6516 6E16 0016 0016 0016 0016 0016 0016 0016 0016 0016 |
The Append Record command is a command sent by a reader-side application to either add an additional record at the end of a linear, record-oriented EF on a card or to write the first record in a cyclic, record-oriented EF on a card. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application.
In the preceding example, P1 is an unused parameter and is always 0016. P2 is the short identifier of the file to which the record append will apply. Lc specifies the number of characters in the record to be appended and the Data field contains the characters to be appended—in this case, the hexadecimal representation of “Sally Green.” That is, for whatever end, this command appends the words “Sally Green” in a record onto the end of the selected file.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | DC16 | 0616 | 0416 | 1416 | 5316 6161 6C16 6C16 7916 2160 4716 7216 6516 6516 6E16 0016 0016 0016 0016 0016 0016 0016 0016 0016 |
The Update Record command is a command sent by a reader-side application to write a record into an EF on the card. This command must be executed against a record-oriented EF. If it is applied to a transparent EF, the command will abort and an error indicator will be sent from the card back to the reader-side application.
As with the Update Binary command, this command is used to write a specific record into an EF. The net result of the operation is that the specific record in the EF is erased and the new record specified in the command is written into the EF.
The master-slave command protocol specified by ISO/IEC 7816-4 is quite restrictive in its ability to accommodate the wide variety of commands that you might want to access on a smart card. In an attempt to compensate for some of the syntactic shortcomings, ISO/IEC 7816-4 also defines a number of administrative commands that allow a wider latitude of command structures and responses.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | C016 | 0016 | 0016 | 1416 | empty |
The Get Response command is another command that allows the use of the T=0 link-level protocol for conveying the full range of APDUs. Specifically, the Case 4 type of APDU body cannot be supported with the T=0 protocol. That is, you can't send a body of data to the card and then receive a body of data back as a direct response to that command. For this type of command, using the T=0 protocol, the initial command results in a response that indicates more data is waiting (in the card). The Get Response command is then used to retrieve that waiting data.
It should be noted that no other command can be interleaved between the original command and the Get Response command.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | 7016 | 0016 | 0116 | 0016 | empty |
The Manage Channel command is used by the reader-side application to open and close logical communication channels between it and the card. When the card initially establishes an application-level protocol with the reader-side application (i.e., following the ATR sequence) a basic communication channel is opened. This channel is then used to open and/or close additional logical channels via the Manage Channel command.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | C216 | 0016 | 0016 | 0716 | C016 A416 0016 0016 0216 3F16 0016 |
The Envelope command is a command that supports the use of secure messaging via the T=0 link-level protocol. In secure messaging, the full command APDU should be encrypted. However, because the CLA and INS bytes from the APDU overlay elements of the transmission protocol data units (TPDU), these bytes (in the TPDU) cannot be encrypted if the link-level protocol is still to work correctly. So the Envelope command allows a full APDU to be encrypted and then included in the Envelope command's data section (of its APDU). The card's APDU processor can then extract the “real” command and cause it to be executed.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | CA16 | 0216 | 0116 | 1416 | empty |
The Get Data command is a command sent by a reader-side application to read and return the contents of a data object stored within the file system on the card. This command is essentially the complement of the Put Data command (defined in the next section). This command tends to be very card specific in its internal implementation. However, the semantics of the command are well defined. That is, the definition of just what constitutes a data object varies widely from card to card, but what the command does should be consistent from card to card. Thus, for retrieving a small amount of information, this command might well be preferable to retrieving information from a specific file.
CLA | INS | P1 | P2 | Lc | Data |
|---|---|---|---|---|---|
C016 | DA16 | 0216 | 0116 | 0116 | FF16 |
The Put Data command is a command sent by a reader-side application to put information into a data object stored within the file system on the card. This command tends to be very card specific in its implementation; however, it is relatively general in its specification. So, the fact that the definition of just what constitutes a data object varies widely from card to card does not necessarily mean that the semantics of the command varies from card to card. In fact, the attractive feature of this command is the fact that you do not need to know the identity of a specific file into which the “data” is to be stored. This tends to make the command similar across a variety of different smart cards. An application, should it need to store only a modest bit of information, can do so with this command and be moderately assured that the command will work on a variety of different smart cards.
This chapter has hopefully provided you with a fairly extensive introduction into the structure of the smart card–side of a smart card–aware application. The most interesting facets of this environment are the security mechanisms that are defined through a set of international standards and which find themselves present on most smart cards in use today. Further, these same international standards establish a paradigm for smart card applications in the form of an on-card file system replete with an authentication and authorization mechanism that is firmly rooted in the use of cryptographic services to achieve the desired characteristics of security. A series of commands for manipulating this on-card file system forms the backbone of many smart card applications in use today.