Authenticating Secure Tokens Using Slow Memory Access

John Kelsey Bruce Schneier

{schneier,kelsey,schneier}@counterpane.com
Counterpane Systems, 101 East Minnehaha Parkway, Minneapolis, MN 55419

Abstract There is another class of applications for smart

cards—applications in which the value of a success-
We present an authentication protocol that allows a ful attack is much smaller. These cards might pro-
token, such as a smart card, to authenticate itself vide micropayment information, low-security access
to a back-end trusted computer system through an control, or act as payment vehicles in circumstances
untrusted reader. This protocol relies on the fact with low marginal cost of goods (pay television, pub-
that the token will only respond to queries slowly, lic transportation, etc). In these applications we are
and that the token owner will not sit patiently while less concerned with individual fraud, and more con-
the reader seems not to be working. This protocol cerned with an organized attack to create and dis-
can be used alone, with “dumb” memory tokens or tribute fake cards. Someone who sneaks onto the
with processor-based tokens. subway or watches a satellite movie without paying
isn’t going to affect the service provider’s bottom
line, but someone who is able to counterfeit access
tokens that allow everyone to sneak onto the subway
1 Introduction or watch the movie could collapse the entire system.
Hence, the primary threat is not from an isolated
Smart cards have been used in many applications attack against a single card, but an attack that can
that require that the data be secured from the card- be scaled to multiple cards.
holder. In the Modex stored-value smart card sys- The threat is from untrusted card readers that the
tem, for example, the smart card stores a particular user may stick his card into. In this paper, we pro-
monetary value. An attacker who can successfully pose a low-tech authentication protocol that is useful
change the value stored in the card can essentially in this sort of situation. Our protocol makes use of
print money.1 In GSM phones, smart cards provide what we will call a “slow memory device”: a device
identity information used to prevent cloning and in that responds to queries by revealing the contents of
billing. An attacker who can modify that informa- different memory locations, but one that necessarily
tion can charge cellular phone calls to another ac- takes several seconds to do so.
count [BGW98]. Smart cards used to protect satel-
lite television can be attacked to obtain free services The protocol relies on the fact that the cardholder
[McC96]. does not have infinite patience. If he puts his smart
card into a reader and nothing happens for several
These cards are vulnerable to a large class of at- seconds, he will likely pull the card out and try
tacks [And94, Sch97, Row97, Sch98], from reverse- again. If nothing happens again, he will find an-
engineering [AK96] and protocol failures [AN95] other reader. The slow response of the card ensures
to side-channel attacks [Koc96, Koc98, KSWH98, that a fraudulent reader can only do so much dam-
DKL+99] and fault analysis [BDL97, BS97]. In all of age before the cardholder removes his card.
these attacks, the attacker can defeat the security of
the card by breaching its secure perimeter and learn- This protocol makes no cryptographic assumptions,
ing the confidential information stored within. With and is independent of any cryptography that may or
reverse-engineering, the attacker defeats the tamper- may not be in the system. It can be implemented by
reisistance measures directly; with side-channel and itself, or in conjunction with cryptographic controls.
fault-analysis attacks, the attacker exploits weak- The rest of the paper is organized as follows. In Sec-
nesses in the physical security to learn information tion 2 we describe the slow memory device and its
within the secure perimeter. functionality. In Section 3, we describe our authen-
1 For other examples, see [CP93], [SK97], and [RKM99]. tication protocol. In Section 4 we discuss variants
and extensions to this basic protocol, and in Section (3) Terminal sends this information over an en-
5 we discuss applications. crypted link to the Trusted Device.

(4) Trusted Device generates a random challenge

