Table Of ContentAuthenticating 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-
ful attack is much smaller. These cards might pro-
We present an authentication protocol that allows a
vide micropayment information, low-security access
token, such as a smart card, to authenticate itself
control, or act as payment vehicles in circumstances
to a back-end trusted computer system through an
withlowmarginalcostofgoods(paytelevision,pub-
untrusted reader. This protocol relies on the fact
lictransportation, etc). Intheseapplicationsweare
that the token will only respond to queries slowly,
less concerned with individual fraud, and more con-
andthatthetokenownerwillnotsitpatientlywhile
cerned with an organized attack to create and dis-
the reader seems not to be working. This protocol
tribute fake cards. Someone who sneaks onto the
can be used alone, with “dumb” memory tokens or
subway or watches a satellite movie without paying
with processor-based tokens.
isn’t going to affect the service provider’s bottom
line, but someone who is able to counterfeit access
tokensthatalloweveryonetosneakontothesubway
1 Introduction
orwatchthemoviecouldcollapsetheentiresystem.
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
thatrequirethatthedatabesecuredfromthecard- 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
posealow-techauthenticationprotocolthatisuseful
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
thatrespondstoqueriesbyrevealingthecontentsof
billing. An attacker who can modify that informa-
differentmemorylocations, butonethatnecessarily
tion can charge cellular phone calls to another ac-
takes several seconds to do so.
count [BGW98]. Smart cards used to protect satel-
litetelevisioncanbeattackedtoobtainfreeservices 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]andfaultanalysis[BDL97,BS97]. Inallof
age before the cardholder removes his card.
theseattacks,theattackercandefeatthesecurityof
thecardbybreachingitssecureperimeterandlearn- This protocol makes no cryptographic assumptions,
ingtheconfidentialinformationstoredwithin. With andisindependentofanycryptographythatmayor
reverse-engineering,theattackerdefeatsthetamper- maynotbeinthesystem. Itcanbeimplementedby
reisistance measures directly; with side-channel and itself,orinconjunctionwithcryptographiccontrols.
fault-analysis attacks, the attacker exploits weak-
Therestofthepaperisorganizedasfollows. InSec-
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-
1Forotherexamples,see[CP93],[SK97],and[RKM99]. tication protocol. In Section 4 we discuss variants
Form SF298 Citation Data
Report Date
Report Type Dates Covered (from... to)
("DD MON YYYY")
N/A ("DD MON YYYY")
01011999
Title and Subtitle Contract or Grant Number
Authenticating Secure Tokens Using Slow Memory Access
Program Element Number
Authors Project Number
Task Number
Work Unit Number
Performing Organization Name(s) and Address(es) Performing Organization
Information Assurance Technology Analysis Center (IATAC) Number(s)
3190 Fairview Park Drive Falls Church VA 22042
Sponsoring/Monitoring Agency Name(s) and Address(es) Monitoring Agency Acronym
Monitoring Agency Report
Number(s)
Distribution/Availability Statement
Approved for public release, distribution unlimited
Supplementary Notes
Abstract
Subject Terms
Document Classification Classification of SF298
unclassified unclassified
Classification of Abstract Limitation of Abstract
unclassified unlimited
Number of Pages
6
Form Approved
REPORT DOCUMENTATION PAGE
OMB No. 074-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions,
searching existing data sources, gathering and maintaining the data needed, and completing and reviewing this collection of information. Send
comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden to
Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-
4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503
1. AGENCY USE ONLY (Leave 2. REPORT DATE 3. REPORT TYPE AND DATES COVERED
blank) 1/1/99 Report
4. TITLE AND SUBTITLE 5. FUNDING NUMBERS
Authenticating Secure Tokens Using Slow Memory Access
6. AUTHOR(S)
Not provided
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
REPORT NUMBER
Information Assurance
Technology Analysis Center
(IATAC)
3190 Fairview Park Drive
Falls Church, VA 22042
9. SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING / MONITORING
AGENCY REPORT NUMBER
Defense Technical
Information Center
DTIC-AI
8725 John J. Kingman Road,
Suite 944
F11t.. SBUPePlLvEoMEiNrT,A RYV AN O TE2S2060
12a. DISTRIBUTION / AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE
A
13. ABSTRACT (Maximum 200 Words)
We present an authentication protocol that allows a token, such as a smart card, to
authenticate itself to a back-end trusted computer system through an untrusted reader.
This protocol relies on the fact that the token will only respond to queries slowly, and
that the token owner will not sit patiently while the reader seems not to be working. This
protocol can be used alone, with "dumb" memory tokens or with processor-based tokens.
14. SUBJECT TERMS 15. NUMBER OF PAGES
Authentication
16. PRICE CODE
17. SECURITY 18. SECURITY 19. SECURITY CLASSIFICATION 20. LIMITATION OF
CLASSIFICATION CLASSIFICATION OF ABSTRACT ABSTRACT
OF REPORT OF THIS PAGE Unclassified Unlimited
Unclassified Unclassified
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. Z39-18
298-102
andextensionstothisbasicprotocol,andinSection (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
andsendsitbackovertheencryptedlinktothe
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
amemorydevice,butneverrespondstoarequestin the result back over the encrypted link to the
less than t seconds (t = 10, for the purposes of this Trusted Device.
example). Itisimpossibleforaterminaltogetmore
(6) The Trusted Device verifies this information; if
informationduringthattime;thetoken’selectronics
it checks out, it believes that the Token is cur-
are such that it simply cannot respond to requests
rently inserted into the Terminal.
faster.
Thismemorytokenhasmmemorylocations,eachw
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-
3 The Basic Protocol tions. Each time read request comes in, it takes ten
secondstorespond,andwithoutreverse-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.
•
Now, this can be extended a little bit without the
The Trusted Machine: A trusted computer
• user knowing. A malicious Terminal might ignore
connected to, and possibly remote from, the
theprotocolcompletely,andsimplyquerytheToken
Terminal.
(repeat step (5)). Maybe the Terminal can perform
six queries instead of one, doubling the transaction
Ourauthenticationprotocolissimple. Auserinserts
time, before the Token owner removes his card.
hisTokenintoaTerminal. TheTerminalnowneeds
to prove to a Trusted Machine that the Token is Toprovideadequatesecurity,weneedtoaccountfor
currently inserted into the Terminal. possible malicious behavior by the Terminal in how
manytransactionsareallowed,keepingtheprobabil-
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
an attacker eavesdrops on each authentication, he
(1) The holder of the Token inserts it into the Ter-
will learn the contents of n memory locations, not
minal.
all of them different, after each transaction. The
(2) Terminalreadstheheaderinformationfromthe average number of authentications that the Token
Token. canaccomplishbeforetheattackerhasabetterthan
0.5chanceofimpersonatingtheToken(thatis,being (1) The holder of the Token inserts it into the Ter-
able to respond correctly to a random query), is: minal.
(2) Terminalreadstheheaderinformationfromthe
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.
than0.5probabilityofbeingabletoimpersonatethe
(4) Trusted Device generates a random challenge
Token by answering a random challenge correctly.
andsendsitbackovertheencryptedlinktothe
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
(5a) TheTerminalsendstheTokenarequestforthe
know. Hence, a malicious Terminal can learn the
n memory locations.
entire contents of a Token in m/n queries. So for
theparametersabove,amaliciousterminalthatcon-
(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
putsthe32-bitCRCofthenrequestedmemory
the Token. The Token owner, though, would have
locations.
tobeconvincedtoallowtheTokentobeusedin100
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’dhavesomeuser-interfacemechanismon
best if there are lots of Terminals under different
theToken,likeapushbutton.TheTokeniswillingto
entities’ control. If a Token only interacts with one
perform only once per button-push. Alternatively,
Terminal every time it executes the protocol, then
theTokenbuzzesorlightsuponcepermemoryquery
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
cheapenoughtobeimplemented.Notethatthisup-
istoomuchmemory,theTrustedDevicecouldstore
datemustoccuronboththeTokenandtheTrusted
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-
TrustedDeviceorthatthedifferentTrustedDevices
orylocationswouldthenbethememoryaddressen-
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.
Thisvariantdoesnothelpagainstimpersonationat-
tacks.Whatitdoesdoistomakecontinuedsynchro-
4.3 CRC Hardware on the Token nization of those counterfeit Tokens very expensive
and complex. Now, if any memory location in the
IftheTokencanaffordCRChardware, thenqueries 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-
ingoftheToken’smemorylocations,itcanbegiven gateaspecificthreat,andcanbeusedinconjunction
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.
Theslowmemoryprotocolisdesignedtofrustratea
particular kind of attack. It is intended to provide
References
security against an insecure reader trying to collect
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.AndersonandM.Kuhn,“TamperRe-
that the back-end database (the Trusted Device in sistance – A Cautionary Note,” Second
the protocol) is compromised. USENIX Workshop on Electronic Com-
merceProceedings,USENIXPress,1996,
Amoreextensivesecurityanalysiswillbeinthefinal
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,“KeyingHashFunctionsforMes-
per. sageAuthentication,”AdvancesinCryp-
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,wearelessconcernedwithasingleper- ton, “On the Importance of Check-
sonhackingtheauthenticationdevicethanthesame ingCryptographicProtocolsforFaults,”
singlepersonbeingabletodistributealargenumber AdvancesinCryptology—EUROCRYPT
of them. ’97 Proceedings, Springer-Verlag, 1997,
pp. 37–51.
One of the most beneficial aspects of this protocol
isthatitworkswellwithcryptography,eventhough
[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
DatabaseswithObservers,”Advancesin
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, toap-
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,EuropeanScramblingSys-
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,“CryptographicDesignVul-
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
TrustedCoprocessor,”Journal of Future
Generation Computer Systems, v.13,
n.1, 1997, pp. 9–18.
