Sie sind auf Seite 1von 11

Breaking Up Is Hard To Do: Modeling Security

Threats for Smart Cards


Bruce Schneier Adam Shostack
Counterpane Systems Netect, Inc.
schneier@counterpane.com adam@netect.com

Abstract 1.1 From Computers to Smart Cards


Smart-card systems di er from conventional com- The best way to understand the threats facing a
puter systems in that di erent aspects of the system smart card is to start with the threats associated
are not under a single trust boundary. The proces- with a conventional desktop computer. We believe
sor, I/O, data, programs, and network may be con- that the most important security aspect of smart
trolled by di erent, and hostile, parties. We discuss cards, as participants in protocols, is the way in
the security rami cations of these \splits" in trust, which they di er from other computational devices.
showing that they are fundamental to a proper un- By starting with a general purpose computer, and
derstanding of the security of systems that include splitting apart its various functions into those that
smart cards. make up a smart card and its operating environment,
we can examine each change and how it a ects secu-
rity. Each of these splits adds opportunities for at-
tack. For example, consider a case where the owner
of a card does not control the data stored on it.
1 Introduction This leads to attacks by the person possessing the
card against the data stored within it. This attack
simply isn't possible if there is no such split.
Smart cards, credit-card sized devices with a single Our model of a general purpose computer consists
embedded chip|CPU and RAM/ROM|are viewed of a CPU, storage, input/output devices, and power
by some as \silver bullets" of computer security. supply. The CPU is the primary processor of the
They are being proposed (and used) for access con- computer, responsible for carrying out computation.
trol, electronic commerce, authentication, privacy In a normal computer, it is tightly coupled to its
protection, etc. Unfortunately, there is little anal- storage, such as RAM, disk drives, or tape, as well
ysis of the security risks particular to smart cards, as its generalized I/O devices, such as keyboards or
and the unique threat environments that they face. mice for input, terminals or printers for output, and
In this paper, we discuss the security model of a various digital communication ports, such as serial
smart card system independently of its application. ports or ethernet cards. In this con guration, the
We look at the fundamental properties of a smart computer can be treated as a single unit for most
card|a CPU and memory device with no means of threat models.
communicating with the outside world|and show We begin by miniaturizing the computer, which adds
how these properties make systems based on smart nothing beyond a useful visualization tool. Consider
cards riskier than similar systems based on self- a computer such as the REX personal organizer.
contained computers. A clear example is a person This PC-CARD has a small screen, a PC-CARD in-
carrying a card whose computer is under someone terface to communicate with another computer, and
else's control. This is an unusual situation for a a few buttons for input. We will now transform the
typical computer, and a common one for a smart- REX, in stages, into a smart card, showing how each
card. We show that for many applications, using step of the transformation leads to new vulnerabili-
a smart card securely means understanding it not ties.
as a \trusted" computation platform, but as a data
storage device with limited computational abilities. Consider the I/O port, and replace it with a slow-
speed serial port. The system that the card con- 2 Model Trust Environment of
nects to has a limited ability to attack it, since the
card is presumably going to be attached only to its a Smart Card
owners computer, or perhaps, for a few moments,
to another to trade contact information. The card, There are many parties potentially involved in any
throughout, has the ability to send and receive in- smart-card based system. Usually, there are at least
formation through its screen and buttons. It would ve or six, including the cardholder, the terminal,
not be dicult to transform something like the REX the data owner, the card issuer, the card manufac-
into a secure electronic checkbook. (There are other turer, and the software manufacturer.
engineering challenges, but it is substantially easier
than building the same system with a smartcard.)  The cardholder is the party who has day to
day possession of the smart card. The card is
Continue by decoupling the input mechanism, such in his wallet; he decides whether and when to
that user input must go through a keyboard attached use it. In the case of a smart card used as an
to the reader. It is obvious that the keyboard could electronic wallet, he is the person to whom the
record PIN and card information for use in a later wallet was issued to. He may control the data
attack. Lastly, remove the screen, such that the card on the card, depending on the system, but it is
has no way of communicating with its user except highly unlikely that he has had control of the
through a screen of indeterminate fealty. protocols, software, or hardware choices made
The essential characteristic of a smart card is that in the creation of the card system. Note that
its functionality is split in ways unusual for a com- this is in contrast to many personal computer
puter. These splits mean that a smart card is \hand- based systems, where the owner and user usu-
icapped," by which we mean \unable to interact with ally has some say in the system he is using.
the world without outside peripherals." This is the  The data owner is the party who has control of
essential nature of smart cards: one that di erenti- the data within the card. In cases such as using
ates them from portable computers such as the Palm a card as a mechanism for carrying digital cer-
Pilot, and that de nes the trust model in which they ti cates, the card owner is also the data owner.
are forced to operate. Other splits may and do occur, However, if the card is an electronic-cash card,
but the fundamental one is that of being restricted the issuer of the cash is the data owner, and this
in their I/O. split opens the possibility of attack.
Smart card functionality is split in other ways. The  The terminal is the device that allows the
cardholder might not have any control of the soft- smart card to interactions with the world. The
ware running on the card. In the case of multifunc- terminal controls all I/O to and from the smart
tion cards, the card issuer might not have any control card: the keyboard by which any data is entered
either. The owner of the data inside the card might into the smart card, and the screen by which
not be the cardholder, and the data owner might re- any data from the smart card is displayed. If
quire that the cardholder not be able to modify, or the card is used as a phone calling card, the
even view, the data. terminal is the pay phone. If the card is used
In the following sections, we examine the rami ca- as an ATM identi cation card, the termainal is
tions of the split described above, as well as others the ATM. If the card is a pay-TV membership
commonly found in smart-card systems. Our mod- card, the terminal is the set-top box. 1
els often include ve or six parties. We examine in  The card issuer is the party who issued the
depth how the parties, when split, might attack each smart card. This party controls the operating
other. We also examine the motivations that cause 1 The previous two examples|ATM identi cation card and
attackers to engage in the variety of mischief that pay-TV membership card|illustrate times when the termi-
becomes possible when roles are split apart. And nal, as well as the smart card, may be broken into several
nally, we discuss di erent resistance models. parties. In the case of an ATM machine, the use of another
bank's ATM network and terminal is common, which means
that the bank can not rely on the terminal to be friendly. In
the case of the pay-TV system, the terminal is in the long
term possession of the user, and can be attacked in the safety
and comfort of the user's home. In cases where the terminal
ownership, programming, possession, or other functions are
split, a full analysis needs to be performed to ensure that the
security impacts of the splits are understood.
system running on the smart card, and any data Both Mondex and VisaCash are examples of
that is initially stored on the smart card. If this type of system. The card owner is the cus-
the card is a telephone payment card, the is- tomer. The terminal owner is the merchant.
suer is the phone company. If the card is an The data owner and the card issuer are both
employee ID card, the issuer is the employer. the nancial institution that supports the sys-
Sometimes the issuer just issues the card and tem.
then disappears from the system; other times
he is involved with the system throughout. In  Digital Check Card This is similar to the
some multi-function cards, the card issuer may card above, except that the card owner is the
have nothing to do with the applications run- data owner.
ning on the card, and may only control the op-  Prepaid Phone Card. These are simply a
erating system. In other multi-function cards, special-use stored value card. The card owner is
the same issuer may control all the applications the customer. The terminal owner, data owner,
running on the card. and card issuer are all the phone company.
>From the security analysis point of view, it is often  Account-based Phone Card. In this system,
simplest to view the card issuer, the manufacturer, the smart card does not store an account bal-
and the software engineers as the same party, how- ance, but simply an account number which is
ever, they rarely actually are. Hence: a pointer into a back-end database. The card
owner and data owner is the customer, while
the terminal owner and card issuer is the phone
 The card manufacturer is the party who pro- company.