and sends it back over the encrypted link to the
2 The Slow Memory Device Terminal. This challenge consists of a list of n
memory locations on the Token.
This protocol assumes the existence of a slow mem-
ory token. By this we mean a token—a smart card, (5) Terminal reads the n memory locations from
a Dallas Semiconductor iButton, etc.—that acts as the Token, XORs them all together, and sends
a memory device, but never responds to a request in the result back over the encrypted link to the
less than t seconds (t = 10, for the purposes of this Trusted Device.
example). It is impossible for a terminal to get more
information during that time; the token’s electronics (6) The Trusted Device verifies this information; if
are such that it simply cannot respond to requests it checks out, it believes that the Token is cur-
faster. rently inserted into the Terminal.

This memory token has m memory locations, each w Note that there are no cryptographic primitives in
bits wide (w = 64 for the purposes of this example). the protocol: the only mathematical operation in-
The token does not need a processor, nor does it volved is XOR. There are no encryption functions,
need to implement any cryptographic primitives in one-way hash functions, or message authentication
order to execute this protocol. codes used in the protocol.
The Token might have 1000 64-bit memory loca-
tions. Each time read request comes in, it takes ten
3 The Basic Protocol seconds to respond, and without reverse-engineering
the device and tampering with its internals, this
There are three parties in this protocol: can’t be made any faster. Assuming ten seconds per
communications exchange, and setting n = 1, steps
• The Token: The slow memory device. (2) and (3) take ten seconds, step (4) takes another
ten seconds, and step (5) takes another ten seconds.
• The Terminal: The untrusted card reader. This gives us a total of 30 seconds per transaction.
• The Trusted Machine: A trusted computer Now, this can be extended a little bit without the
connected to, and possibly remote from, the user knowing. A malicious Terminal might ignore
Terminal. the protocol completely, and simply query the Token
(repeat step (5)). Maybe the Terminal can perform
six queries instead of one, doubling the transaction
Our authentication protocol is simple. A user inserts
time, before the Token owner removes his card.
his Token into a Terminal. The Terminal now needs
to prove to a Trusted Machine that the Token is To provide adequate security, we need to account for
currently inserted into the Terminal. possible malicious behavior by the Terminal in how
many transactions are allowed, keeping the probabil-
The Terminal is only marginally trusted, and could
ity of success acceptably low even if most Terminals
be malicious. In order to complete the protocol cor- are corrupt.
rectly the Terminal must be connected, via a secure
data link, to a Trusted Device. The Trusted Device
keeps an exact copy of the contents of the Token; 3.1 Reasonable Values for n
this is a shared secret that the Terminal does not
know. Suppose the Token has m memory locations, that
Our protocol is as follows: each instance of the protocol requests the XOR of
n random locations, and that n << m. Assuming
(1) The holder of the Token inserts it into the Ter- an attacker eavesdrops on each authentication, he
minal. will learn the contents of n memory locations, not
all of them different, after each transaction. The
(2) Terminal reads the header information from the average number of authentications that the Token
Token. can accomplish before the attacker has a better than
0.5 chance of impersonating the Token (that is, being (1) The holder of the Token inserts it into the Ter-
able to respond correctly to a random query), is: minal.
(2) Terminal reads the header information from the
log(n)/(log(m) − log(m − n)) Token.

