A smart card is a tiny outpost on the frontier of an IT network. It provides a secure place to store information and a secure platform for performing a modest amount of processing. It is able to sense and record what happens out there and communicate in a secure manner back to other nodes of the network. And, on its own, it can enable or disable functionality at its point of use based on policies installed by its issuer.
The success of smart cards in the GSM network has been based on their use as authentication tokens, but their value is by no means limited to this application. Indeed, even in the GSM network, the value of a secure computing platform at the edge of the network is being recognized by a number of applications that are independent of the original authentication function of the SIM.
Like most of the other elements of an IT architecture, a smart card cannot justify its existence if it serves only one purpose or is hardwired to only one application. It must be configurable and programmable and it must be able to adapt to new situations and new requirements. If it is purpose-built and static, it will likely be left behind, doomed by the infrastructure demands we have discussed throughout the course of this book. In this final chapter, we will don our borrowed wizards' hats, gaze into our cloudy crystal balls, and seek to review the current trends and future directions in smart card standardization and smart card development.
When it comes to real-life standardization, the efforts of Dr. Klaus Vedder in the European Telecommunications Standards Institute (ETSI) Smart Card Platform (SCP) project are setting the pace. As generalizations of the core of GSM and 3G SIM standards, the SCP standards build on a field-proven and market-tested base. There are other smart card standardization efforts both under the umbrella of recognized standards development organizations such as the International Standards Organization (ISO) and within industry organizations such as the GlobalPlatform consortium and the Java Card Forum organization. The SCP effort is interesting in that while it, like the other organizations mentioned, is driven by representatives of both the smart card industry as well as the issuer and application communities, the SCP is perhaps a bit more focused on creating practical standards that can be verified through stringent interoperability testing.
Pressures driving smart card development over the last decade or so involved standardization of the infrastructure (software stack and hardware) of PC and terminal systems along with requirements for improved efficiency by letting smart cards work in more than one application area simultaneously. When it comes to future trends and directions in smart card operating systems and the smart card as an application platform, there are two relatively new driving forces at play: concurrent execution and network access. These forces are evolving smart card operating systems from simple command dispatch loops into real operating systems and they are enabling applications to cooperate with each other rather than having to be worlds unto themselves.
The notion of context switching among applications on a smart card was introduced by Java Card in support of the Shareable Interface Object (SIO). SIO is essentially a remote procedure call (RPC) from one card application to another. The calling application is blocked until the called application returns the answer. This mechanism allows for the on-card extension of multiple applications that may well have been developed and deployed in isolation. Such mechanisms do not, however, push us to the state of multiprocessing and multithreading, which we see on mainstream operating systems. Rather, it is the efficiency demand of multiapplication cards being able to interact with many transactions throughout a widespread network in a near simultaneous fashion that drives the need for multiprogramming mechanisms.
Work on operating systems for smart cards that is more comparable to the operating systems on general computing platforms is going on in a number of quarters. One of the first ones out of the gate is Fujitsu's HIPERSIM smart card operating system. Because one of the authors of this book designed HIPERSIM, this “next generation” smart card operating system will be discussed as representative of work in this area. It is probably safe to assume that others will follow.
The ETSI Smart Card Platform (SCP) project was a direct descendant of the ETSI SMG9 working group that had been so successful in specifying and standardizing the most successful smart card rollout, the GSM SIM. In fact, during its birthing process, SCP was known as “newSMG9.”
The terms of reference of the ETSI Project Smart Card Platform (EP SCP) are given in the following sections.
The main responsibilities of EP SCP are:
development and maintenance of a common integrated circuit chip (ICC) platform for all mobile telecommunication systems
development and maintenance of application-independent specifications for the ICC/Terminal Equipment interface of those telecommunication systems under the responsibility of ETSI
development and maintenance of application-independent ICC standards for general telecommunication purposes
development and maintenance of ICC standards employing advanced security methods for telecommunications applications, such as financial transactions over Mobile Telecommunication Networks (“mobile commerce”)
The main tasks of EP SCP are:
maintenance of the common platform standards developed by the committee
specification of enhancements to the common platform to allow the addition of innovative features and functions
specification of generic items for ICC for telecommunications, including, but not restricted to
interface enhancements, such as new commands and improved transmission efficiency
application management, including download and load mechanisms
electrical/physical parameters and protocol issues
advanced security mechanisms and related protocols
advanced functionality for use by applications supported by the common platform standards
specifications for the use of low-voltage technology for telecommunications cards
elaboration and maintenance of ICC-related test specifications for the common platform in collaboration with the respective groups of 3GPP and other smart card specification bodies
The committee meets at least three times a year in plenary. These meetings would normally be co-located with the meeting of at least one of the participating committees using the common platform specifications. To facilitate a truly international participation, the chairman of EP SCP is invited to exercise the chairman's rights to invite participation in the initial stage from companies involved in the standardization work for mobile communication systems in 3GPP, 3GPP2, GAIT, T1P1, TR45, and others to be identified. To facilitate its smooth functioning the committee elects in plenary a chair and two vice-chairs. To facilitate the progression of work, working parties are established and closed as (and when) necessary. EP SCP will reflect on its work and its future organizational structure (e.g., a partnership project) after the first meetings have been held.
To facilitate its work, EP SCP identifies relevant bodies and sets up liaisons to these bodies. EP SCP has direct communications with the relevant bodies of all committees involved in elaborating the common platform, in particular, with those bodies involved in the specification of security matters such as ETSI TC SEC and AHAG. In addition, EP SCP has a liaison with CEN TC224 and other regional/national bodies to be identified. Some informal liaisons are handled by delegates attending international standardization meetings and forums; for example, ISO TC68 C6, ISO/IEC JTC1/SC17, the Java Card Forum, and the WAP Forum.
The approach of SCP is to define a core set of smart card standards and to imagine that entities using those standards will adapt the core set to their particular situation by defining, if need be, deltas or modifications on the core set for the specific situation. Thus, for example, there are 3GPP and GSM deltas on top of the SCP core standards that say how the core specifications are constrained or applied to become the specifications for 3G and GSM SIMs, respectively.
The SIM standards for smart cards come as close as the smart card industry has ever come to delivering on the promise of card interoperability, arguably for four very practical reasons:
The standards are written to be implemented.
The standards include test suites.
Hardware is built that is predicated on compliance to the standards.
SIM issuers are serious about and test for interoperability.
It is worthwhile discussing each of these points briefly because standardization and interoperability are quite difficult to achieve in practice, yet are so enticing in theory. First, SIM standards were and are written to actually be implemented. They include the intersection and “consensus-ized” version of all the good ideas about smart cards. They avoid the inclusion of a lot of variants and options, and phrases like “left to the implementation.” ISO standards, on the other hand, end up being the union of everybody's ideas of how smart cards are supposed to be so that everyone can claim compliance but with no resulting interoperability. Second, SIM standards include test suite standards. Perhaps the most famous (in a very rarefied domain of fame, to be sure) smart card test suite standard is GSM 11.17, “Subscriber Identity Module (SIM) conformance test specification.” A test suite standard converts the statements of the standard (for with it is the test suite) into defined behavior. For example, Section 8.8 of GSM 11.11 defines the INCREASE command as follows:
This function adds the value given by the ME to the value of the last increased/updated record of the current cyclic EF, and stores the result into the oldest record. The record pointer is set to this record and this becomes record number 1. This function shall be used only if this EF has an INCREASE access condition assigned and this condition is fulfilled (see bytes 8 and 10 in the response parameters/data of the current EF, clause 9). The SIM shall not perform the increase if the result will exceed the maximum value of the record (represented by all bytes set to “FF”).
Input:
value to be added
Output:
value of the increased record
value that has been added
The test for this GSM 11.11 command in GSM 11.17 is described as follows:
It shall be mandatory for all cards complying with GSM 11.11 and containing EFACM and EFACMMAX to support all functions described therein.
CR1—. This function shall add the value given to the value of the last increased/updated record of the current cyclic EF and store the result into the oldest record.
CR2—. The record pointer shall be set to this record and this record becomes the first record.
CR3—. The function shall only be used if the
INCREASEaccess condition is fulfilled.CR4—. The function shall accept as an input, the value to be added.
CR5—. The function shall output the value of the increased record and the value that has been added.
CR6—. The SIM shall not perform the
INCREASEif the result would exceed the maximum value of the record (represented by all bytes set to “FF”).
Initial conditions:
The SIM is connected to an ME simulator.
Each record in EFACM contains the data “00 00 01.”
Test procedure:
The ME simulator resets the SIM.
The ME simulator sends
SELECTcommands to the SIM to select EFACM under DFGSM.The ME simulator sends an
INCREASEcommand with value “00 00 02” to the SIM.The status condition returned by the SIM shall be SW1='9816', SW2='0416' - access condition not fulfilled [CR3].
The ME simulator sends a
VERIFY CHVcommand to the SIM.The ME simulator sends an
INCREASEcommand with value “0016 0016 0316” to the SIM.The status condition returned by the SIM shall be SW1='9F16', SW2='0616' [CR4].
The ME simulator sends a
GET RESPONSEcommand to the SIM.The response data shall be '0016 0016 0416 0016 0016 0316' [CR1,5].
The ME simulator sends an
INCREASEcommand with value “0116 0216 0016” to the SIM.The ME simulator sends a
GET RESPONSEcommand to the SIM.The response data shall be '0116 0216 0416 0116 0216 0016' [CR1].
The ME simulator sends a
READ RECORDcommand usingABSOLUTEmode with record 1 to the SIM.The data read shall be '0116 0216 0416' [CR2].
The ME simulator sends an
INCREASEcommand with value “FF16 0016 0016” to the SIM.The status condition returned by the SIM shall be SW1='9816', SW2='5016' - increase cannot be performed - Max value reached [CR6].
The ME simulator sends an
INCREASEcommand with value “0016 FF16 FD16” to the SIM.The ME simulator sends a
GET RESPONSEcommand to the SIM.The response data shall be '0216 0216 0116 0016 FF16 FD16' [CR5].
GSM 11.17 goes through the entire GSM 11.11 standard this way, giving detailed “if you do this, then this should happen” instructions. Such a test suite removes all possibility for Monday morning interpretation and marketing spin on the GSM 11.11 standard. A SIM acts like what GSM 11.17 says, or it doesn't. The hardware has to speak for itself.
The third factor that has contributed to the success of GSM smart card standards is that hardware, namely GSM cell phones, is built that is premised on the standards. Nokia doesn't build one phone for Schlumberger SIMs and another phone for Gemplus SIMs. It builds phones that comply with GSM 11.11. The same holds for Ericsson and Motorola and all the other handset manufacturers. If you want to bring a SIM to market, then it must work in all these handsets, which means it must comply with GSM 11.11 down to the very last bit and byte.
The final factor that makes SIM standards work is that network operators who are the live customers for SIMs really care about interoperability. They shop for it, test for it, and get really grumpy if they find they don't have it. When pressed by a strong marketplace, smart card manufacturers will, at the end of the day, respond to customer demands for interoperability.
One of the reasons why smart cards have met more limited success outside the GSM application is that interoperability was promised but often not delivered. Without the strong market driver and knowledgeable customer base, too often interoperability was not achieved because there was no overarching concern for doing all the sometimes painful things necessary to achieve it. As value of smart cards in the GSM setting was recognized and efforts were mounted to create this value in other settings, the contribution of the GSM standards to the success of the SIM also were recognized. SCP is the first step to extend the SIM standardization process to other cards: first, to cards in telecommunication systems and, perhaps later, to cards in all settings. Certainly, the name of the effort—Smart Card Platform—invites card issuers for whatever application to consider these standards.
Table 11.1 is a list of the standards in the SCP series as of the end of 2001.
The first task of the SCP project has been to “core” the GSM and 3GPP SIM standards and to make the result a specification for smart cards in general, not just TDMA SIMs. This task is nearing completion. The next task will be to consider other smart card standards and to determine which parts of them could be included in the SCP core and which parts are truly a function of their application domain. This process has already started with the consideration of the EMV2000 specifications and the GlobalPlatform specifications.
The participation of the banking card community in SCP has been encouraged but has been, at best, lukewarm to date. Unlike the telecommunications industry, which knows it lives or dies on real interoperability, the banking card community still seems to depend on closely held control that closed, proprietary systems provide. As a result, banks and bank card associations do not generate the level of customer demand for interoperability and standards compliance that is generated by the telecommunications industry and that is necessary to achieve interoperability and standards compliance.
Table 11.1. SCP Specifications
ID | Name |
|---|---|
SCP 101.222 | ETSI Numbering System for Telecommunications Application Providers |
SCP 102.221 | UICC-Terminal Interface; Physical and Logical Characteristics |
SCP 102.222 | Administrative Commands for Telecommunications Applications |
SCP 102.223 | Card Application Toolkit (CAT) |
SCP 102.224 | Security Mechanisms for the Card Application Toolkit |
SCP 102.225 | Secured Packet Structure for UICC Applications |
SCP 102.226 | Remote APDU Structure for UICC-Based Applications |
SCP 102.230 | UICC-Terminal Interface; Physical, Electrical, and Logical Test Specification |
SCP 102.240 | UICC Application Programming Interface (API) |
SCP 102.241 | Java Card™ API for the UICC |
From a card issuer's perspective, what is compelling about the SCP effort is that the smart card platform it is describing, the UICC, is truly multiapplication. Not only can it contain data from multiple application providers, but it can contain executable code from multiple application providers. This is the first set of smart card specifications that acknowledge the reality of the smart card usage. Namely, if smart cards are to succeed in an IT setting, they have to be multipurpose and able to evolve as the system evolves.
Perhaps because there is no printing on the outside and because the card is hidden in the guts of the mobile phone where it is rarely seen, SIM issuers were the first large issuers to get over the need to see their logos and own the physical card. There are not yet SIMs issued by large corporations, and you can't go down to Radio Shack and buy a SIM and expect your local 3G operator to put its bits on it, but the architecture of the SCP platform, the UICC, differentiates cleanly between the owner of the platform and the provider of each of the applications running on the platform. Thus, for example, both the GSM SIM and the 3G USIM are thought of and standardized as applications running on the UICC. There is no technical necessity for the provider of either of these applications to be the provider of the physical card.
Moving from a single-provider to a multi-provider card poses a number of technical and business challenges. The Global Platform security framework that was described in Chapter 6 has addressed some of the technical challenges, particularly in the area of loading and deleting applications. Two challenges that are still the elephants sitting in the middle of the room are data sharing and application cooperation.
The mechanics of data sharing can be handled by the Boolean expression access control lists (ACLs) that are already in SCP 102.221. What is missing in the SCP specifications currently is a general-purpose framework for doing authentication and a unified way to store cryptographic information. There are candidates on the horizon for both of these needs—namely, IETF's Extensible Authentication Protocol (EAP) for the former and ISO 7816-15 for the latter.
Application cooperation is knottier than data sharing because it involves real-time trust. The Shareable Object Interface of Java Card is a valiant first attempt at application cooperation and the problems it encountered certainly threw light on how knotty a problem this is going to be. Perhaps the Java Card 3.0 specifications will address some of the deficiencies. In any case, from the cardholder's point of view, using multiple card applications in a single transaction is not an abstract notion. Consider, for example, listening to a tune on your cell phone. You will use one application to gain access to the network, a second to pay for the download, a third to do digital rights management on the download, and perhaps a fourth to get some frequent listener points. All of these applications are involved in what—from the cardholder's point of view—is one transaction.
Application cooperation is one of two demands being placed on smart card operating systems that are causing today's operating systems to show their age. The other is network access.
The vision of a smart card as an application platform rather than a simple security token is a paradigm shift for smart card operating systems. In the simple security token era, smart card operating systems were little more than file systems with a dispatch loop. The dispatch loop was driven by incoming commands and the microtasks were the handlers for each APDU. The model of computing was that of a single threaded remote procedure call (RPC) server.
There will undoubtedly continue to be demand for this type of smart card operating system. But it is also true that this operating system model cannot completely support the needs of the platform vision or the UICC standards. Just as there are hand calculators and computers, so will there be dispatch loop smart cards and smart cards with real operating systems.
There are a number of forces that are working to create a new type of smart card operating system:
First, a new generation of smart card processors and memory architectures is currently under development. Many of the compromises forced on today's application frameworks by the limitations of today's processors will be removed. While we will undoubtedly evolve into the future, specifying an API that is unconstrained by the past and is designed explicitly for this new generation of machine can provide a beacon to guide that evolution.
Second, today's smart card operating systems and application frameworks are intrinsically local and monoapplication. Various cosmetic design patches have been applied to make them appear to be network-aware and multiapplication, but these efforts are, as they say in Texas, tantamount to putting lipstick on a pig. The very notion of first- and second-level applications belies the monoapplication architecture of the current generation of SIM operating systems. The future of the smart card is multiapplication and network connected. These are capabilities of an operating system that can't be laid over the top of a simple, purpose-built APDU dispatch loop. They go all the way to the iron.
Third, and finally, it is becoming abundantly clear that if the suite of everyday smart card applications is going to extend beyond Windows logon and your favorite coffee shop's frequent drinker points, the creativity, innovation, and entrepreneurial drive of the third party application development community will have to be courted and harnessed. The experience and the market orientation to build the full range of applications that will be needed to deliver on the financial and consumer promises of smart cards in corporate or consumer settings may well require input beyond the players in today's market. Outdated, arcane, and overly constrained programming frameworks send the message to the third party application development community, intended or not, to take your application ideas elsewhere.
Necessarily, smart card applications come in two parts: on the smart card and off the smart card. We will call the former part the card part and the latter part the terminal part of the application. The two parts of the application are connected by a communication protocol of some sort that we will give the generic name secure messaging. Both the card part and the terminal part of the application are necessarily written against an API, which includes access to the secure messaging function so each part can communicate with the other. From 30,000 feet, a smart card application looks like Figure 11.1.
Smart card application developers are concerned as much, if not more, with the programming interface provided to the terminal side of the application as with the programming interface provided to the card side. Smart card APIs have been covered in Chapters 4 and 6.
We propose the following three simple requirements as the basis for the design of COSng:
Requirement #1: The COSng architecture must be based on modern and familiar models of computation in order to attract the widest range of application developers.
Requirement #2: COSng must enable concurrently running applications to communicate with one another and cooperate in delivering a service.
Requirement #3: COSng messaging must enable an application to establish a secure end-to-end communication link between the card side (wherever it is) and the terminal side (wherever it is). Either side of the application can initiate the communication.
One way to think about COSng is to define it in terms of existing popular APIs and to do so in a way that the card API is as close as possible to the terminal API. This strategy can be summarized in the following two COSng Design Rules:
Design Rule #1: COSng shall be a currying of existing general-purpose computing APIs and widely used data communication protocols.
Design Rule #2: The card side of the COSng shall be a subset of the terminal side of the COSng.
COSng has five subsystems. Each subsystem serves a specific purpose. The specification for each part is based on existing, general-purpose computing subsystems.
The five component subsystems are:
File System Including Data Sharing—. SCP 101.221 with Boolean ACLs
Multitasking Including Inter-Application Communication and Synchronization—. Mach, uITRON, L4, eCOS
Cryptography Including Authentication and Authorization—. PKCS #11 and ISO 7816-8 and 9
Communication Including Secure Messaging—. IPv6 over T=1
Human Interface—. SCP 102.223 Card Application Toolkit (CAT)
Almost any hierarchical file system with file and directory names of arbitrary length and alphabet will do. The open/read/write/close application program interface to file and directory operations is as close to a universal in computing as you can get.
How file systems still differ is in their approach to access control. The multiparty environment of a smart card does not map gracefully, if at all, into the owner/group/world type of access controls found on workstations and personal computers, nor does its reliance on centralized authorization servers. Fortunately, ISO 7816-9 and SCP 101.221 have defined a very flexible and general-purpose access control notation that can easily be grafted onto file systems with names larger than 2 bytes.
There are a number of good candidates here that are good because multitasking and interapplication communication are the most significant steps that smart card operating systems have to make. eCOS is an operating system provided by RedHat that is based on uITRON. Fujitsu's HIPERSIM smart card operating system, which is described in the following sections, is based on Mach.
The “Cryptoki” interface to cryptographic operations and cryptographic hardware is field-proven and widely used. In fact, many cryptographic smart cards come with Cryptoki interface libraries. The strength of Cryptoki is that it is designed to span a broad range of cryptographic protocols. In a sense, it is more of a general framework than an API to specific algorithms. On the other hand, PKCS #15 also defines how many, if not all, of the popular algorithms are represented within this framework. An alternative would be to use the algorithm identification scheme of ISO 9979 and ISO 10116 underneath the Cryptoki API.
The number of different types of communication channels that will be available to applications in general continues to grow. This impacts smart card applications particularly because of their inherently distributed nature. Techniques such as ISO 7816-4 logical channels and secure messaging that do nothing more than connect the smart card to the local terminal are of little use in building other than local applications. The GlobalPlatform specifications deliver a secure messaging concept much closer to the true requirements. However, these specifications are still too emeshed in a business model of card issuance and operations than is desirable and secure messaging is (in GP) heavily intertwined with these concepts.
If the smart card is to be network-aware, then it will have to communicate through, not to, the local terminal. In fact, from the point of view of a growing number of applications, the local terminal is an insecure device and certainly not one that can be trusted in the role of a network proxy server. The smart card must be able to participate in secure, end-to-end communication that regards everything between the two end points, including the handset, as a point of attack.
Another aspect of smart card usage, which will benefit from a more general physical interface, is the infrastructure problem associated with smart cards. Today, for a card with physical contacts, a smart card reader is required on a PC or in a terminal to make a physical connection to the card. As we saw in Chapters 6 and 7, there are moves in this direction by using the USB physical interface. This type of smart card (the two we discussed in Chapter 6) don't require a separate reader; they can use a USB port on a PC. Further, the card can make use of the USB protocol with its higher speed. Unfortunately, even this approach still requires layering on top of the ISO link-level protocol layers.
So, in the longer term, a new I/O mechanism, which would remove the need for a special smart card reader, would be extremely attractive. Perhaps the most attractive option would be a high-speed wireless connection directly from the on-card ICC to a PC or terminal. Unfortunately, this is not likely to happen until a reliable on-card power source is developed. A wireless connection with enough range to be very interesting (e.g., Bluetooth) will likely need a direct power source rather than just an RF signal.
As a general framework for communication programming, sockets have proven to be as popular and useful as Cryptoki has been for cryptographic programming. You can plug a wide range of communication protocols into the sockets framework and, thus, the API is stable as new and better channels become available to connect the two sides of the core API. Perhaps a combination of wireless and IP is the desired wave of the future?
At first blush, it seems strange to talk about a human interface API in a smart card. This function has historically been completely delegated to the terminal. But, the utility of enabling smart card applications to communicate directly with the cardholder has been proven by the GSM SIM Application Toolkit and its descendant, the SCP Card Application Toolkit. There are a couple of reasons why this is attractive:
By embedding the human interface to a card application in the card itself, the cardholder is presented with the same interface to the application regardless of what terminal devices he or she is using to activate the application.
A card can provide identifying marks on its human interface that are clues to the cardholder that he or she is really communicating with the card and that the card interface is not being “spoofed” by the terminal.
The first next generation smart card operating system on the market is Fujitsu's HIPERSIM smart card operating system. HIPERSIM is based on the Mach microkernel and was designed and built by a team of engineers led by one of the authors (SBG) of this book.
The Mach micro-kernel was chosen primarily because the message-passing metaphor of Mach was a natural fit to the need for efficient and secured communication between the applications on a smart card. Figure 11.2 shows the “wedding cake” overall architecture of HIPERSIM. The operating system is divided into three major components, or sets:
The Manufacturer's Set is a generic, multitasking operating system kernel consisting of an input/output subsystem, a file system, a cryptographic framework, and the Mach task manager. The only code in the Manufacturer's Set that knows it is a smart card is the code in the input/output subsystem that handles the T=0 and T=1 protocols of SCP 102.221.
The Developer's Set is the middle layer of the wedding cake. (Some might think of it as the frosting layer.) This is where the generic operating system of the Manufacturer's Set is turned into a smart card operating system. The Developer's Set layer knows all about the ISO standards and the SCP standards. It is a smart card through and through.
The Application's Set is the collection of applications that are running on the card. The set will be different from application domain to application domain and from card issuer to card issuer. Domain-specific applications available initially include the GSM SIM and 3G USIM applications, the WIM application of the WAP Forum, and the USAT Interpreter of 3GPP.
There generic application is called the UICC application that implements the commands of SCP 102.221 and SCP 102.222. This application can be included on any card. The efficient interapplication communication capabilities enable all the other applications on the card to use the UICC application for the standard smart card commands that the domain-specific application wants to apply to its files.
Smart card issuers of yesteryear—the financial institutions, the entertainment distributors, and the network operators—believe they have inherited the right to be the keepers of the trust infrastructure that smart cards create and the value that it generates.
Corporate IT managers and security officers, on the other hand, have realized that their guardianship of enterprise IT assets extends to the very edge of their networks and that they are obliged to take charge of the smart card–protected boundary of their domain. If the banks, media moguls, and the telecoms want to play in the corporate arena, it will be as bags of bits on corporate smart cards. For many practical and legal reasons, corporations seem unlikely to cede control of their security infrastructures to either their banks, their ad agencies, or their telecommunications providers. The corporations will own the platform when it involves corporate assets.
A consumer is a corporation of size one, and it is also starting to occur to consumers that they, too, can and should have a say in who their trust brokers will be. They may choose their bank, their phone company, or their classical radio station as the provider of their personal smart card platform. And in the interest of securing and controlling both their privacy and their identity, the consumer will pick and choose their other trust brokers and require them to put their bits on this chosen platform.
Finally, the day of the much-talked-about “white card” is not as unimaginable as it once was. In this not-so-distant smart card era, the customer goes down to Radio Shack and buys a generic smart card—the white card—and is the keeper of his or her own security and privacy. Banks, record companies, movie merchants, phone companies, and perhaps even governments will put their bits on the cardholder's smart card.