>>> 2023-09-03 plastic money (PDF)
You will sometimes hear someone say, in a loose conceptual sense, that credit cards have money in them. Of course we know that that isn't the case; our modern plastic card payment network relies on online transactions where the balance tracking and authorization decisions happen within a financial institution that actually has the money (whether it's your money or credit). There is an alternate approach though, one which has historically been associated with terms like "epurse" in the technology industry: what if the balance tracking and authorization decisions were actually made inside of the card?
Ten years ago this proposal might have seemed more absurd in the United States (amusing since, of course, the technology to facilitate this is much older). Payments in the US were made using magnetic cards with two tracks totally hundreds of bits. Debit cards could contain a challenge value used to verify the PIN, but even then the decision of whether or not to accept a PIN offline was made entirely by the payment terminal. Fraud related to these cards became a problem quickly enough that offline processing of card transactions (for example by the use of a "kerchunker" impression machine) became very rare, and all transactions were conducted online. Even then cards were vulnerable to duplication and this was a fairly common form of fraud.
Europeans, though, had been using smart card technology dating back to as early as the '80s in France. These cards had an onboard microcontroller that could make decisions and even run applications. Inside of the card there is nonvolatile storage that can retain a cryptographic key, allowing the card to participate in a cryptographic challenge-response process that made duplication very difficult. Even better, PIN verification was performed inside the card, meaning that even a malicious terminal could not accept an invalid PIN during an offline transaction.
And today, that's the most widespread application of smart card technology: cryptographic challenge-response authentication. The technique is ubiquitous both in payment systems and in access control and ID verification, spanning a wide gamut of capabilities from DESfire keycards to the United States Government's behemoth of an identity credential standard, PIV.
It's sort of interesting that these less ambitious applications of smart cards are about as far as they've gotten in the United States. Their capabilities are much greater than modern applications suggest. Smart cards were, from the very beginning, conceived as much more powerful multi-application devices that were capable of enough internal accounting logic to implement true stored value cards, or SVCs. Cards which "contained" money in a balance that could be debited and credited fully offline, just by a terminal communicating with the card.
First, bit of history of the smart card. One of the reasons that smart cards have made relatively little inroads in the US is their European origin. Nearly all of the development of smart card technology happens in European companies companies like Gemplus (Netherlands) and Axalto (France), today merged into Gemalto, part of French defense conglomerate Thales. Not to be understated either is the German company Giesecke+Devriant. Many early developments happened within the French Bull group as well, which through merger into Honeywell continues to make related products. Identity technology vendor Morpho, later Safran Morphotrust, today Idemia, forms the backbone of the TSA and Border Patrol's ubiquitous travel surveillance from their headquarters in the suburbs of Paris. They are further accused of providing identification technology to Chinese government agencies for purposes of oppression. Identity is a sticky business.
These companies have a long-running relationship with secure identity. G+D has long been a major international center of expertise in currency manufacturing and security, and the US Federal Reserve System for example relies on G+D equipment to detect counterfeits. Gemalto became one of the primary vendors in secure digital identity technology, and Thales carries this on today, providing major components of the US federal government's USAccess/HSPD-12 scheme.
It all began with payphones. Well, that's not true, there were plenty of developments in smart card technology before they were applied to payphones, but payphones introduced the technology to the French masses in 1986. France also pioneered chip-based online transactions, with a nationwide ATM network based on smart cards in 1988 and ubiquitous issuance of a precursor to EMV in 1993. We have to be careful to differentiate online and offline systems, though. One of the confusing issues around SVCs is their functional similarity to online transaction cards using an integrated chip for authentication purposes. To understand more clearly, let's take a closer look at one of the most common SVC applications in the US: the laundry card.
Laundromats are conceptually simple; each machine needs a coin acceptor (often limited to quarters only) and a coin vault. In practice, it's a little more complex. Most customers don't walk in with enough quarters any more, so the laundromat has to provide a change machine. Change machines, being stocked with hundreds of dollars in coins and bills, are an attractive target for theft. Besides, they aren't that reliable. Emptying the coin vaults on each machine daily is a time sink for staff, especially when the risk of theft requires multiple staff members as a precaution. Wouldn't it be easier if laundromat payments were electronic?
Today there are a number of ways to achieve that end, most of them worse than the old system of rolls of quarters, involving some combination of QR codes, smartphones, Bluetooth, and "The Cloud." These approaches were a nonstarter in the '00s, though. Wireless networking was in its infancy, the cost of putting network connectivity in every machine was very high. A solution was needed that allowed the billing devices in machines to be offline, operating totally independently. Any case of offline payment terminals calls for SVCs.
So in many laundromats even today, there is a device on the wall somewhere called a value transfer machine, or VTM. Actually the term VTM is a trademark of one of the major vendors of these systems, ESD, but it's such a good generic term that I will disregard their claim and use it across vendors. At the VTM, a customer either inserts their smartcard or presses a button indicating that they want to purchase one. The VTM accepts a payment by either cash or payment card, and then "transfers" that "value" to the inserted smart card---or a new one dispensed from an internal stack. Pricing details vary, but smart cards aren't as cheap as anyone would like and so it's common to charge a few dollars for a new card. Customers are encouraged to keep their card for the long term.
What happens internally? A very simple implementation suffices to explain the concept. On the smart card, there is a value in nonvolatile memory that represents the amount of money on the card. When you add money, the VTM increments that value. When you insert the smart card into a laundry machine and start a cycle, the billing device in the machine (usually a drop-in replacement for a coin acceptor with the same electrical interface) decrements that value. And there you have it: the card is just like cash, representing value on its own, with no online operations required.
Of course you can see the problems with this scheme: couldn't anyone just write a bigger number to the card? The earliest implementations tried to prevent this with simple password schemes or very elementary cryptography, and results were poor. The French payphone system of the late '80s, for example, was known to be vulnerable to duplication of cards and so naturally a black market emerged.
The history of early SVCs, mostly of the '80s and '90s, being vulnerable to at least duplication if not outright forgery gave them a poor reputation for security that persists to this day. It doesn't need to be that way, though, and excepting some obsolete systems still in use it isn't. If we can make the blockchain work we can certainly make SVCs work (admittedly this somewhat self-defeating argument presages the failure of SVCs to catch on for general purpose use). The problem with early SVC systems was the limited computational capabilities of the smart card, no match for the high complexity of strong cryptographic algorithms. Smart card technology advanced, though.
The term "smart card" is not very precisely defined but tends to refer to any card with an Integrated Circuit Chip (ICC) compliant with one of several specifications for physical and electrical interface, mostly ISO 7816 for contact operation and ISO 14443 for contactless operation. It's important to understand that while the term "smart card" is most often used to refer to contact operation, that's not a limitation of the technology. Historically some cards implemented contact and non-contact operation by having two separate chips, but that method is well obsolete. Modern smart cards, especially payment cards, are usually dual-interface cards where the same ICC is capable of communicating the same logical protocol over either the contact interface ("insert") or the noncontact interface ("tap"). Since the noncontact interface is compatible with NFC, smartphones are able to use their secure element to run an application similar to the one that runs on EMV cards.
If these cards are so smart, what do they actually do? Well, that part has varied a great deal over time. The earliest smartcards, developed in the '70s, were essentially memory and nothing else. Later on, though, smart card software evolved to multi-application cards in which a smart card operating system provides services and manages the selection of applications.
Perhaps the most famous smart card operating system is Java Card, a platform that allows smartcards to run constrained Java applets. Java Card was developed by French conglomerate Schlumberger, whose identity and card division spun out to form a major part of Gemplus (now part of Thales). Besides supporting very constrained devices, Java Card was designed for the high-security applications typical of smart cards. It provides full-featured cryptography up to ECC on modern devices, but more importantly enforces security isolation of applets and their communications and memory.
Java Card is particularly widely known because of its role in the "Java Ring," a chunky fashion accessory that presents a Java Card environment in the onewire-based "iButton" form factor. iButtons are a topic for their own post one day, being surprisingly widely used in a couple of niches where their improved durability over ICC-type smart cards is an advantage.
Java Card is also widely used, being one of the most common operating environments on practical smart cards. There is a good chance that you have more than one Java Card environment on your person at this moment. Discussing the full scope of Java Card applications requires a bit more rambling on the smart card as a physical object, though.
If you are a dweeb about identity documents, you have probably read into ISO 7810. This standard describes a set of physical form factors for identification documents. Most notable is the ID-1 form factor, which is widely used for payment cards, driver's licenses, and in general any standard-sized wallet card. Size ID-3 from the same standard is the norm for passports. But then there's an apparent oddity, size ID-000, a small 25x15mm card with a notch out of one corner. Sound familiar? ISO 7810 ID-000 is the physical description of a conventional SIM card.
SIM cards are just smart cards. Big reveal, I know! GSM was standardized by an organization out of Paris in the same time period that France Telecom adopted smart cards for payphone payment. When looking for a transportable means of authenticating the phone owner, it was an obvious choice. SIM cards no longer conform is ISO 7810 in most cases (having migrated to the smaller micro and nano formats), but continue to be compliant with ISO 7816 for electrical and protocol compatibility. It is no coincidence that SIM cards are often shipped in an ISO 7810 ID-1 compliant carrier, since these make personalizing and testing in the factory easy to do with standard smart card interfaces.
ISO 7816, the standard for smart cards specifically, describes the physical position and layout of the contacts on the ICC. It also describes an electrical interface [1] and logical protocol for communication with smart cards. Smart card communication is based on APDUs, or application protocol data units, packets exchanged between the reader and card. APDUs can indicate a standardized cross-vendor operation code, or a proprietary operation specific to some application on the card. This is a little network protocol used within the confines of the card slot, and smart card applications specify which APDU commands must be supported by cards.
The abstraction of the fairly well-defined APDU protocol creates a healthy degree of separation between smart card uses and implementations. This is all to say that the software running on smart cards often varies by vendor, even within a common application. Java Card is very common, but not universal, for both SIM cards and EMV payment cards. It competes with "native" operating systems like MULTOS. These native operating systems tend to leave more memory and processor time for applications because of the lack of a bytecode interpreter (yes, Java Cards actually run a very constrained JVM), but usually lead to application development in C which is less appealing than "weird constrained Java" to many organizations.
As you might imagine given this range of applications, security expectations for smart cards are high. In fact, the modern concept of a "secure element" largely originates with smart cards, and many secure elements in things not shaped even remotely like cards continue to use the ISO 7816 logical interface and Java Card. The SIM card is really just a portable secure element, capable of running multiple applications with nonvolatile storage, and in some countries (mostly European) they have been used for broader identification and authentication purposes. Smart cards are expected to be resistant to both electronic and physical tampering. Smart cards were historically a common form factor for cryptographic secure elements, being used to protect key material of sensitivity ranging from satellite TV scramble codes to military communications equipment---although for reasons of both durability and not having been invented overseas, the US NSA has historically preferred more homegrown form factors for cryptographic elements.
Putting this all together, you can probably see that it is indeed possible to build a reasonably secure stored value smart card system. All increment and decrement operations can be cryptographically authenticated. Unique secret keys, "burned in" to cards as part of personalization and not readable from outside of the secure element, can be used to authenticate the card and prevent duplication. While it is conceptually possible to duplicate stored value cards through laboratory analysis, the cost is unlikely to be less than the value cap imposed by the SVC service.
In the '90s, SVCs started to catch on. A marquee implementation went on display to the world in 1996: at the Summer Olympics, held in Atlanta, three banks partnered with the Olympic committee and businesses to offer an SVC payment system. It was particularly appealing to international visitors: debit and credit cards rarely worked overseas in 1996, and tourists in the US for the duration of the Olympics could hardly be expected to open US bank accounts. SVCs provided a convenient alternative to cash. Visitors could buy them in fixed denominations with cash or travelers cheque, and value could be reloaded at kiosks around the Olympics sites. The SVC nature of the system allowed the offline payment terminals to be deployed to area businesses relatively cheaply, without a requirement for a phone line like the credit card terminals of the era.
The Olympics SVCs were manufactured by the usual suspects: Gemplus, Schlumberger, and G+D. The cards ran a cryptographic application generally based on the existing French payment card system, a precursor to EMV that was focused on supporting offline use-cases. The Olympics experiment was mostly considered a success, with few technical problems. The banks involved were apparently underwhelmed at the number of cards issued, and it was speculated at the time that they were perhaps more popular with collectors than users. One can imagine that the SVC technology, entirely new to locals and visitors not from Western Europe (and, to be fair, some from Australia), faced some challenges in gaining consumer confidence.
SVCs became a standard feature of the Olympics for a few years, making their last appearance (as far as I can tell) in 2002 at Salt Lake City. This was reportedly a very limited system based on magnetic stripe cards, and so I assume that it was not an SVC system at all but just a gift card system with the heritage of the 1996 and 1998 SVCs. It is likely impossible to design magstripe SVCs that are not vulnerable to trivial duplication, I know of only one method and it is experimental (characterization of weak permanent magnetic fields acquired by the magstripe during the manufacturing process, which seem to be unique enough to differentiate individual cards).
SVCs saw other experimental applications at the same time. The University of Michigan deployed a smart card SVC in 1996 as well, allowing students to load funds and spend them on campus and at nearby businesses. This type of program became fairly popular at large universities, but beware a terminological challenge: many universities still refer to their student ID payment card program as a stored value card for historic reason, but none that I'm aware of today actually are. With universal acceptance of payment cards, it is far more cost effective to make an arrangement with a bank and processor to encode student IDs as Visa or MasterCard cards. They then function as specialty prepaid cards with whitelisted merchants and purchase types, a service readily available from the prepaid card issuance industry.
Another nascent application of SVCs in the US were welfare programs like SNAP and WIC, implemented through a system called Electronic Benefits Transfer or EBT (EBT replaced the physical "stamps" in "food stamps"). Once again, while a few states adopted SVCs and may even still call their EBT cards SVCs, every example that I know of today is processed on the Visa or MasterCard network as a prepaid card.
Why is it that SVCs gained so little traction for payments in the US? A 1999 Spectrum article rounds up the state of SVCs at the time, optimistically opening that the contents of your wallet "might be replaced by just two or three smartcards." One look at the typical wallet will show that this hasn't gone as hoped. The true promise of multi-application cards, that you could have your government ID, payment card, health information, etc. all as applications on a single physical card, is virtually nonexistent in practice. Outside of specialty systems like PIV, the multi-application capability of smart cards is mostly only used to interact with different kinds of payment networks. Perhaps the most common smart card application in the US is called "CHASE VISA" and it is basically the reference EMV application with the name changed [2]. If there's even a single other application on the card, it's probably for interaction with an EFT network.
It's fairly easy to see why this happened: different applications are issued by different organizations. The thought of your driver's license and credit card being one physical object almost certainly induces nightmares of having your credit card number stolen and then having to interact with the DMV (or, as it is pronounced in the New Mexico vernacular, the MVD). The practical logistics of multi-application cards are difficult to manage, and the cards are cheap enough that it's easier for everyone to keep different applications separate.
What of payment cards, though? Smart cards for payments are now the norm even in the backwards United States [3], but stored value systems are harder to find today than they were in 1999. Spectrum elaborates, after discussing the popularity of smart card systems (broadly defined) in Europe:
Why has it taken so much longer for smartcards to take off in the United States? In the first place, some of these cultural and political drivers are absent. The country has an excellent telecommunications infrastructure. There is no governmental or centralized mandate in any of the traditional application areas of smartcards. But the industry is evolving. The activities of Europay, MasterCard, and Visa (EMV) in developing specifications for financial-transaction cards will have a major impact on the U.S. market and the rest of the world. Nonetheless, it is felt that a smartcard will have to be able to handle several applications for the technology to gain widespread acceptance in the United States.
EMV sure did have an impact in the US, even if it took a solid decade. Multi-application cards seem dead in the water from a practical perspective; even though many more sophisticated smart card systems (like MULTOS) are designed for remote issuance and updating of applications. Anyone who has had access to their office and email at the mercy of the USAccess/HSPD-12 PIV scheme can attest that its Thales-built remote personalization system is... not exactly ready for the average consumer.
Besides, the telecommunications point is not to be underestimated. By the time SVC technology competed in America, telephone connected payment card terminals were already becoming the norm (mostly from American Verifone, although French Ingenico was a major player). Rates of telephone service and, not long after, internet service in the US were very high. These factors made offline systems much less attractive: merchants unhappy with the risk of offline processing of non-chip credit cards were just moving to online processing, not to smart cards.
The lack of a standards body to set the direction is also undeniably a factor. The introduction of EMV took as long as it did in large part because of the fragmentation of the payment card industry; different components of the market had different objectives and there was no one to push them along. To be fair, US payment card issuers cope with fraud better than most overseas observers seem to give them credit for. The inconvenience of card fraud is relatively low; I recently had credit card information stolen (how, I can only speculate) and there was no action involved on my part beyond responding to a text message alert and receiving a new card in the mail. Because of the card information update service the processors provide to qualified merchants, I haven't even had to reenter my card information on any subscriptions. A lot of effort has been put into smoothing over the fraud that occurs, even if it does seem that one of my cards is used fraudulently every two years or so.
Despite the lackluster adoption of SVCs in the US, they have a few strongholds, both here and abroad. First, although a somewhat minor detail, I cannot help but note the military overseas SVC program that my career once incidentally involved. The EagleCash system, operated by the Department of the Treasury, provides SVCs to members of the armed forces (sometimes branded NavyCash or Armed Forces EZPay due to variants of the program rules). The cards are mostly used in overseas military installations and aboard ships, situations in which offline processing can remain a big advantage. EagleCash was considered the most prominent deployment of SVCs in the US, and probably still is. EagleCash reaches nearly a billion dollars in annual turnover, mostly in the Middle East.
Much more widespread, though, are transit cards. Many transit systems globally use some sort of SVC for fare payment, under different names in different cities. Prominent US examples include Clipper (SF Bay area), Ventra (Chicago), MetroCard (New York City), and SmarTrip (national capital region). Overseas, Oyster (London), Rav-Kav (Israel), and Octopus (Hong Kong) are well-known. Many of these systems were pioneering when implemented, and some remain pioneering payments technologies today.
Many early US systems, such as Clipper, were implemented at least in part by the Cubic Corporation. If that sounds like an ominous defense contractor, it is. Cubic produces a wide range of C4ISR systems for the US military, but because of its location (in the Bay Area) and early involvement in transportation technologies, Cubic became a major US vendor in transit fare collection systems. The nearly identical fare gates of BART and the DC Metro, for example, were early models designed and built by Cubic (BART and DC Metro are twin projects in many ways). They originally used magstripe tickets, and I have read that they were controlled by PDP computers although I am unsure if this factual or just confusion with the better documented use of PDP/8E computers to drive the train arrival signs and announcements.
Cubic came back in the '00s with noncontact SVC payment systems, which are now widely deployed in major US cities and many overseas systems. Of the systems I listed above, most had Cubic as at least a member of the consortium that implemented them, if not as the prime contractor. Oyster, for example, was implemented by Cubic alongside EDS, now a division of HP perhaps best remembered for the political career of its founder Ross Perot.
How do these systems work exactly? Offline systems simplify payment networks in some ways, but also add complexity, which is often apparent in transit systems that combine offline terminals (for example in buses) and online terminals (for example at train platforms). I will walk through a description of the operation of Clipper, with which I am most familiar. The details vary from system to system depending on architectural decisions made during the original system design and modernization efforts that have been performed since, so details vary. For example, some newer systems especially abandon offline operation almost entirely and have even in-vehicle terminals perform online transactions via either public or municipal LTE networks.
A Clipper card can be purchased from a number of vendors, either first-party ticket windows in certain stations or private convenience stores that have opted to participate in the program. These stores can also add value to an existing Clipper card, from cash or a payment card transaction, by entering the value to add into a device very much like a credit card terminal (it is, running custom software as many do) and then tapping the card to it to allow the write operation to complete. Similarly, cards can be purchased or value added via vending machines at stations, which usually require the card to be tapped twice: once to read the current value and determine eligibility to add value (there is a value cap, for example), and a second time to write the added value.
Because these transactions involve writing to the card, the new value is available immediately. It can be spent on fixed terminals like station fare gates, but also on vehicle terminals as in buses. Either way the terminal reads the value from the card, determines eligibility, and writes the new (decreased) value back to the card.
Things get a little bit strange, though, when you consider one of the most common user patterns in the modern era: you can create an account online and associate the card with your account, and then you can add value online. This is convenient, but confronts the offline nature of the system. You add value to the card, but there's no way to write the new value to it.
The solution, or at least partial solution, to this problem looks something like this: fare payment terminals have to receive a streaming log of value-add operations so that they can apply them the next time they are presented with the relevant card. Online systems, like vending machines and fare gates in train stations, find out about online value-adds almost immediately. If you mostly use a train, the operation is almost completely transparent, as you add value online and it is written to your card next time you pass through a fare gate.
For the offline terminals in buses, though, things aren't so smooth. These terminals operate fully offline while the vehicle is on route. At the end of the day, as vehicles are stored in yards, the payment terminals connect to a local area wireless network (traditionally 802.11a). They upload on-vehicle transaction logs for reporting, but also download logs of online transactions. If you add value to a card with a zero (or near zero) value and then try to board a bus, it is likely that you will be rejected: the value-add hasn't been written to the card yet, and the bus terminal hasn't been told about it. The transit operator often sets an expectation of one business day for online value adds to be available if your first trip is an offline terminal.
It may be that Bay Area transit operators are transitioning to online vehicle terminals to address this problem, it wouldn't surprise me as IP connectivity in transit vehicles is becoming the norm for multiple reasons. But, of course, in an environment where all devices are online the value of SVCs as a technology is greatly reduced. At some point the SVC nature of the system becomes more vestigial than anything else, although it can provide valuable fault tolerance.
The case of transit is more complex than just incrementing and decrementing, though. Passes (including automatically "earned" passes in many systems) and transfer discounts between operators can make fare logic surprisingly complex, and that's before considering the many rail systems that charge fare per zone traveled. To accommodate this kind of fare tabulation logic, transit SVCs typically store a history of the most recent transactions and cumulative counters of different types of transactions. This allows the system to compute distance-based fare (by comparing the current and previous transaction for their location), offer transfer discounts (by comparing the last two or three transactions to a table of discounts between operators), and automatically change to passes when they become most economical (by checking registers of accumulated fare per operator per time period).
Put together these programs can make fare calculation very complex, which is one of the advantages of computerized fare collection with usage history: the software can ensure that the fare paid is optimal, in the sense of being the lowest fare the customer is eligible for. Prior to these systems features like transfer discounts often went unused because of the added complexity of presenting a ticket and payment or determining validation procedures between transit agencies.
Even transit agencies are moving away from SVCs as IP connectivity to vehicles becomes more affordable and more common. Centralized systems, while they require network infrastructure, can be more flexible and more user-friendly.
It doesn't look like SVCs have much of a future. Despite being the dream of the '90s, they have gone the way of, well, so many other dreams of the '90s technology industry. By the time the ingredients for SVCs to succeed became widely available, they were somewhat of a solution in search of a problem. Network connectivity was spreading rapidly for other reasons, online processing of payments offered other advantages, there just weren't that many reasons to go the SVC route.
Smart cards are an important part of payments infrastructure today because of the EMV standard, and they continue to have applications in both their traditional form factor and embedded variants. Despite the power available from multi-application cards, MIFARE with its simple cryptographically protected read/write operation is more common in practice. So pour one out for SVCs, or more accurate to the tradition, put $10 on a laundry card, put it in a drawer, and move to a different city.
[1] The topic of electrical interface is actually slightly confusing because the standard describes 5v, 3v, and 1.8v logic levels. Modern cards are nearly always 1.8v, but fully compliant readers need to detect and provide the correct operating voltage to the card. This complexity is one of the factors that has lead to occasional security vulnerabilities in smart cards around supply voltage.
[2] Most payment card terminals query the name of the selected application and display it. Often it is only "VISA" or "MASTERCARD" but a few issuers customize their card loads to brand the application name. Just a bit of trivia.
[3] Outside of certain more niche applications like cardlock fuel cards, which are broadly compatible with payment cards for ease of implementation but don't seem to be interested in making the move to chip-and-whatever.