For example, for m = 1000 and n = 5, an attacker (3) Terminal sends this information over an en-
who eavesdrops on 322 authentications has a better crypted link to the Trusted Device.
than 0.5 probability of being able to impersonate the
(4) Trusted Device generates a random challenge
Token by answering a random challenge correctly.
and sends it back over the encrypted link to the
This, of course, is not the most effective attack. A Terminal. This challenge consists of a list of n
fraudulent Terminal will specifically query the To- memory locations on the Token.
ken to learn the memory locations that it does not
know. Hence, a malicious Terminal can learn the (5a) The Terminal sends the Token a request for the
entire contents of a Token in m/n queries. So for n memory locations.
the parameters above, a malicious terminal that con- (5b) The Token goes through the motions (and de-
ducts 100 fraudulant transactions will have a better lay) of sending it out internally, but only out-
than 0.5 probability of being able to impersonate puts the 32-bit CRC of the n requested memory
the Token. The Token owner, though, would have locations.
to be convinced to allow the Token to be used in 100
ineffectual transactions. (6) The Trusted Device verifies this information; if
it checks out, it believes that the Token is cur-
rently inserted into the Terminal.
4 Extensions
Each memory location can now be 32 bits long, and
even one unknown memory location in the query
4.1 A Button on the Token string prevents an attacker from succeeding in an
impersonation attack. Note that this system works
Ideally, we’d have some user-interface mechanism on best if there are lots of Terminals under different
the Token, like a pushbutton. The Token is willing to entities’ control. If a Token only interacts with one
perform only once per button-push. Alternatively, Terminal every time it executes the protocol, then
the Token buzzes or lights up once per memory query this system doesn’t work very well.
answered. This would make multiple queries much
harder for the Terminal to make, since the Token
owner could detect that the protocol was not pro- 4.4 Incrementing Values in the Token
ceeding as specified. and Trusted Device

If we’re worried about an attacker reverse-

4.2 Reducing Storage Requirements
engineering and making lots of copies of the Token,
in the Trusted Device then we have each query of memory location cause
that memory location to increment by one, mod-
As written, the Trusted Device must store a com- ulo 232 , or rotate left one bit, or whatever else is
plete copy of the Token’s memory location. If this cheap enough to be implemented. Note that this up-
is too much memory, the Trusted Device could store date must occur on both the Token and the Trusted
the Token’s ID information and a secret key known Device, and assumes that there is either only one
only to it (and not the token). The Token’s meme- Trusted Device or that the different Trusted Devices
ory locations would then be the memory address en- can communicate with each other securely to syn-
crypted with this secret key, and would have to be chromize these updates.
loaded onto the Token by the Trusted Device.
This variant does not help against impersonation at-
tacks. What it does do is to make continued synchro-
4.3 CRC Hardware on the Token nization of those counterfeit Tokens very expensive
and complex. Now, if any memory location in the
If the Token can afford CRC hardware, then queries challenge string has been changed, the duplicated
can be handled using this alternate protocol: Token fails to give the correct answer.
4.5 Reducing the Amount of Trust in 7 Conclusions
the Trusted Device
Security countermeasures must be commensurate
A given Trusted Device may be only partially with the actual threats. In this paper we have pre-
trusted. Instead of having it store a complete list- sented a low-tech security solution that helps miti-
ing of the Token’s memory locations, it can be given gate a specific threat, and can be used in conjunction
a series of precomputed challenges in order and the with other cryptographic countermeasures.
right responses to be expected. (If we use the previ-
ous extension, this will work only for small numbers
of different Trusted Devices.) 8 Acknowledgments
The authors would like to thank Chris Hall for his
helpful comments. Additionally, the authors would
5 Security Analysis like to thank Niels Ferguson, who broke one of our
MACs and subsequently inspired this research.
The slow memory protocol is designed to frustrate a
particular kind of attack. It is intended to provide
security against an insecure reader trying to collect References
enough information from a token to be able to im-
personate it. It does not provide security against [And94] R. Anderson, “Why Cryptosystems
someone reverse-engineering the token and cloning Fail,” Communications of the ACM, v.
it (although the extension described in Section 4.2 37, n. 11, Nov 1994, pp. 32–40.
considerably frustrates that attack in most circum-
stances), nor does it provide security in the event [AK96] R. Anderson and M. Kuhn, “Tamper Re-
that the back-end database (the Trusted Device in sistance – A Cautionary Note,” Second
the protocol) is compromised. USENIX Workshop on Electronic Com-
merce Proceedings, USENIX Press, 1996,
A more extensive security analysis will be in the final pp. 1–11.
paper.
[AN95] R. Anderson and R. Needham, “Pro-
gramming Satan’s Computer,” Com-
puter Science Today: Recent Trends and
6 Applications Developments, LNCS #1000, Springer-
Verlag, 1995, pp. 426–440.