duces the smart card. Note that this is a simpli-
cation; the manufacturer may or may not own  Access Token. In this application, the smart
the fab in which the cards are actually made; card stores a key which is used in a login or
they may have subcontracted design functions, authentication protocol. In the corporate case,
and they may be using third party tools in their the card holder is the employee, the data owner,
work, such as (chip design language) compilers. terminal owner, and issuer are likely the com-
However, we model all of these as the card man- pany. In the case of a multi-use access token,
ufacturer. Opportunities to subvert the manu- the card holder and data owner might be the
facture of the card come in many places, to a same person, while the terminal owner may be
wide variety of individuals. a merchant and the data owner a nancial in-
stitution.
 The software manufacturer is the party who
produces the software that resides on the smart  Web Browsing Card. In this application, a
card. This is again a simpli cation of a proba- customer can use his card in his own PC to buy
bly complex array of makers of compilers, util- things on the WWW. This is another exam-
ities, etc. Issues of trusting trust [Tho84] arise ple of a cash card. The di erence is that the
here in the same ways they do with the card card holder and terminal owner are both the
manufacturer. customer (i.e., the owner of the PC). The data
owner and card issuer are both the nancial in-
stitution.
3 Examples of Trust Splits in  Digital Credential Device. In this applica-
Smart-Card Systems tion, the smart card stores digital certi cates
or other credentials for presentation to another
Following are representative smart-card based sys- party. Here, the card holder and the data owner
tems, described in terms of what parties control dif- are both the same. The terminal owner is either
ferent aspects of the system. This list is not meant to the other party (in an in-store application, for
be exhaustive, and there are both other examples of example) or the card holder (browsing on the
splits described here and other splits not described WWW). The card issuer is the CA that issued
here. the credentials, or some other party that col-
lects the credentials.
 Digital Stored Value Card. These are pay-  Key Storage Card. In this application, the
