As we have discussed throughout this book, a smart card can be a valuable addition to a variety of applications, many based in wide area computer systems and networks. A smart card is an excellent security token for large-scale security infrastructures. Its ability to store information in a tamper-resistant and tamper-evident package and to provide secure computation on the same platform makes it an excellent facility to store cryptographic keys through which the identity of the cardholder can be authenticated. Further, a wide variety of personal information about the cardholder can be stored on the card and carried on his or her person.
As we've looked at the various aspects of smart cards, we've touched on many if not all of the elements of large-scale smart card systems: the participants in developing, deploying and using the systems; the constituent elements of the systems; and many of the mechanisms used within the systems. In this chapter, we'd like to bring all of these into focus and, with this in mind, look at the characteristics that will guide why and how we want to manage the system. This will hopefully give you a basis on which to ground your understanding of the issues involved in fielding a smart card system and the aspects of card management that you'll need to consider as you field that smart card system.
Using smart cards in an application involving individuals (cardholders) and a wide area infrastructure such as a banking system or mobile telephone system involves the intersection of two large-scale systems. If the smart card is capable of supporting multiple applications, and even more so if the card is post-issuance programmable, then the convergce of three large-scale systems is involved:
Card system—. Smart card development, manufacturing, and deployment
Operating Infrastructure—. Application Operations System infrastructure development, deployment, and operations
Application system—. Application development
Figure 10.1 is a simplified illustration of the convergence of these large-scale systems, portraying them by showing many of their constituent activities and the interconnection of these activities. At the top of the figure we see the principle operations involved in developing and deploying the smart card system; below are shown the steps involved in developing and deploying the applications that will make use of the smart cards. Finally, at the bottom and down the right-hand side of the figure are shown the primary elements of the operational and management system for families of applications. As illustrated in Figure 10.1, each of these systems represents a significant administrative and support load in its own right. Making all three types of systems work together is a particularly daunting task. To accomplish it well, a coherent management approach and an integrated management system are desirable, if not mandatory.
Within large-scale, smart card–based application systems, there are a number of distinct roles played out in the development, deployment, and ongoing operations of the complete system infrastructure. Some of these roles are consistent with those found in typical IT systems. Some are perhaps a bit unique to the smart card arena. In the course of this book, we've mentioned most of these principals from time to time; now, in the following sections, we'll examine some of them in a more coherent fashion. In a couple of areas, we'll provide the names of some organizations that are well known in these particular arenas. Theirs aren't the only groups in these areas, but serve as examples of the types of groups you'll seek out if you become involved in considering the deployment of a smart card-based system.
The central entity in any commercial smart card application venture is the card issuer. This is the control point for the application system—the owner of it, if you will. More to the point, the card issuer is usually the ultimate risk taker/holder in the system. If there is a breakdown in the overall integrity (security) of the system, it is the card issuer's nickel at stake.
Historically, smart card systems started with the card issuer. The card issuer would develop the concept for the application or application system and would approach the smart card manufacturer, and others, to develop on-card and off-card components of the system. In many instances, particularly with financial systems, the card issuer would be responsible for the long-term operation of the system. With current systems, we are at a bit of a transition point insofar as system development goes. Today, significant parts of an application infrastructure either exist or are off-the-shelf components, ready to be integrated into a final system.
With the current style of system deployment, smart cards themselves are often off-the-shelf items. The card's integrated circuit chip (ICC) architecture is developed as a moderately general-purpose computing platform and the installation of the final application software on it typically involves either soft-mask or application installation at prepersonalization time (a concept we'll look at in more detail a little later on in this chapter).
The card is typically given to the cardholder by a card issuer. In the case of financial cards, the issuer is generally a bank or other financial institution. The card issuer generally is responsible for providing the system in which the card can be used to perform its security-related functions. One aspect of this system is typically the linking of salient information about the cardholder to the functional characteristics of the card. In this area, the issuer functions as a certification authority or as a “trust broker.” It is through the actions of the issuer that various parties of a subsequent transaction can achieve some level of trust in the transaction even though they do not know each other prior to the initiation of the transaction.
In the financial environment, very well-defined protocols have been put in place by associations of financial organizations and buttressed by binding national and international laws and agreements. In the emerging world of computer networks, the existence of equivalent certification authorities is only now being legitimized by evolving system deployment.
A significant impediment to the deployment of smart card-based systems in the IT world has been the lack of card issuer experience in the area. The degree of liability assumed by the card issuer in this situation can be difficult to assess. In a corporate environment, it is a natural assumption that the corporate entity assume the role of card issuer, and, in fact, this is the most common model for successful systems. Given that a common role for smart cards in any system, but particularly in IT systems, is to establish an authenticated identity, the corporate HR function is perhaps the most logical card issuer of choice. As a matter of fact, the identity that can be established through a corporate HR office is probably the “best” identity that can be established short of a government ID based on a comprehensive security check.
As we saw in Chapter 2, the ICC contained in a smart card is a complete computer assembly contained within a single chip. The various elements of the ICC (i.e., the central processing unit, the various types of memory, and the other components) are quite comparable to those components as housed for general-purpose computer systems. The ICC manufacturers for smart cards are general silicon vendors who also design and manufacture components for more general-purpose computer systems. Some of the well-known ICC manufacturers are:
Infineon (www.infineon.com)
ST Microelectronics (www.stm.com)
Atmel (www.atmel.com)
Philips Semiconductors (www.philips.com)
Fujitsu (www.fujitsu.com)
Hitachi (www.hitachi.com)
The relationship among card issuers, ICC manufacturers, and smart card manufacturers is complex. Each has evolved a degree of control in developing and deploying smart card systems; in many instances, these entities are complementary while in some areas they appear competitive.
The product delivered by the ICC manufacturer is typically a smart card chip delivered in one of two forms: either as a wafer with many ICCs on it or as a module comprised of a single ICC and its associated contact faceplate. Smart card manufacturers can typically work with either variant.
The smart card manufacturer, as the name implies, is the entity that builds the smart card. The manufacturer typically develops the base operating system software for the card and perhaps the application-level software as well. The card manufacturer creates the card body from raw PVC and installs the ICC into it. The manufacturer will typically be responsible for card printing and system personalization (or the ICC), although these functions are sometimes assumed by the issuer or perhaps even a service bureau function. We'll look at the manufacturing process for a smart card a little later in this chapter.
Some of the prevalent smart card manufacturers are:
Gemplus (www.gemplus.com)
SchlumbergerSema (www.schlumbergersema.com)
Giesicke & Devrient (www.gdm.de)
Oberthur (www.oberthur.com)
These companies provide a significant fraction of the smart cards produced in the world today.
The application developer in today's system environment is part developer and part integrator. Many components of the overall application are built as standard modules, ready to be specialized for inclusion into a specific application system.
In today's marketplace, application developers are generally recruited by the card issuers or they are in the (speculative) business of building systems and recruiting card issuers to deploy them. What does not exist today is a significant population of application developers who can develop a product to sell into deployed systems. Thus, smart card systems are not yet like PC systems where applications can be independently marketed. It is, in fact, one small goal of this book to help facilitate such developers.
In the world of financial applications, a very significant role is played by the developer of the point-of-sale terminal. While smart cards provide a significant security environment for the component of the system that resides with the cardholder, a standard personal computer that might be found in the office or store of a vendor does not provide an equivalent security level. This is the realm of the POS terminal. These terminals can contain most or all of the off-card application necessary to interact with the cardholder's smart card.
The POS often contains a smart card in its own right. This security authentication module (SAM) will be contained within a POS and it serves (at least) two purposes: to authenticate the identity of the POS and to contain a purse on behalf of the POS owner/vendor to record transactions and their values.
POS manufacturers have a variety of associations, but one of the more active at the moment is the STIP group, which we discussed in Chapter 7.
A smart card can represent the cardholder in an electronic environment. Further, the card can be programmed to require some type of identity authentication from the cardholder before it will provide such electronic representation for the cardholder. That is, the smart card can use a variety of mechanisms in a transaction with the cardholder through which the cardholder convinces the card that it should act on the cardholder's behalf. Some of the mechanisms used by the card to authenticate the identity of the bearer include requiring
the bearer to enter a personal identification number (PIN)
the bearer to enter some known personal information stored on the card
some biometrical characteristic of the bearer, such as a fingerprint or a facial image, to be measured by a sensor or collection of sensors and then matched against a benchmark of this characteristic stored on the card
the bearer to properly perform a series of operations leading to a specific state known to the card
The identity authentication transaction that occurs between the card and the cardholder is a rather complete, specific example of the transaction that one wants to occur generally through the enabling actions of the card. That is, both sides of the transaction (i.e., the card and the cardholder) must be concerned with
authenticating the identity of the other (party to the transaction)
being authorized with the appropriate privileges once identity is authenticated
being assured of the integrity of the transaction
being assured of the privacy of the transaction
being able to confirm that the transaction took place in a proper fashion
We've examined the main actors in a large-scale smart card system. Now let's look at the infrastructure of the system itself. The infrastructure for smart card-based systems is, today, probably best represented by the Internet. That is, the infrastructure is comprised of many platforms and their network connections through which specific elements of smart card-based systems can be interconnected.
Essentially none of the platforms and none of the communication channels used in a widespread smart card application can be assumed to be secure in and of themselves. Consequently, the smart card (as a security platform itself) must be vigilant as to what other entities it is talking to. The designers and developers of systems have to guard against nonsecure elements of the infrastructure from being able to authenticate an identity to which the smart card will free to talk.
Smart cards use a computer platform on which information can be stored such that access to it can be strictly controlled by the cardholder, the card issuer, or the provider of any specific applications on the card. Further, software can be executed on the card under strict control of either the cardholder, the card issuer, or the provider of specific applications on the card. Given these characteristics, the smart card provides a variety of useful security characteristics, including
storage of passwords for access to computer systems, networks, information stores, and so forth
storage of keys, public and private, for authenticating identity
storage of keys, public and private, for encrypting information to ensure its privacy
storage of information to be conveyed to various access points for a system (e.g., a financial system) without the cardholder being able to access or change that information in any way
performance of encryption algorithms for authenticating identity
performance of encryption algorithms for ensuring the privacy of information
The access point of any smart card with any electronic system is typically referred to in the ISO specifications as an InterFace Device (IFD); most of the time, the terms terminal, smart card reader or smart card interface device are used. Terminals can vary significantly in complexity and capability and, hence, in the level of security that they support. At the most capable level, a terminal is a secure computing platform on a par with the smart card itself, although typically not nearly so small, inexpensive, and portable. In such a configuration, a terminal might contain a comparatively powerful computer processor, memory, telecommunications interfaces to local and wide area computer networks, display screens, and input devices (e.g., a keypad or keyboard) through which a user can enter information (to the terminal's processor and then perhaps on to the smart card), and perhaps even biometric sensors that the terminal can use to ascertain personal characteristics of the cardholder. For example, fingerprint readers and facial characteristics scanners are beginning to emerge within the security marketplace as viable elements of terminals.
A highly integrated configuration, including a tamper-resistant computer, memory and secondary storage, and a secure cardholder verification entry facility, typically would be provided by a card issuer to a merchant. This terminal provides a secure point of presence (from the standpoint of the card system issuer) in the merchant's environment through which the issuer system can communicate with the cardholder's smart card.
The most basic job of the reader is to provide a physical connection to the eight contact pins on the face plate of a smart card. Because the smart card is a serial device, some of the first smart card readers merely extended the serial port to contacts that would touch the plates on the smart card. These readers eventually gained the name dumb or pass-thru readers because they relied on the host to implement the low-level communications and timing issues involved with the communication. Typical dumb readers have a crystal to drive a clock and a means of powering the chip with possibly some rudimentary protocol negotiating capabilities with the card. On the other end of the spectrum exist readers that implement the entire protocol in their firmware. Such readers may accept up to a 260-byte APDU, reset the card, examine the atr, set the protocol parameters, and perform the low-level T=0/1 protocol automatically just returning the result of the command. Typically, this type of behavior is implemented in a reader that is hoping to achieve EMV certification.
Simple smart card readers come in a variety of shapes and sizes and also can connect to your computer in a variety of ways. Some of the more common readers include:
Keyboard—. Built into the keyboard so no extra cords exist. A PIN pad exists in the keyboard. High convenience; high cost ($30–80).
PCMCIA—. Able to fit into a PCMCIA socket. This is useful for mobile applications such as a laptop or a handheld portable. Moderate cost ($30–60).
Serial port—. Connects to a serial port. This is the most common reader, although USB is becoming more popular. Lowest cost ($10–40).
Floppy—. Fits into something that looks like a floppy disk. This has been used as a means to have a cross-platform reader. Not common; high cost ($80+).
USB—. Low-cost reader of the future. Many can be on the bus at a time, hardware is cheap, and standards exist for communication to it. Low cost ($15–50).
Contactless—. Has no contacts but uses inductance to communicate. Mostly used for physical access systems. High cost ($150+).
Each of these readers can also have a variety of capabilities with them such as an embedded LCD display so the user can be prompted to do a particular action. They may also have an embedded PIN pad so the user can authenticate to the card. There might be a biometric, such as a fingerprint panel; we'll consider this a bit more in a later section of this chapter.
The reader may have multiple slots so that two cards can be required to perform a particular transaction. PC/SC has a manufacturer-specific SCardControl function such that applications or service providers can send commands to the driver to trigger some of these extended capabilities. An abstract way to do this was not done in the first draft of PC/SC, but the 2.0 draft outlines how this might be done.
The “ultimate” smart card reader would perhaps do three-factor authentication without communicating to an external device. It would contain a smart card reader for “something you have,” a PIN pad for “something you know,” and a biometric sensor for “something you are.” It would also contain an LCD display to give feedback to the user about his or her status or position of biometric.
In emerging computer network environments, the terminal component from earlier smart card–based systems is separated into a computer component (i.e., a PC, a network computer, a workstation, or some similar designation) to which is attached a relatively simple smart card reader. This particular configuration raises some security concerns with respect to the use of smart cards. In particular, the cardholder should always understand the security risks in providing verification of identity to the card through a computer system of unknown control. Obviously, this same concern can be raised for all levels of systems; Trojan horse ATMs reportedly have been deployed to fraudulently gain account numbers and PINs from unsuspecting users. For home computer-type systems, however, the risks of the system being in a position to capture sensitive information are significantly greater.
The point then is that the cardholder should be reasonably cautious of the computer systems through which the card is used. If it's the personal computer system of the cardholder, then the risks are greatly minimized because the cardholder has control over the system's security environment. If it's a personal computer system being used in a commercial environment, then the cardholder should be concerned with the general security environment presented; for example, with the manner in which a PIN is entered.
If a personal computer configuration makes use of a simple smart card reader and the cardholder is expected to enter a PIN through the computer's keyboard, then it's a relatively simple procedure for the system manager of the personal computer configuration to be able to capture the keystrokes and hence to know the PIN for the cardholder's card. If the computer belongs to the cardholder and is under the direct control of the cardholder, then the security risks (of having the PIN captured) are greatly minimized. For public environments, it is possible to obtain more sophisticated smart card readers that have integrated keypads through which a PIN can be entered and passed on to the card, not to the computer system to which this terminal is connected.
The network through which computer systems are connected should always be treated as a completely unsecure environment. The application developer, the card issuer, and the cardholder should all view the communication channel as completely open to the world. Information that passes through these channels can be monitored, captured, and manipulated by unknown persons and/or systems.
The application is the particular system or system component that is provided through the auspices of the card issuer (or at least with the concurrence of the card issuer) and is intended to provide some type of service to be accessed by the cardholder. The application may make use of an infrastructure within the network or within the end computer system through which the cardholder gains access to it. In these cases, however, the application must be concerned with the security of this infrastructure.
In many existing smart card–enabled systems, all the players operate within an environment provided by the card issuer. In the Internet environment, it is more difficult to provide a well-controlled infrastructure for all these players. They must each understand the security limits of the components that they deal with.
We've had an overview of the actors and the infrastructure for a large scale smart card system; now let's look at some aspects of the convergent systems that were introduced in Figure 10.1. From its design inception to its widespread deployment, a smart card typically goes through a rather consistent life cycle. This life cycle may vary a bit from card manufacturer to card manufacturer and from application system to application system, but for the most part, it goes through a consistent series of phases.
A smart card typically involves two distinct development phases:
development of the smart card operating system and application software
manufacturing of the smart cards
In Figure 10.1, these two phases are illustrated in the two top rows of tasks shown. Consider first the development of software for the card. Throughout the course of this book we've examined a variety of approaches for providing software, both systems and applications on a smart card. We'll do a succinct review in the following section. Then, we will consider the manufacturing, deployment, and operation of a smart card system.
Applications that make use of smart cards typically comprise software that runs on an off-card computer (a PC or PC-class computer), on the smart card itself, and perhaps even on other computers widely distributed within a local area or wide area network. Software to run on the card itself (i.e., within the ICC embedded in the card), comes in a spectrum of flavors as illustrated in Figure 10.2.
Hard-mask software is developed in advance of the manufacture of the ICC, which is embedded in a smart card plastic body. The hard-mask software is provided to the chip manufacturer and it is created as a bit pattern in the read-only memory (ROM) of the ICC. Hard-mask software comprises the base operating system of the smart card. Historically, all of the application and operating system software of the card was built into ROM. As an evolutionary measure, however, some of the base operating system and application software came to be stored in electrically erasable and programmable read-only memory (EEPROM).
In developing hard-mask software, it is difficult to debug and test the software completely prior to its being built into ROM during the ICC manufacturing process. Because of this, in some instances, the hard mask would have errors in it following the manufacturing process—not manufacturing errors, mind you, but rather design and coding errors in the operating system software. It was found that by designing appropriately positioned “jump tables” in the ROM software (we considered this in Chapter 6), it was possible to make use of software loaded into EEPROM after the ICC manufacturing was completed.
The software loaded into EEPROM came to be known as soft-mask software (soft, because it could actually be modified after ICC manufacturing). This mechanism then allowed two distinct types of software to be added after manufacturing:
bug fixes for the base operating system
additional commands for supporting application systems
Now, if an error in the hard mask prevented its being used, there was a chance to correct the error through a soft mask. This was a great time saver over having to redo the manufacture of the ICC. With judicious design, it even became feasible to develop new commands to be loaded into (and executed from) EEPROM. This meant that a more generic smart card could be tailored for a specific application without completely redesigning the ICC software. Thus, the turnaround time for deploying a smart card application was decreased.
Finally, with the advent of the addition of a virtual machine on the card, it became possible to develop new application code in an interpreted language. Such programs could then be loaded onto the card even after the card had been issued to the cardholder.
Programs to be stored into the chip on a smart card are often referred to as masks. The term derives from the fact that the software is actually reduced to a bit pattern, which is actually masked onto the silicon components (the ROM) of the chip during the fabrication process. If the program is to be stored into ROM as part of the fabrication process of the chip itself, then this is generally referred to as a hard mask.
On a chip, software can also be stored in, and executed from, EEPROM. In this case, the software can actually be written to the chip after the card manufacturing process is completed. This type of software is often referred to as a soft mask in the smart card domain. For other domains—that is, in other areas where embedded microprocessor units are used—this would often be referred to as firmware.
As we have seen through the course of this book, the form of software on a smart card can take a variety of forms. The two cards that we examined in some detail in Chapter 6, the Cryptoflex and the Cyberflex Access cards, contain variants of most of the known forms. The Cryptoflex card makes use of a hard mask to contain the base operating system and a fixed command set to which the card responds. The hard mask was developed in a high-level programming language, probably C or C++, and the compiled and linked machine language form was masked into the ROM of the ICC embedded in the smart card plastic body. The Cryptoflex card includes several administrative commands that allow additional base operating system or additional fixed commands to be stored in EEPROM during the final phases of the card manufacturing operation (i.e., using a soft-mask approach). Prior to the cards being issued to the cardholder, the administrative commands that support soft-mask development were permanently disabled on the card.
The Cyberflex Access card also makes use of hard mask for the base operating system and the Card Manager application. This card also includes administrative commands that allow the addition of soft-mask software prior to releasing the card to the cardholder. The primary way to add software (commands) to the Cyberflex Access card is through Java Card applets, which are loaded onto the card either as part of the prepersonalization phase of manufacturing or after the card has been issued to the cardholder.
All of these various mechanisms for adding software to a card have their own sets of benefits and liabilities. Each requires a specialized software development environment as well. Included in most of these environments are various types of specialized equipment or software support infrastructures.
For (hard-mask) software loaded onto the chip during the manufacturing process, the process for writing and then checking the software (debugging) can be very long and involved. In particular, supporting a debugging environment in which checkpoints can be set with code and a dynamic debugger used to isolate errors is difficult to provide on an isolated ICC meant for a smart card. In order to mitigate this difficult situation somewhat, most chip manufacturers provide software simulators for their chips. This allows the software developer to create a full complement of software for a chip and check it out via the simulator prior to actually fabricating a set of chips with the software included.
While a chip simulator improves the software development process, it still leaves many aspects of the software unchecked. For example, it is very difficult to check the timing of various operations through a simulator. As seen in Chapter 3, many aspects of the communication between the off-card and the on-card application are critically depending on the timing of various transactions between the reader and the card. These aspects of the software's execution can usually not be tested with the simulators provided for most chips. Instead, development tools called chip emulators are available that allow the actual ICC hardware to be used, but augmented by external memory and other debugging aids.
To improve the testing environment, but without requiring the actual fabrication of chips with embedded application software, most chip manufacturers provide hardware emulators for their chips. With an emulator, a variant of memory is provided that can be accessed both by a computer being used for the software development environment and by the processor of a chip of the form to be deployed on the smart card. This emulator allows the software developer to write code and load it into this sharable memory. The code, thus loaded, can then be executed by the processor in the emulator. In this way, the code is being run in an environment much like that in the final smart card; the timing of operations is much closer to that found on the smart card itself.
The communication between the reader and the smart card occurs through a half-duplex communication channel, much like is found with a typical PC connection to a local or wide area network. In this environment, it is very useful to be able to monitor the bits traveling across the interface lines between the reader and the card. Just as in the case with a local or wide area network connection, this can be accomplished with a protocol analyzer.
The manufacturing of smart cards comprises a number of distinct steps:
Fabrication of the chip, or many chips in the form of a wafer. Several thousand ICCs are manufactured at a time in the form of silicon wafers. An individual chip for a smart card is approximately 25 square mm, or about 5 mm on a side. The template for the circuitry on a chip is repeated many thousands of times to overlay a silicon wafer approximately 4 inches in diameter. Such a wafer might routinely contain 3,000 to 4,000 chips when completed. The actual fabrication of the chips on the silicon wafer (illustrated in Figure 10.3) is done through a highly refined process of vacuum deposition of extremely pure semiconductor material on the silicon substrate.
Packaging of individual chips for insertion into a card. Once a wafer is completed, each individual chip on the wafer must be tested to make sure that it is operable. Each good chip is identified by a physical marking in preparation for sawing the wafer into many thousands of pieces (i.e., one chip in each piece). Once the chips are segmented, an electrical connector, which is larger than the chip itself, is attached. Very tiny electrical connectors (wires) link various areas on this connector with specific pins on the chip itself. The various steps involved in getting to this point were shown in Figure 10.3. The resulting configuration is referred to as a module. Figure 10.4 illustrates the components of a module, including the microelectronic connections between the connector and the chip.
Fabrication of the card. The card itself is constructed out of polyvinyl chloride (PVC) or some similar material. Both the chemical characteristics and the dimensions of the card and its associated tolerances are stringently regulated by international standards (further discussed in Chapter 3). The card material is produced in a large, flat sheet of the prescribed thickness. For many types of mass-produced cards, these sheets are then printed.
Individual cards are then punched from this flat sheet and the edges of each card are ground to a smooth finish.
Insertion of the chip into the card. Once the module and card are prepared, the two are brought together during an insertion operation. A hole is made in the card, and the module is glued into it. This hole is typically produced either through a milling operation or by melting the material and pushing the module directly into it as illustrated in Figure 10.5.
Prepersonalization. Once the module is inserted into the card, most smart card applications require that certain programs and/or data files be installed on each chip (card) before the card can be personalized and given to a specific cardholder. This general preparation of software or files on the card is done through an operation called prepersonalization, which is done through the I/O connectors on the surface of the card and, hence, can proceed only at the speed supported by that interface. Prepersonalization of the card generally entails loading information onto each individual card that pertains to a large collection of cards. Historically, this information might involve a file structure to be present on the card to hold information about the cardholder and about applications in which the cardholder could be involved. With more recent card developments, such as post-issuance programmable smart cards, the prepersonalization activity might involve loading application software directly onto the card.
Personalization. The personalization procedure involves putting information such as names and account numbers into the chip on the card. This also usually entails writing a PIN on the card that the cardholder can then use to confirm his or her identity to the card. The personalization procedure usually involves physical manipulation of the card as well (i.e., pictures, names, and address information often are printed on the card). In addition, some information, such as account numbers, may be embossed on the card to allow physical transference of that information onto other media (e.g., printing a paper receipt of a credit card transaction).
Card personalization is typically the last step in preparing the card before it is issued to the cardholder and put into the cardholder's possession. This final personalization step may involve physical preparation of the card's body and/or preparation of information stored in the ICC of the card. This final personalization step has at least two distinct purposes, both of which help define the physical requirements on the personalization operation itself.
First, the card will likely contain information through which the card can authenticate its identity to the (one or more) application system(s) in which it may operate and keys through which the cardholder can authenticate his or her identity to the card. This information must be prepared and loaded into the card in a secure fashion, which generally means in a secure environment as well as through secure procedures. Second, the card must be placed directly into the possession of the cardholder and then activated for use by the cardholder.
Printing of the card. The printing of graphics and text on a smart card is an extremely important feature. The appearance of the card generally reflects both aesthetically and financially on the issuer of the card. Branding information, such as corporate symbols and logos, builds name recognition for the issuer and has significant advertising value. When a card is used as a personal identification card, a person's picture, along with name and address information, often is printed on the card. For many cards supporting financial transactions, issuers often are concerned with the threat of counterfeiting of their cards and will sometimes make use of anti-counterfeiting mechanisms such as holograms printed on the face of the card as a safeguard, much as is found in thwarting the counterfeiting of currency (Figure 10.5).
Depending on the information to be placed on a card, a variety of printing processes can be utilized. For cards that will have exactly the same graphics on every card (e.g., telephone cards, transit tokens, and the like), the printing step is often done prior to the insertion of the ICC in the card. In this case, the cards are formed from large plastic sheets. The printing is done on the sheet, prior to cutting the individual cards from the sheet. Following the printing operation, the individual cards are stamped from the sheet and their edges are smoothed to conform to ISO specifications, which are examined in a bit more detail in Chapter 3.
Card activation—initialization of the program and program information on the chip in the card. Distinct from prepersonalization activities, these initialization activities involve actually activating the applications on the card. This is typically the last act in issuing the card to the cardholder and, in some instances, may actually be done after the card is in the hands of the cardholder. In such cases, the activation activity has more to do with backend processing systems than with the card itself.
Having looked at the actors, infrastructure, and some of the operational elements of a large-scale smart card-based system, let's now see if we can identify the aspects of the system that we need to manage through a comprehensive card management system. In addition, we'll examine some of the mechanisms that we'll use for our management activities.
In Figure 10.6, we illustrate the four major components of a general smart card system. Our goal is to make sure that each of these components is operating in a well-defined manner, which is capable of being measured and hence managed. By measured, we mean that we will consider each of these components in terms of a finite state machine and that through a comprehensive management system we will be able to monitor and hopefully control the state of each component and the state transitions that will occur as our system functions. If we can do this, then we can maximize the probability that the functioning system will achieve the business goals that we've established. In other words, we want to build our level of trust in the functioning system.
The components that will form the basis of our management activities are related to each other in a predictable fashion. We will establish this relationship in the form of a data model, which we can graphically represent in terms of an entity-relationship diagram as shown in Figure 10.7. Hopefully, the E-R diagram is self-explanatory, but let's browse through it just to be sure. We can pick any of the entities as our starting point, but let's focus first on the main topic of this book: the smart card.
The smart card is the personal token to be carried by and used by the cardholder in this system. The card has a number of well-defined states that it moves through as it progresses through the manufacturing to deployment to use phases. We'll look at the various card states and the transitions among them in the next section. A card has two main purposes as indicated by the E-R diagram: it contains some aspect of an application and it participates in the general application by virtue of this aspect and also the keys that the card contains. The E-R diagram says that the card has a “one-to-many” relationship with each of these other entities: one card can contain many keys and one card can contain many applications, or elements of applications.
Working our way around the diagram then, let's now consider the key. As the diagram indicates, a key (or keys) controls access to a card and also controls execution of (or access to the execution of) applications. There can be many keys associated with one card and there can be many keys associated with many applications.
Continuing on, let's examine the application. Many applications can be related to many keys and many applications can be related to (loaded onto) one card. The application is essentially the specific business goal of our system. It is effected by its generating a number of transactions; actually, it may create from one to many transactions. The transaction is a specific mechanism by which our business goal (our application's purpose) is achieved. An application generates a transaction if so controlled by a key(s) and the key itself is the validation of the transaction.
So, our management system is going to be a mechanism that allows us to monitor the state of these four main entities and to at least monitor, and perhaps control, the transitions between the various states of these entities. As we've illustrated in Figure 10.8, a state transition itself is a well-defined thing. So, let's now look at the state diagrams and transition tables for each of these entities.
In Chapter 6, we briefly considered the life-cycle states of a card as defined within the GlobalPlatform specifications. We're going to adopt a slightly different set of states in an attempt to consider a bit more general application architecture. The life-cycle states of a card are then defined in Figure 10.9.
A card moves through these states in a series of well-defined, atomic transitions. These are indicated in Table 10.1.
Table 10.1. State Transitions for a Card
Old State | New State | Transition Criteria |
|---|---|---|
Manufactured | Initialized | Add card and issuer data to card |
Initialized | Issued | Add cardholder to card and get into possession of cardholder |
Issued | In Use | Cardholder acknowledges possession of card |
In Use | Blocked | Excessive unsuccessful PIN entries |
Blocked | In Use | Successful entry of Unblock PIN |
Blocked | Retired | No more Unblock PIN entries possible |
In Use | Retired | Passage of expiration date |
Through the use of public key cryptography mechanisms, it is possible to address the concepts of authentication and integrity in a highly dispersed security infrastructure. In fact, many of the same techniques can be used to address authorization and privacy as well, and those points are discussed in Chapter 4.
In smart card–based systems, keys are used to establish identities. As we've seen in a number of cases, we typically need to establish the identities of computers talking to computers, people talking to computers, and people talking (communicating with) other people. The establishing of keys through which we can authenticate identities is one of the most critical, security-related tasks in preparing and issuing smart cards.
Both private key and public key cryptography can be used to establish identity. In the security commands of the two smart cards we examined in Chapter 6, we noted that we can use either cryptographic system with the same set of commands. The real difference between the systems comes from their respective difficulties in preparing and distributing the keys.
If we have a large number of smart cards in a system and a large number of terminals that provide the computer interfaces into which smart cards are inserted, we can either have a large number of unique keys establishing the various identities or we can have a few keys to essentially identify the boundary of the system (i.e., we can identify participants in the system). If we use a lot of unique keys, then we have a difficult key distribution problem in creating all those keys in the first place, associating them with various identities, and then distributing them to the platforms encompassed by those identities.
If we make use of a small number of keys and use them to establish participation in the system, then we increase the risk to the entire system if a key is compromised in any way. Given the philosophy we're to use for key management, we then have the problem of generating the keys, confirming that they're “good” keys, and distributing them to the relevant platforms. That said, let's now define the life-cycle states of the keys to be used in our system; this is done in Figure 10.10.
The state transition criteria for movement among these states is indicated in the transition table shown in Table 10.2.
Table 10.2. Key State Transitions
Old State | New State | Transition Criteria |
|---|---|---|
Generated | Installed | Key successfully generated on card or injected onto card from off-card |
Installed | In Use | Passing of key quality and installation tests |
In Use | Blocked | Excessive, unsuccessful attempts to use the key |
Blocked | Compromised | Declaration that key is no longer valid |
Blocked | In Use | Reinstatement of key by holder of master key |
In Use | Compromised | Expiration of lifetime for key |
Another variant of a key is a PIN. Authenticating the identity of a person to a computer (smart card) typically involves the use of a PIN. A PIN can either be assigned by the card management system, or it can be chosen by the cardholder so that it's a number that is easy to remember. In either case, the point at which we store the PIN on the card, and activate it as the means of doing cardholder verification, is the point at which we've actually issued the card.
If we use a mechanism of allowing the cardholder to select the PIN, then we must provide to the cardholder a secure computing platform on which to enter the selected PIN. If we allow the card management system to select the PIN, then we'll typically use a different (physical) pathway to load the PIN onto the card versus the pathway we use to tell the cardholder what the PIN is.
Private keys can refer either to the keys used in symmetric algorithms or it can refer to the private key portion of a public/private key pair in a public key cryptographic system. In either case, generating the key involves generation of a test random number string, and then performing a variety of “goodness” tests to determine whether the key has good cryptographic qualities.
Perhaps the most important aspect of generating a key is to start with a sufficiently randomized process for the initial key generation. Most instances of compromised security systems that we see in the literature arise from not using adequately randomized key generation procedures. If the generation of a particular key can be anticipated (guessed), then the entire security infrastructure is compromised.
Given an appropriately random key to start with, there are a variety of tests for either symmetric or asymmetric cryptographic systems to determine how “good” a particular key is. For asymmetric cryptographic systems, the tests are generally aimed at determining whether the seed for the key is truly a prime number (with large prime numbers being the basis for good asymmetric key pairs).
Private keys are typically stored on smart cards and are always used on the card. They are never removed from the card once stored there. When made possible by the card, it is very attractive to actually generate the key on the smart card itself. This is perhaps the most secure form of key generation. It does require, however, that key “goodness” tests be available on the smart card.
Public keys generally refer to one of the keys in an asymmetric cryptographic system. It is the key that is incorporated into a digital certificate and then widely circulated within the PKI. At smart card personalization time, a public/private key pair is generated on the card. They are put through a series of “goodness” tests. Then, the private key is stored in a key file on the card while the public key is exported off of the card and used in a request for a signed digital certificate. The certificate is stored back onto the card and is also typically stored in a network directory server.
We defined the starting point of a card to be when it is considered to be “manufactured.” For an application, we'll consider the starting point of its lifetime to be when it is “archived” following the development process. From this point on, it is ready to be loaded onto a card and put into general use. The life-cycle states for an application are shown in Figure 10.11.
The state transitions for an application are shown in Table 10.3.
Table 10.3. Application State Transitions
Old State | New State | Transition Criteria |
|---|---|---|
Archived | Loaded | Writing of code from server to EEPROM |
Loaded | Installed | Link application into card application selection mechanism |
Installed | In Use | Initial activation of program to set up application context |
In Use | Blocked | Detection of attempt of unauthorized or inappropriate use |
Blocked | In Use | Reception of valid application unblock message |
Blocked | Deleted | Erasure of EEPROM holding application |
In Use | Deleted | Removal of program from application selection mechanism on card |
The transaction is the basic building block of the functioning application; the real work of the system is done during transactions. Remember, a transaction is an atomic operation; either it all gets completed successfully or none of it is completed. The states of a transaction are illustrated in Figure 10.12.
The transition criteria for transaction state changes are listed in Table 10.4.
Table 10.4. Transaction State Transactions
Old State | New State | Transition Criteria |
|---|---|---|
Initiated | Submitted | Transaction has been formatted and sent to transaction processing center |
Submitted | Rejected | Rejection message received back from transaction processing center |
Rejected | Submitted | Corrective action taken on rejected transaction and it is resent to transaction processing center |
Submitted | Accepted | Acceptance message received back from transaction processing center |
Rejected | Abandoned | Data contained in transaction declared to be invalid and log entry is made |
Accepted | Committed | All data used to build transaction is updated to reflect transaction |
It is worth noting that many transactions that smart cards are involved with occur in terminals or back-end processing systems. In these instances, the terminals or back-end systems can archive the transaction processing and make it available to the card management system, or actually be part of the card management system. In some instances, however, the card itself can log the transactions that it takes part in. In these cases, it is interesting to consider how to feed these transaction logs (stored on many smart cards) back into a card management system.
We now have some idea of the information that we need to track within a card management system. That is, the information involved in creating and using the four major characteristics of our system. This will entail capturing, storing, and providing general access to a great deal of information. There are a number of general management system components that can be combined in a number of ways to achieve the management capabilities that we're after.
We'll view our card management system as being comprised of two major subsystems, which are tightly related to (connected to) each other. In general, we might actually consider the second to be a subsystem of the first. These are:
card management system
card issuing system
Each of these subsystems in turn is comprised of a number of elements.
We'll think of the card management system as being comprised of four general elements as indicated in Figure 10.13.
Most trust models in this emerging infrastructure are based on the concept of a certificate that ties real-world identification information for an entity together with a public key component of a public/private key pair to be used to authenticate identity in an electronic environment. A certificate is to be issued by a certification authority (CA), which is some person or entity that will attest to some degree to the connection of identity information to a public key.
One variant of this model makes use of the trust between individuals who know each other to build a chain of trust from one individual to another when the two may not actually know each other. In this model, one receives a public key and associated identity information from a person he or she knows and who will vouch for the information received. This model could be seen to work for relatively small numbers of individuals, but its applicability for handling very large numbers of individuals is still being explored.
Large-scale trust models are currently rooted in the concept of a CA or even hierarchies of CAs (i.e., organizational entities known as CAs perform the service of validating identity information, associating that information with a specific entity [person or organization], and associating all this with a public key). This attestation is provided in the form of a document (a certificate) that is digitally signed by the CA. The intent is that the CA forms a trusted third party to all two-way transactions. If two different parties can each trust the CA, then they can trust the information received from the CA (certificates) and, hence, can trust each other if each has received a certificate from the CA.
Issuing a signed digital certificate requires a two-stage operation. As we've seen, the purpose of the certificate is to tie together physical identity (of a person) with a private key, which can be used to authenticate their identity or to project their identity over a distant network. The act of ensuring that the physical information actually corresponds to the identity in question becomes a task for a registration authority (RA). Once the RA approves the issuance of a certificate, it can then be signed by a certifying authority.
A certificate is a set of information that connects a physical identity (for example, a name, an address, a telephone number, a Social Security number, a driver license number) with the logical identity represented by a public/private key pair. Here's an example:
Serial Number = 889fba340000000000010000000000
X.509 Certificate Signature Algorithm ID:
{ 1 3 14 3 2 13 } == SHA-WITH-DSA-SIGNATURE
X.509 Certificate Signature Algorithm parameters:
30 5a 02 20 c2 0a 28 7b f5 7e ce 13 c2 a3 6e 72 92 c7 13 67
d9 8f 15 73 e2 ea 19 b1 67 8f 80 f8 8a d4 c2 a3 02 14 ff 9a
ff a2 7b 05 01 2e 99 a8 49 a8 cb 7f d6 ab fd 68 2f 1d 02 20
c0 c9 2d 97 f5 28 11 f5 3b 8d 81 8c 02 59 67 2a 54 25 4b 81
ae 91 c3 70 f9 9b 90 cb de f3 2b 9e
Issuer Name: /C=USA/O=SmartCommerceCorp
Not Valid Before: 12:39:16, 08/30/2000 GMT
Not Valid After: 12:39:16, 11/28/2002 GMT
Subject Name: /C=USA/S=NY/L=Albany/O=SmartCommerceCorp/
OU=Sales/CN=Jane Doe/T=Sales Manager
Subject Public Key Algorithm: { 1 2 840 113549 1 3 1 } ==
Diffie-Hellman
Subject Public Key Algorithm parameters:
Diffie-Hellman Modulus (p): 575e67ece4e0a0b76fd457621dca50b3fd631c7d622105a3461865da39a42ffb
Diffie-Hellman Generator (g): 6b4b0d3255bfef95601890afd8070994
Subject Public Key: Diffie-Hellman public value =
3bf531a6602de246927003d0121d57d9cf089dbafcc99e65524d40adf73b12aa
There are a variety of recognized standards associated with such certificates. The information content is defined in the X.509 specification. Actual formats for conveying certificates are defined in the Public Key Cryptography Specifications (PKCSs). The specification PKCS #10 defines the format for requesting a certificate from a CA and the specification PKCS #7 defines the format for the certificate issued by the CA.
The key management component of the card management system is distinct from the CA in that it involves itself with the generation and (private/secret) archiving of keys used throughout the smart card system. The key management system must be able to create or generate keys as needed and securely distribute them to where they are needed. A significant aspect of key management is the escrowing of keys such that, with proper authorization, keys can be retrieved in order to access secret (encrypted) information.
The key management system must be involved with the initial preparation of cards as well as their ongoing use.
In a network infrastructure supporting the use of smart cards within a PKI, a general directory service is a useful backup mechanism to the card itself. That is, information from digital certificates and, in fact, the certificates themselves, can be stored on a directory server accessible by applications in a wide area network. Such directory servers are typically built along the lines of X.500 servers. These servers can be accessed from various applications through the lightweight directory access protocol or LDAP mechanism. Such directory services are often referred to as LDAP services.
As indicated previously, signed digital certificates are an effective way to build a chain of trust from a central authentication authority to widely distributed access points. The signature on the certificate is easily authenticated and subsequently provides an excellent mechanism through which a trusted environment can be extended from a trusted third party to other participants in transactions around the network.
A digital certificate typically contains a time interval during which it is valid. If a certificate is presented during the period when it is indicated to be valid, then a receiving entity should be able to trust the authentication information presented in the certificate. The certificate allows use of the authentication (and other) information from the certificate in off-line as well as online transactions. An off-line transaction is one in which there is no real-time communication link extending beyond the systems directly involved in the transaction. This is an arena of significant opportunity for smart card–based transactions.
In some cases, however, a real-time check on the authenticity of a certificate is required. In this case, a database of invalidated certificates can be maintained.
A certificate revocation list (CRL) is such a list of invalidated certificates. To be used in confirming the authenticity of certificates during a transaction, the list must be continuously available online and its address must be known and authenticated in its own right. The contents of such a CRL are essentially a digital certificate. It is issued by the card management system in response to some action that serves to invalidate the certificate.
During the course of a transaction, when a certificate is obtained from a card, if a general network connection is available, it is a straightforward operation to access a CRL to confirm that the certificate is still valid. Should the certificate be found to have been revoked, it is useful if a command can be issued to the card to lock it and prevent it from being used for further services. If possible, cards should be physically confiscated at this point; but if not, locking the card will at least prevent its being used again. Further, it is possible to report the locking operation to the card management system to indicate that a card has been deactivated and to prevent the card from being presented for reactivation.
The application management component is concerned with the applications found on cards or the applications that cards participate in. This is where transaction archiving and/or monitoring would come into play. The element of the management system would need to keep track of all the applications in the system, who can use them, who has used them, what has been done with them, and the current state of their being. Obviously there is a lot of latitude for such a component.
A typical approach through which smart card systems are programmed to react in the event of a detected attack on the smart card itself is by locking down the card and not allowing it to communicate with the outside world in other than a highly restricted way. For example, if a PIN code is used to authenticate the identity of the cardholder to the card, and if a PIN is incorrectly entered several times, a card is often programmed to go mute as a response to this perceived attack. When this happens, the only thing the card will respond to is a command sequence from the off-card application through which an UNBLOCK PIN command is issued to the card. This command contains a second order PIN which, if the card identifies it as the correct such PIN, causes the card to reset the counter, which determines the number of incorrect PIN entries that can be entered. This command can typically also redefine the PIN to some new value.
Such an operation is typically done only at some administrative center staffed by the card issuer. The cardholder is required to bring the card to the center, re-prove his or her identity is the one actually associated with the card, and then allow an administrator to reset the PIN code.
The protocol for blocking a card when a card contains a number of applications, each from potentially different application developers, might be more involved. However, most card issuers tend to enforce very strict responses to perceived attacks.
One of the very common occurrences that a card management system must accommodate is lost cards. A mechanism for replacing lost cards with a new replacement card must be supported, but the security and integrity of the system must be maintained in so doing.
Replacing an identity card can be as simple as reprinting and activating a new card based on information stored within the card management system during the card issuing process. In concert with this operation, however, is a need to invalidate the old card in order to subvert attempts to surreptitiously obtain additional (perhaps fraudulent) cards. The CRL we discussed previously is a good mechanism to achieve this end.
Using smart cards within an application system is only possible if you can handle the logistical problem of preparing the cards for the individual cardholder. In virtually all systems, a card issuing system is an integral part of overall card management. This system is the point where the cardholder meets the card and both meet the system management or administration. Let's look at the four components of this (sub)system.
In the very first chapter of this book, we discussed the “Big 4” applications in the IT world for which smart cards were particularly applicable. In these applications, it was obvious that cards would be issued to individual cardholders and the card personalization would involve both printing and electronic preparation of the card. This being the case, an important aspect of the issuing system is to capture the required personal information about each individual cardholder. Capturing the information implies that we can validate the information as well as fetch other related information from a variety of sources. The usual result of the component will be a database of information about the cardholders in the system.
If a card is personalized for each cardholder and includes a photograph or other biometric information, then the issuing system will have to be equipped to actually print the card. Properly sizing the printing services to the loading (number of cardholders to be served) is a very important aspect of overall system architecture. In particular, whether to do printing in widely dispersed locations in real-time or to do it in centralized locations in a service-bureau style of operation is part of this architectural puzzle.
In general, the printing services will require a printer capable of 4-color printing of a card, application of anti-counterfeiting mechanisms, writing of magnetic stripes, and personalization of the on-card ICC.
The application personalization component can be through of as the application management system presence at the card issuance operation. This component will deal with directly connecting the individual cardholders to each application found on the card.
Smart cards are just beginning to use authentication mechanisms that rely on biometric (from the Greek, roughly translated as life measurement) information to uniquely identify the cardholder. Several types of biometric information are currently in use, although not always with smart cards.
Fingerprint recognition—. Relies on unique fingerprint ridges.
Voice pattern—. Relies on our unique voice patterns.
DNA sampling—. Relies on our unique patterns of DNA.
Facial recognition—. Relies on facial and bone structure of individuals.
Keystroke recognition—. Relies on unique typing style of individuals.
Handwriting recognition—. Relies on unique handwriting styles of individuals.
Iris/Retinal recognition—. Takes a snapshot of the blood vessels in the retina or pattern of coloration in the cornea of the eye.
Each of these techniques ties the authentication of the cardholder to measurable characteristics of the cardholder's person. In using this type of information to establish the identity of the cardholder, a number of security criteria must be met in issuing the card:
The measurement of the biometric information must be performed on a secure (trusted) platform where it can be loaded onto the card as well as stored in a card management system.
The identity of the cardholder (name, address, etc.) must be firmly established before the biometric information is gathered.
The information must be recorded on the card without external copies being made, which might subsequently be used to impersonate the cardholder.
The oldest and most widely used biometric is fingerprint recognition. Each finger contains a characteristic known as friction ridges. While many are similar, no two friction ridges are the same. By imaging these ridges, we get a fingerprint.
Combination smart card and fingerprint readers come in several styles but, most notable are the image and capacitance types. Image style readers take a picture of the finger and then image the print based on the picture. Capacitance array readers contain millions of capacitors where ridges of a fingerprint will make a bridge between their endpoints, enabling a more accurate representation of the ridges and valleys of the print.
Most implementations of fingerprint biometrics create a template from the original image, which is a fraction of the size of the original fingerprint image. This template can be used only to compare the fingerprint against other templates. Think of it like a one-way function: A gets squashed down to B. If we want to see if C is equal to A, we must squash C down to D and compare B and D. In this manner, the template cannot be used to re-create the original print but rather a simple mathematical representation of it.
Because these templates are fairly small in size, they can easily be stored onto a smart card. This provides two benefits:
The user walks away with his or her identity, which is stored on the card.
To perform the authentication operation, there is a 1-to-1 match instead of a 1-to-many match.
There are two terms to describe the functionality of biometrics: FAR and FRR. FAR is the False Acceptance Rate or the probability that an intruder is accepted with a measurement that does not belong to the enrolled user. FRR is the False Rejection Rate, which is the probability that a valid user is not recognized. Good biometrics have a low FAR and low FRR, but sometimes it is necessary to tweak them so that user convenience is not hindered.
This chapter has offered a broad overview of the characteristics of card management systems that are necessary in deploying smart cards in large-scale systems. Such systems are available from a number of sources. Our goal has been to identify some of the characteristics that you need to be aware of in selecting such a system for use in deploying a large-scale smart card–based infrastructure.