A complete discussion of applications, along with [BCK96] M. Bellare, R. Canetti, and H. Kar-
their security ramifications, will be in the final pa- wczyk, “Keying Hash Functions for Mes-
per. sage Authentication,” Advances in Cryp-
tology — CRYPTO ’96 Proceedings,
The most obvious applications are things like non-
Springer-Verlag, 1996, pp. 1–15.
duplicable keys for locks and alarms, free passes or
one-day (or k-day) coins, and login keys. In these [BDL97] D. Boneh, R.A. Demillo, R.J. Lip-
applications, we are less concerned with a single per- ton, “On the Importance of Check-
son hacking the authentication device than the same ing Cryptographic Protocols for Faults,”
single person being able to distribute a large number Advances in Cryptology—EUROCRYPT
of them. ’97 Proceedings, Springer-Verlag, 1997,
One of the most beneficial aspects of this protocol pp. 37–51.
is that it works well with cryptography, even though [BGW98] M. Briceno, I. Goldberg, D. Wagner,
it has no cryptography itself. We can use a message “Attacks on GSM security,” work in
authentication code such as HMAC [BCK96] in ad- progress.
dition to this protocol, and if the MAC breaks, the
memory trick still works. Or course, all Trusted De- [BS97] E. Biham and A. Shamir, “Differen-
vices must be trusted with copies of the memory tial Fault Analysis of Secret Key Cryp-
maps. tosystems,” Advances in Cryptology—
 CRYPTO ’97 Proceedings, Springer-
Verlag, 1997, pp. 513–525.
[CP93] D. Chaum and T. Pederson, “Wallet
Databases with Observers,” Advances in
Cryptology — CRYPTO ’92 Proceed-
ings, Springer-Verlag, 1993, pp. 391–407.
[DKL+99] J.-F. Dhem, F. Koeune, P.-A. Leroux,
P. Mestre, J.-J. Quisquater, and J.-L.
Willerns, “A Practical Implementation
of the Timing Attack,” CARDIS ’98
Proceedings, Spriger-Verlag, 1999, to ap-
pear.
[Koc96] P. Kocher, “Timing Attacks on Im-
plementations of Diffie-Hellman, RSA,
DSS, and Other Systems,” Advances in
Cryptology—CRYPTO ’96 Proceedings,
Springer-Verlag, 1996, pp. 104–113.
[Koc98] P. Kocher, “Differential
Power Analysis,” available online from
http://www.cryptography.com/dpa/.
[KSWH98] J. Kelsey, B. Schneier, D. Wagner, and
C. Hall, “Side Channel Cryptanalysis of
Product Ciphers,” ESORICS ’98 Pro-
ceedings, Springer-Verlag, 1998, pp. pp
97–110.
[McC96] J. McCormac, European Scrambling Sys-
tems, Waterford University Press, 1996.
[RKM99] C. Radu, F. Klopfert, and J. De
Meester, “Interoperable and Untrace-
able Debit-Tokens for Electronic Fee
Collection,” CARDIS ’98 Proceedings,
Springer-Verlag, 1999, to appear.
[Row97] T. Rowley, “How to Break a Smart
Card,” The 1997 RSA Data Security
Conference Proceedings, RSA Data Se-
curity, Inc., 1997.
[Sch97] B. Schneier, “Why Cryptography is
Harder than it Looks,” Information Se-
curity Bulletin, v. 2, n. 2, March 1997,
pp. 31–36.
[Sch98] B. Schneier, “Cryptographic Design Vul-
nerabilities,” IEEE Computer, v. 31, n.
9, September 1998, pp. 29–33.
[SK97] B. Schneier and J. Kelsey, “Remote
Auditing of Software Outputs Using a
Trusted Coprocessor,” Journal of Future
Generation Computer Systems, v.13,
n.1, 1997, pp. 9–18.