ment cards intended to be substitutes for cash. user stores various (possibly veri ed) public
keys in a smart card to protect them having 5 Classes of Attack
to be stored on his less secure PC. Here, the
card holder, the data owner, and the terminal
owner are the same. Due to the large number of parties involved in any
smart-card based system, there are many classes of
attacks to consider. Our goal here it to categorize
 Multi-Function Card. This card is the most them by function split. That is, we will look at at-
complicated. The card manufacturer and card tacks by system participants against one another.
issuer are separate, as are the software manufac- Most of these attacks are not possible in conven-
turers. The data owner may be the cardholder tional computer systems, since they would take place
for some applications, and a separate entity for within a traditional computer's security boundary.
others. There are multiple terminal owners, de- However, they are possible in the smart card world.
pending on which applications are on the card.

4 Smart Card Threat Models


5.1 Attacks by the Terminal Against
An attack is simply de ned as an attempt by one or the Cardholder or Data Owner
more parties involved in a smart-card transaction to
cheat. We consider two classes of attackers, those
who are parties to the system, and those who are These are the easiest attacks to understand. When a
interlopers. Attacks by participants could be a card- cardholder puts his card into a terminal, he is trust-
holder trying to cheat a terminal owner, a card issuer ing the terminal to relay any input and output from
trying to cheat a cardholder, etc. Outsider attacks the card accurately. For example, if a user puts a
could be mounted by someone who steals a card: a stored value card into a vending machine and makes
temporary cardholder who steals a card from a le- a $1 purchase, he is relying on the terminal to send a
gitimate cardholder, or replaces terminal software or \deduct $1" message to the card, and not a \deduct
hardware. Attacks by outsiders are often similar to $10." Similarly, when the card sends a message to
attacks on protocols involving general purpose com- the cardholder that says \balance = $1," the card-
puters, however, they may take advantage of various holder is relying on the terminal's screen to relay
properties of the system created by the separation that message accurately. The ability for a rogue
of roles. terminal to do damage in this environment is sig-
Motives for attack to fall into a few broad categories ni cant, and it is impossible for the cardholder to
[Sch97]. First and most obvious are nancial thefts, detect this kind of fraud in the context of a single
including theft of money or credit, or theft of ser- terminal. This kind of fraud has been attempted
vices sold to the general public, such as telephone using fake ATM machines [Joh93].
cards. There are also impersonation attacks, where Prevention mechanisms in most smart card systems
the card system is an intermediate target, with the center around the fact that the terminal only has
system being attacked to gain access to some com- access to a card for a short period of time. Soft-
puter system, or other access control device. These ware on the card could limit the amount of damage a
di er from theft of service in that the user could rogue terminal could do. A stored-value card could,
not purchase the service legitimately. For example, for example, only allow the terminal to deduct $1
the use of an access card to get into a computer maximum per transaction, and to perform no more
system; computer access is generally available, but than one transaction every minute [KS99b]. How-
access to the particular system is the goal of the ever, there are prevention mechanisms which involve
attacker. There are attacks on privacy, where one having the user own the smart card terminal, such
party wants more information than is given by the as one attached to a personal computer. The real
protocol. Lastly, there are publicity attacks, where prevention mechanisms, though, have nothing to do
the attacker is motivated not by any direct nancial with the smart-card/terminal exchange; they are the
gain through attacking the system, but a desire for back-end processing systems that monitor the cards
notoriety. and terminals, and ag suspicious behavior.
5.2 Attacks by the Cardholder [AK96], fault analysis [BS97, BDL97], and side-
Against the Terminal channel attacks such as power and timing analysis
[Koc96, Koc98b, KSWH98b, DLK+99]. These at-
More subtle are attacks by the cardholder against tacks have been particularly e ective against pay-
the terminal. These involve fake or modi ed cards TV access cards [McC96, Row97], and have been
running rogue software, with the intent of subverting used against digital cellular telephone access cards
the protocol between the card and the terminal. For [BGW98]. They are starting to be used against
some examples, see [McC96]. stored-value cards for electronic commerce [Row97].
Good protocol design mitigates the risk of these Countermeasures include not putting valuable data
kinds of attacks, which can be made more dicult by onto cards, and not putting global secrets onto cards.
hard-to-forge physical aspects of the card (e.g., the In general, a system design where the compromise of
hologram on Visa and MasterCard cards), which can a card puts that card only at risk is much better than
be checked by the terminal owner manually. Note a design where the compromise of a single card risks
that digital signatures on the software are not ef- compromise of the entire system [KS99a].
fective here since a rogue card can always lie about
its signature, and there is no way for the terminal
to peer inside the card. Defending against this kind
of attack requires another function split: the card-
holder must not be able to manipulate the data in-
side the card.
5.4 Attacks by the Cardholder
5.3 Attacks by the Cardholder Against the Issuer
Against the Data Owner
There are many nancial attacks that appear to be
In many smart-card-based commerce systems, data targeting the issuer, but this may be illusory. In
stored on that card must be protected from the card- fact, the attacks are targeting the integrity and au-
holder. In some cases, the cardholder is not allowed thenticity of data or programs stored on the card.
to know that data. A building access card, for ex- These attacks are made possible by the issuer's de-
ample, could have a secret value inside the card; cision to use a smart-card system where the card-
knowledge of this value could allow the cardholder holder holds data for the issuer or other party. Using
to make additional access cards. Or knowledge of a the pay telephone application as an example, if the
secret key in an electronic commerce card could al- phone were to use an account based system, where
low the cardholder to make fraudulent transactions. a simple card holds a very long account number,
In other cases, the cardholder is allowed to know the which is used by the phone company to dereference
value, but not allowed to change it. If the card is a an account stored on a back-end system, then there
stored-value card, and the user can change the value, are account guessing and theft attacks based on the
he can e ectively mint money. numbers. This sort of system can be enhanced by
There are two essential characteristics of these at- adding a challenge/response or inverted hash chain
tacks. One, the card must act as a secure perimeter, mechanism for sending replay resistant passwords.
preventing the cardholder from accessing the data This makes strong use of a simple smart card in con-
inside the card. In this context, the card may need junction with a back oce managed authorization
to be fairly con dent that it will detect and respond scheme to resist fraud. If the card issuer chooses
to attacks with a minimum of control over its envi- to put bits that authorize use of the system in the
ronment. And two, the attacker has access to the card, they should not be surprised when those bits
card on his own terms. He is allowed to take the are attacked. These bits could be \authenticated"
card into his laboratory and perform whatever ex- account numbers, or it could be a system with a key
periments he wants to. He is allowed to take cards buried within the card, on the assumption that this
and destroy them in order to learn how they work. key can not be extracted, and proper completion of
the protocol indicates that the card has not been
There have been many successful attacks against tampered with. These systems all rest on the ques-
the data inside a card. These attacks include tionable assumption that the security perimeter of a
reverse-engineering and defeating tamper-resistance smart card is sucient for their purposes.
5.5 Attacks by the 5.7 Attacks by the Issuer Against
Cardholder Against the Software The Cardholder
Manufacturer
In general, most systems presuppose that the card
issuer holds the best interests of the cardholder at
Generally, in systems where the card is issued to an heart. This is not necessarily the case, and a mali-
assumed hostile user, the assumption exists that the cious issuer can launch several attacks against card-
card will not have new software loaded onto it. This holders.
is enforced by the use of pre-issuance stages with
various one-way transformations being employed by These attacks are typically privacy invasions of one
the card manufacturer to ensure that the software kind or another. Smart-card systems that serve as a
is not tampered with. The underlying assumption substitute for cash must be designed very carefully
may be that the split between card owner and soft- to maintain the anonymity and unlinkability that are
ware owner is unassailable, and relies on the separa- a property of cash money. Attacks or design failures
tion being strong. However, attackers have shown a can substantially reduce the privacy of the system.
remarkable ability to get the appropriate hardware Alternately, a system may be sold as having more
sent to them, often gratis, to aid in launching an privacy than it in fact o ers, allowing the issuer to
attack. gather data surreptitiously about the cardholders.
Features introduced into the card as the system ma-
tures may alter initial characteristics of the system
with substantial impact on the privacy of the sys-
tem. This can count as an attack by the issuer be-
cause the cardholder is rarely asked or able to discern
5.6 Attacks by the Terminal Owner the security impact of a change to the system made
Against the Issuer by the issuer. These changes are often not optional
from the customers viewpoint; accept the upgrade
or leave the system. Lastly, this type of attack may
In a system closed to outsiders, such some prepaid be carried out by the issuer, or by the hardware or
telephone cards, the terminal owner is also the card software designer, in collaboration with terminals,
issuer (the phone company has both roles). In some without the knowledge or consent of the issuer.
more open systems, like Mondex, the terminal owner
is the merchant and the card issuer is Mondex. The
latter split introduces several new attacks. 5.8 Attacks by the Manufacturer
The terminal controls all communication between Against the Data Owner
the card and the card issuer (generally the back-end
of the system). In this system, the terminal can al- Certain designs by manufacturers may have substan-
ways falsify records that have nothing to do with the tial and detrimental e ects on the data owners in a
smart card, refuse to record transactions, etc. The system. The design of secure multi-user computers
terminal can also fail to complete one or more steps is a challenging one, and the security model to use to
of a transaction to facilitate fraud or create customer establish a secure kernel that o ers processes protec-
service diculties for the issuer. By failing to com- tion from each other is not a solved problem. By pro-
plete the action of debiting a card, a terminal can viding an operating system that allows or even en-
cheat the issuer, or by completing a transaction and courages multiple users to run programs on the same
not o ering service (i.e., a pay phone) can create a card, a number of new security issues are opened up.
service nightmare. The rst, and most obvious, is subversion of the
These attacks are not related to the smart-card na- operating system and subsequently other programs.
ture of the system, and are simply attacks against This is an area where mainstream operating system
the relationship between the terminal owner and the manufacturers have failed to provide adequate pro-
card issuer. Some systems try to mitigate this threat tection for the last thirty years. The vendors who
by having the card and back-end computer make a have announced smart card operating systems re-
secure connection through the terminal. Many sys- cently do not have enviable records. However, even
tems use monitoring on the back end to reduce the if the smart-card operating system can be made se-
e ectiveness of these attacks. cure, issues of user interface security remain and are
exacerbated by the smart-card's handicapping. How card. When a terminal is subverted, its desire to
is the user (or the designer) to know what program participate in a fair manner is replaced by a desire
is running when the card is inserted into a terminal? to subvert the protocol (why else subvert the termi-
How to ensure that your program is talking to the nal?). Thus, when a system assumes that the data
terminal, not through another program? How can a stored on a card is secure because the interests of the
program that believes itself compromised terminate cardholder and issuer are aligned, a vulnerability is
safely, and signal outward the cause for its demise? opened by the theft of the card.
Or should it even try; what interesting attacks might Alternately, we examine a system with a smart-card
become possible if a card announces its own immi- reader attached to a PC, where that PC is acting
nent suicide? Can the card ensure that once such a as part of the terminal. The terminal is presumed
message is sent the action of destroying its memory to be friendly to its owner; perhaps it is being used
is completed, in the presence of a possibly hostile to carry web certi cates from home to work. Un-
power supply? fortunately, the terminal can be transformed by the
Less obvious would be intentionally poor random introduction of an ActiveX Control that changes the
number generators [KSWH98a], or other aspects reader software. This attack, by changing the ex-
of cryptographic implementation which are dicult pected behavior of a component, can re-cast the se-
and arcane areas to test [Sch97, Sch98a, Koc98a, curity of the protocol. The behavioral change here
Sch98b]. The manufacturer is in an admirable po- can be active, in the case of changing a request and
sition to engage in kleptographic attacks [YY96, its associated display, or passive, in the case of mon-
YY97a, YY97b]. Of the major smart card vendors, itoring attacks. Monitoring attacks can attack the
none has an admirable record of creating operating privacy of the transactions made by the card or the
systems that were free of exploitable vulnerabilities. secrecy of PIN or other data. The latter is probably
In addition, by providing implementations of various a precursor to an active attack, not necessarily in the
supporting protocols, the vendor may be able to leak domain of the smart-card protocol. That is, recall
an application's keys using any of several subliminal that PINs are often used in more than one system,
channels [Sim84, Sim85, Sim86, Sim94]. and that the active attack does not need to attack
And nally, it is possible for one application on a the smart-card system.
smart card to subvert another application running
on the same smart card. It has been shown how to
take a secure protocol and to create another proto- 6.1 Attacks by Third Parties Using
col, also secure, such that the second protocol breaks Stolen Cards
the rst protocol if both are running on the same de-
vice using the same keys [KSW96]. There are two di erences between this attack and
an attack by the cardholder. One, the thief does
not have access to any secret information required
6 Transformative, or Imper- to activate the card. And two, the thief has only
a limited amount of time to carry out his attack
sonation, Attacks before the cardholder will notice that his card has
been stolen.
There is a class of attacks based on separating or Hence, all the attacks by the cardholder are pos-
changing the roles played by various parties; for ex- sible with the following addition: the thief is not
ample, changing the card holder by stealing the card concerned with any long-term repercussions against
may allow access to data that the card holder has the legitimate cardholder. For example, a low-value
stored, or ActiveX may allow an attacker to become stored-value card might deal with the potential of
(in essence) the terminal owner, engaging in the set cardholder fraud by simply keeping records of card-
of attacks available to terminal owners. holder transactions, and billing (or prosecuting) any
The essential character of a transformative attack discrepancies. A thief who steals a card would not
is that a party is transformed, leading to an un- be deterred by this defensive measure.
expected set of motivations for that party. When It is possible to build defenses into the system either
a card is stolen, the (de facto) cardholder has lost at the card or at the issuer's level. At the card level,
all interest in maintaining the security of the ac- there are perimeter and anomaly defenses available.
count, and possibly in the physical integrity of the The perimeter defense is that the card can consider
several bad PIN attempts to be indicative of attack. these methods in detail; we believe they are less ef-
(Note that this opens the card to a denial of ser- fective and more prone to implementation and de-
vice driven by a malicious terminal.) The anomaly sign failure than the second, which is to make en-
detection defense would be for the card to store his- tire classes of attack ine ective. This can be done
tory information and detect a pattern change in its most e ectively by reducing the number of parties,
use. This is an aggressive requirement, but in those or increasing the transparency of a party's role to
cases where a card can be used oine, it may make the point where carrying out an attack is dicult.
sense to raise a ag of some type, possibly requiring The easiest way to reduce the number of parties
contact with its issuer before additional use to allow is to combine roles so that there are fewer hats to
the back end system a chance to make a more elab- wear. If, for example, the cardholder is also the data
orate or sophisticated decision, or perhaps simply to owner, all attacks by by the cardholder against the
defend the system against card duplication. data owner are simply irrelevant. Or, if the terminal
owner is also the issuer, then attacks by the terminal
owner on the issuer are only possible in the transfor-
6.2 Eve and Mallet mative case, where an attacker takes control of the
terminal.
If we assume that the use of a smart card is to allow Another, orthogonal, security measure is strong au-
protocol interactions between mutually distrusting dit. Systems should not only be designed to pre-
parties, or at least parties whose interests diverge, vent atacks, but also to detect attacks when they
then the protocols must resist (set of attacks). Thus, occur and collect evidence that can be used to
most attacks based on eavesdropping or malicious prosecute the attackers using existing legal sys-
protocol manipulation can be modeled as the case tems. Further research into this area is required
of one party attacking another. Assuming that the [KS96, SK97a, SK97b, SK98, SK99].
protocol is well designed, it will resist these attacks
equally well if the attacker is internal or external.
7.1 Fewer Splits
6.3 Collaborative Attacks Each time a system has the design role of two or
more parties merged into one, the avenues of attack
Systems that rely on the split between various com- that are available to one of those parties against the
ponents being maintained as a hostile boundary other disappears. For example, if the cardholder and
without co-operation may nd themselves surprised terminal are merged by adding screen and data en-
when roles they had thought split are brought to- try to the card, then the keysning and untrusted
gether. The smart card and set top box, supposedly display problems simply disappear.
representing di erent interests, may collaborate in Contrariwise, adding parties to the system opens
obtaining unauthorized service for the owner of the new venues of attack which need to be considered.
television. Similarly, the terminal's owner may be The separation of the terminal and card from each
surprised to discover that both the card and the ter- other creates a venue which could scarcely have
minal, made and programmed by the same shop, been designed better to enable man-in-the-middle
have certain undocumented features. The number attacks. The combination of physical encasement of
of possible collaborations and interesting models for the card, and terminal's control of the user interface
attack grows with the number of parties to the sys- and network allow most any such attack documented
tem. Those who forget that most attacks are perpe- to be carried out if the protocol is not designed to
trated by insiders will likely be reminded (assuming handle it. Experience has shown that even many
their fraud detection models are good enough.) security products are released without consideration
given to meet-in-the-middle, replay, and re ection
style attacks [Sho96, Sho97]. Even if these attacks
7 Resistance Models are considered, the addition of parties to a transac-
tion makes managing keys, nonces, sequence num-
There are, broadly, two ways to resist attacks against bers, and other defenses substantially more dicult.
smart card systems. The rst is to make speci c Considering the smart card's inability to communi-
attacks harder: use strong cryptographic protocols, cate with the outside world, the simplest reduction
increase tamper-resistance, etc. We don't discuss is to ensure that the cardholder and data owner are
one. This is also usually one of the least expensive. the eld [And94, Sch97, Sch98a, Koc98a, Sch98b].
The other extremely e ective change to be made, The addition of parties to a design is a remarkably
adding screen and input devices to the card, also in- simple class of implementation failure to discover,
volves a substantial increase in the cost of the card. making this a useful class of defense.
Another facet to the transparency defense is to avoid
7.2 More Transparency the complexities and risk of multi-application smart
cards. Not using a multi-application smart card
It is widely understood by the security community both reduces the number of parties involved and
that the best way to ensure the security of a system creates a simpler operating environment with less
is to allow widespread public examination of it. It complexity and potential for bugs. The reduction
has been shown repeatedly that interested attackers in the number of parties using the card (from N to
will obtain speci cations or attack the system with- 2) means that the issues of OS subversion and cross
out them [Sho96, Bla94], and that open publication application attacks are practically eliminated.
leads to review and analysis [Sch99]. (Examples are
IPSec, PGP, and S/MIME.) Combining the mech-
anisms of simplicity and openness greatly simpli es 8 Conclusions
the task of reviewers who choose to examine a sys-
tem. Thus, reducing the number of parties not only We have shown that the splitting of the security
eliminates entire classes of attacks as shown above, perimeter is a dicult task. In particular, having
but it also makes the task of analyzing the system a user carry a computer on behalf of a data owner
simpler. The simplicity of the security analysis will he may wish to attack is a very risky situation for
likely cause the analysis to occur sooner, as well as the data owner. We have also shown that the card's
giving it a higher likelihood of success. handicap of being unable to communicate makes it
The transparency defense involves cleanly separat- highly vulnerable to attacks by the terminal. These
ing roles so that attacks are more dicult to execute. vulnerabilities are part of smart-card systems by de-
For example, the Mondex system includes a variety sign, and require substantial e ort to combat.
of terminal types (some portable) that allow a user We have outlined a pair of fundamental defenses for
to check certain parameters independently of a mer- cards, that operate at the system design level, o er-
chant terminal. This allows a class of attacks on ing system designers a new model in which to eval-
the cardholder or be discovered much more quickly. uate their systems. This model encourages pushing
Access to the full set of Mondex stored parameters security into the earliest phases of system design.
(i.e., the data owner's data) would presumably make We o er as a prime candidate for improvement plac-
the system that much more secure by increasing the ing some user interface under the control of the user.
audit-ability of the system. Similarly, an attack by System designs that re-combine the roles into more
the software manufacturer is made more dicult capable systems will likely nd their investment re-
by the presence of strong and clear speci cations, sults in fewer points of weakness.
and/or open source implementations.

7.3 Design for Security References


This defensive model of design is focused on design- [And94] R. Anderson, \Why Cryptosystems
ing systems to be secure from the architecture down Fail," Communications of the ACM,
[SSS+98, Sch98c]. Adding security to a system af- v. 37, n. 11, Nov 1994, pp. 32{40.
ter the design phase has been shown to be dicult, [AK96] R. Anderson and M. Kuhn, \Tamper
expensive, and failure prone. Therefore, we prefer a Resistance { A Caution-
model where careful design from the start eliminates ary Note," Second USENIX Workshop
the need for many costly and complex attempts to on Electronic Commerce Proceedings,
bolt security on at a later phase. The reductionist USENIX Press, 1996, pp. 1{11.
model not only simpli es the process of design and
implementation, but is fairly dicult to implement [BDL97] D. Boneh, R.A. Demillo, R.J. Lip-
incorrectly. We have seen that implementation fail- ton, \On the Importance of Checking
ures are a primary cause of cryptosystem failure in Cryptographic Protocols for Faults,"
Advances in [KS99a] J. Kelsey and B. Schneier, \Secure
Cryptology|EUROCRYPT '97 Pro- Authentication with Multiple Paral-
ceedings, Springer-Verlag, 1997, pp. lel Keys," ESORICS '98 Proceedings,
37{51. Springer-Verlag, 1999, to appear.
[BGW98] M. Briceno, I. Goldberg, D. Wagner, [KS99b] J. Kelsey and B. Schneier, \Au-
\Attacks on GSM security," work in thenticating Secure Tokens Using
progress. Slow Memory Access," 1st USENIX
Workshop on Smartcard Technology,
[BS97] E. Biham and A. Shamir, \Di erential USENIX Press, this volume.
Fault Analysis of Secret Key Cryp-
tosystems," Advances in Cryptology| [KSW96] J. Kelsey, B. Schneier, and D. Wagner,
CRYPTO '97 Proceedings, Springer- \Protocol Interactions and the Cho-
Verlag, 1997, pp. 513{525. sen Protocol Attack," Security Pro-
tocols, International Workshop April
[Bla94] M. Blaze, \Protocol Failure in the Es- 1997 Proceedings, Springer-Verlag,
crowed Encryption Standard," Pro- 1998, pp. 91-104.
ceedings of Second ACM Conference
on Computer and Communications [KSWH98a] J. Kelsey, B. Schneier, D. Wagner,
Security, ACM Press, 1994. and C. Hall, \Cryptanalytic Attacks
on Pseudorandom Number Genera-
[DLK+99] J.-F. Dhem, F. Koeune, P.-A. Leroux, tors," Fast Software Encryption, 5th
P. Mestre, J.-J. Quisquater, and J.- International Workshop Proceedings,
L. Willerns, \A Practical Implementa- Springer-Verlag, 1998, pp. 168{188.
tion of the Timing Attack," CARDIS
'98 Proceedings, Spriger-Verlag, 1999, [KSWH98b] J. Kelsey, B. Schneier, D. Wagner, and
to appear. C. Hall, \Side Channel Cryptanalysis
of Product Ciphers," ESORICS '98
[Joh93] K. Johnson, \One Less Thing to Proceedings, Springer-Verlag, 1998,
Believe in: High-Tech Fraud at an pp. pp 97{110.
ATM," The New York Times, 13 May
93, pp. 1,B9. [McC96] J. McCormac, European Scrambling
Systems, Waterford University Press,
[Koc96] P. Kocher, \Timing Attacks on Imple- 1996.
mentations of Die-Hellman, RSA,
DSS, and Other Systems," Advances [Row97] T. Rowley, \How to Break a Smart
in Cryptology|CRYPTO '96 Pro- Card," The 1997 RSA Data Security
ceedings, Springer-Verlag, 1996, pp. Conference Proceedings, RSA Data
104{113. Security, Inc., 1997.
[Koc98a] P. Kocher, \Hidden Flaws: Avoiding [Sch97] B. Schneier, \Why Cryptography is
Unexpected Weaknesses," The 1998 Harder than it Looks," Information
RSA Data Security Conference Pro- Security Bulletin, v. 2, n. 2, March
ceedings, RSA Data Security, Inc., 1997, pp. 31{36.
1998.
[Sch98a] B. Schneier, \Security Pitfalls in
[Koc98b] P. Kocher, \Di erential Power Anal- Cryptog-
ysis," available online from raphy," CardTech/ SecureTech Con-
http://www.cryptography.com/dpa/. ference Proceedings, Volume 1: Tech-
nology, CardTech/SecureTech, Inc.,
[KS96] J. Kelsey and B. Schneier, \Authenti- 1998, pp. 621{626.
cating Outputs of Computer Software
Using a Cryptographic Coprocessor," [Sch98b] B. Schneier, \Cryptographic Design
Proceedings 1996 CARDIS, Sep 1996, Vulnerabilities," IEEE Computer, v.
pp. 11-24. 31, n. 9, September 1998, pp. 29{33.
[Sch98c] B. Schneier, \Method and Apparatus [Tho84] Ken Thompson, \Re ections on
for Analyzing Information Systems Trusting Trust," Communications of
Using Stored Tree Database Struc- the ACM Vol. 27, No 8, August 1984,
tures," U.S. Patent 5,850,516, 15 Dec pp. 761-763.
1998.
[Sim84] G.J. Simmons, \The Prisoner's Prob-
[Sch99] B. Schneier, \Cryptography: The lem and the Sublimian Channel, Ad-
Importance of Not Being Di erent," vances in Cryptology: Proceedings of
IEEE Computer, 1999, to appear. CRYPTO '83, Plenum Press, 1984,
[Sho96] A. Shostack, \Observed pp. 364{378.
Weaknesses in the Security Dynam- [Sim85] G.J. Simmons, \The Sublim-
ics Client/Server Protocol," Network inal Channel and Digital Signatures,"
Threats Workshop, Dec 2-4, 1996, R. Advanced in Cryptology: Proceedings
Wright and P. Neumann, eds., DI- of EUROCRYPT 84, Springer-Verlag,
MACS Series in Discrete Mathematics 1985, pp. 364{378.
and Theoretical Computer Science, v.
38, American Mathematical Society, [Sim86] G.J. Simmons, \A Secure Sublinimal
1996. Channel (?)" Advanced in Cryptology:
Proceedings of CRYPTO 85, Springer-
[Sho97] A. Shostack \Low Hanging Fruit: A Verlag, 1986, pp. 33{41.
Replay Attack on the TIS FWTK,"
presentation at the CRYPTO '97 [Sim94] G.J. Simmons, \Subliminal Channels:
rump session. Past and Present," European Trans-
[SK97a] B. Schneier and J. Kelsey, \Auto- actions on Telecommunications, v. 4,
matic Event-Stream Notorization Us- n. 4, 1994, pp. 459{473.
ing Digital Signatures," Security Pro- [YY96] A. Young and M. Yung, \The Dark
tocols, International Workshop, Cam- Side of Black Box Cryptography," Ad-
bridge, United Kingdom, April 1996 vances in Cryptology | CRYPTO '96
Proceedings, Springer-Verlag, 1997, Proceedings, Springer-Verlag, 1996,
pp. 155{169. pp. 89{103.
[SK97b] B. Schneier and J. Kelsey, \Remote [YY97a] A. Young and M. Yung, \Kleptog-
Auditing of Software Outputs Using a raphy: Using Cryptography against
Trusted Coprocessor," Journal of Fu- Cryptography," Advances in Cryptol-
ture Generation Computer Systems, ogy | EUROCRYPT '97 Proceedings,
v.13, n.1, 1997, pp. 9-18. Springer-Verlag, 1997, pp. 62{74.
[SK98] B. Schneier and J. Kelsey, \Crypto- [YY97b] A. Young and M. Yung, \The
graphic Support for Secure Logs on Prevalence of Kleptographic Attacks
Untrusted Machines," The Seventh on Discrete-Log Based Cryptosys-
USENIX Security Symposium Pro- tems," Advances in Cryptology |
ceedings, USENIX Press, Jan 1998, CRYPTO '97 Proceedings, Springer-
pp. 53-62. Verlag, 1997, pp. 264{276.
[SK99] B. Schneier and J. Kelsey, \Secure Au-
dit Logs to Support Computer Foren-
sics," ACM Transactions on Informa-
tion and System Security, v. 1, n. 3,
1999, to appear.
[SSS+98] C. Salter, O. Saydjari, B. Schneier,
and J. Wallner, \Toward a Secure Sys-
tem Engineering Methodology," New
Security Paradigms Workshop 1998
Proceedings, IEEE Computer Society
Press, to appear.